How to fix a code to not corrupt an application
•Transferir como PPTX, PDF•
0 gostou•2,505 visualizações
How to find most effective place to start refactoring a code? How to plan and process refactoring to hold stable application? Is refactoring an action or process?
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a How to fix a code to not corrupt an application
Semelhante a How to fix a code to not corrupt an application (20)
Mais de Michal Lukaszewski
Mais de Michal Lukaszewski (9)
Último
Último (20)
How to fix a code to not corrupt an application
- 1. How to fix a code to not corrupt an app Michał Łukaszewski Software Engineer, Intel /m_lukaszewski
- 10. • Refactoring is (continuous) process, not an action.
- 12. When you look into an abyss, the abyss also looks into you. Friedrich Nietzsche
- 14. Technical
- 16. • Refactoring is (continuous) process, not an action. • Refactoring is not • Bugfix, • Security fix, • Optimization.
- 19. Martin Fowler
- 22. • Refactoring is (continuous) process, not an action. • Refactoring is not • Bugfix, • Security fix, • Optimization. • Refactoring should provide (a lot of small) improvements.
- 24. Is it mess?
- 25. Or complex?
- 27. Team changed?
- 32. Michael Feathers
- 40. • Refactoring is (continuous) process not an action. • Refactoring is not • Bugfix, • Security fix, • Optimization. • Refactoring should provide (a lot of small) improvements. • Refactoring should be founded on knowledge (measures).
- 48. • Refactoring is (continuous) process, not an action. • Refactoring is not • Bugfix, • Security fix, • Optimization. • Refactoring should provide (a lot of small) improvements. • Refactoring should be founded on knowledge (measures). • Refactoring should improve only what needs improvement.
- 51. 改善
- 52. 改善 Kai Zen
Notas do Editor
- Sakichi Toyoda Przemysł włókienniczy Wynalazca krosna zatrzymującego się przy zerwanej nici Automatyzował swoją fabrykę
- Kiichirō Toyoda Syn Sakichi W 1930 wyjechał do USA „z misją handlową” Podlądał Forda Wprowadził Toyotę na rynek samochodowy Just-in-Time – niskie koszty, jakość, eliminacja marnotrastwa na etapie procesu
- Taiichi Ōno Inżynier Toyoty Od połowy lat 40 zaczął wprowadzać narzędzia i zasady organizujące pracę w Toyota Production System Ojciec Lean Manufacturing z którego wywodzi się Lean Management.
- Jedna z najefektywniejszych metodyk zwinnych. I najtrudniejszych. Z niej wywodzi się kanban, skrzynki z sugestiami pracowników i wiele innych drobiazgów, które pomagają firmie usprawniać oraz kontrolować procesy tak by unikać marnotrastwa. Do realizacji Lean stosowanych jest wiele narzędzi i metodyk – najlepiej gdy dobrane są optymalnie dla typu organizacji, kultury kraju, dojrzałości zespołu.
- Jej celem jest ograniczenie kosztów przy zachowaniu sprawnego (just in time) dostarczania coaz wyższej jakości produktu – efektywność!
- Cykl Deminga cykl PDCA z ang. Plan-Do-Check-Act lub cykl P-D-S-A z ang. Plan-Do-Study-Act P-D-C-A ZAPLANUJ (ang. Plan): Zaplanuj lepszy sposób działania, lepszą metodę. WYKONAJ, ZRÓB (ang. Do): Zrealizuj plan na próbę. SPRAWDŹ (ang. Check): Zbadaj, czy rzeczywiście nowy sposób działania przynosi lepsze rezultaty. POPRAW (ang. Act): Jeśli nowy sposób działania przynosi lepsze rezultaty, uznaj go za normę (obowiązującą procedurę), zestandaryzuj i monitoruj jego stosowanie.
- Edwards Deming w ostatnich latach życia zgłaszał zastrzeżenia do interpretacji trzeciego kroku cyklu, która jest zbyt uproszczona i nie ujmuje sensu metodyki tzw. projektowania eksperymentalnego (Design of Experiments, w skrócie DOE). Przywrócono P-D-S-A ZAPLANUJ (ang. Plan): Planuj każdą zmianę z wyprzedzeniem. Przeanalizuj obecną sytuację oraz potencjalne skutki zmian zanim jakiekolwiek podejmiesz. Z góry przemyśl, co powinieneś zmierzyć, aby przekonać się, czy zrealizowałeś swój zamiar. Zaplanuj pomiar, jako jeden z elementów realizacji zmiany. Myśl o pomiarze aż do następnego kroku (przez cały okres planowania). Opracuj plan wdrożenia zmiany, zadbaj przy tym o pełną obsadę tego przedsięwzięcia właściwym personelem oraz zaangażuj właścicieli procesów. WYKONAJ, ZRÓB (ang. Do): Przeprowadź pilotażowe wdrożenie zmiany w małej skali, w kontrolowanych warunkach (tzn. najpierw przeprowadź eksperyment, bądź zbuduj prototyp). ZBADAJ (ang. Study): Gruntownie przeanalizuj rezultaty eksperymentu. Wyprowadź wnioski – co zebrane dane mówią na temat skuteczności próbnego wdrożenia? ZASTOSUJ, DZIAŁAJ (ang. Act): Podejmij właściwe działania, aby wdrożyć standard takiego procesu, który wytworzył rezultaty najbardziej pożądane.
- Co powinno nam z łatwością skojarzyć się z TDD i jego słynnym Red-Green-Refactor Łeee, będzie o testach. Nie. Nie będzie o tym jak naprawiać kod. Zadamy sobie o wiele ważniejsze pytanie – dlaczego go naprawiać.
- Praca z przestarzałym kodem jest naturalna dla kazdego programisty. Niektórzy nawet czynią z tego pasję i specjalizację. To super, tak długo jeśli ich pasja polega na wycianiu tego kodu do nowocześniejszej lub bardziej optymalnej formy.
- Rany boskie, ten znowu o kasie. To nie do końca mój pomysł :P
- główny naukowiec w Obtivia, specjalista od refaktoringu
- 6 lat temu napisał ciekawy artykuł o praktycznym podejściu do refaktoringyu Zauważył, że pliki czy obszary aplikacji możemy podzielić na szybko zmienne i wolnozmienne
- A ponieważ każdy kawałek kodu w nich zawarty możemy podzielić wg jakości kodu, mierzonej na przykład złożonością cyklomatyczną powstaje ciekawy rozkład
- Nazywany dzisiaj potocznie kwadratem Featersa Wprowadza on bardzo ciekawy podział aplikacji ułatwiając podejmowanie decyzji o miejscu, w którym należy rozpocząć poprawianie aplikacji. Narzędzia, brzydkie-stabilne, małe, szybko zmienne ale stabilne i miejsca gdzie my, jako zespół, popłynęliśmy w nawarstwiające się pokłady... błedów projektowych.
- Oczywiście analiza statyczna daje nam więcej informoacji niźli tylko o złożoności. Mamy do dyspozycji np mess detector czy copy-paste detector i ten ostatni dostarcza informacji o błędach projektowych naruszających zasadę DYI.
- O dry...
- Ok, ale analiza statyczna to nie wszystko na co nas stać. Jednym z najczęściej pomijanych metod, która potrafi dostarcza niezwykle ważnych informacji z czysto biznesowego punktu widzenia jest profilowanie. PRofilowanie pokazuje jak płyną dane w aplikacji, które jej części są najbardziej obciążane obsługą danej komendy i gdzie _sumarycznie_ idzie najwięcej zasobów. Jest to metoda trudna i wymagająca wiedzy, ale przede wszystkim uczciwości w przygotowaniu i przeprowadzaniu pomiarów. Oraz interpretacji wyników. Dlaczego to ważna biznesowo informacje? Bo uczciwie przeprowadzone daje informacje nt czasów reakcji aplikacji, zasobów koniecznych potrzebnych do zachowania budżetu wydajnościowego oraz pozwala prognozować dalsze inwestycje w sprzęt i optymalizacje kodu
- Te wszystkie pomiary są nam potrzebne, aby nie rozpoczynać zmian na podstawie przeczuć, poprawiając kod tam, gdzie kompletnie nie musi być poprawiany.
- Dzięki temu wiemy dokładnie co I DLACZEGO zmieniamy, a to (plus testy!) ma zabezpieczyć nas przed wprowadzeniem regresji, ale także...
- Przed przeginaniem pałki i marnowaniem czasu na coś, czego użytkownik po prostu nie potrzebuje.
- Naszym zadaniem jako inżynierów jest prostować zagmatwane wymagania, porządkować je i nadawać im sens. Naszym! Idealnie jest oczekiwać wspaniałej dokumentacji, ale jeśli jej nie otrzymamy to naszym obowiązkiem jest dopytać zamawiającego (mniej lub bardziej bezpośrednio), aby zrobić tylko to czego naprawdę chce.
- Refactoring to nieustający proces poprawy kodu aplikacji. I jako proces podlega dokładnie tym samym regułom co pisanie nowego kodu – bo w gruncie rzeczy i tak najczęściej piszemy kod, który ma zastąpić stary. Wykorzystaj regułę 8 godzin aby nie popłynąć z „usprawnieniami” w tygodnie. Poświęć na to jeden dzień i wróć do „zamówionych” zadań.
- Eksperymentuj z rozwiązaniami! Jeśli wprowadzasz relatywnie często małe usprawnienia to nawet jeśli któreś „nie pójdzie” – możesz je szybko zmienić na ulepszone, albo wycofać się ze zmiany!
- Tak więc zachowaj spokój i naprawiaj kod