The Art of Defensive Programming By Ipan Ardian
1 like240 views
Defensive programming is a form of programming intended to ensure software continues functioning under unexpected conditions. It is important for software dealing with safety, security, or high availability. Without defensive programming, bugs can have serious consequences like falsely reporting missile attacks, delivering fatal radiation overdoses, or destroying expensive rockets. Defensive practices include writing solid code following principles like single responsibility, testing units of code, conducting code reviews, and tracking errors in real time.
The Art of Defensive Programming By Ipan Ardian
- 1. THE ART OF DEFENSIVE PROGRAMMING MEETUP CIREBON DEV #3 IPAN ARDIAN
- 2. <HELLO!/> Ipan Ardian Sr. Software Engineer Indosystem & Loket (GoJek Group) 9+ years’ experience http://ipanardian.com 2
- 3. WHAT’S DEFENSIVE PROGRAMMING Let’s start with the definition first 3
- 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. WHY DEFENSIVE PROGRAMMING Does it matter 5
- 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 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. “You can’t sleep well if you are not confident that your last commit didn’t take down the whole application” 8
- 10. 10
- 11. 11 Try to be as strict as possible. Assert that your input values are what you expect. Never Trust User Input
- 12. Don’t write STUPID code, use SOLID code!! Write SOLID Code 12
- 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. 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. As developers shouldn’t trust others developers’ code. We shouldn’t trust our code neither. Code Review 16
- 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