Under my point of view, BMC Remedy Developer Studio is young. Despite it comes from the old administrator, it presents the main characteristics of a young software. The main flaw, there are a lot of missing features. The good side, there’s a lot of thing to improve and the product evolves quick between versions.
In this post I will comment some points I think that the developer studio should have. Those are different from any list you have seen since I’m a lover of best practices.
Unitary Automatic Testing
Nowadays there is no programming languages that doesn’t posses a unitary testing framework. For those who don’t know what is a unitary test, it is a simple test where you can check some particular part of your code. So when you create a new function, you can create some unitary tests indicating some input values and the expected output. At every compilation the framework tests the automatic testing and if some function starts to malfunction, then an alarm is raised.
This concept would be very useful on an environment like ARS, where the developing can be categorized as spaghetti code. In spaghetti code it is very easy to break something at another part of the program were you improve some function (like when you pull and spaghetti end, another end at the other part of the plate disappears. So to have an automated test would be very useful.
The first critic to my desire can be: “Remedy is not programming, it’s developing. And the unitary test concept doesn’t fit well”. I think that it fits. I explain my concept of a test unit:
- First create a test environment, that is: a definition of data contained at database. I mean, I can create a controlled environment where the form I want to test has three requests with known values.
- Second define a set of actions: Each action is a test itself. For instance I can perform a read action with a determined qualification and a particular user. Or I can test a service action, or a set action, etc.
- Third, for each action define the expected result. For instance, for the read action, I expect to receive only one request. Or for a set action I expect to create a new request with one particular value at some field.
This is an example of an automated unitary testing for filters. The same can apply for other elements like active links or escalations.
Best Practices Auditor
A best practices auditor is an element that check your definition to look for bad practices. I know that you currently have the warnings and the analyzer. Those two are great, but the concept I’m thinking about is much more complex.
I’m think in a naming check, that your company can configure. For instance you can check for the use of “_###” pattern at the end of your filter names, where the number is the execution order. And you can forbid or force this naming strategy. Or you can check if the naming convention uses camelcase. Or you can check if a lot of sequential filters use the same qualification, and those must be inside a guide. Or you can check that the same code is repeated on several forms and your company rule is to share the workflow. Or you can force to comment all objects before updating.
Using a complex and advanced auditor means that you can configure your company rules and force your team to follow them.
Predefined Development Schemas
There are some actions that are repeated several times at developing. For instance, when I add a field that references another form (like the department name in an employees form) I do a lot of actions like: creating a filed to store the Entry ID. Creating active links to populate the entry ID from the name. The same with filters. A check with filters about the entry id and the name. A menu to show all the names. Etc. I do it mechanically, and always using the same elements. It would be great to have a wizard that allows you to create a reference menu field, and it creates all the other elements. It could even ask you what filed should be copied at every update.
This will not only make developers life easier, it will also create a library of code telling developers the best way to achieve things.
Synchronizing Teams
Currently the only way to interact with other developers at the same server is protecting an object, preventing other developers to work with the same object. For me that isn’t enough. It would be great to know what elements have other developers opened. Even internal messaging would be great.
Step by step debugging
The mother of all my wishes. I know that it exists an step by step debugging tool, but it is command based. In fact I think that the most desired tool would be an step by step simulator, where you can check how the values at the fields change.
Final comments
Well, this is only my opinion. I think that the Developer Studio has still a long way to travel and it can be an outstanding tool, reaching the state-of-the-art of development tools. But I know that this is like writing to Santa. Who knows? maybe this Christmas, we could receive a good present.
Excellent article although there is one core feature that I think is missing. Now that we have the Overlays functionality, the ability to compare the Overlay and Base object within Developer Studio is vital, and missing.
I would like to see a single-click ‘Compare’ option providing the ability to immediately see the differences between a Base and Overlay object – specifically for upgrades and Overlay reconciliation, this would be a real time saver as you could identify whether workflow has been overlaid unnecessarily.
Yes! There are a lot of lacks in the field of overlays. But if I say that the developer studio is young, then the overlays are a baby. Let them to upgrade the product a couple of years!