10 Best Practices for Software Engineering: Difference between revisions
From charlesreid1
(Created page with "Following Heroux and Willenbring's paper, here are 10 "best practices" for software engineering: 1 Issue-tracking software for requirements, features, and bugs 2 Manage source:...") |
|||
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Following Heroux and Willenbring's paper, here are 10 "best practices" for software engineering: | Also see: [[NASA 10 Best Practices for Software Engineering]] | ||
=Heroux and Willenbring's 10 Best Practices= | |||
In a draft paper called [http://www.sandia.gov/~maherou/docs/BarelySufficientSoftwareEngineering.pdf Barely Sufficient Software Engineering (pdf file)] that I find myself returning to again and again as a computational chemical engineer, Michael Heroux and James Willenbring, both of Sandia National Laboratories, wrote up 10 (actually, 11) guidelines for writing scientific code that is high quality and encourages collaboration. | |||
They are: | |||
0. Manage your source (the basics) | |||
1. Use issue-tracking software for requirements, features, and bugs | |||
2. Manage your source (beyond the basics) | |||
3. Use mailing lists to communicate | |||
4. Use checklists for repeated processes | |||
5. Create barely sufficient, source-centric documentation | |||
6. Use configuration management tools | |||
7. Write tests first, run them often | |||
8. Program tough stuff together | |||
9. Use a formal release process | |||
10. Perform continual process improvement | |||
=An Abbreviated Version= | |||
Issue tracking | |||
Version control | |||
Mailing list | |||
Checklists! Checklists! | |||
Self documenting | |||
Configuration management | |||
Test driven | |||
Pair programming | |||
Formal release | |||
Continuous improvement | |||
=Also See= | |||
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 | 1 Issue-tracking software for requirements, features, and bugs | ||
| Line 20: | Line 78: | ||
10 Continuous process improvement | 10 Continuous process improvement | ||
--> | |||
[[Category:Programming]] | |||
[[Category:Top 10]] | |||
[[Category:Scientific Computing]] | |||
[[Category:Best Practices]] | |||
Latest revision as of 02:04, 9 October 2019
Also see: NASA 10 Best Practices for Software Engineering
Heroux and Willenbring's 10 Best Practices
In a draft paper called Barely Sufficient Software Engineering (pdf file) that I find myself returning to again and again as a computational chemical engineer, Michael Heroux and James Willenbring, both of Sandia National Laboratories, wrote up 10 (actually, 11) guidelines for writing scientific code that is high quality and encourages collaboration.
They are:
0. Manage your source (the basics)
1. Use issue-tracking software for requirements, features, and bugs
2. Manage your source (beyond the basics)
3. Use mailing lists to communicate
4. Use checklists for repeated processes
5. Create barely sufficient, source-centric documentation
6. Use configuration management tools
7. Write tests first, run them often
8. Program tough stuff together
9. Use a formal release process
10. Perform continual process improvement
An Abbreviated Version
Issue tracking
Version control
Mailing list
Checklists! Checklists!
Self documenting
Configuration management
Test driven
Pair programming
Formal release
Continuous improvement
Also See
See Also: The Cathedral and the Bazaar (19 best practices for creating open-source software)