Agile Development Notes

Posted Sat, 04/05/2008 - 12:42am by james
No votes yet
  1. Remove duplicate code.
  2. Turn comments into code.
  3. Remove code smells.
    1. Duplicate code.
    2. Too many comments.
    3. Type code.
    4. Switch or a long if-then-else-if.
    5. Cannot give a good name to a variable, method or class.
    6. User names like XXXUtil, XXXManager, XXXController and etc.
    7. User the words "and, "or" and etc. in the name of a variable, method or class.
    8. Some instance variables are not always used.
    9. A method contains too much code.
    10. A class contains too much code.
    11. A method takes too many parameters.
    12. Two classes are using each other.
  4. Keep code fit when new requirements come in.
    1. Keep an eye on code smells.
  5. Take care to inherit.
    1. Make sure data and db are in sync.
  6. Check for inappropriate references.
    1. Look: are there circular references
    2. Think: what it really needs?
    3. Think: can it be reused in a new environment?
    4. Look: now, I need to reuse it in this environment, can it be done?
  7. Employ MVC - model, view, controller.
  8. Make user stories.
    1. Find all user stories or use cases, attach guess of difficulty of each case, attach time to one case, multiple rest of cases and add, this is the guess of project time.
    2. After first iteration, determine velocity of the development time. Adjust split stories up and their rank to meet the estimated time requirements. If early, develop more stories, if behind, take out or split stories for a future iteration.
  9. OO design with CRC cards (class responsibility collaboration card).
  10. Acceptance testing.
    1. Use automated tools.
    2. Test code should not have any controlling functions.
  11. Acceptance test a UI.
    1. Make a user story.
    2. Test each part separately.
  12. Unit tests.
    1. Unit tests belong to the developers.
    2. Acceptance test belongS to customers.
    3. Use unit tests to squash bugs (keep the same tests).
  13. Test driven development.
    1. Write the tests first. This way, you ensure that the nonexistence code fails, then you write the code that makes it pass.
    2. Different from inherently assuming the code passes, then make it fail with the tests.
  14. Team development with CVS (subversion now).
  15. Essential skills for communications.
    1. Do not create documentation just because it feels right, do it only for the purpose of communication. Even then, there are other ways to communicate and documentation may not be the best way.
    2. Face to face communication is much more effective than documentation, unless the team is quite large or the participants can't come together.
    3. Keep the communications as frequent as possible.
    4. Keep the communication path as short as possible.
    5. Communicate relevant information only.
  16. Pair programming.
    1. Lots of advantages.
    2. Costs 15% more time to develop, but saves bug fixing time.
    3. Sometimes it doesn't work, like people without confidence, emotionally blocking people, stress/heavy deadlines.

 

ShareThis
AttachmentSize
ESAD.pdf2.21 MB

Syndicate

Syndicate content