Changes between Version 2 and Version 3 of AlphaReleaseDocumentation

Show
Ignore:
Timestamp:
03/28/2011 09:35:53 PM (3 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 ==