Jakość oprogramowania jest rozbudowaną dziedziną wiedzy, którą każdy programista zna doskonale, ale ilu tak naprawdę stosuje skutecznie? W prelekcji przedstawię zarówno najważniejsze, zweryfikowane praktycznie sposoby podnoszenia i utrzymywania jakości oprogramowania na założonym poziomie, jak również omówię kilka pułapek, w które nadzwyczaj łatwo wpadamy.
Prezentacja przedstawia pomysł Scotta Amblera na prowadzenie analizy w metodach zwinnych: Agile Modeling oraz Agile Model Driven Development.
Prezentacja została przedstawiona na spotkaniu IIBA PC Business Analysis Round-tables #7 Pomysł na analizę w Agile: Agile Modeling:
http://www.meetup.com/IIBA-PC-Business-Analysis-Round-tables/events/222647759/
Kompendium wiedzy dla każdego programisty, projektanta i kierownika projektu
* Nowoczesne metodyki wytwarzania oprogramowania
* Narzędzia do modelowania aplikacji i automatycznego generowania kodu
* Koncepcja architektury sterowanej modelami
* Sposoby zapewnienia jakości aplikacji
Tworzenie aplikacji korporacyjnych to wyścig z czasem. Organizacje zmieniają się podobnie jak otoczenie biznesowe, w którym działają. Zbyt długi okres przygotowania aplikacji może sprawić, że po wdrożeniu okaże się ona bezużyteczna. Z drugiej jednak strony, zbyt duży pośpiech przy tworzeniu aplikacji powoduje, że pomija się fazę modelowania i testowania, pisząc kod źródłowy bez jakiejkolwiek koncepcji i planu. Efektem takiego pośpiechu są aplikacje niedostosowane do wymagań użytkowników i pracujące niestabilnie. Sposobem na stworzenie odpowiedniego systemu informatycznego dla korporacji jest wykorzystywanie odpowiednich metodyk projektowych i nowoczesnych narzędzi ułatwiających zarówno pisanie, jak i testowanie aplikacji.
Książka "J2EE. Podstawy programowania aplikacji korporacyjnych" przedstawia najlepsze praktyki projektowe stosowane przy tworzeniu systemów informatycznych z wykorzystaniem platformy J2EE. Opisano w niej kolejne etapy projektu oraz narzędzia i metodyki, dzięki którym przeprowadzenie każdego z nich będzie szybsze i efektywniejsze. Czytając ją, poznasz metodyki RUP i XP, typy architektur systemów oraz sposoby modelowania aplikacji i narzędzia do automatycznego generowania szkieletu kodu źródłowego. Dowiesz się, jak optymalnie skonfigurować środowiska programistyczne i jak testować kolejne moduły aplikacji. Nauczysz się korzystać z nowoczesnych metodyk i narzędzi.
* Podstawowe wiadomości o błyskawicznym wytwarzaniu aplikacji (RAD)
* Metodyki projektowe Rational Unified Process (RUP) oraz Extreme Programming (XP)
* Wielowarstwowe architektury systemów
* Modelowanie systemów za pomocą języka UML
* Automatyczne generowanie kodu
* Stosowanie narzędzi XDoclet i Hibernate
* Komunikacja z bazami danych
* Zasady programowania aspektowego
* Testowanie aplikacji
Wiadomości zawarte w tej książce sprawią, że będziesz w stanie szybciej projektować i tworzyć aplikacje korporacyjne.
O zagadnieniu:
Czy następuje taki moment w życiu programisty, kiedy może on stwierdzić, że jego warsztat jest już doskonały? Nie, jeżeli pracuje w technologiach internetowych. Ta dziedzina informatyki rozwija się w niesamowicie szybkim tempie, a stworzone wczoraj rozwiązania warto stosować już dziś!
Cel i korzyści spotkania:
Podczas spotkania słuchacze poznają aktualnie wykorzystywane technologie oraz kluczowe umiejętności w produkcji aplikacji internetowych, jak również metody programowania ekstremalnego i techniki zwinnego wytwarzania oprogramowania. Osobom, które dopiero zaczynają swoją przygodę z web development, zostanie przedstawiona propozycja działań, których sumienne podjęcie się gwarantuje odniesienie sukcesu zawodowego.
4Developers 2015: Jak przekonać managera, że czas na refaktoring jest potrzeb...PROIDEA
Sebastian Łaciak
Language: Polish
Jest tysiące powodów dla których nasze projekty mogłyby być lepsze a świat dzięki temu piękniejszy. Niestety często na drodze stoi manager i brak czasu na pielęgnowanie kodu. Podczas sesji postaram się przekonać Was, że nie stoimy na pozycji przegranej oraz podam wiele argumentów, których będziecie mogli użyć po powrocie do biura. Poruszony zostanie również temat roadmapy.
Sprzedaj swój program. Droga do udanych projektów programistycznychWydawnictwo Helion
Stwórz niezawodne oprogramowaniespełniające oczekiwania użytkowników
* Wykorzystuj odpowiednie narzędzia projektowe.
* Wdrażaj nowoczesne metodologie.
* Szybko rozwiązuj problemy.
Dyskusje nad wadami i zaletami przeróżnych metodologii tworzenia oprogramowania, mające na celu wyłonienie najlepszej z nich, zwykle do niczego nie prowadzą. Zwolennicy poszczególnych metodologii, takich jak Rational Unified Process, programowanie ekstremalne i inne, starają się udowodnić, że to ich stanowisko jest poprawnym sposobem realizacji projektów informatycznych. Tymczasem nie istnieje "jedyne słuszne" i uniwersalne podejście, które sprawdza się we wszystkich okolicznościach. Wybór właściwej metodologii w ogromnej mierze zależy od typu projektu i wielkości zespołu pracującego nad nim. Należy kierować się nastawieniem czysto pragmatycznym, czyli wybrać taką metodologię, która będzie najbardziej korzystna dla określonego projektu. Niewłaściwy wybór może skończyć się porażką.
Książka "Sprzedaj swój program. Droga do udanych projektów programistycznych" to zbiór wskazówek przedstawiających narzędzia i techniki, dzięki którym każdy projekt programistyczny zakończy się sukcesem. Czytając ją, nauczysz się korzystać z nowoczesnych instrumentów wykorzystywanych do projektowania oprogramowania, kontroli wersji kodu źródłowego i śledzenia procesu usuwania błędów. Dowiesz się, w jaki sposób zorganizować pracę zespołu projektowego i wdrażać metodologię wytwarzania oprogramowania. Porady, które znajdziesz w tej książce, pomogą Ci rozwiązać problemy pojawiające się podczas realizacji projektów programistycznych. Poznasz nowoczesne metody oraz dowiesz się, kiedy i jak z nich korzystać.
* Planowanie infrastruktury
* Dobór narzędzi projektowych
* Automatyzacja zadań
* Tworzenie listy zadań
* Rola kierownika technicznego
* Metodologia pocisku smugowego
* Rozwiązywanie problemów
Wskazówki zawarte w tej książce sprawią, że każdy prowadzony przez Ciebie projekt zakończy się w terminie i zmieści w wyznaczonym budżecie.
Jak zacząć przygodę z tworzeniem dużych produkcji? Co zrobić, żeby stać się częścią branży gier? Prezentacja pokazuje możliwe ścieżki rozwoju dla programistów, pokazując przy tym, że gry mają znacznie więcej wspólnego z "poważnym" oprogramowaniem niż się może wydawać.
Konrad Gadzina: Test-Driven Gamedev - testy automatyczne a tworzenie gierGameDesire Academy
Celem prezentacji jest przedstawienie korzyści, jakie developerzy gier mogą wyciągnąć z tworzenia testów automatycznych i odpowiedź na kilka podstawowych pytań, m.in. czy gry są zbyt skomplikowane na automatyzacje testów? Co i jak testować - od testów jednostkowych po testy integracyjne. Czym jest "red-green-refactor mantra"? Jak Test-Driven Development wychodzi ze starcia z legacy code? Oraz jak coding dojo może pomóc wdrożyć zespół w TDD?
Prowadzący - Konrad Gadzina, Senior Software Engineer w Ganymede
Link do YT: https://youtu.be/5_af-R3WxdY
Girls in It - Front-end & Back-end. Jak zacząćmonterail
“Girls in IT” to cykl spotkań dla kobiet, które mają na celu pokazać od kuchni jak wygląda praca w firmie technologicznej i pomóc im podjąć właściwą decyzję na temat kariery zawodowej.
W pierwszej części, przeznaczonej dla przyszłych Front-end Developerek, opowiemy na czym polega tworzenie strony internetowej i podzielimy się listą niezbędnych źródeł dla początkujących.
Druga część zawiera praktyczne informacje dotyczące Backend development'u. Przedstawimy specyfikę pracy na tym stanowisku, dobre praktyki, a także cenne wskazówki od naszych ekspertek.
https://www.youtube.com/watch?v=ww36brBuxU8
O czym będzie?
1. Ograniczenie "apetytu" czyli ustalenie wspólnego celu
2. Techniki zbierania wymagań,
3. Mock-upy nie tylko dla UXowców,
4. Wizualizacja + schematy jako uniwersalny język,
5. Co warto wiedzieć o komunikacji - czyli parę praktycznych wskazówek
How we built a tools stack for the benchmarking AI and what happened nextMichal Lukaszewski
Origin story about testers team which transformed to a team of programmers writing custom software for ML and AI testing. How we started, what mistakes we did and how we solved them.
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?
More Related Content
Similar to Dwa sposoby na pisanie aplikacji bez błędów
Prezentacja przedstawia pomysł Scotta Amblera na prowadzenie analizy w metodach zwinnych: Agile Modeling oraz Agile Model Driven Development.
Prezentacja została przedstawiona na spotkaniu IIBA PC Business Analysis Round-tables #7 Pomysł na analizę w Agile: Agile Modeling:
http://www.meetup.com/IIBA-PC-Business-Analysis-Round-tables/events/222647759/
Kompendium wiedzy dla każdego programisty, projektanta i kierownika projektu
* Nowoczesne metodyki wytwarzania oprogramowania
* Narzędzia do modelowania aplikacji i automatycznego generowania kodu
* Koncepcja architektury sterowanej modelami
* Sposoby zapewnienia jakości aplikacji
Tworzenie aplikacji korporacyjnych to wyścig z czasem. Organizacje zmieniają się podobnie jak otoczenie biznesowe, w którym działają. Zbyt długi okres przygotowania aplikacji może sprawić, że po wdrożeniu okaże się ona bezużyteczna. Z drugiej jednak strony, zbyt duży pośpiech przy tworzeniu aplikacji powoduje, że pomija się fazę modelowania i testowania, pisząc kod źródłowy bez jakiejkolwiek koncepcji i planu. Efektem takiego pośpiechu są aplikacje niedostosowane do wymagań użytkowników i pracujące niestabilnie. Sposobem na stworzenie odpowiedniego systemu informatycznego dla korporacji jest wykorzystywanie odpowiednich metodyk projektowych i nowoczesnych narzędzi ułatwiających zarówno pisanie, jak i testowanie aplikacji.
Książka "J2EE. Podstawy programowania aplikacji korporacyjnych" przedstawia najlepsze praktyki projektowe stosowane przy tworzeniu systemów informatycznych z wykorzystaniem platformy J2EE. Opisano w niej kolejne etapy projektu oraz narzędzia i metodyki, dzięki którym przeprowadzenie każdego z nich będzie szybsze i efektywniejsze. Czytając ją, poznasz metodyki RUP i XP, typy architektur systemów oraz sposoby modelowania aplikacji i narzędzia do automatycznego generowania szkieletu kodu źródłowego. Dowiesz się, jak optymalnie skonfigurować środowiska programistyczne i jak testować kolejne moduły aplikacji. Nauczysz się korzystać z nowoczesnych metodyk i narzędzi.
* Podstawowe wiadomości o błyskawicznym wytwarzaniu aplikacji (RAD)
* Metodyki projektowe Rational Unified Process (RUP) oraz Extreme Programming (XP)
* Wielowarstwowe architektury systemów
* Modelowanie systemów za pomocą języka UML
* Automatyczne generowanie kodu
* Stosowanie narzędzi XDoclet i Hibernate
* Komunikacja z bazami danych
* Zasady programowania aspektowego
* Testowanie aplikacji
Wiadomości zawarte w tej książce sprawią, że będziesz w stanie szybciej projektować i tworzyć aplikacje korporacyjne.
O zagadnieniu:
Czy następuje taki moment w życiu programisty, kiedy może on stwierdzić, że jego warsztat jest już doskonały? Nie, jeżeli pracuje w technologiach internetowych. Ta dziedzina informatyki rozwija się w niesamowicie szybkim tempie, a stworzone wczoraj rozwiązania warto stosować już dziś!
Cel i korzyści spotkania:
Podczas spotkania słuchacze poznają aktualnie wykorzystywane technologie oraz kluczowe umiejętności w produkcji aplikacji internetowych, jak również metody programowania ekstremalnego i techniki zwinnego wytwarzania oprogramowania. Osobom, które dopiero zaczynają swoją przygodę z web development, zostanie przedstawiona propozycja działań, których sumienne podjęcie się gwarantuje odniesienie sukcesu zawodowego.
4Developers 2015: Jak przekonać managera, że czas na refaktoring jest potrzeb...PROIDEA
Sebastian Łaciak
Language: Polish
Jest tysiące powodów dla których nasze projekty mogłyby być lepsze a świat dzięki temu piękniejszy. Niestety często na drodze stoi manager i brak czasu na pielęgnowanie kodu. Podczas sesji postaram się przekonać Was, że nie stoimy na pozycji przegranej oraz podam wiele argumentów, których będziecie mogli użyć po powrocie do biura. Poruszony zostanie również temat roadmapy.
Sprzedaj swój program. Droga do udanych projektów programistycznychWydawnictwo Helion
Stwórz niezawodne oprogramowaniespełniające oczekiwania użytkowników
* Wykorzystuj odpowiednie narzędzia projektowe.
* Wdrażaj nowoczesne metodologie.
* Szybko rozwiązuj problemy.
Dyskusje nad wadami i zaletami przeróżnych metodologii tworzenia oprogramowania, mające na celu wyłonienie najlepszej z nich, zwykle do niczego nie prowadzą. Zwolennicy poszczególnych metodologii, takich jak Rational Unified Process, programowanie ekstremalne i inne, starają się udowodnić, że to ich stanowisko jest poprawnym sposobem realizacji projektów informatycznych. Tymczasem nie istnieje "jedyne słuszne" i uniwersalne podejście, które sprawdza się we wszystkich okolicznościach. Wybór właściwej metodologii w ogromnej mierze zależy od typu projektu i wielkości zespołu pracującego nad nim. Należy kierować się nastawieniem czysto pragmatycznym, czyli wybrać taką metodologię, która będzie najbardziej korzystna dla określonego projektu. Niewłaściwy wybór może skończyć się porażką.
Książka "Sprzedaj swój program. Droga do udanych projektów programistycznych" to zbiór wskazówek przedstawiających narzędzia i techniki, dzięki którym każdy projekt programistyczny zakończy się sukcesem. Czytając ją, nauczysz się korzystać z nowoczesnych instrumentów wykorzystywanych do projektowania oprogramowania, kontroli wersji kodu źródłowego i śledzenia procesu usuwania błędów. Dowiesz się, w jaki sposób zorganizować pracę zespołu projektowego i wdrażać metodologię wytwarzania oprogramowania. Porady, które znajdziesz w tej książce, pomogą Ci rozwiązać problemy pojawiające się podczas realizacji projektów programistycznych. Poznasz nowoczesne metody oraz dowiesz się, kiedy i jak z nich korzystać.
* Planowanie infrastruktury
* Dobór narzędzi projektowych
* Automatyzacja zadań
* Tworzenie listy zadań
* Rola kierownika technicznego
* Metodologia pocisku smugowego
* Rozwiązywanie problemów
Wskazówki zawarte w tej książce sprawią, że każdy prowadzony przez Ciebie projekt zakończy się w terminie i zmieści w wyznaczonym budżecie.
Jak zacząć przygodę z tworzeniem dużych produkcji? Co zrobić, żeby stać się częścią branży gier? Prezentacja pokazuje możliwe ścieżki rozwoju dla programistów, pokazując przy tym, że gry mają znacznie więcej wspólnego z "poważnym" oprogramowaniem niż się może wydawać.
Konrad Gadzina: Test-Driven Gamedev - testy automatyczne a tworzenie gierGameDesire Academy
Celem prezentacji jest przedstawienie korzyści, jakie developerzy gier mogą wyciągnąć z tworzenia testów automatycznych i odpowiedź na kilka podstawowych pytań, m.in. czy gry są zbyt skomplikowane na automatyzacje testów? Co i jak testować - od testów jednostkowych po testy integracyjne. Czym jest "red-green-refactor mantra"? Jak Test-Driven Development wychodzi ze starcia z legacy code? Oraz jak coding dojo może pomóc wdrożyć zespół w TDD?
Prowadzący - Konrad Gadzina, Senior Software Engineer w Ganymede
Link do YT: https://youtu.be/5_af-R3WxdY
Girls in It - Front-end & Back-end. Jak zacząćmonterail
“Girls in IT” to cykl spotkań dla kobiet, które mają na celu pokazać od kuchni jak wygląda praca w firmie technologicznej i pomóc im podjąć właściwą decyzję na temat kariery zawodowej.
W pierwszej części, przeznaczonej dla przyszłych Front-end Developerek, opowiemy na czym polega tworzenie strony internetowej i podzielimy się listą niezbędnych źródeł dla początkujących.
Druga część zawiera praktyczne informacje dotyczące Backend development'u. Przedstawimy specyfikę pracy na tym stanowisku, dobre praktyki, a także cenne wskazówki od naszych ekspertek.
https://www.youtube.com/watch?v=ww36brBuxU8
O czym będzie?
1. Ograniczenie "apetytu" czyli ustalenie wspólnego celu
2. Techniki zbierania wymagań,
3. Mock-upy nie tylko dla UXowców,
4. Wizualizacja + schematy jako uniwersalny język,
5. Co warto wiedzieć o komunikacji - czyli parę praktycznych wskazówek
How we built a tools stack for the benchmarking AI and what happened nextMichal Lukaszewski
Origin story about testers team which transformed to a team of programmers writing custom software for ML and AI testing. How we started, what mistakes we did and how we solved them.
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?
Prelection about alternative for MVC, presented at PHPersPL meetup in Gdańsk, 26.10.2015.
ADR is a concept to provide clean and SOLID delivery pattern, designed for HTTP applications and proposed by Paul M. Jones. First implementation of ADR you can find in Radar Framework (written in PHP), fulfilling the assumptions of PSR-7 by FIG.
Będzie o budowaniu wydajności aplikacji, parę słów o mikro optymalizacji (z przykładami) i czytelności kodu, programowaniu obiektowym, możliwych rozwiązaniach, dyscyplinie, znajomości języka i wyborach w prawdziwym świecie.
http://michal.lukaszewski.eu/2014/03/08/wydajnosc-i-optymalizacja.html
Technologie mobilne w platformach edukacyjnych. Kosmikus, studium przypadkuMichal Lukaszewski
Prezentacja przygotowana na potrzeby cyklu Launch & Learn prowadzonego w Young Digital Planet. Autorzy: Sławek Rodak i Michał Łukaszewski (ja).
Prelekcja składała się z dwóch części:
1. Czego technologia oczekuje od biznesu aby przygotować dobry produkt uwzględniający urządzenia mobilne
2. Co technologia musi wiedzieć aby wesprzeć biznes w realizacji dobrego produktu.
Kosmikus, produkt YDP, jako studium przypadku - jakie technologie zostały wybrane i dlaczego, gdzie były kompromisy i dlaczego.
Przegląd najważniejszych technologii pozwalających zrealizować aplikacje dostępne na szerokim spektrum urządzeń.
Mnóstwo linków do źródeł, porównań.
Prezentacja do ściągnięcia również stąd:
http://sdrv.ms/MtH62k
W razie pytań, wątpliwości, chęci podyskutowania - zapraszm do kontaktu :)
6. Zrozumienie wymagań
• „Dlaczego?” zamiast „co?”
• Zrozumienie intencji ważniejsze od listy funkcji
• Odtworzenie aktualnego procesu klienta
• Optymalizacja wymaga wiedzy eksperckiej.
7. Zrozumienie wymagań
• „Dlaczego?” zamiast „co?”
• Zrozumienie intencji ważniejsze od listy funkcji
• Odtworzenie aktualnego procesu klienta
• Optymalizacja wymaga wiedzy eksperckiej.
• Klient nie zna się na Twojej robocie
• nie wie czego od Ciebie wymagać.
• Ale zna się na swoim biznesie.
• W przeciwieństwie do Ciebie.
13. Modelowanie
• Modelowanie procesu biznesowego klienta
• Jego rzeczywistości biznesowej.
• Wszystkie modele są uproszczone
• Więc wszystkie modele są błędne
• Ale niektóre są użyteczne
• „Mental model” jako MVP
14. Architektura jako most między modelem, a
kodem
Business
requirements
Architecture Implementation
15. Architektura jako most między modelem, a
kodem
• Model opisuje w przybliżeniu rzeczywistość klienta.
• Architektura opisuje techniczne ramy, na których oprze się model.
• Programista implementuje zachowania w ramach przyjętej
architektury.
16. Architektura jako most między modelem, a
kodem
• Architektura musi być mądra, nie musi mieć mądrej nazwy.
• Ale architektura heksagonalna i czysta architektura naprawdę są super!
• Architektura musi być optymalna biznesowo.
21. Szacowanie
• Szacowanie pewne
• <= 1MD
• Szacowanie prawdopodobne
• 2-3MD
• Wszystko powyżej to wróżbiarstwo
Reguły te nie zmieniają się wraz z doświadczeniem zespołu.
28. TDD a rzeczywistość
• „Wszyscy” piszą testy.
• Część pisze testy z sensem.
• A część nawet przed implementacją.
• „To tylko prosta klasa, co tu testować?”.
29. TDD a rzeczywistość
• Testy są często większe niż implementacja.
• Są kosztowne w utrzymaniu.
• Wrażliwe na zmiany implementacji.
• Ciężko uzasadnić ten wydatek w budżecie projektu.
31. Specification as example
• Test jednostkowy nie jest testem.
• Jest specyfikacją.
• Czyli dokumentacją.
• Opisuje oczekiwane zachowania.
• API
• Sprawdza obsługę błędów.
32.
33. Specification as example
• Test nie jest testem.
• Jest specyfikacją.
• Czyli dokumentacją.
• Opisuje oczekiwane zachowania.
• Sprawdza obsługę błędów.
34. Testy jako miara jakości kodu.
• Kod, który się nie zmienia nie wymaga zmiany testów
• Prosty kod wymaga prostych testów
• Proste testy prostego kodu są szybkie
• Problem z odcięciem zależności jako flaga spartolonego projektu
• Prawo Demeter i Dependency Injection, ftw!
• Specyfikacja zawsze pokrywa kod w 100%
35. Testy wspierają utrzymanie jakości kodu.
• Nie tylko testy jednostkowe:
• Lintery
• Analiza statyczna
• Regularne profilowanie
• Automatyzacja
• per Pull Request
• Testy funkcjonalne
• Testy integracyjne
• Blokowanie zmian wprowadzających regresję jakości.
• Code Review jako bezwymiarowa ocena jakości kodu.
36. Testowanie
• TDD -> BDD -> ...
• Specification as example
• Testy jako miara jakości kodu
40. SOLID jako droga wojownika
• SOLIDny kod to kod czysty, prosty i stabilny.
• SOLIDny kod łatwo uczynić kodem bezpiecznym.
• SOLIDny kod świetnie się rozwija minimalizując ryzyko regresji.
• SOLIDny kod banalnie się testuje.
• SOLIDny powinien być kod, ale i architektura.
41. SOLID jako droga wojownika
SOLID to sposób myślenia o projektowaniu i implementacji.
43. Programowanie defensywne
• YAGNI!
• Konstruktor jako jedyny punkt wstrzyknięcia zależności
• Tylko niezbędne zależności
• Minimalna ilość metod publicznych
• A każda z nich – finalna.
46. Dla kogo powstaje kod (i dokumentacja)?
• Kodujesz dla innych programistów.
47. Dla kogo powstaje kod (i dokumentacja)?
• Kodujesz dla innych programistów.
“Any fool can write code that a computer can understand. Good
programmers write code that humans can understand.”
– Martin Fowler
48. Dla kogo powstaje kod (i dokumentacja)?
Wszystkie techniki czystego kodu obniżają koszt utrzymania, nie
wytworzenia.
• Wszystkie „skróty i hacki” obniżają koszt wytworzenia, ale mogą doprowadzić
do śmierci projektu/kodu na dłuższą metę.
49. Dla kogo powstaje kod (i dokumentacja)?
Kod wyspecyfikowany (np. testami) jest przenaszalny pomiędzy
programistami.
• Chroń swoje stanowisko robiąc dobrą robotę
• Nie kod, który tylko ty rozumiesz
50. Good enough
• Proces wytwarzania oprogramowania to (technicznie) nieograniczona
ilość iteracji cyklu Deminga.
• Lepsze jest gorsze.
• Refactoring jako stały proces towarzyszący
• Nie akcja naprawcza!
52. Implementacja
• SOLID jako droga wojownika
• Programowanie defensywne
• Dla kogo powstaje kod (i dokumentacja)?
• „Good enough”
53. Mniej błędów gdy
• Sumiennie zebrane wymagania.
• Rozumiesz wymagania.
• Masz dobry model (wystarczające przybliżenie).
• Architektura jest optymalna biznesowo.
• Szacowanie, planowanie, kontrola postępów.
• Specyfikacja „zamiast” testowania.
• Stała kontrola jakości kodu (CI + analiza statyczna + automatyzacja).
• Dobry projekt kodu (SOLID, programowanie defensywne).
• Czytelny kod („twój kod opowiada historię”).
• „Good enough”.
Trzeba pamiętać, że ważną cechą CA jest to, że nawiązuje do wcześniejszych opracowań Wujka Boba, z SOLID na czele
"Eagleson's Law: Any code of your own that you haven't looked at for six or more months might as well have been written by someone else." - Alan Eagleson
"Eagleson's Law: Any code of your own that you haven't looked at for six or more months might as well have been written by someone else." - Alan Eagleson