Refaktoryzacja I dług techniczny

Slides:



Advertisements
Podobne prezentacje
Jak utkać swoją własną sieć? Dominika Miernik i Dorota Szczerbak
Advertisements

Jarosław Kuchta Jakość Oprogramowania
Projekt Do kariery na skrzydłach – studiuj Aviation Management Projekt współfinansowany ze ś rodków Europejskiego Funduszu Społecznego. Biuro projektu:
Opis metodyki i procesu produkcji oprogramowania
Jak radzić sobie ze stresem w pracy „How To Deal With Stress At Work”
Refaktoryzacja czyli odświeżanie kodu
Języki programowania obiektowego
Jak napisać dobry projekt w 7. Programie Ramowym
-Witam nazywam się Weronika Zgorzelska oraz Oliwia Kołakowska. -Witam serdecznie 1.Od kiedy pan gra w FC Barcelonie… -W FC Barcelonie gram od 13 roku.
GRAMATYKA Zastosowanie czasowników SHOULD i OUGHT TO.
Zestawienie wyników badań Researches summary. 1. Czy Twoi rodzice uprawiają jakieś sporty lub w inny aktywny sposób spędzają wolny czas poświęcając im.
Present Simple vs. Present Continuous
Szkoła Podstawowa im. Adama Mickiewicza w Skalmierzycach
I ETAP realizowany na przełomie marca i kwietnia Korzenie cywilizacji Wyprawa w górę Nilu Odkrywanie przeszłości-Dlaczego Mumia nie wstaje Warsztaty ceramiczne.
Egzamin maturalny ustny z języka obcego obowiązujący od roku szkolnego 2011/2012 Prezentacja przygotowana na podstawie informacji zawartych w informatorze.
Wyobraź Sobie… NAJNOWSZY PRODUKT! Broadcasting do nielimitowanej ilości odbiorców Najnowsza i JEDYNA tego typu Technologia Streamingu.
Present simple vs Present continuous
Author: Welcome to London's history and culture.
Deutsche Bank PBC Finansowanie eksportu w Deutsche Bank PBC
Refaktoryzacja Robert Pająk.
Surowosc obyczajow w Arabii Saudyjskiej Cruelty in Saudi Arabia.
Music: Nightengale Serenade
SZKOŁA Z KLASĄ 2.0 English SOS.
How to make an application on Step by Step Instructions
SHOPPING- ROBIENIE ZAKUPÓW.
Wydział Elektroniki Kierunek: AiR Zaawansowane metody programowania Wykład 5.
Hallo again! Your task is to translate the following sentences paying close attention to : Verb + ing To + infinitive Infinitive.
The History St. Peter and Paul's Church.. The end of work Miner1: We are buried. Miner2: We can' t go out. bury-zasypać Koniec pracy Górnik1: Jesteśmy.
 Primary School no 17  John Paul II, Chorzow, Poland  Made by Monika Winkler`s Project Group.
Rights of the child. Kliknij, aby edytować format tekstu konspektu Drugi poziom konspektu  Trzeci poziom konspektu Czwarty poziom konspektu  Piąty poziom.
Przetwarzanie sprzedaży z wykorzystaniem strony trzeciej (bez awiza dostawy) SAP Best Practices.
OOP, Desing Patterns … and more Michał Dubel
Polsko-Norweski Fundusz Badań Naukowych / Polish-Norwegian Research Fund Testowanie metriksów czyli do czego jesteśmy zobowiązani zapisami aplikacji Warsztaty.
Wstęp do Fizyki Środowiska - Podstawy mechaniki płynów Problems 1 Lecture 1 1)In a vertical capillary filled with water air bubbles are rising Sketch the.
CROSSWORD: SLANG. Konkurs polega na rozwiązaniu krzyżówki. CROSSWORD: SLANG Wypełnione karty odpowiedzi prosimy składać w bibliotece CJK, lub przesyłać.
… there was someone in the past who said: „To earn million you need billion”. In my opinion, it’s true.
Conditionals Tryby warunkowe.
Zwrot going to – określa nasze plany na przyszłość lub przewidywania:
Les meilleures photos de L'année 2005 D'après NBC A life for two, full of tenderness, obtains happiness as they get closer to heaven. Życie we dwoje,
Gry i zabawy poznane w Hiszpanii
Komponentowe i rozproszone Interludium czyli krótki wykład o rozpraszaniu.
Paulina Kowalczyk Dominika Struzik I LO Tadeusz Kosciuszko in Wielun POLAND.
You are about to see a few sentences in Polish. Try to translate them into English, but keep in mind they are: The First Conditonal The Second Conditional.
Which of the following two restaurants do you prefer? Któr ą z tych dwóch restauracji ty by ś wybrał ?
Hallo again! Your task is to translate the following sentences paying close attention to : Verb + ing To + infinitive Infinitive.
S: Present Simple vs Present Continuous.
JOB SEARCH IS A JOB Career planning is building bridges from one’s current job/career.
Przetłumacz podane w nawiasach fragmenty zdań na j. angielski.
Development of rural tourism and agritourism Experience of the past 20 years Elżbieta Wyrwicz Department of Tourism 3rd International Conference AGROTRAVEL.
Refaktoryzacja „Any fool can write a code that computer understands. Good programers write code that human can understand” – Martin Fowler.
Zdania okolicznikowe przyczyny clauses of reason.
Marcin Gliński Instytut Języków Romańskich i Translatoryki UŚ Regionalny Ośrodek Doskonalenia Nauczycieli WOM w Katowicach NOCNE POWTÓRKI MATURALNE 2016.
C PRZEWODNIK PO NAJCIEKAWSZYCH MIEJSCACH WROCŁAWIA - GUIDE TO THE MOST INTERESTING PLACES OF WROCLAW Cześć jestem Krzysztof. Dziś będę pokazywał Ci Najciekawsze.
Zdania okolicznikowe skutku informują o skutku zdarzenia lub czynności. Odpowiadają na pytania: z jakim skutkiem? co miało miejsce w związku z tym? i.
Www,mojesilnedrzewo.pl. W dniach 15 marca – 30 kwietnia 2010.r.wytwórnia wody mineralnej Żywiec Zdrój SA wspólnie z Fundacją Nasza Ziemia i Regionalną.
Opracowanie: Katarzyna Gagan, Anna Krawczuk
Music: Nightengale Serenade
Music: Nightengale Serenade
Forest fire protection
Najlepszy czas na działanie jest TERAZ!
Przetestuj Usability Mateusz Kaczmarek
Trudny czy łatwy labirynt?
SafeSurfing Moduł 1 Jak bezpiecznie korzystać z internetu i jak chronić swoje dane osobowe?
A prototype of distributed modelling environment
Running Dictation Activity to Engage Students in Reading, Writing, Listening, and Speaking.
Polish L3 Learning Pack Saying your name
Sport in Bydgoszcz There are many clubs in Bydgoszcz where people practise various sports, e.g. athletics, rowing, speedway, basketball, volleyball and.
zl
1) What is Linux 2) Founder and mascot of linux 3) Why Torvalds created linux ? 4) System advantages and disadvantages 5) Linux distributions 6) Basic.
Refaktoryzacja czyli odświeżanie kodu
Zapis prezentacji:

Refaktoryzacja I dług techniczny

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

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

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.

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

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 = ? http://blog.codinghorror.com/code-smells/ 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

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

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

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

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

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.

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

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.

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.

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?

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.

Dług techniczny

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

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

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

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

Jak mierzy DT Prosta metryka:

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.

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

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.

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

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

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

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 Ń

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

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

Practices Transparent Design Quality

Practices Transparent Design Quality

Drivers Testability Abstractions Understability Encapsulate design decision