10 Best Practices for Software Engineering: Difference between revisions
From charlesreid1
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
=Abbreviated= | |||
Issue tracking | |||
Version control | |||
Mailing list | |||
Checklists! Checklists! | |||
Self documenting | |||
Configuration management | |||
Test driven | |||
Pair programming | |||
Formal release | |||
Continuous improvement | |||
=Full= | |||
See Also: [[The Cathedral and the Bazaar]] (19 best practices for creating open-source software) | See Also: [[The Cathedral and the Bazaar]] (19 best practices for creating open-source software) | ||
Revision as of 02:38, 6 July 2013
Abbreviated
Issue tracking
Version control
Mailing list
Checklists! Checklists!
Self documenting
Configuration management
Test driven
Pair programming
Formal release
Continuous improvement
Full
See Also: The Cathedral and the Bazaar (19 best practices for creating open-source software)
Following Heroux and Willenbring's paper (http://www.sandia.gov/~maherou/docs/BarelySufficientSoftwareEngineering.pdf), here are 10 "best practices" for software engineering:
1 Issue-tracking software for requirements, features, and bugs
2 Manage source: beyond the basics
3 Use mailing lists to communicate
4 Use checklists for repeated processes
5 Barely-sufficient, source-centric documentation
6 Configuration management tools
7 Write tests first, run them often
8 Program tough stuff together
9 Use formal release process
10 Continuous process improvement