Download to read offline
Uploaded byHean Hong Leong
Developing Better Software
The document outlines best practices for software development, emphasizing guidelines like not trusting external input, using proven methods, and adhering to the principle of least privilege. It addresses challenges in developer experience, performance optimization, and the importance of continuous learning and automation. The author encourages sharing knowledge and exploring new technologies while highlighting the importance of making code maintainable and secure.
More Related Content
Similar to Developing Better Software
Developing Better Software
- 1. Developing Better Software Leong HeanHong Inno Tech Boot Camp 2018
- 2. Purpose ● Define someguideline for best practices ● Serve as starting point for exploration and learning ● This is not complete, neither is it final!
- 4. Approach ● Focus moreon how to think, instead of how to do ● Continuous learning from various sources (not just Google) ● Share what you learned
- 6. Guideline ● Don’t trustexternal input ● Avoid security by obscurity ● Use proven methods/algorithms ● Configurable security algorithms ● Principle of least privilege
- 7. Don’t Trust ExternalInput ● JS validation can be bypassed ● Client (e.g. mobile client, end user) may not provide input as intended/specified ● ALWAYS validate all input ● Escape data before saving in database ● Escape data in display ● Minimise dependency on input. Verify with data source, perform calculation.
- 8. Avoid Security ByObscurity ● “Obscurity is fine until it is discovered, but once someone has worked out your particular obscurity, then your system is vulnerable again. Given the persistence of attackers, this equates to no security at all.” - xan on https://stackoverflow.com/a/533997/58542 Google: why security by obscurity is bad (http://bfy.tw/GX6K)
- 9. Use Proven Methods/Algorithms ●Self-inventing “complex” algorithm may not be as secured as you think ● Prefer opened, tested methods/algorithms ● Recommended encryption algo: AES, RSA ● Recommended hash algo: SHA2 family, SHA3 family, bcrypt
- 10. Configurable Security Algorithms ●MD5 was popular, now it is considered insecure. Can you change algorithm without affecting application? Linux shadowed password: $id$rounds$salt$hashed E.g. $5$rounds=80000$wnsT7Yr92oJoP28r$cKhJImk5mfuSKV9b3mumNzlbst FUplKtQXXMo4G6Ep5
- 11. Principle Of LeastPrivilege ● Give user just enough privileges to get job done. ● Not everyone need sudo privilege. ● Not everyone need write permission, read-only is sufficient.
- 12. Challenge ● If sourcecode is stolen, is application still secure? ● If database access is comprised, is data still secure? ● If password is stolen, is account still secure? ● If <x> is <y>, is <z> still secure?
- 13.
- 14. DX: Problems ● Youwork in a team. ● Existing/new developer work on your code. ● You work on code written 2 years ago. ● Adding new feature without breaking things. ● Modify existing features without breaking things.
- 15. No one wantsto pick up your shit!
- 16. ● KISS -Keep It Simple and Stupid ● DRY: Don’t Repeat Yourself ● UNIX philosophy: Do 1 thing, do it well ○ Small function/class ● Use well-know things e.g. Design Pattern, builtin libraries ● Follow conventions (consistency) DX: Guideline (1)
- 17. ● Minimise dependenciesamong code ● Don’t speak. If you need to speak, speak little. If you need to speak a lot, speak loudly. DX: Guideline (2)
- 18. DX: Documentation ● Level1: Code should be self-explanatory (variable/method/class/package name) ● Level 2: Comment, comment comment ● Level 3: Wiki, spec documents
- 19. Hong’s Mistake Rule™ 1.Make is impossible to make mistake. 2. Make it hard to make mistake. 3. Reduce damage of mistake.
- 20.
- 21. Popular Techniques (1) ●Offload to specialized services/engines E.g. Hadoop, search/indexing engine, mail service, SMS gateway, analytic engine ● Do things offline/later. Suggestion: use message queue, preprocessing ● Caching Suggestions: Redis
- 22. Popular Techniques (2) ●Use native functions. Don’t implement yourself. ● Test app in older phone models. ● Test app in slow network condition.
- 23. DB Performance ● Thereis no need to do everything in single DB query. Consider splitting into 2 queries. Process data using code. ● Index, index, index. ● Study how DB works. How it perform search. How it insert data. How it index data. How it execute AND/OR/JOIN, .... ● RDB is not suitable for all occasions. It is not the only type of DB on earth!
- 24.
- 25. ● Are Iproud of my work? ● Can other developers benefit from my work?
- 26. Automate Automate anything thatyou need to repeat more than once. Article: http://bit.ly/2H5O62o
- 27. Work Smart Programmer writescode to solve problems.
- 28.
- 29. Guideline ● These isalways a better way of doing things. ● Learn from the best. E.g. Google, Facebook, Apple, Amazon, … ● Try something new in each project. Make your work fun! ● Learn a new language. Learn a new framework. ● Don’t reinvent the wheel.
- 30. Tips On Learning ●Make it a habit, make it fun. ● Learn something that interest you. ● Learn it’s pros and cons. ● Know when to use it, when NOT to use it. ● Think how to modify and adopt it to our existing application/company.
- 31. Technology Adopted OverThe Years ● Git ● Laravel ● Ionic ● React Native ● Electron ● RabbitMQ ● Go Programming ● Cloud Computing (AWS, Digital Ocean) ● What’s next?
- 32.
- 33. A regular palindromeis a string of numbers or letters that is the same forward as backward. For example, the string "ABCDEDCBA" is a palindrome because it is the same when the string is read from left to right as when the string is read from right to left. Write a program that determines if a given word is palindrome. “MADAM” => TRUE “ALEX” => FALSE “REDIVIDER” => TRUE “LINEAR” => FALSE
Editor's Notes
- #3 Limited, not completed, starting point
- #4 Secure agenda: build awesome team You chosen to be part of team because you have the potential to be awesome
- #5 Think, learn, share
- #6 Security Don’t trust user Don’t invent your own method Use standardized, tested methods Assume people want to break, abuse your system
- #14 Developer experience Cannot make mistake Hard to make mistake Knowledge transfer
- #21 Performance Background/offline process 3 party specialised service Cache, queue Understand how system works
- #25 Self improvement Lazy and smart developer Automation Sharing
- #28 Solve problems using code
- #29 Shaing
- #30 Why is Google using XYZ? Why is Facebook using ABC?
- #33 Programming challenge