Development Environment
- Source control - e.g. Git (preferred choice) , Csv, Svn
- May use internal server or public source controls (e.g. Github/ Unfuddle)
- Team members should receive notification whenever there's new push/commit to the server repository.
- Knowledge base - Wiki
- Team members should try to contribute on:
- Project documentations
- Technical know-hows
- Workflow control for agile development. Some choices:
- Simple and easy to use - Pivotal Tracker
- More comprehensive one - Atlassian JIRA
- Continuous integration - Build and test server. For example:
- Jenkins - For Ruby on Rails developments
- CuriseControl.NET - For .NET developments
- Test Automation
- Browser test - Selenium IDE
General Coding Practices
- DRY - Don't repeat yourself. Never copy and paste same (similar) block of code in multiple places within the project. Instead, common functionalities should be "extracted" to a single access point like a helper function or by other means.
- Coding conversions - Team members should follow a single set of coding conversion.
- Try to keep each line under 120 to 150 chars.
- Code with comments.
- Should always keep the code clean and easy for maintenance.
- Should keep small code source files. Every source code file should in general not more than 500 or even 300 lines (excluding large blocks of comments).
- Should keep small functions - not more than 30 to 50 lines.
- Should keep functions as private/protected as possible. Only expose a function to public whenever necessary.
- Every single function/method should be unit tested.
- Regular code coverage test.
- Developers may keep a work diary to log everyday's work done.
Daily Collaboration Practices
- Team members MUST complete test (unit, functional, integration test) and make sure there's no unexpected error before pushing code to repository.
- The build server (e.g. Jenkins/CuriseControl.NET) should run complete test whenever there's code update on repository. In this way, whoever broke any tests can be clearly identified.
- If there's unexpected errors (except explicit NotImplementedError) reported by build server, whom pushed the related code should fix the errors ASAP.
- Responsibilities - whenever a feature raised a issue/bug need to be fixed/enhanced, the team member(s) who contributed to that feature should be have the priority to follow the case.
- Communications
- Better communications between team members always save development time and avoid unnecessary bugs.
- Always let other team members know what you're working on.
- Pending or unfinished feature can be marked as "NotImplementedException" and let the corresponding test fail. Then commit code to repository.
- Any bug reported from QA Engineers should state as much details as possible including the environment and steps to reproduce a bug.
- Code review
- Team members should review each others' code.
- For any problem spotted, one should inform the author of that code. In addition, adding unit tests to indicate the problem may also helps.
- It there's no QA team in the group. Developer should write additional test cases for each other! It's always better for a developer to find a bug before the end users!
- All developers should stand by when a new release is deployed to production.
- Business logic and any updates should be kept in a centralized repository such as work flow control or wiki.
- Every developer should try their best to commit/push the work done on that day before leaving the office.
Source Control Usage Practices
- New project feature should be developed on a separated branch. Then merge back to master/main trunk when finished and tested.
- Project releases should be tagged.