Refaktoryzacja I dług techniczny

Prezentacja na temat: "Refaktoryzacja I dług techniczny"— Zapis prezentacji:

1 Refaktoryzacja I dług techniczny

2 Refaktoryzacja „Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” Martin Fowler

3 Agenda Brzydkie zapachy Pierwsze spotkanie TDD i ciągły refaktoring
Dlaczego refaktoryzować? Kiedy Refaktoryzować? Strategia

4 Odrobina propagandy Kod trudny do zrozumienia jest trudny do modyfikacji. Kod zawierający duplikacje jest trudny do zrozumienia i modyfikacji. Kod zawierający skomplikowaną logikę jest trudny do zrozumienia i modyfikacji. Każdy głupiec potrafi napisać kod który rozumieja komputery. Dobry programista potrafi napisać kod, który rozumieją ludzie.

5 Symptomy Sztywność Delikatność Nieprznośnośc Lepkość
Zbędna komplikacja Zbędna powtarzalność Nieprzejrzystość

6 Zapaszki w kodzie Duplicated code = Zduplikowany kod
Long method = Długie metody Large class = Duże klasy Too many parameters = Zbyt wiele parametrów Feature envy = Zazdrosć o funkcjonalność. Inappropriate intimacy = obnażanie się Refused bequest = odrzucone dziedzictwo Lazy class / Freeloader = leniwe klasy Contrived complexity = Niepotrzebna komplikacja Ubercallback = ? Duplicated code: identical or very similar code exists in more than one location. Long method: a method, function, or procedure that has grown too large. Large class: a class that has grown too large. See God object. Too many parameters: a long list of parameters in a procedure or function make readability and code quality worse. Feature envy: a class that uses methods of another class excessively. Inappropriate intimacy: a class that has dependencies on implementation details of another class. Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class. See Liskov substitution principle. Lazy class / Freeloader: a class that does too little. Contrived complexity: forced usage of overly complicated design patterns where simpler design would suffice. Excessively long identifiers: in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture. Excessively short identifiers: the name of a variable should reflect its function unless the function is obvious. Excessive use of literals: these should be coded as named constants, to improve readability and to avoid programming errors. Additionally, literals can and should be externalized into resource files/scripts where possible, to facilitate localization of software if it is intended to be deployed in different regions. Ubercallback: a callback that is trying to do everything

7 Bad stinks If it stinks, change it
Kent’s Beck grandma about babies’ diapper change strategy

8 First randezvous bez zmian funkcjonalności
Refaktoryzacja: zmiana dotyczaca wewnętrznej struktury kodu, mająca na celu porawę jego czytelności i modyfikowalności bez zmian obserwowalnego zachowania tego kodu bez zmian funkcjonalności

9 TDD and continues refactoring
Red Tworzymy test, który wyraża oczekiwania odnośnie zachowania kodu. Test nie przechodzi. Green Implementujemy w jak najprostszy spsób potrzebne zachowanie. Być może naiwnie, bez optymalnego “designu”, z ew. duplikacjami itd. Refactor Możemy poprawić “design”. Ew. eksperymenty są dużo łatwiejsze z uwagi na testy, które zapewniają utrzymanie funkcjonalności. Nie refaktoryzujemy niekompilującego się kodu Nie refaktoryzujemy przy niedziałających testach

10 TDD i Ciągły refaktoring
Utrzymujemy niski poziom błędów Refaktoryzujemy bez strachu Powstaje prostszy, lepszy kod Programujemy bez stresu

11 Dlaczego refaktoryzować?
Aby łatwiej dodać nowy kod. Aby poprawić design oprogramowania. Aby uczynić kod łatwiejszym do zrozumienia. Aby uprzyjemnić development. R. ułatwia znajdowanie błędów. R. pomaga tworzyć kod szybciej.

12 Kiedy refaktoryzować? Reguła trzech:
Pierwszy raz gdy coś robisz, po prostu zrób to Za drugim razem gdy robisz cos podobnego - zastanów się Za trzecim razem popraw kod tak by unikać duplikacji

13 Kiedy refaktoryzować? Przed dodaniem nowej funkcjonalności. R. pozwala lepiej zrozumieć kod wymagający modyfikacji. R pozwala poprawić design a w konsekwencji dodać nową funkcjonalność mniejszym nakładem pracy. Przed poprawą błędów. W trakcie code review.

14 Refactoryzacja vs. projekt
Zastanowienie/project przed napisaniem jest wskazane, ale nie próbujemy za wszelka cenę znaleźć optymalnego rozwiązania. Raczej implementujemy rozsądne rozwiązanie i po lepszym zrozumieniu, zdobyciu dświadczenia ulepszamy pierwotne rozwiązanie. Niekiedy po jakimś czasie.

15 Refactoryzacja vs. projekt
Przeprojektowanie (overengineering) – refactoring pozwala raczej preferować prostotę zamiast elastyczności (na wszelki wypadek) Nigdy nie wiadomo na pewno jakie zmiany konieczne bedą w przyszłości. Złe predykcje skutkują niepotrzebną (tj. niewykorzystaną) elastycznościa (i komplikacją). Nacisk na to: Jak trudno bedzie wprowadzić zmianę (zrefaktoryzować kod) a nie na to czy elastyczność jest potrzebna?

16 Jaka strategia Gdy dodajesz/zmieniasz funkcjonalnośc, a kod nie ma najlepszej struktury najpierw refaktoryzuj tak by zmiany funkcjonalne stały się łatwiejsze. Zanim rozpoczniesz refaktoryzację upewnij się czy masz zestaw testów zapewniający bezpieczeństwo Refaktoryzuj małymi krokami. Uruchamiaj testy. Najlepszy sposób aby poprawić ew. błąd to undo. Nie optymalizuj zawczasu, skoncentruj się na prostocie designu. Użyj narzędzi do profilowania żeby upewnić się, że optymalizacja jest potrzebna.

17 Dług techniczny

18 Dług techniczny Historia metafory Definicja intuicyjna
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.“ Ward Cunningham, 1992 Definicja intuicyjna Definicja normatywna

19 Definicja normatywna Reguły projektowe Ostrzeżenia kompilatora
Zapachy w kodzie Zgodność ze standardami Metryki kodu jakościowe ilościowe

20 Dług techniczny Teoretyczne podstawy reguł projektowych
Definicja oparta na standardach nie rozróżnia przyczyn i objawów Czy definicje ilosciowe są użyteczne?

21 Ekonomia zachowań i kod
Łatwiej dodać kilka linii do istniejącej metody niż stworzyć nową metodę? Łatwiej dodać nową metodę do istniejącej klasy niż stworzyć nową klasę? Kształt kodu nie powinno być zaskoczeniem

22 Jak mierzy DT Prosta metryka:

23 Jak mierzyć DT Odległość od idealnego kodu
Co to znaczy kod idealny? Niebezpieczeństwem może być nadmierna optymalizacja (Over-Optimization) Dług techniczny – nakład pracy niezbędny do refaktoryzacji kodu nającej na celu łatwe dodanie nowej funkcjonalności.

24 Refaktoryzacja Testowalność Abstrakcje + Zrozumiałość
Ukrywanie decyzji projektowych

25 Practices Design Decision Cards Feature Trend Cards
Maintain cards for each of the design decisions you make that you may consider revisiting someday. Periodically re-estimate them to consider feasibility. Feature Trend Cards Hypothesize a couple of features that you will never add to your code. Task them and estimate them periodically. See the debt trend for areas they touch. Design Decision Cards put functionality on the client/server Internationalisation later Feature trend Cards Zakladamy funkcjonalnosc (niedodana) I estymujemy cyklicznie Przygladamy sie dlugowi poszczegolnych obszarow ktore dotykaja.

26 Practices Split prep-refactorings
Highlight refactoring within a team by making it a separate task done by different people. The handoff forces discussion

27 Practices Privileged Abstractions Architectural Mapping
Select the abstractions that you consider primary in the system and document them. Have conversations around them Architectural Mapping Diagram the system you are working as it were the terrain of an old country. Document the dragons. Have a common team vision of the place where the best code resides Cykliczna dyskusja o primary abstractions Explain the system using 4 objects

28 Practices Scratch Refactoring Suggestive Refactoring
Refactor massively in an editor. Emphasize extractions, and moves. Don’t worry about compilation. Never check it in. Use the experience to explore Suggestive Refactoring Create small refactoring stories based upon and add them to the backlog

29 Practices Limited WIP Refactoring Architectural Mapping
Never have more than 2 or 3 large scale refactorings in progress at once. This forces focus and emphasizes completion Architectural Mapping Diagram the system you are working as it it were the terrain of an old country. Document the dragons. Have a common team vision of the place where the best code resides Ń

30 Practices Silent Alarms Scrape the Pan
Don’t have check-in gates. Let people make mistakes. Investigate the mistakes off-line and see why they happened. Then, intervene Scrape the Pan Global mutable state binds code in place. Consolidate the state to make it possible pry out particular subsystems, making them independently testable Silent alarms Nie ma check-in gates. Inwestigate-offline. Niech ludzie robia bledy - I widza dlaczego sie zdarzyly W przeciwnym wypadku beda szukac obejsc. Przyklad MS FX-cop itd: zle efekty - duzo dluzsze chechiny Scrape the Pan Grupowanie globalnych mutowalnych stanow

31 Practices Direction Tagging
Create tags for areas that need work. Make them orthogonal and embed them in the code. They do not go stale as comments do. Tackle then in a limited WIP manner

32 Practices Transparent Design Quality

33 Practices Transparent Design Quality

34 Drivers Testability Abstractions Understability
Encapsulate design decision