A piggy bank of commands, fixes, succinct reviews, some mini articles and technical opinions from a (mostly) Perl developer.

Jump to

Quick reference

What a healthy development environment looks like

In my opinion, the best set up would include:

Software
  • Jira for issue tracking 
  • A wiki for information sharing 
  • Git for version control
  • Continuous integration and continuous deployment (e.g. with Jenkins)
  • Use an existing package provider like Redhat, don't compile publicly available software yourself
Environment
  • Full commit history available with details of developer name and change ticket ID
  • Full ticket history available to read, with no historical tickets in the "old" system and unreadable
  • /etc/init.d scripts ('service') for starting, stopping and restarting software
  • VMs for development 
  • Identical production, development and test environments
  • Continuous Integration: Every check-in to any development branch is run through the test suite, and any failures are emailed to the author
  • Immutable infrastructure: Servers are not changed. All changes begin with pushing to a repo, and a new server is then built and deployed to a subset of users, tested, then to all users.
  • One-touch deployment, identical in both production and development environments 
    • Continuous deployment: Every commit to trunk that passes the test suite is deployed
  • Refactoring code as required, restricted only by the need to pass the test suite
  • All major software components described on wiki with details of source code, restarting, troubleshooting, owner, etc.
Tests
  • Easy to run the entire test suite for any branch
  • Test suite should complete quickly
  • A test suite that is comprehensive and well understood by all
  • Test coverage stats are visible to everyone
  • Tests for hallmarks of quality like 'use strict' and embedded documentation (even if a blacklist of legacy code is required)
Code
  • Clear model-view-controller separation
  • All code contained within re-usable modules (scripts are thin wrappers around classes)
  • No "utility classes" (inherit/use roles if common methods are needed)
  • No "god classes" (split up methods into meaningul sublclasses or roles)
  • All logic contained within meaningful "noun" classes designed for problem domain
  • Meaningful variable names in domain language and no unnecessary abbreviations
  • Plentiful comments, written in the language of the problem domain
  • All classes/modules to have embedded documentation
People
  • For every piece of work, three people should discuss it together for a few minutes after a technical design has been proposed, and before any development work is started - a representative of the business, a QA tester and a developer.
    • They should ask questions like "Are the requirements accurate and high quality?", "Does the proposed solution fulfill the requirements?", "Is the proposed solution high quality?", "Can the proposed solution be easily tested?", etc.
  • The product manager as well as the people coming up with requirements must be readily available to answer questions.
  • To facilitate communication. teams should *not* be split across timezones
    • (separate) Scrums should take place at the beginning of the local day