Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Art of Defensive Programming By Ipan Ardian


Published on

The Art of Defensive Programming

Published in: Engineering
  • Login to see the comments

The Art of Defensive Programming By Ipan Ardian

  2. 2. <HELLO!/> Ipan Ardian Sr. Software Engineer Indosystem & Loket (GoJek Group) 9+ years’ experience 2
  3. 3. WHAT’S DEFENSIVE PROGRAMMING Let’s start with the definition first 3
  4. 4. 4 Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. Defensive programming practices are often used where high availability, safety or security is needed — Wikipedia
  5. 5. WHY DEFENSIVE PROGRAMMING Does it matter 5
  6. 6. 6 WW3, ALMOST… In 1980, NORAD reported that the US was under missile attack. The problem was caused by a faulty circuit, a possibility the reporting software hadn’t taken into account. DEADLY RADIATION THERAPY A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of X-rays. BUGS
  7. 7. 7 ROCKET LAUNCH ERRORS The European Space Agency’s Ariane 5 Flight 501 was destroyed 40 seconds after takeoff (June 4, 1996). The US$1 billion prototype rocket self-destructed due to a bug in the on-board guidance software. LOST IN SPACE One of the subcontractors NASA used when building its Mars climate orbiter had used English units instead of the intended metric system, which caused the orbiter’s thrusters to work incorrectly. Due to this bug, the orbiter crashed almost immediately when it arrived at Mars in 1999. The cost of the project was $327 million.
  8. 8. “You can’t sleep well if you are not confident that your last commit didn’t take down the whole application” 8
  9. 9. 9 Know The Language
  10. 10. 10
  11. 11. 11 Try to be as strict as possible. Assert that your input values are what you expect. Never Trust User Input
  12. 12. Don’t write STUPID code, use SOLID code!! Write SOLID Code 12
  13. 13. 13 From STUPID to SOLID Code! STUPID Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication SOLID Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
  14. 14. Writing unit tests will help you adhering to common principles such as High Cohesion, Single Responsibility, Low Coupling and right object composition Test test test! 14
  16. 16. As developers shouldn’t trust others developers’ code. We shouldn’t trust our code neither. Code Review 16
  17. 17. Stop hoping your users will report errors. Monitor and fix crashes in real time. Iterate continuously. Boost efficiency. Improve user experience. Tracking Error 17
  18. 18. <THANKS!/> Any questions? 18
  19. 19. QUIZ TIME Open