[PL] Jak programować aby nie zwariować?

Jak programować aby
nie zwariować?
Jakub Marchwicki
04.04.2013

Co ja tu robię?ból
liczba slajdów

liczba slajdów
OK
Ryzyko
utraty
zdrowia
35 slajdów

liczba slajdów
OK
Ryzyko
utraty
zdrowia
205 slajdów

I po co to wszystko?
Bo software to nasze hobby

fach

fach
zawód

fach
zawód
przyjemność

bo płacą nam za pisanie
dokumentacji
pisanie kodu to przyjemność

Kiedy software jest dobry?
Oprogramowanie musi działać
Musi być na czas
Musi być rozbudowywalne
Modyfikowalne
Musi mieć odpowiednią jakość
Punkt wyjścia

Kiedy software jest dobry?
Musi być na czas
Modyfikowalne
To zależy???
Punkt wyjścia

Więc czym jest jakość
Dla kogoś Dla siebie
Dla kogo pracuje?

„Jakość (jak piękno) jest sądem
wartościującym, wyrażonym przez
użytkownika. Jeśli nie ma takiego
użytkownika – nie ma takiego sądu”
Platon

„Jakość to sposób myślenia,
który powoduje, że stosuje się i
bez przerwy poszukuje
najlepszych rozwiązań”
William Edwards Deming

If design is a hypothesis
how can you prove it?
Czy mój software jest dobrej jakości?

Czy mój software jest dobrej jakości?
Musi być na czas
Modyfikowalne

Jak programować aby nie zwariować?

Konkretyzacja pewnej idei
Wprowadzenie uporządkowanego
sposoby pracy
Ujęcie złożonych czynności w zestaw
powtarzalnych kroków
Framework to pewna obietnica

No więc mamy to zadanie
I ten ciekawy framework
…
Wyobraźmy sobie nowy projekt…

…w którym framework nie zadziałał

Szukamy doświadczenia, pytamy

Samodzielnie poszukujemy drogi

Porzucamy framework i robimy po staremu

I jeżeli ma szczęście do pierwszy dwóch

• Kod jest podstawowym medium
komunikacji w projekcie
• Zły kod to jak solenie herbaty koledze
z zespołu albo plucie do kanapki – a
przecież nie jesteśmy złośliwi
Wartości

• Jako zespół jesteśmy jednością
– Jak ja pójdę na skróty, to kolega
będzie się męczył
– I jako całość i tak będziemy
nieefektywni
Wartości

• Programy są częściej czytane niż
pisane
• Więcej czasu poświęcamy na
modyfikację istniejącego kodu niż na
tworzenie nowego
Implementation Patterns

• Komunikacja – kod źródłowy powinno
się czytać jak książkę
• Prostota – wprowadzaj złożoność
tylko wtedy, kiedy jest to konieczne
• Elastyczność – elastyczność to
dodatkowa złożoność, więc
wprowadzaj ją tylko tam gdzie to
konieczne
Implementation patterns

• Lokalne konsekwencje – zmiana w
jednym miejscu nie powoduje zmian w
innych
• Minimalne powtórzenia – DRY

• Dane i logika razem – ponieważ dane
i logika z reguły zmieniają się w tym
samym czasie
• Symetria – utrzymuj podobny poziom
abstrakcji w obrębie metody / klasy

„Czysty kod jest prosty i bezpośredni.
Czysty kod czyta się jak dobrze
napisaną prozę. Czysty kod nigdy nie
zaciemnia zamiarów projektanta; jest
pełen trafnych abstrakcji i prostych
ścieżek sterowania.”
Grady Booch – to jeden z tych panów od UMLa

• Po prostu głęboko wierzymy że dobry
kod nam pomoże
• Choć nie wiemy jak, intuicyjnie
staramy się go stosować
• Z pokorą przyjmujemy karcący wzrok
mnicha
Nie wiemy że nie wiemy

• Uczymy się… bez wnikania w kontekst
 Nazywaj zmienne w taki a taki sposób
 Stosuj komentarze w takich a nie innych
przypadkach
 Dziel funkcje na części zgodnie z takimi
a takimi zasadami
• Z czasem zobaczymy że z czystym
kodem lepiej się pracuje… tak po
ludzku

Nasz mózg lepiej reaguje na czysty kod
• Utrzymujemy koncentrację
• Nie gubimy wątków, swobodniej
podążamy tokiem myślenia
• Cognitive load – możemy pomieścić
poszczególne kawałki kodu w głowie
więc potrafimy się miedzy nimi
swobodnie przemieszczać

• Nazwy
• Funkcje
• Komentarz
• Formowanie kodu
• Obiekty i struktury danych
• Obsługa błędów
Poziom I

• Nazwy
• Funkcje
• Komentarz
• Formatowanie kodu
• Obiekty i struktury danych
• Obsługa błędów
Poziom I

• Nazwy zmiennych, metod, klas
powinny być wystarczająco opisowe
aby zrozumieć jaką wartość
przetrzymuje zmienna i jaką czynność
wykonuje metoda.
Zmienne

• Nazwy nie powinny wymagać
dodawania komentarza
• Nazwy zmiennych nie mogą
wprowadzać w błąd!
• Nazwy metod nie mogą ukrywać
funkcjonalności!
Nazewnictwo

int d1; //dni od rozpoczęcia
int d2; //dni do zakończenia
int d3; //dni wolnych
int daysSinceStart;
int daysTillEnd;
int daysOf;
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
} public List<int[]> getDates() {
List<int[]> dateList = new ArrayList<int[]>();
for (int[] week : theWeeksArray)
if (week[0] == BEGIN_DATE)
dateList.add(x);
return dateList;
}

for (int i=0; i<10; i++){
k += ((l[i]*1.5) / 3 );
}
float milleageRate;
const int NUMER_OF_EMPLOYEE = 3;
float sum = 0;
for ( int i=0; i<numberOfTrips; i++ ){
float totalCompensation = tripLength[i] * milleageRate;
float deduction = totalCompensation / NUMER_OF_EMPLOYEE;
sum += deduction;
}

• Korzystaj z nazw, które można
wymówić
Ułatwiają zapamiętywanie
Umożliwiają swobodną dyskusję o kodzie
Nazwewnictwo

public class CsmrDt {
public void crtshpcrt() {/*...*/};
public void remcrt() {/*...*/};
private final int ssntm = 10;
/*...*/
}
public class CustomerDataset {
public void createShoppingCart() {/*...*/};
public void removeCart() {/*...*/};
private final int sessionTimeout = 10;
/*...*/
}

• Używaj rzeczowników lub wyrażeń
rzeczownikowych do nazywania klas
np.: Customer, Account, Page
• Nie nazywaj klas za pomocą
czasowników
• Używaj nazw konkretnych a nie
“wszystkoznaczących”
ManagerFactoryProcessor
Klasy

• Używaj czasowników lub wyrażeń
czasownikowych do nazywania metod np.:
addUser, deleteCustomer, update
• Twórz nazwy metod tak, aby wyrażały to co
robią
Metody

• Nazwy powinny sugerować co zwracają
• Nazwy muszą mówić o całym zakresie
funkcjonalności
Metody
String findLastNameOfCustomerWithId(long customerId){...}
Map<Long, Customer> customers;
Customer getCustomer(Long id){
Customer customer = customers.get(id);
if(customer == null){
customer = createNewCustomer(id);
}
return customer;
}

• Bądź konsekwentny i używaj tych samych
słów do określania podobnych czynności,
np.: add, get, DeviceManager,
ProtocolController
Metody

• Zasada pierwsza:
funkcje powinny być małe
• Zasada druga:
funkcje powinny być jeszcze mniejsze
Funkcje

Functions should do one thing.
Should do it well
Should do it only!
Funkcje

Funkcje
• Korzystaj z nazw dokładnie opisujących
przeznaczenie funkcji
• Nie obawiaj się konstruowania długich nazw
• Stosuj spójne nazwy - wykorzystuj te same frazy,
rzeczowniki czy czasowniki dla funkcji
wykonujących analogiczne operacje
• addCustomer, putItemToBasket
• UserSettings, AdminConfiguration
• Nie ukrywaj funkcjonalności za złymi nazwami
funkcji

Funkcje
• Pisz funkcje zawierające jak najmniejszą liczbę
argumentów
• Funkcją idealną jest funkcja bezargumentowa
• Dopuszczalne są funkcje
jedno- i dwuargumentowe
• Unikaj funkcji już z trzema argumentami
• Funkcje posiadające więcej niż trzy argumenty
stosuj tylko w uzasadnionych sytuacjach

writeField(outputStream, name);
outputStream.writeField(name);
createSquare(width, height);
calculateRectangularPrismVolume(double height,
double width, double depth);
calculateRectangularPrismVolume(Area rectangle,
double depth);

Funkcje
• Stosuj wyjątki zamiast zwracania
kodów błędów
• Korzystanie z kodów błędów tworzy
głęboko zagnieżdżone struktury
• Wyjątki pozwalają na oddzielenie
przetwarzania błędów od prawidłowej
ścieżki wykonywania kodu

if (changeDate(date) == OK) {
if (dateFilled(date) == OK) {
if (dateFromFuture(date) == OK) {
System.out.println("Data została zmieniona.");
} else {
System.out.println("Data niepoprawna.");
}
} else {
System.out.println("Brak podanej daty.");
}
} else {
System.out.println("Błąd podczas zmiany daty.");
return ERROR;
}
try {
changeDate(date);
dateFilled(date);
dateFromFuture(date);
}
catch (Exception e) {
System.out.println(e.getMessage());
}

Funkcje
DRY – Don’t repeat yourself
• Duplikacja zmniejsza czytelność
• Zwiększa koszty utrzymania, refactoringu i
poprawiania błędów
• Prowadzi do rozbieżności funkcjonalnej
modułów wykonujących to samo
• Zmniejsza reusability kodu

Funkcje
Jeden poziom abstrakcji na funkcje
• Nie realizuj w funkcji zadań które operują
na innych poziomach abstrakcji
• Pomieszane poziomy abstrakcji
zmniejszają czytelność kodu, utrudniają
zrozumienie logiki i prowadzą do
zwiększenia duplikacji kodu

Komentarze
„Nie komentuj złego kodu – popraw go”
Brian W. Kernighan i P.J. Plaugher

Komentarze
Są złe bo
• Często się powtarzają
• Są mylące
• Nadmiarowe
• Klamry zamykające
• Zakomentowany kod
• Informacje nielokalne
• Nie są utrzymywane

Komentarze
• Konieczność dodania komentarza
oznacza zazwyczaj kod do
poprawienia
• Napraw i uporządkuj zły kod a nie
komentuj

//Sprawdzenie czy klient ma możliwość korzystania ze zniżki
if (customer.isStudent() ||
(customer.age < 18) || (customer.age > 65))
if (customer.isEligibleForDiscount())

Komentarze
Bywają dobre, np:
• Komentarze prawne
• Komentarze informacyjne
• Wyjaśnienia
• Ostrzeżenia
• Komentarze TODO
// Dopasowany format kk:mm:ss EEE, MMM dd, yyyy
Pattern timeMacher = Pattern.compile("d*:d*:d* w*, w* d*, d*")

Komentarze
• Nieprawdą jest, że wszystkie funkcje
powinny posiadać Javadoc, a każda
zmienna komentarz
• Ten typ komentarzy powoduje
zaciemnianie kodu i dezorganizację

public abstract class ContainerBase implements
Container, Lifecycle, Pipeline,
MBeanRegistration, Serializable {
/**
* The processor delay for this component.
*/
protected int backgroundProcessorDelay = -1;
/**
* The lifecycle event support for this component.
*/
protected LifecycleSupport lifecycle = new LifecycleSupport(this);
/**
* The container event listeners for this Container.
*/
protected ArrayList listeners = new ArrayList();
/**
* The Loader implementation with which this Container is associated.
*/
protected Loader loader = null;
/**
* The Logger implementation with which this Container is associated.
*/
protected Log logger = null;
/**
* Associated logger name.
*/
protected String logName = null;
/**
* The Manager implementation with which this Container is associated.
*/
protected Manager manager = null;

„If you decide to write a comment, then
spend the time necessary to make sure it is
the best comment you can write”
Robert C. Martin
Komentarze

Formatowanie
• Konwencje formatowania w zespole.
Ustal i się ich trzymaj

Formatowanie
• Odpowiednie formatowanie kodu
ułatwia czytanie klasy.
• Redukuje czas potrzebny na szukanie
składowych, konstruktorów itp.
• Nie musimy przeglądać całej klasy aby
sprawdzić czy ma konstruktor bo
wiemy dokładnie gdzie go szukać

• Ukrywaj szczegóły techniczne i stosuj
terminy abstrakcyjne
Abstrakcja danych
public static interface Vehicle {
double getFuelTankCapacityInGallons();
double getGallonsOfGasoline();
}
public static interface Vehicle {
double getPercentFuelRemaining();
}

• Prawo Demeter – zasada minimalnej
wiedzy
• Moduł powinien nie wiedzieć nic o
wnętrzu obiektów, którymi manipuluje
Prawo Demeter

• Prawo Demeter głosi, że metoda f
klasy C powinna wywoływać tylko
metody z:
• Klasy C,
• Obiektu utworzonego przez f,
• Obiektu przekazanego jako argument f,
• Obiektu umieszczonego w zmiennej
instancyjnej klasy C.
Prawo Demeter

• Możesz bawić się ze sobą
• Możesz bawić się własnymi
zabawkami (ale nie możesz ich
rozbierać)
• Możesz bawić się zabawkami które
dostałeś
• Możesz bawić się zabawkami które
zrobiłeś samodzielnie
Prawo Demeter

final String outputDir = context.getOptions().getScratchDir().getAbsolutePath();
Options options = context.getOptions();
File scratchDir = options.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();

// before refactoring
class Customer {
String getMailingAddressLine1();
String getShippingAddressLine1();
}
class Employee {
String getHomeAddressLine1();
}
public void method() {
customer.getMailingAddressLine1();
employee.getHomeAddressLine1();
}

class Customer {
}
class Employee {
}
}
// after refactoring, before Demetering
class Address {
String getLine1();
String getLine2();
}
Class Customer {
Address getMailingAddress();
Address getShippingAddress();
}
class Employee {
Address getHomeAddress();
}
customer.getMailingAddress().getLine1();
employee.getHomeAddress().getLine1();
}

class Customer {
}
class Employee {
}
}
// after refactoring, before Demetering
class Address {
String getLine1();
String getLine2();
}
Class Customer {
}
class Employee {
}
customer.getMailingAddress().getLine1();
employee.getHomeAddress().getLine1();
}
//after Demeterizing
class Address { // same as above
String getLine1();
String getLine2();
}
class Customer {
}
class Employee {
}
}

• Ukrywaj szczegóły wnętrza obiektów
• Nie łam hermetyzacji bez powodu,
łatwiejsze pisanie testów nie jest
powodem
Prawo Demeter
BufferedOutputStream bos =
context.createScratchFileStream(classFileName);

• Za idealną formę struktur danych
przyjmuje się obiekty transferu danych
(DTO)
• Są przydatne do komunikowania się z
bazą danych, analizowania
komunikatów z gniazd sieciowych itp.
Data Transfer Objects

• DTO są to mogą być klasy
pozbawione funkcji, ale ze zmiennymi
publicznymi
• Częściej spotykaną formą jest postać
typu beans
• Posiada ona zmienne prywatne, do
których dostęp uzyskuje się za
pomocą getterów i setterów
Data Transfer Objects

public class Client {
private String name;
private String lastName;
private long clientId;
public Client(long clientId, String name, String lastName) {
this.clientId = clientId;
this.name = name;
this.lastName = lastName;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getLastName() {
return lastName;
}
public void setlastName(String lastName) {
this.lastName = lastName;
}
public long getClientId() {
return clientId;
}
}

Budowanie oprogramowania z
wykorzystaniem struktur danych
wpływa w przyszłości na:
Budowanie oprogramowania z
wykorzystaniem obiektów wpływa na:
łatwość i elastyczność dodawania
nowych funkcji – dodanie nowej
funkcji nie wymaga zmiany żadnej ze
struktur
łatwość i elastyczność w dodawaniu
nowych obiektów – nie wymaga
zmiany żadnych funkcji ani innych
obiektów
trudność dodawania nowych struktur
– musimy zmienić wszystkie funkcje
trudność dodawania nowych funkcji –
musimy zmienić wszystkie obiekty
Obiekty vs struktury danych

• Mówiliśmy o kodach błędu i wyjątkach
• O blokach try-catch-finally

• Grupuj wyjątki ze względu na kontekst i
zachowuj symetrię w kodzie
• Osłaniaj wyjątki:
• przechwytuj i przekształcaj zgłaszane wyjątki
• uniezależniaj się od wyjatków wprowadzonych przez
API, używaj wyjątków specyficznych dla własnej
aplikacji
Klasy wyjątków

ACMEPort port = new ACMEPort(12);
try {
port.open();
} catch (DeviceReponseException e) {
reportPortError(e);
logger.log("Wyjątek odpowiedzi urządzenia", e);
} catch (ATM1212UnlockedException e) {
reportPortError(e);
logger.log("Wyjątek odblokowania", e);
} catch (GMXError e) {
reportPortError(e);
logger.log("Wyjątek odpowiedzi urządzenia");
} finally {
/*...*/
}

ACMEPort port = new ACMEPort(12);
try {
port.open();
} catch (DeviceReponseException e) {
reportPortError(e);
logger.log("Wyjątek odpowiedzi urządzenia", e);
reportPortError(e);
logger.log("Wyjątek odblokowania", e);
reportPortError(e);
logger.log("Wyjątek odpowiedzi urządzenia");
} finally {
/*...*/
}
LocalPort port = new LocalPort(12);
try {
port.open();
} catch (PortDeviceFailure e) {
reportError(e);
logger.log(e.getMessage(), e);
} finally {
/*...*/
}
public class LocalPort {
private ACMEPort innerPort;
public LocalPort(int portNumber) {
innerPort = new ACMEPort(portNumber);
}
public void open() {
try {
innerPort.open();
} catch (DeviceResponseException e) {
throw new PortDeviceFailure(e);
}
}
/*...*/
}

• Wykorzystuj zgłaszanie wyjątków lub
zwracanie obiektu specjalnego
przypadku
Zwracanie null
List<Item> items = getItems();
if (items != null) {
for (Item i : items) {
totalCost += i.getCost();
}
}
List<Item> items = getItems();
for(Item i : items) {
totalCost += i.getCost();
}

public interface Animal {
public void makeSound();
}
public class Dog implements Animal {
public void makeSound() {
System.out.println("woof!");
}
}
public class NullAnimal implements Animal {
public void makeSound() {
}
}

• Przekazywanie null jest gorsze od
jego zwracania
Przekazywanie null
public class MetricsCalculator {
public double rectanglePerimeterCalculate(
double x, double y) {
return 2 * (y + x);
}
/* ... */
}

• Defensive programming
Przekazywanie null
public class MetricsCalculator {
if (x == null || y == null) {
throw InvalidArgumentException("Niewłaściwy
argument.");
}
return 2 * (y + x);
}
} public class MetricsCalculator {
assert x != null : "x nie może być null";
assert y != null : "y nie może być null";
return 2 * (y + x);
}
}

• SOLID
• Zasady programowania obiektowego
• Zasady projektowania obiektowego
Poziom II

SOLIDny programista
• The Single Responsibility Principle – klasa
powinna mieć tylko jeden powód do zmiany
• The Open Closed Principle – klasę można
łatwo rozszerzać, nie modyfikując jej
• The Liskov Substitution Principle – klasy
pochodne muszą być przeźroczystymi
zamiennikami klasy nadrzędnej

• The Interface Segregation Principle – dla
różnych klientów twórz osobne interfejsy
• The Dependency Inversion Principle –
bądź zależny od abstrakcji a nie od
konkretnych implementacji
SOLIDny programista

• Należy znać hierarchię dziedziczenia, aby
zrozumieć metodę
• Kod metody polimorficznej jest rozrzucony
po kilku klasach
• Nie zawsze jest oczywisty stan obiektu, z
którego dziedziczymy
• Dodatkowe elementy (pola, metody) są
mocno związane (coupling) z klasą
nadrzędną
Kompozycja i dziedziczenie

• Niezależność klas zawieranych
• Można je używać w wielu kontekstach
• Niskie związanie (coupling)
• Łatwiej testować
Kompozycja i dziedziczenie

• Odpowiedzialność – tylko jedna
 obiekty maja własną osobowość,
unikaj schizofrenicznych obiektów
• Enkapsulacja – to co się zmienia
enkaspuluj
• Preferencja kompozycji ponad
dziedziczenie

• Dokładanie ponad modyfikacje
– Gdy dodajemy nową funkcjonalność raczej dokładamy
nowe byty niż modyfikujemy istniejące.
• Lokalne zmiany
– Zmiana ma konsekwencje lokalne, a nie globalne.
Zasięg rażenia zmian jest jak najmniejszy.
• Nieinwazyjność zmian
– Dodanie nowych rzeczy (odpowiedzialności,
funkcjonalności, zachowań) do istniejących bytów jest
przezroczyste ich dla klientów.

public class Sql {
public Sql(String table, Column[] columns)
public String create()
public String insert(Object[] fields)
public String selectAll()
public String fieldByKey(
String keyColumn, String keyValue)
private String ColumnList(Column[] columns)
private String valuesList(
Object[] fields, final Column[] columns)
}

abstract public class Sql {
public Sql(String table, Column[] columns)
abstract public String generate();
}
public class CreateSql extends Sql {
public CreateSql(String table, Column[] columns)
@Override public String generate()
}
public class SelectSql extends Sql {
public SelectSql(String table, Column[] columns)
}
public class InsertSql extends Sql {
public InsertSql(String table, Column[] columns)
private String valuesList(Object[] fields, final Column[] columns)
}
public class FindKeyBySql extends Sql {
public FindKeyBySql(String table, Column[] columns, String keyColumn, String keyValue)
}
public class ColumnList {
public ColumnList(Column[] columns)
public String generate()
}

Odpowiedzialność. Enkapsulacja. Kompozycja
• To co leży u podstaw możemy
stosować na każdym poziomie
• Projektując klasy
• Projektując moduły, komponenty
• Projektując systemy

• Każdy wzorzec opisujemy w trzech
kontekstach:
 Odpowiedzialność
 Enkapsulacja / hermetyzacja
 Kompozycja
Wzorce projektowe

• Rozdziela i przesłania implementację
zachowań, czynności.
• Hermetyzujemy zmienny sposób
tworzenia obiektów
• Nowe funkcjonalności uzyskujemy
poprzez dodawanie komend, poprzez
kompozycję.
Wzorce projektowe: komenda

• Każdy element systemu:
 Ma swoją odpowiedzialność
 Hermetyzuje pewne zachowania
 Składa się z kilku współpracujących
elementów
Moduły

• Boundary: zewnętrzny interfejs,
kontrakt, fasada
• Control: logika biznesowa,
implementacja
• Entity: persystencja
Boundary. Control. Entity

• Każdy framework opisujemy w trzech
zdaniach:
 Odpowiedzialność
 Enkapsulacja
 Preferowanie kompozycji
Frameworki

• Pozwala na obiektowy dostęp do bazy
danych
• Enkapsulujemy typ bazy, sposób
dostępu do danych
• Preferencja kompozycji (?)
ORM

• Nie ważne czy na poziomie klasy,
modułu, frameworka – stosujemy te
same bazowe pojęcia
• Dedukujemy, indukujemy –
posługujemy się doświadczeniem
• Rozumiemy że nie ma uniwersalnych
rozwiązań – ważny jest kontekst.

• Spring czy EJB
Nie ma idealnych rozwiązań

• Spring czy EJB
• JSF czy JSP

• Spring czy EJB
• JSF czy JSP czy Velocity

• Spring czy EJB
• JPA czy iBatis

• Spring czy EJB
• JPA czy iBatis czy JDBC

• Spring czy EJB
• MVC czy MVP

• Spring czy EJB
• MVC czy MVP
• Java czy .NET

• Spring czy EJB
• MVC czy MVP
• Java czy .NET czy Python

• Spring czy EJB
• MVC czy MVP
• Java czy .NET czy Python czy PHP

Bo nasz mózg pracuje zupełnie inaczej

Affordance
a quality of an object, which
allows an individual to perform
an action. For example, a knob
affords twisting, and perhaps
pushing, while a cord affords
pulling

• Pytamy doświadczonego kolegę
Co robimy gdy robi się gorąco

• Sami szukamy drogi

• Próbujemy na siłę

• Próbujemy na siłę
• Porzucamy i wracamy do
nawyków

Single
Responsibility
Open Closes
Principle
Liskov Substitution
Interface
Segregation
Dependency
Injection
Singletons
Tight Coupling
Untestable Code
Premature
Optimization
Indescriptive
Naming
Duplication

• Nie ma kodu perfekcyjnego
• Ale jest wystarczająco dobry
 modyfikowalny
 refaktoryzowalny
 „disposible” over „maintainable”
• Kod który mogę w każdej chwili
wyrzucić i wymienić
Tworzymy dobry kod

Jak żyć?
2010
2009
2009
2008

Jak żyć?
2010
2009
2009
2008
2007

Jak żyć?
2002
1996 / 2000
2002

Jak żyć?
2002
1996 / 2000
2002
1994

jmarchwicki@ydp.eu
http://marchwicki.pl/blog
@kubem
Shu-Ha-Ri

[PL] Jak programować aby nie zwariować?

Recommended

Recommended

More Related Content

Similar to [PL] Jak programować aby nie zwariować?

Similar to [PL] Jak programować aby nie zwariować? (20)

More from Jakub Marchwicki

More from Jakub Marchwicki (6)

[PL] Jak programować aby nie zwariować?