Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
3 Cards in this Set
- Front
- Back
|
Design principles - SOLID - DRY - KISS - YAGNI - Worse is better - convention over configuration - separation of concerns - principle of least knowledge - tourist principle - single source of truth - single version of the truth |
SOLID Single responsibility principle a class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class) Open/closed principle “software entities … should be open for extension, but closed for modification.” Liskov substitution principle “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract. Interface segregation principle “many client-specific interfaces are better than one general-purpose interface.” Dependency inversion principle one should “depend upon abstractions, [not] concretions." DRY: don't repeat yourself KISS: keep it simple, stupid YAGNI: "You aren't gonna need it", i.e. don't implement until needed. Worse is better: It is the idea that quality does not necessarily increase with functionality—that there is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse. convention over config: The phrase essentially means a developer only needs to specify unconventional aspects of the application. For example, if there is a class Sales in the model, the corresponding table in the database is called "sales" by default. It is only if one deviates from this convention, such as calling the table "product sales", that one needs to write code regarding these names. separation of concerns: a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern, e.g. HTML vs CSS vs JS principle of least knowledge - Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. - Each unit should only talk to its friends; don't talk to strangers. - Only talk to your immediate friends. |
|
|
Drawbacks of not using separation of concerns? |
Adding new features will take an order of magnitude longer Impossible to optimize Extremely difficult to test Fixing and debugging can be a nightmare (fixing something in one place can lead to something else breaking that seems completely unrelated). |
|
|
Describe microservices and their pros |
a style of software architecture that involves delivering systems as a set of very small, granular, independent collaborating services. Pros: The services are easy to replace, Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best |
