Changes between Version 2 and Version 3 of AlphaReleaseDocumentation


Ignore:
Timestamp:
03/28/11 21:35:53 (4 years ago)
Author:
akearney
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AlphaReleaseDocumentation

    v2 v3  
    1818
    1919== Implementation ==
     20Coding Practices
     21The important aspects of our coding practices are based around AGILE practices and tickets. [[br]]
     22All coding updates are meant to maintain modularity and should only address and solve one ticket at a [[br]]
     23time. Tickets should be made whenever an improvement or task is noticed that it is needed and assigned [[br]]
     24either at meetings or when taken by a member. The goal should be completed as quickly and as well as possible,[[br]] with emphasis on getting things good enough and moving on. When code needs to be refactored, a new ticket[[br]]
     25should be made for this. The task of refactoring should be taken by someone who did not write the original[[br]]
     26code, so that more than one outlook can be explored on a complicated area of code. To avoid problems with [[br]]
     27merging code, most of our coding will be done at separate times than other people. When more than one person [[br]]
     28is working on the code at the same time, files being changed should be coordinated through Google chat. [[br]]
     29Frequent commits will be used to make sure that the same areas of code aren’t being changed by more than [[br]]
     30one person. The general style of coding for our project should match standard Python style including [[br]]
     31comments and naming conventions. Any commits should be strictly following the architecture because the [[br]]
     32coding principles such as don’t repeat yourself, low coupling and single purpose modules were being [[br]]
     33implemented in the architecture. In order to keep all of these principles intact, the diagrams created [[br]]
     34in planning must be followed. We have created separate modules for each behavior we wanted to express in [[br]]
     35our project. Any new behaviors require a new module and updating the architecture while keeping design [[br]]
     36principles in mind.
     37       
     38
    2039
    2140== Installing and Running ==