Best Practices - Seeqnce - 23/24-02-2012
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Best Practices - Seeqnce - 23/24-02-2012

on

  • 1,632 views

 

Statistics

Views

Total Views
1,632
Views on SlideShare
1,470
Embed Views
162

Actions

Likes
0
Downloads
6
Comments
0

5 Embeds 162

http://youhoo.im 131
http://ychaker.github.com 18
http://www.linkedin.com 10
https://www.linkedin.com 2
http://localhost 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Best Practices - Seeqnce - 23/24-02-2012 Presentation Transcript

  • 1. Best Practices Youssef Chaker February 23-24 2012 Presented byMonday, February 27, 12
  • 2. Day 1 The Why, What and HowMonday, February 27, 12
  • 3. but first... Who am I and why should you listen to me?Monday, February 27, 12
  • 4. Monday, February 27, 12
  • 5. Why?Monday, February 27, 12
  • 6. Developers are not code monkeysMonday, February 27, 12
  • 7. Better relationships with customers and business dev peopleMonday, February 27, 12
  • 8. Professionalism ...remember that one?Monday, February 27, 12
  • 9. <warning>Monday, February 27, 12
  • 10. Ariane 5 Flight 501 Flight 501, which took place on June 4, 1996, was the first, and unsuccessful, test flight of the European Ariane 5 expendable launch system. Due to an error in the software design (inadequate protection from integer overflow), the rocket veered off its flight path 37 seconds after launch and was destroyed by its automated self-destruct system when high aerodynamic forces caused the core of the vehicle to disintegrate. It is one of the most infamous computer bugs in history. The breakup caused the loss of four Cluster mission spacecraft, resulting in a loss of more than US$370 million 10Monday, February 27, 12
  • 11. Therac-25 The Therac-25 was a radiation therapy machine produced by Atomic Energy of Canada Limited (AECL) [...]. It was involved with at least six accidents between 1985 and 1987, in which patients were given massive overdoses of radiation, approximately 100 times the intended dose. Three of the six patients died as a direct consequence. These accidents highlighted the dangers of software control of safety-critical systems, and they have become a standard case study in health informatics and software engineering. [...] A commission has concluded that the primary reason should be attributed to the bad software design and development practices, and not explicitly to several coding errors that were found. In particular, the software was designed so that it was relatively impossible to test it in a clean automated way.Monday, February 27, 12
  • 12. More online: http://en.wikipedia.org/wiki/List_of_software_bugsMonday, February 27, 12
  • 13. </warning>Monday, February 27, 12
  • 14. what not to do!Monday, February 27, 12
  • 15. source: http://thedailywtf.com/Articles/Flexible-Spending.aspx#pic2Monday, February 27, 12
  • 16. Shortcuts Quick & dirty Cutting CornersMonday, February 27, 12
  • 17. Live CodingMonday, February 27, 12
  • 18. A Simple Prayer Lord, please protect our biggest VPS from Erics installed software - including but not limited to plugins and gems written by 11 year old  Pakistanis. May his apps be well behaved and may they be considerate of CPU and RAM. Lord, if any of these terms are unfamiliar to you, look them up on Wikipedia. Peace be to all other apps and all other VPSs on the same physical server. Amen.Monday, February 27, 12
  • 19. what to do?Monday, February 27, 12
  • 20. What You Already Know • Follow coding standards. • Be consistent. If you do operations in a specific way, do that kind of operations in the same way (e.g. defining variable/method/class names, parenthesis usage etc.). • More code does not mean better code. Keep it simple and reduce complexity. • Catch specific exceptions instead of highest level class Exception. This will provide understandability and more performance. • Use understandable and long names for variables. Loop variable names can be i, j, k, index etc., local variable names must be longer than loop variables, parameter names must be longer than local variables and static variable names must be longer than parameters; proportional with scope size. • Dont use magic numbers and strings directly in the code. Use constants. This method provides more modularity and understandability. • Use understandable comments. Bad comment is worse than no comment. • Method names must include "what is done by this method" information.Monday, February 27, 12
  • 21. • Package related classes (that changed together and/or used together) together. • Use positive conditionals. Readability of positive conditionals are better than negative ones. • Use dependency injection to manage too many singletons. • Use exceptions only for catching exceptions, not for control flow. Think as required and perform control flow with control statements/conditionals. • Dont use so many arguments with methods. Keep the number at most 8-10. If more is required, review your design. • Dont use method alternatives with boolean flag variables (public void someMethod(bool flag)). Write more than one method for each flag condition. • Think twice before defining a method as static and be sure if you really need to. Static methods are harder to manage. • Avoid using methods with reference parameters. Use multi attributed object parameters instead. • Number of interface methods must be minimized to decrease coupling/dependency.Monday, February 27, 12
  • 22. What School Did not Teach You • Deliver often, get user feedback in a continuous regular and intense flow • Dont try to be too much smarter than your customer, just enough • Do only whats needed to deliver the functionality expected in each step in the best possible way • Make sure you love and care about your work, code, user and customerMonday, February 27, 12
  • 23. Questions? Comments? Concerns?Monday, February 27, 12
  • 24. “Motivational products don’t work. But our Demotivators® products don’t work even better.”Monday, February 27, 12
  • 25. TDD Test Driven DevelopmentMonday, February 27, 12
  • 26. Write Tests Let them failMonday, February 27, 12
  • 27. Write the minimal code that will make your tests passMonday, February 27, 12
  • 28. Write More TestsMonday, February 27, 12
  • 29. rinse lather repeatMonday, February 27, 12
  • 30. source: http://www.agiledata.org/essays/tdd.htmlMonday, February 27, 12
  • 31. = TFD Test First DevelopmentMonday, February 27, 12
  • 32. TDD = x + TFD any guesses to what x is?Monday, February 27, 12
  • 33. RefactorMonday, February 27, 12
  • 34. source: http://www.agiledata.org/essays/tdd.htmlMonday, February 27, 12
  • 35. source: http://www.despair.com/overconfidence.htmlMonday, February 27, 12
  • 36. Monday, February 27, 12
  • 37. TDD || / less fluff, more stuffMonday, February 27, 12
  • 38. xUnit Frameworks RSpec for more: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworksMonday, February 27, 12
  • 39. Monday, February 27, 12
  • 40. Monday, February 27, 12
  • 41. bash-3.2$ bundle exec rake spec ..................................................................................*..................................................................................................... ....................................................... Pending: GroupVenue add some examples to (or delete) /Users/ychaker/Dev/jogabo/spec/models/ group_venue_spec.rb # No reason given # ./spec/models/group_venue_spec.rb:4 Finished in 3 minutes 43.24 seconds 239 examples, 0 failures, 1 pending ................................................................................................................................................................. ............................................................................. Finished in 3 minutes 49.69 seconds 238 examples, 0 failuresMonday, February 27, 12
  • 42. Break 15 minutesMonday, February 27, 12
  • 43. and we’re back...Monday, February 27, 12
  • 44. Question: Why are you writing code? What’s the purpose of your code?Monday, February 27, 12
  • 45. Answer: solve Business problems produce a certain BehaviorMonday, February 27, 12
  • 46. Then maybe we should do Behavior Driven Development!Monday, February 27, 12
  • 47. D’oh!Monday, February 27, 12
  • 48. source: http://www.agiledata.org/essays/tdd.htmlMonday, February 27, 12
  • 49. Disclaimer: The RSpec example was actually a BDD exampleMonday, February 27, 12
  • 50. User StoriesMonday, February 27, 12
  • 51. FeaturesMonday, February 27, 12
  • 52. ScenariosMonday, February 27, 12
  • 53. Monday, February 27, 12
  • 54. Integration TestingMonday, February 27, 12
  • 55. cucumber demoMonday, February 27, 12
  • 56. Continuous Integration (CI)Monday, February 27, 12
  • 57. HudsonMonday, February 27, 12
  • 58. Monday, February 27, 12
  • 59. Monday, February 27, 12
  • 60. standup, stretch your legsMonday, February 27, 12
  • 61. if there’s anything I want you to take away from today is this last partMonday, February 27, 12
  • 62. Client-server model (examples) • Concurrent Versions System (CVS) • Subversion (svn)Monday, February 27, 12
  • 63. Distributed model (examples) • Fossil • git • MercurialMonday, February 27, 12
  • 64. delete, don’t comment outMonday, February 27, 12
  • 65. Always use source control system even if the project has only one developerMonday, February 27, 12
  • 66. git demoMonday, February 27, 12
  • 67. Questions? Comments? Concerns?Monday, February 27, 12
  • 68. Monday, February 27, 12
  • 69. Day 2 Go BeyondMonday, February 27, 12
  • 70. ActivityMonday, February 27, 12
  • 71. Be Agile, Be HappyMonday, February 27, 12
  • 72. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes & toolsWorking software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.Monday, February 27, 12
  • 73. Let’s go closerMonday, February 27, 12
  • 74. Agile Modeling Agile Unified Process (AUP) Dynamic Systems Development Method (DSDM) Essential Unified Process (EssUP) Extreme Programming (XP) Feature Driven Development (FDD) Open Unified Process (OpenUP) Scrum Velocity trackingMonday, February 27, 12
  • 75. ScrumMonday, February 27, 12
  • 76. Monday, February 27, 12
  • 77. iterative, incremental framework for project management and agile software development.Monday, February 27, 12
  • 78. Monday, February 27, 12
  • 79. 2-4 week sprintsMonday, February 27, 12
  • 80. “ScrumMaster”, who maintains the processes (typically in lieu of a project manager)Monday, February 27, 12
  • 81. “Product Owner”, who represents the stakeholders, represents the businessMonday, February 27, 12
  • 82. “Team”, a cross- functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.Monday, February 27, 12
  • 83. Pigs & Chickens A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”Monday, February 27, 12
  • 84. Key Notions • (Sprint) Planning • Backlog* • (Sprint) Burn down • Daily Standups • + more... *Backlog: Product/Sprint backlog or any list of tasksMonday, February 27, 12
  • 85. Scrum for KidsMonday, February 27, 12
  • 86. YES! I’m seriousMonday, February 27, 12
  • 87. The MeadsMonday, February 27, 12
  • 88. Introducing the Scrum BoardMonday, February 27, 12
  • 89. The PughsMonday, February 27, 12
  • 90. The Board (again)Monday, February 27, 12
  • 91. The Toyota wayMonday, February 27, 12
  • 92. The Right Process Will Produce the Right Results 1. Create continuous process flow to bring problems to the surface. 2. Use the "pull" system to avoid overproduction. 3. Level out the workload (heijunka). (Work like the tortoise, not the hare.) 4. Build a culture of stopping to fix problems, to get quality right from the [start]. 5. Standardized tasks are the foundation for continuous improvement and employee empowerment. 6. Use visual control so no problems are hidden. 7. Use only reliable, thoroughly tested technology that serves your people and processes.Monday, February 27, 12
  • 93. Add Value to the Organization by Developing Your People and Partners 1. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others. 2. Develop exceptional people and teams who follow your companys philosophy. 3. Respect your extended network of partners and suppliers by challenging them and helping them improve.Monday, February 27, 12
  • 94. Continuously Solving Root Problems Drives Organizational Learning 1. Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu, 現地現物); 2. Make decisions slowly by consensus, thoroughly considering all options (Nemawashi, 根回し); implement decisions rapidly; 3. Become a learning organization through relentless reflection (Hansei, 反省) and continuous improvement (Kaizen, 改善).Monday, February 27, 12
  • 95. Break 15 minutesMonday, February 27, 12
  • 96. and we’re back...Monday, February 27, 12
  • 97. Monday, February 27, 12
  • 98. ActivityMonday, February 27, 12
  • 99. Sprint Planning+ Scrum PokerMonday, February 27, 12
  • 100. Daily Standups Short: less than 15 minutes What did I do yesterday? What am I doing today? What are my obstacles?Monday, February 27, 12
  • 101. Stay Flexible Stay LeanMonday, February 27, 12
  • 102. RetrospectivesMonday, February 27, 12
  • 103. Monday, February 27, 12
  • 104. Monday, February 27, 12
  • 105. Pair ProgrammingMonday, February 27, 12
  • 106. Monday, February 27, 12
  • 107. Questions? Comments? Concerns?Monday, February 27, 12
  • 108. BonusMonday, February 27, 12
  • 109. Lean StartupMonday, February 27, 12
  • 110. ScreenMonday, February 27, 12
  • 111. You have now learnt the basic of software craftsmanshipMonday, February 27, 12
  • 112. References• Fowler, Martin. The New Methodology: http://martinfowler.com/articles/newMethodology.html• Wikipedia. Agile Software Development: http://en.wikipedia.org/wiki/Agile_software_development• Manifesto for Agile Software Development: http://agilemanifesto.org/• Wikipedia. Scrum (development): http://en.wikipedia.org/wiki/Scrum_(development)• Wikipedia. Ariane 5 Flight 501: http://en.wikipedia.org/wiki/Ariane_5_Flight_501• Ariane 5 Failure, Full Report: http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html• Wikipedia. Tehrac-25: http://en.wikipedia.org/wiki/Therac-25• Wikipedia. List of software bugs: http://en.wikipedia.org/wiki/List_of_software_bugs• Rails Maturity Models: http://railsmaturitymodels.com/practices• Scrum For Kids http://scrumforkids.com/• Toyota Production System http://en.wikipedia.org/wiki/Toyota_Production_System• The Toyota Way http://en.wikipedia.org/wiki/The_Toyota_Way• Manifesto for Software Craftsmanship http://manifesto.softwarecraftsmanship.org/• The Lean Startup http://theleanstartup.com/• Cucumber-Rails https://github.com/cucumber/cucumber-rails• Gherkin https://github.com/cucumber/cucumber/wiki/GherkinMonday, February 27, 12
  • 113. Contact @ychaker http://youhoo.im http://linked.com/in/ychakerMonday, February 27, 12