- Formulate the hypothesis.
- Conduct the experiment, collect the results and verify if the hypothesis is correct.
- If desirable results are not obtained, make changes to certain parameters, and repeat.
This is how we test our software too:
- Formulate what a program is intended to do.
- Run the program, collect the results and check if it matches the expectations.
- If not, tweak the program code or input, and repeat.
While the association of software engineering to the scientific side may be a bit obvious, it is the artistic elements that are difficult to relate to. An obvious question is - what is artistic about lines of program code or instructions that are always difficult to read and comprehend? In my opinion, the artistic elements of software engineering are more in the design of the program than in the actual code itself, however, that is not to say that good code doesn't have any artistic elements.
A program that considers the following design elements is generally considered more artistic than one that doesn't.
- Consider a component-based design that follows the high-cohesion-low-coupling paradigm, with a well defined API that specifies the component contract.
- While designing classes, consider the responsibility of each class and ensure that a class doesn't do too much or too little.
- Follow a general naming convention for components and classes. A good guideline for the MVC (Model-View-Controller) architectural style is to have classes with the names such as - xxxxView, xxxController, xxxManager. Classes that are a part of a component that offers a service could be named as xxxService; as an example - DatabaseService, LoggingService etc.
- Consider using design patterns when possible, as they offer a consistent - and often familiar - solution to a known problem.
- Have a long-term view while designing the components and classes. Remember, a good artist paints what she sees, whereas a great one paints from her imagination, what no one else sees.
- Follow the same structure while laying out the source code. Always have a comment block for every class and method.
- Avoid methods that are too long. A general guideline is to have methods that generally fit within a screen length for the new high-resolution monitors.
- While doing defensive null checks, consider having return statements when the object is null, instead of having deeply nested "if" statement that contain logic when the object is not null.
- Consider using a static analysis tool, so that consistent coding guidelines and good coding practices are enforced throughout the code.
While doing all the above may not make your program work any better than it currently does, it would certainly improve the readability and maintainability of the code, enabling others to understand it and extend it. And, if others can understand and relate to your work, then there is definitely something artistic about it.
No comments:
Post a Comment