Clean code and architecture
JavaScript
- Designing very large JavaScript applications
Tests are not only for testing that your math functions do the right thing. They are also for infrastructure and for the major design features of your application.
SOLID
Zasady OOP
Zasady FP
3rs of software architecture
readable, reusable, refactorable software
- Refactorability
- Refactor without breaking the system
- Reusability
- Modules are reusable
- Functions are small
- Side effects are avoided
- Readability
- Code is consistently formatted
- Variables are named well
- Functions are documented
Clean code
Variables
- Use meaningful and pronounceable variable names
- Use the same vocabulary for the same type of variable
- Use searchable names and name constants
- Use explanatory variables
- Avoid Mental Mapping
- Don't add unneeded context
- Use default arguments instead of short circuiting or conditionals
Functions
- Function arguments (2 or fewer ideally)
- Functions should do one thing
- Function names should say what they do
- Functions should only be one level of abstraction
- Remove duplicate code
- Set default objects with Object.assign
- Don't use flags as function parameters
- Avoid Side Effects (part 1)
- Avoid Side Effects (part 2)
- Don't write to global functions
- Favor functional programming over imperative programming
- Encapsulate conditionals
- Avoid negative conditionals
- Avoid conditionals
- Avoid type-checking (part 1)
- Avoid type-checking (part 2)
- Don't over-optimize
- Remove dead code
Objects and Data Structures
Classes
SOLID
Testing
Concurrency
Error Handling
Comments
Translation
Folder structure
Helpers vs Utils
- https://github.com/erikras/react-redux-universal-hot-example/issues/808
- https://stackoverflow.com/questions/30273993/javascript-best-way-to-structure-helpers-functions-in-nodejs
Utils is a place where you can place small snippets you can use throughout the application. Small functions to build bigger things with.
Helpers is more of a place where you store code architectural snippets in my view. Things essential for bootstrapping components and developer ergonomics.
Dług technologiczny
Otóż dług technologiczny może występować przy zastosowaniu dowolnej metodologii. Jest od niej niezależny. Dług technologiczny pojawia się tam, gdzie pojawia się niedbałość, spowodowana czasami brakiem kompetencji programistów, ale znacznie częściej, lub nawet prawie zawsze, złym, nieodpowiedzialnym zarządzaniem projektem. Nawet przeciętny programista jest w stanie po sobie posprzątać, jednak jeżeli product owner widzi tylko nowe funkcjonalności, a project manager nie jest wstanie wynegocjować czas na spłatę długu technologicznego, skutek jest opłakany. Źródło