My Other lists

• JavaScript/Node Best Practices
• PR Code Review Practices
• Defensive Programming / Application Security Best Practices

I had collected some points and created a list of some best practices for software development. I plan to refer to this list from time to time to help me become a better Engineer. Publishing the list so that others too may refer and get benefitted from this list.

1. Learn & practice Design Patterns
2. Practice KISS (Keep It Simple Stupid), DRY (Don't Repeat Yourself) design principles
3. Practice Occam's Razor problem-solving principles; Occam's razor simply states that of any given set of explanations for an event occurring, the simplest one is most likely the correct one
4. Always ask questions when in doubt. Do not assume anything, be explicit over being implicit.
5. Remember, Explicit is better than implicit
6. Don't be afraid to experiment, or to commit mistakes, however, you must learn from your mistakes quickly and ensure the same mistake does not happen again. Write test cases to protect yourself from common mistakes.
7. Test everything (Only your code, not other people's code which you are referring, like external libraries)
8. Keep learning, keep reading latest articles, books, watch tutorials, attend workshops, discuss with experts to update your knowledge and skillsets
9. Keep practising Algorithms and Puzzles solving to improve your problems solving skills
10. Document everything and don't forget to update those documents when information or relevant facts change
11. Never ignore errors or exceptions. Always log your errors with full details sans sensitive information
12. Log everything and store the logs a remote location for thorough analysis and for historical reference (Loggly/ELK Stack)
13. Assign a transaction id to each log statement
14. Increase transparency using smart logging
15. Continuously analyze Performance of your code and your application
16. Document your technical debts, and clear those debts as soon as the opportunity arrives
17. Mark unfinished/incomplete part of the code, //TODO: (Technical Debt)
18. Better yet, create a fresh ticket for these //TODO
19. Document your application's API by using Swagger
20. Periodically perform Security Audit of code/project (Very important)
21. Always perform even-sided validation Client and Server-side validation both
22. Comment code to explain intent, use doc comment to document the summary functionality of functions
23. Keep comments relevant as your code evolves
24. Don't use comments as an excuse for bad code. Keep your code clean
25. Don't use clean code as an excuse to not comment at all
26. Everyone in a team should use the same code formatting strategy (Same prettier configuration everywhere)
27. Always pull/update before commit/push
28. Put some extra effort to write a good commit message. You should describe your work briefly in the commit message. First line should be the work summary. Separate the subject from the body with a newline
29. Within your PR comment write a brief overview of the functionality of your code, or why you did it the way you did it, if possible, write assumptions as well if there are any
30. Update your Jira/Github Issue task item with actions/user stories, and development checklist
31. Always make time to review other's code. Add constructive, helpful comments or solutions instead of just pointing out errors or mistakes. Code reading/reviewing improves your thought process and overall understanding of the project
32. Always constructively criticize someone else's code if they ignore any coding best practices. Point out the specific "guideline" that is not being followed
33. Always calculate estimates for tasks, add a 20% buffer to the estimate. Try to complete the task within the given estimated time. However, refrain from overestimating, and adjust your estimating strategies continuously to become adept at estimation.
34. Always challenge yourself, keep updating your estimates, if your success rate is below 70%.
35. Always tackle the hardest tasks first. Solve the most complicated problems first before solving easy tasks. However, you can always use opportunities as and when it arrives to pick low hanging fruits.
36. Don't write code that you think you might need in future, but don't need yet
37. Always remove unnecessary code, keep cleaning dead codes
38. Fail fast and fail early. Check input and fail on nonsensical input or invalid state as early as possible, preferably with an exception or error response
39. When in doubt, throw exceptions
40. Write your code defensively. Always think about what can go wrong, what will happen on invalid input, and what might fail, which will help you catch many bugs before they happen
41. If a function or method goes past 30 lines of code, consider breaking it up. The good maximum module size is about 500 lines. Test files tend to be longer than this
42. Refactor whenever you see the need and have the opportunity to do so
43. Make code correct first and fast second. Make sure your code is working as expected and tests are green; in the refactoring phase, you may optimize your code. When working on performance issues, always profile before making fixes
44. Use meaningful and pronounceable variable names (Especially as Parameters)
45. Functions should do one thing and one thing only. Practice Single Responsibility Principle
46. Function names should say what they do
47. Always Unit Test your Code (even for simple/quick fixes and one-liners)
48. Writing code is easy, but reading it is hard, sometimes incomprehensible. So, write code as if you are writing poetry, your code should be easy to read
49. Still, don't be too verbose in your coding. Remember, compact but comprehensive coding gives less surface area for bugs to hide in
50. if you are using some reference code picked from some article or StackOverflow, always include the link beside the referenced code as a comment, so that reviewers can visit the link to understand why you did what you did
51. Organize your files around product features/pages/components, not roles. Also, place your test files next to their implementation.
52. Design a rollback solution for deployments
53. Don't over-optimize your code, keep it open for extension
54. Be stateless, kill your servers almost every day
55. Serve frontend content using dedicated middleware (Nginx, S3, CDN)
56. Good habits take some time to set in, so be vigilant and mindful about your habits; keep reading this list

NOTE: If you want to update this list, please comment, I'll incorporate your changes.

Ref.
https://kkovacs.eu/software-project-best-practices-checklist
https://opensource.com/article/17/5/30-best-practices-software-development-and-testing
https://github.com/elsewhencode/project-guidelines
https://github.com/dereknguyen269/programing-best-practices
https://blog.galaxyweblinks.com/software-design-tips-aligning-ideas-through-diagrams/