This is the second part of the article, if you haven’t read the first part yet you can find it here.
Breaking up Code
Do you recognize this, all code is found in a couple of very large files a giant switch statement that handles everything needed. It amazes me that people code in this fashion, like they were trying to beat a record in the most amounts of lines in one singe file.
I don’t know about you, but I find these methods to be a bad practice. Not only does the amount of code make it far harder to read, debug and maintain. It’s so much cleaner and better in pretty much every way to break up the code into functions or/and classes.
If you’re coding something in PHP, it might be wise to put all your database related functions in a file called dbFunctions.php. This makes it easier to maintain, and you can easily find the code needed.
The pros with doing it in this way can be concluded to the following points:
- It gains teamwork productivity. If code is broken up into smaller chunks, you can then assign it to various team members to work on. In this way you won’t have some team developers waiting for the other to finish before they can start working on their assignment.
- As I mentioned before, this makes your code much cleaner and easier to read.
- Using this method will make your code more reusable, and minimize unnecessary redundancy. You can use the already written functions and classes again and again. You just need to have it written once, include the module/file and you’re ready to go. If you later on need to change or add something to how one of the components work. You’ll just have to alter one file.
At the start of a project, you should sit down and spend some time on planning how you’re going to break up the code into smaller chunks/components.
Usually you need to sketch it down, and draw some lines between the different components to get a better picture of which components are depended of which, and what components should have a higher priority. As it not that good to have coded a bunch of components that depend on two larger components that doesn’t exist yet and you cannot test it.
A good idea is to assign an individual to be responsible for a specific component; the person will then have to make sure that the code for the component works.
Another good thing to do, is to have the job as the build/development manager, the person would have to make sure that all the components work with each other and make sure that the work on the other components is working smoothly.
Using a Standard Directory Structure
As bad as it is to have giant files, it’s also not wise to not have a structured directory where your files/components will be located. Having all the files in one single directory can be messy, and you have to count on the mess increasing the more files you have.
So work out how you’ll organize the files, and make sure that all the team members knows about it at any given time. Have the tree structure of the layout printed out and put on the wall if that’s necessary as long as you all know how it works.
Sharing In House functions, Documentation
As you develop functions libraries, you must make them available to the other programmers on your team. It’s not uncommon for each programmer to develop their own database, date and debug functions which I see as a big waste of resources. By making the functions available you save a lot of time and the productivity increases as the others can reuse the code.
But they are available for everyone in my developing directory you might say, yeah well how often do you spend time going through the directories looking for a function that you might need?
You should adopt a system for documenting the in house function libraries, where each developer can check if there already is a function for that available.
Implementing Version Control
Version Control systems works somewhat as a central repository or archive and supply a controlled interface for accessing and sharing your code, and if you need documentation.
So why should you use this? Well the reasons are many. Imagine that two coders are working on the same file, Jim and Sara. Sara adds a chunk of code to the file but Jim accidentally overwrites her changes with his as he didn’t know that there was a newer version of the file at the time.
Another situation, you perform some major changes to a file to find that the code isn’t working that well and find yourself struggling with getting it to the way it was before.
These problems can be solved if you use a version control system, these systems can track changes to each file found in the repository. So can both see the current state of the file and how it looked like at any given moment in the past. The issue with two programmers editing a file at the same time is also solved when using this system. If the two versions have changes in different parts of the file, it will merge them together, but if a situation occurs where the changes are in the same part, the person that tries to save last will be notified and both version are shown so changes can be made.
This is something I highly recommend to use when working in a team, to avoid headaches!
Documenting your Project
There are many different kinds of documentation that you can produce for your programming projects, some examples are:
- User’s guide
- Technical documentation/developer’s guide
- Data tree/dictionary (class documentation etc.)
- Design documentation
I won’t be teaching you how to document you projects, that’s something up to each and every project. However I will say that this is an important part of the project and cannot be neglected.
Some languages enable you to automatically generate some of these documents; of course I’m talking about the technical documentation and data dictionaries. Javadoc generates a tree of HTML files containing prototypes and descriptions of class members for Java programs.
For PHP there are a whole bunch available, phpdoc, PHPDocumentor, phpautodoc and the list goes on.
Testing
This is another key point of software engineering that is overlooked very often for some reasons. Sure you might run the code two or three times a day and conclude that it works without errors and everything is fine. But are you really sure that is the case; this is a mistake many make by thinking that the code is fine as long as it runs.
Remember eliminating bugs is quite impossible but you can do still reduce the level of bugs in your code significantly before releasing it. I would recommend you to get another team in to look at the code you have developed and test run it. This type of analysis often suggests:
- Test cases you have not considered
- Improvements in security
- Erros you have missed
- Optimization
- Additional functionality
- Existing components you can use to improve the code
Even if you’re not working in a team, or at a company but alone, I am sure you can find another person that is in the same situation as you and offer to test and analyze their code if the other person does the same for you.
Also before you release the final product, I recommend running a small beta test for a specific amount of persons. If you’re product isn’t available for free, I’d recommend it to be handed out for free to let say 100 persons to crash test it. You won’t believe what feedback you’ll get back. Not only bug reports but also user experience remarks, suggestions etc.
So this is something you ought to consider doing before you release it officially.
The End…
I hope you enjoyed this article and I hope it will give you some ideas that you can apply to your own projects in the future.
Share with the world:
These icons link to social bookmarking sites where readers can share and discover new web pages.
