Próbowałem planować z wyprzedzeniem, ale nie mogę przewidzieć wszystkiego, dopóki nie zacznę opracowywać kodu.
Kuszące jest myślenie, że idealne planowanie zapewni doskonałe projektowanie / architekturę oprogramowania, jednak okazuje się, że jest to kategorycznie fałszywe. Są z tym dwa duże problemy. Po pierwsze, „na papierze” i „kod” rzadko się zgadzają, a powodem jest to, że łatwo jest powiedzieć, jak należy to zrobić, a nie w rzeczywistości . Po drugie, nieprzewidziane zmiany wymagań stają się widoczne na późnym etapie procesu projektowania, o których nie można było mówić od samego początku.
Czy słyszałeś o ruchu Agile? Jest to sposób myślenia, w którym cenimy „reagowanie na zmiany”, a nie „przestrzeganie planu” (między innymi). Oto manifest (to szybki odczyt). Możesz także poczytać o Big Design Up Front (BDUF) i o tym, jakie są pułapki.
Niestety, wersja korporacyjna „Agile” jest nieprawdziwa (certyfikowani mistrzowie scrum, ciężki proces w imieniu „Agile”, wymuszanie scrum, wymuszanie 100% pokrycia kodu itp.), I zwykle powoduje zmiany asinine procesu, ponieważ menedżerowie myślę, że Agile to proces i srebrna kula (której nie ma). Przeczytaj zwinny manifest, słuchaj ludzi, którzy rozpoczęli ten ruch, takich jak wujek Bob i Martin Fowler, i nie daj się wciągnąć w nonsensowną wersję „corporate Agile”.
W szczególności zazwyczaj można uciec od zrobienia TDD (Test Driven Development) na kodzie naukowym i istnieje duża szansa, że twój projekt oprogramowania okaże się całkiem cholernie dobry. Wynika to z faktu, że udany kod naukowy ma przeważnie bardzo przydatne interfejsy, a wydajność stanowi drugorzędną (a czasem konkurencyjną) kwestię, dzięki czemu można uzyskać bardziej „chciwy” projekt. TDD zmusza twoje oprogramowanie do ultra-użyteczności , ponieważ piszesz, jak chcesz , aby rzeczy były nazywane (najlepiej) przed ich faktyczną implementacją. Wymusza również małe funkcje za pomocą małych interfejsów, które można szybko wywołać w prosty sposób „wejściowy” / „wyjściowy”, i daje ci dobrą pozycję do refaktoryzacji w przypadku zmiany wymagań.
Myślę, że wszyscy możemy się zgodzić, że numpyodnosi sukcesy naukowe oprogramowanie komputerowe. Ich interfejsy są małe, super użyteczne, a wszystko ładnie się gra. Zauważ, że numpyprzewodnik referencyjny wyraźnie zaleca TDD: https://docs.scipy.org/doc/numpy-1.15.1/reference/testing.html . W przeszłości korzystałem z TDD w oprogramowaniu do obrazowania SAR (radar z syntetyczną aperaturą): mogę również stwierdzić, że działa on wyjątkowo dobrze w tej konkretnej dziedzinie.
Zastrzeżenie: Część projektowa TDD działa gorzej w systemach, w których fundamentalne refaktoryzacja (np. Decyzja, że potrzebujesz oprogramowania, aby była wysoce współbieżna) byłaby trudna, jak w systemie rozproszonym. Na przykład, jeśli musiałbyś zaprojektować coś takiego jak Facebook, na którym masz miliony równoczesnych użytkowników, zrobienie TDD (by poprowadzić twój projekt) byłoby błędem (nadal można używać po przygotowaniu wstępnego projektu i po prostu „przetestować pierwszy rozwój” „). Ważne jest, aby pomyśleć o zasobach i strukturze aplikacji przed wskoczeniem do kodu. TDD nigdy nie doprowadzi Cię do wysoce dostępnego, rozproszonego systemu.
Jak mogę uniknąć poczucia, że gdybym całkowicie przebudował program od zera, zrobiłbym to znacznie lepiej?
Biorąc powyższe pod uwagę, powinno być nieco oczywiste, że idealny projekt jest w rzeczywistości niemożliwy do osiągnięcia, więc pogoń za idealnym projektem jest grą głupców. Naprawdę możesz się tylko zbliżyć. Nawet jeśli uważasz, że możesz przeprojektować od zera, prawdopodobnie nadal istnieją ukryte wymagania, które się nie pokazały. Co więcej, przepisywanie zajmuje przynajmniej tyle czasu, ile zajęło opracowanie oryginalnego kodu. Niemal na pewno nie będzie krótszy, ponieważ jest prawdopodobne, że nowy projekt będzie miał własne nieprzewidziane problemy, a ponadto musisz ponownie wdrożyć wszystkie funkcje starego systemu.
Inną rzeczą do rozważenia jest to, że Twój projekt ma znaczenie tylko wtedy , gdy zmieniają się wymagania .Nie ma znaczenia, jak zły jest projekt, jeśli nic się nigdy nie zmienia (zakładając, że jest w pełni funkcjonalny w obecnych przypadkach użycia). Pracowałem nad linią bazową, która zawierała 22 000 instrukcji przełączania linii (funkcja była jeszcze dłuższa). Czy to był okropny projekt? Cholera, to było okropne. Naprawiliśmy to? Nie. Działało to dobrze, a ta część systemu nigdy tak naprawdę nie powodowała awarii ani błędów. Dotknęło go to tylko raz w ciągu dwóch lat pracy nad projektem, a ktoś, jak się domyślacie, umieścił inną obudowę w przełączniku. Ale nie warto poświęcać czasu na naprawę czegoś, co jest dotykane tak rzadko, że po prostu nie jest. Niech niedoskonały projekt będzie taki, jaki jest, a jeśli nie jest zepsuty (lub ciągle pęka), nie naprawiaj go. Więc może mógłbyś zrobić lepiej ... ale czy warto byłoby przepisać? Co zyskasz
HTH.