Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>To improve the maintainability you could:</p> <ul> <li><p>If you are the sole developer then adopt a coding style and stick to it. That will give you confidence later when navigating through your own code about things you could have possibly done and the things that you absolutely wouldn't. Being confident where to look and what to look for and what not to look for will save you a lot of time.</p></li> <li><p>Always take time to bring documentation up to date. Include the task into development plan; include that time into the plan as part any of change or new feature.</p></li> <li><p>Keep documentation balanced: some high level diagrams, meaningful comments. Best comments tell that cannot be read from the code itself. Like business reasons or "whys" behind certain chunks of code.</p></li> <li><p>Include into the plan the effort to keep code structure, folder names, namespaces, object, variable and routine names up to date and reflective of what they actually do. This will go a long way in improving maintainability. Always call a spade "spade". Avoid large chunks of code, structure it by means available within your language of choice, give chunks meaningful names.</p></li> <li><p>Low coupling and high coherency. Make sure you up to date with techniques of achieving these: design by contract, dependency injection, aspects, design patterns etc.</p></li> <li><p>From task management point of view you should estimate more time and charge higher rate for non-continuous pieces of work. Do not hesitate to make customer aware that you need extra time to do small non-continuous changes spread over time as opposed to bigger continuous projects and ongoing maintenance since the administration and analysis overhead is greater (you need to manage and analyse each change including impact on the existing system separately). One benefit your customer is going to get is greater life expectancy of the system. The other is accurate documentation that will preserve their option to seek someone else's help should they decide to do so. Both protect customer investment and are strong selling points.</p></li> <li><p>Use source control if you don't do that already</p></li> <li><p>Keep a detailed log of everything done for the customer plus any important communication (a simple computer or paper based CMS). Refresh your memory before each assignment.</p></li> <li><p>Keep a log of issues left open, ideas, suggestions per customer; again refresh your memory before beginning an assignment.</p></li> <li><p>Plan ahead how the post-implementation support is going to be conducted, discuss with the customer. Make your systems are easy to maintain. Plan for parameterisation, monitoring tools, in-build sanity checks. Sell post-implementation support to customer as part of the initial contract.</p></li> <li><p>Expand by hiring, even if you need someone just to provide that post-implementation support, do the admin bits. </p></li> </ul> <p>Recommended reading:</p> <ul> <li><p><a href="http://cc2e.com/" rel="nofollow noreferrer">"Code Complete" by Steve Mcconnell</a> </p></li> <li><p>Anything on <a href="http://en.wikipedia.org/wiki/Design_pattern_(computer_science)" rel="nofollow noreferrer">design patterns</a> are included into the list of recommended reading.</p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload