Sharing this book helps too!
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, most student projects can be done without using too many special tools, but such teams fall behind teams that do use appropriate tools.
Using an Integrated Development Environment (IDE) such as Visual Studio, NetBeans, and Eclipse is a must for today's programmers. Nobody codes in notepad any more! 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 like 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 licenses are available).
Some tools can check style conformance, auto-format code, and do other types of quality assurance of the source code. E.g. FXCop can be used to enforce coding standards in .NET assemblies.
Profilers are indispensable for effective performance optimizations. They help you pin point actual performance bottlenecks in your program. IDEs such as the latest Visual Studio have in-built profilers. Other examples: CLR Profiler, DotTrace
Some IDEs such as the latest Visual Studio and other speicalised tools such as Microsoft LOC counter help you gather various metrics about the code, such as the LOC written by each team member.
Software Configuration Management (SCM) is another important aspect of a non-trivial project. At a minimum, you should use a source code revision control tool such as Subversion (a Windows client for Subversion is TortoiseSVN) to keep track of code versions. If you are open-sourcing your project, you can use the SVN server provided for free by Google Code Project Hosting.
Institute check-in policies to enforce proper commenting, tagging, and to keep the build unbroken.
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 specialised system testing.
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 help you in project planning and tracking. Trac is an example of a server-based project management tool.
Free project hosting services such as Google Code Project Hosting (GCPH) 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, for example, only open-source projects are allowed on GCPH and Sourecforge. Alternatively, you can use free-for-non-commercial-use accounts provided by commercial project hosting services such as Pivotal Tracker and Zoho.
Most modern IDEs have in-built support for automated project building (look for a 'build' button on your favourite IDE). Specialised 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).
It is good to enforce the use of an issue tracker to record bugs you discover in others' code because it pressurises everyone to produce better quality code (because no one wants to see many bugs recorded against their name). Some issue trackers can be used to record project tasks (not just issues), too, resulting in an automatic record of what each person contributed to the project.
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. If you want to maximise the potential of tools, you should use the right tools and integrate them into your work in such a way that it flows with your team's dynamics. On the other hand, tools cannot help you much in decisions such as how to partition your code into packages, in which directory to place documentation, who does the integration, how to resolve bugs during system testing, etc.
While each student must learn basic usage of each tool selected, it is unrealistic to expect everyone to learn all of them in depth. Instead, become a 'Jack of all tools, a master of at least one'. A way to formalise this approach is to appoint one team member as the 'guru' for each tool (see tip 5.5 for more about gurus).
Your instructor will not specify all the tools you can 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.
Be wary of adopting any old tool/library you find on the Internet. 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; for one thing, 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 on a different PC. If in doubt, check with the instructor first.
It is safer to stick with stable and established software (such as those released by Apache Software Foundation). Do not believe in all the claims made by the tool/library authors. Check the forum/buglist of the software. See how many outstanding issues remain, how fast the author has responded to user queries, and how long the software has been around.
Be wary of bleeding edge tools (e.g. beta releases) - as you cannot afford to spend energy on battling an unstable 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 in-house expertise of each tool - something very much scarce 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 want 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 specialised test driver is one example of 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 from the free online book Practical Tips for Software-Intensive Student Projects V3.0, Jul 2010, Author: Damith C. Rajapakse |---