Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The following are the key software engineering best practices to be used by all developers contributing to Umple. See this page for information about the current development activities in Umple.
See also a sequential list of steps to follow when contributing
You will want to read the instructions for downloading the command line and Eclipse versions of Umple, as well as reading instructions to get set up to develop.
E2. Follow strict test-first development in everything you do. This means:
- When developing a new feature (or change), first create test cases to demonstrate the absence of the feature (which will initially pass), then create the test cases for how the feature will work (that will initially fail - although will be expected to do so so this won't break the build), then implement the feature in the smallest possible increments, testing and committing as you go without breaking the build.
- When fixing bugs, follow a similar path, but add a test to test for the absence of that bug.
- Don't just do unit tests, contribute to our set of testbed systems and build other large systems using your Umple features so they can be system-tested and tried out in practice.
E3. Build and test the entire system locally before committing changes. Check the CheatSheet for hints.
E4. Use Umple in essentially all code you write, not Java.
E5. Document your code. in particular, use proper comment blocks at the beginning of each file, informative comments where necessary in the body, and Readme.txt files in directories.
E7. Add appropriate entries to this Wiki as you need to record important knowledge. Make sure you properly categorize the wiki entries to keep the wiki organized.
E8. Use the umple-dev mailing list for discussion of all changes.
E9. Use proper issue tracking. This includes categorizing all issues properly, closing them out when done, and opening issues or assigning them to yourself before making any changes.
E10. Seek code reviews of pull requests, and review the work of others.
E11. Strive to make the design and code of Umple ever more understandable to others.
Avoiding and Dealing with a mess
To avoid getting messed up, and to recover from a messed up environment, see the following page: Avoiding Mess In Development Environment