]
]Any decent software developer will use a repertoire of useful tools. The better your tools, and the better you know how to use them, the more productive you can be. Of course, you can do the project without using any special tools, but you will probably lose out to teams that do.
Using an Integrated Development Environment (IDE) such as Visual Studio (commercial), NetBeans (free, for Java), IDEA (for Java, commercial, free education licenses may be available), or Eclipse (free, works with multiple programming languages) is a must for today's programmers. Nobody uses notepad any more for writing code! There was a time not long ago when notepad-like text editors could show more productivity than cumbersome IDEs, but those days are gone. Especially for a novice such as yourself, using an IDE is highly recommended. Today's IDEs are loaded with features (and some of them are actually useful!). Keep looking for smart ways to use your IDE - a good way to start is to learn the keyboard shortcuts for frequently used features.
A very much under-used IDE feature is the debugger. Learn how to stop execution at a pre-defined "break point", how to "step through" the code one statement at a time, inspect intermediate values of a variable at various points, etc. Using the debugger to do all this is a much superior way to inserting ad hoc print statements.
Modern IDEs already have some automatic refactoring and code analysis capabilities. But you may also wish to look at more powerful refactoring add-ons such as Re-sharper (a commercial plugin for Visual Studio, free education license are available)
Profilers are indispensable for effective performance optimizations. They help you pin point actual performance bottlenecks in your program. Examples: CLR Profiler, DotTrace
Some tools help you to gather various metrics about the code, such as the LOC written by each team member. E.g., Microsoft LOC counter.
At a minimum, you should use a source code revision control tool such as CVS (a Windows client for CVS is TortoiseCVS), SVN (a Windows client for SVN is TortoiseSVN), or SourceSafe.
Further resources:
Another very much under-used tool is the word processor. See here for a short guide on how to use MSWord more effectively. Tools such as MSVisio (commercial) and ArgoUML (free) can help you with drawing diagrams. Some IDEs let you generate UML diagrams from the source code.
You must automate as much of testing as possible. Unit testing frameworks such as JUnit and NUnit can help in unit testing as well as other types of testing (integration testing, regression testing, system testing).
For most products, it is well worth writing your own test driver for specialized system testing.
Some tools can help you check conformance with standards, auto-reformat of code, and other types of quality assurance of the source code.
E.g., FXCop can be used to enforce coding standards in .NET assemblies
Several types of tools can help you to collaborate easily with your team members. Some simple examples include GoogleDocs, Wikis, and mailing groups.
Tools such as MSProject helps you in project planning and tracking. Trac is an example of a server based project tracking (among other things) tool.
Free project hosting services such as Google code or Sourceforge can be used to host and manage your project online. These services usually come with tools for issue tracking, code versioning, discussion forums etc. but impose some restrictions such as the code has to released to the public. Alternatively, you can use free non-commercial use accounts provided by commercial project hosting services.
Most modern IDEs have in-built support for automated project building (look for a "build" button on your favorite IDE). Specialized build tools include Make and Ant.
Bugs (and other issues such as feature requests) go through a life cycle. For example, a bug can be in different life cycle stages such as "raised", "assigned", "fixed", "reopened" etc. Tools such as Bugzilla and Trac help is in tracking bugs (and other similar issues).
There are tools/libraries to help your code produce an audit trail (a log file) while in operation. Such tools can be easily configured to control the level of details produced. For example, when you suspect a bug in the code that affects the operation in subtle ways, you could increase the level of details in the log file to try and catch the bug.
Using a plethora of tools does not guarantee an increase in productivity or a successful project. It depends on how well you choose your tools, and how well you integrate tools into your work. If you want to maximize the potential of the tools, you need to integrate them into your work in such a way that it flows with your team's dynamics. On the other hand, deciding how to partition your code into packages, which directory to place documentation, who does the integration, how to resolve bugs during system testing etc. are things tools cannot help you with.
While each student must learn the basic usage of each project tool selected, it is unrealistic to expect everyone to learn all project tools in depth. Instead, become a "jack of all tools, a master of at least one". A way to formalize this approach is to appoint one team member as the "guru" for each tool (see here for more about gurus). For example, the testing guru can look for the best testing tools to adapt, learn the selected testing tools in depth, hold a small session to teach the tool to other team members, help other team members to troubleshoot the tool, etc.
Your course instructor will not specify all the tools you should use. It is up to you to find tools that enhance your productivity. If the thought "there must be a smarter way of doing this!" ever crosses your mind during a project task, it is time to look for a tool.
If you find yourself writing code to do a common task (e.g., file handling, sorting, etc.), look for a library that provides that function.
Check the license first (it may not be free). Be extra careful if you are developing the product for an external client who intends to use it for commercial purposes.
While it may be OK to use evaluation versions of tools (as long as the evaluation period covers the project duration), note that your time spent on learning the tool will be lost unless you buy the tool later. On the other hand, incorporating time-limited evaluation versions of libraries into your product is not recommended; it will prevent the archiving of your product for future reference. Be wary of libraries that require installing, as this might cause problems if the product demo is to be done in a separate PC. If in doubt, check with the instructor first.
Be wary of adopting any old tool/library you find on the Internet. It is safer to stick with stable and established tools/libraries (such as those released by Apache Software Foundation). Do not believe in all the marketing claims made by the tool/library authors. Check the forum/buglist of the tool/library. See how many outstanding issues remain, how fast the developers have responded to user queries, and how long the tool/library has been around.
Be wary of bleeding edge tools (e.g., beta releases) - as you cannot afford to spend energy on battling an unstable/buggy tool.
By the same token, be wary of using any old code sample you find from the Internet as they could very well contain bugs.
Whenever possible, choose a common set of tools for the whole team to use. This increases the total expertise team has on a given tool - something very much in short supply in a student team.
Most tools are about automating things. In general, try to automate as much of the project work as possible.
Imagine you wanted to change a method name. You simply right click the method name and specify the new name, and all the references to that method are updated automatically. Then you press another button, which automatically compiles the code, links the code, builds the executable, runs the tests, updates the documentation, packages the product in to a distributable installer, uploads the installer to the website, updates the SCM system, updates the project tracking tool, and emails all users about the update. Now that's automation!
Sometimes you have to create your own tools. A specialized test driver is one example for such a tool. But do not reinvent the wheel.
In addition to the productivity gained by using tools, you can usually earn extra credit for being a good tool user if you document your use of tools.
Things you could document include:
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
 |
Sharing this book helps too! |
---| This page is a part of the online book Tips to Succeed in Software Engineering Student Projects V1.9, Jan 2009, Copyrights: Damith C. Rajapakse |---