Repozytorium Web Developera

Clean code and architecture



  • Single Responsibility Principle (SRP)
  • Open/Closed Principle (OCP)
  • Liskov Substitution Principle (LSP)
  • Interface Segregation Principle (ISP)
  • Dependency Inversion Principle (DIP)
  • Zasady OOP

  • inheritance
  • encapsulation
  • polimorphims
  • abstractions
  • 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


    • 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


    • 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





    Error Handling



    Folder structure

    Helpers vs Utils

    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