Reflections on Software Engineering

Over the past few months, I have been learning a great deal about various tools for use in software engineering as well as the principles behind their use. Of course, the actual use of these tools tends to take precedence in most of these blog entries since that tends to be the more exciting topic. Actually doing something is more glamorous than sitting around discussing theory. However, every once in a while there is the desire to relax and look back on these general principles. This is particularly true for students, who can use the study as a means of procrastinating on other assignments while still doing something academically related.

For these reasons, I have started reflecting on what I have done over these months and have found some questions that I have learned to answer through the work I have done.

1: How does an IDE differ from a build system?

An IDE allows developers to write, compile, and test code on their own systems. Build systems provide standardized compilation, testing, packaging, and automated quality assurance that works across platforms and IDEs. IDEs are suited for individual developers; build systems allow for efficient collaboration between project members. All functions of a build system should be IDE-independent.

2: What is the difference between using == and equals to test equality?

When used with objects, == tests object identity, while the equals method tests object value. As a result, == should be used to check if objects are the same—that is, if one object literally is the other—while equals should be used to determine if two objects have the same value.

3: In what order will Ant resolve dependencies?

Ant will not run a target until all dependencies for that target have been resolved. As a result, the target order will be like a stack in which the first targets are the last to be executed.

4: Does 100% coverage from a white-box test mean that the code is free of bugs?

No; 100% coverage only indicates that the test or tests went through every line of code. This result does not mean that there were no errors in the operation of the application.

5: If the trunk of an SVN project is always supposed to be a working version of the project, why is it necessary to run the “verify” target upon checkout of an updated version?

Running the “verify” target ensures that the updated version does in fact work. The fact that the trunk should always be a working version does not necessarily mean that it will always be a working version. If this initial use of “verify” does not produce any errors, then any errors that are produced after edits to the code must be due to those edits, making resolving those problems easier. However, if the trunk does not pass the “verify” target, then the trunk should be fixed before development can progress further.