Tuesday, 5 December 2017

DRY and KISS Software Development Principles

In software engineering, don't repeat yourself (DRY) is a principle of software development aimed at reducing repetition of software patterns, replacing them with abstractions; and several copies of the same data, using data normalization to avoid redundancy.


The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer. They apply it quite broadly to include "database schemas, test plans, the build system, even documentation". When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.
DRY vs WET solutions


Violations of DRY are typically referred to as WET solutions, which is commonly taken to stand for either "write everything twice", "we enjoy typing" or "waste everyone's time". WET solutions are common in multi-tiered architectures where a developer may be tasked with, for example, adding a comment field on a form in a web application. The text string "comment" might be repeated in the label, the HTML tag, in a read function name, a private variable, database DDL, queries, and so on. A DRY approach eliminates that redundancy by leveraging frameworks that reduce or eliminate all those edit tasks excepting the most important one, leaving the extensibility of adding new knowledge variables in one place.


KISS is an acronym for "Keep it simple, stupid" as a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided. Variations on the phrase include "Keep it Simple, Silly", "keep it short and simple", "keep it simple and straightforward" and "keep it small and simple".

Javascript Crash Course




1. Learn Javascript by 24 tricks:

1.1. Immediately-Invoked Function Expression (IIFE)
https://www.google.pl/search?q=js+iife&rlz=1C1GGRV_plPL752PL752&oq=js+iie&aqs=chrome.2.69i57j0l5.4121j0j7&sourceid=chrome&ie=UTF-8

1.2. Clousures
Domknięcia to funkcje których funkcje wewnętrzne odwołują się do niezależnych (wolnych) zmiennych. Innymi słowy, funkcje zdeklarowane wewnątrz domknięcia 'pamiętają' środowisko w którym zostały utworzone.
Readmore: https://developer.mozilla.org/pl/docs/Web/JavaScript/Domkniecia

2. SOLID principles in JS



3. GRASP principles in JS








UI / browser javascript
4. Projects i am proud of and why




5. Technologies in my toolbox
Webpack

https://medium.com/eventmobi/why-we-switched-to-webpack-69b7396f3ec5



6. Debugging and  profiling nodejs apps







SOLID principles

Single responsibility principle

a class should have only a single responsibility (i.e. changes to only one part of 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.”



Zasada odwracania zależności

Zasada odwracania zależności składa się z dwóch następujących części:
  1. Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Obie grupy modułów powinny zależeć od abstrakcji.
  2. Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. To szczegółowe rozwiązania powinny zależeć od abstrakcji.
Jeśli chodzi o zależność od abstrakcji, można to zamknąć w jednej prostej formule: pisany przez nas kod nie powinien być uzależniony od konkretnej klasy, zależności takie powinny kończyć się na klasach abstrakcyjnych bądź interfejsach. Zasadę zależności od abstrakcji (ang. depend on abstractions) można również streścić w trzech prostych punktach:
  • Żadna zmienna nie powinna zawierać referencji do konkretnej klasy.
  • Żadna klasa nie powinna dziedziczyć po konkretnej klasie.
  • Żadna metoda nie powinna przykrywać metody zaimplementowanej w którejkolwiek z klas bazowych.
  • Podstawowymi zaletami zasady odwracania zależności jest to, że właściwe jej stosowanie jest kluczowe, jeśli chcemy tworzyć frameworki wielokrotnego użytku. Ma ona również duży wpływ na odporność kodu źródłowego na przyszłe zmiany, ponieważ zgodnie z tą zasadą abstrakcje, a także szczegółowe mechanizmy są od siebie odizolowane, co z kolei wpływa na to, że tworzony kod jest dużo prostszy w konserwacji.