Czy potrzeba opracowania specyfikacji oprogramowania znacznie spadła wraz z ewolucją bardziej ekspresyjnych języków programowania?

Dla wielu informatyków, w tym dla mnie kilka lat temu, idealny proces tworzenia oprogramowania wymagałby stworzenia szczegółowych dokumentów projektowych z dużą ilością diagramów UML, zanim zostanie napisany wiersz kodu. (Wygląda to jak opis modelu wodospadu, ale jest taki sam w przypadku zwinnego, z tym wyjątkiem, że iteracje są mniejsze).

W ciągu ostatnich dwóch lub trzech lat całkowicie zmieniłem zdanie. Nadal uważam, że szczegółowa specyfikacja wymagań z powiązanymi przypadkami testowymi jest absolutnie niezbędna. W przypadku dużych projektów przed przystąpieniem do kodowania potrzebowałbym również zarys ogólnej architektury. Ale cała reszta powinna być wykonana w kodzie tak dużo, jak to możliwe. W idealnym przypadku nie powinno być opisu projektu oprogramowania poza samym kodem.

Jak doszedłem do tego wniosku? Oto kilka argumentów:

Informacje zwrotne

Narzędzia do pisania dokumentów lub tworzenia diagramów dostarczają niewiele informacji zwrotnych. Tak, istnieją narzędzia do modelowania, które sprawdzają spójność diagramów UML, ale są one ograniczone i wiążą się z dużym nakładem pracy.

Bez informacji zwrotnej trudno jest rozpoznać i naprawić błędy.

Gdy tylko napiszesz kod, otrzymasz wiele opinii, na przykład:

• Błędy i ostrzeżenia z kompilatora
• Wyniki analizy kodu statycznego
• Testy jednostkowe

Błędy można szybko rozpoznać i naprawić.

Konsystencja

Aby upewnić się, że kod jest zgodny z twoimi dokumentami, musisz to sprawdzać raz za razem. W przypadku częstych zmian trudno jest zsynchronizować kod i dokumenty.

Refaktoryzacja

Istnieją potężne narzędzia i techniki do refaktoryzacji kodu, podczas gdy refaktoryzacja opisów tekstowych lub diagramów jest zwykle trudna i podatna na błędy.

Jest jeden warunek konieczny do działania: kod musi być wystarczająco łatwy do odczytania i zrozumienia. Prawdopodobnie nie można tego osiągnąć za pomocą Asemblera, Basica lub Fortrana, ale współczesne języki (i biblioteki) są znacznie bardziej wyraziste.

Więc jeśli moje argumenty są słuszne, powinien istnieć trend w kierunku mniejszej lub bardziej lekkiej specyfikacji i dokumentacji projektowej oprogramowania. Czy istnieją dowody empiryczne na ten trend?

Podważam założenie, że języki są coraz bardziej wyraziste. W dzisiejszym kodzie ASP.NET w języku c # piszę na mniej więcej tym samym poziomie, co podczas pisania kodu ASP w języku Visual Basic. Nadal używamy c ++. JavaScript dodał funkcje, ale ogólnie język się nie zmienił. To samo z SQL.

Myślę, że te inne zmiany są bardziej znaczące:

1. Przyjęcie zautomatyzowanych testów jednostkowych. Niektórzy twierdzą, że testy są specyfikacją. Więc nie usunęliśmy potrzeby pisania specyfikacji; raczej piszemy je w kodzie, a nie w dokumentach Word.

2. Zmiany w metodologii wdrażania. W przeszłości popełnienie błędu było bardzo kosztowne, ponieważ trzeba było wysłać zaktualizowaną kopię oprogramowania. Więc musiałeś być ostrożny. Dzięki aplikacjom internetowym możesz wdrożyć poprawki do natychmiastowego użycia, a możesz pozwolić sobie na reagowanie na problemy, a nie na ich przewidywanie, restrukturyzację kodu na bieżąco.

3. Przyjęcie wzorców projektowych. Kiedy wszyscy znają wzory, prawie nie musisz niczego projektować; możesz po prostu powiedzieć „dodaj fabrykę repozytoriów”, a Twój zespół powinien to zrobić bez konieczności wyświetlania UML.

4. Kontrakty danych SOA. Obecnie prawie wszystko jest SOA. Wszystko czego potrzebujesz to WSDL. Minęły czasy definiowania i dokumentowania formatów przesyłania danych. Obecny krok w kierunku bardziej RESTful i mikrousług kontynuuje ten trend.

5. Oprogramowanie jest mniejsze. Częściowo w wyniku architektury SOA zespoły piszą mniejsze programy, które są ze sobą powiązane. Każdy pojedynczy element jest mniej złożony i wymaga mniej wstępnego projektu; łatwiej jest również zmienić część architektury bez zepsucia całego rozwiązania z powodu przerw przeciwpożarowych wymuszonych przez definicje interfejsów między komponentami.

6. Znacznie więcej wykorzystania istniejących bibliotek. .NET CLR oferuje mnóstwo gotowych funkcji, więc nie trzeba projektować, powiedzmy, schematu buforowania danych sesji. Biblioteki innych firm, takie jak jQuery UI lub Bootstrap, ustanawiają standardy pisania kodu, aby działały w określony sposób. Nie musisz ich dokumentować; zespoły powinny móc po prostu z nich korzystać.

7. Dojrzałość branży. SWE nauczyły się, że nie ma czegoś takiego jak projekt „Battlestar Galactica”, w którym spędzasz lata próbując osiągnąć określony cel; zanim te lata miną, cel się zmieni. Dziś wiemy, że czas na sprzedaż jest o wiele ważniejszy niż uzyskanie wszystkiego dokładnie tak, jak tego chcemy w projekcie.

8. Lepiej i konsekwentnie wykształceni inżynierowie. Obecnie możesz zatrudnić inżynierów, którzy rozumieją najlepsze praktyki (miejmy nadzieję) i wprowadzą je bez dokumentu projektowego z informacją, co mają robić.

9. Narzędzia zwiększające wydajność, takie jak TFS, pozwalają napisać proste zadanie, które odwołuje się do przypadku użycia i zapewnia kilka punktorów dla wszelkich dwuznacznych decyzji technicznych. Nie potrzebujesz dużo więcej. Programiści mogą przeglądać, szacować, uzyskiwać recenzje kodu, zameldować się itp. Wszystko za pomocą narzędzia. Jest to o wiele bardziej wydajne niż praca z dokumentami zewnętrznymi, ponieważ wiąże wszystko razem.

Nadal potrzebujesz dokumentów projektowych do niektórych rzeczy ... na przykład, jeśli twoja aplikacja jest podzielona na różne komponenty opracowane przez różne zespoły, musisz przynajmniej powiedzieć im, który komponent jest odpowiedzialny za które wymagania. Ale w przeważającej części dzisiejsze metodologie programistyczne pozwalają na znacznie więcej swobody, dając jednocześnie narzędzia do zarządzania i ograniczania ryzyka, które może wyniknąć z błędnej decyzji programisty.

Argumentowałbym za „ nie” .

Z prostego powodu, że

Dla wielu informatyków, w tym dla mnie kilka lat temu, idealny proces tworzenia oprogramowania wymagałby stworzenia szczegółowych dokumentów projektowych z dużą ilością diagramów UML, zanim zostanie napisany wiersz kodu.

Nigdy nie był uważany za „idealny”, ponieważ programowanie ekstremalne istnieje od lat 90 . I jak mówisz:

W idealnym przypadku nie powinno być opisu projektu oprogramowania poza samym kodem.

Kłócono się przed wiekami. Na przykład ten legendarny artykuł z 1992 roku: Czym jest projektowanie oprogramowania .

Powyższe pokazuje, że możesz mieć „ekstremalny” proces z wysoce ewolucyjną architekturą i iteracyjnym podejściem bez potrzeby stosowania skomplikowanych języków lub IDE.

Zamiast tego powiedziałbym, że to „pozorne” przejście od projektowania z dużą ilością diagramów i dokumentacji przypadków do bardziej ewolucyjnego i iteracyjnego podejścia polega na zastąpieniu menedżerów „oldschoolowych” nowymi, którzy dorastali w znacznie większym stopniu dynamiczne środowisko i dla kogo znacznie łatwiej jest zaakceptować i pracować w bardziej „zwinnym” środowisku.

Prawie się z tym zgadzam, ale myślę, że zaczęło się to znacznie wcześniej, niż sugerujesz. Myślę też, że oprócz ekspresji istnieje jeszcze jeden ważny czynnik. Kiedy mój ojciec po raz pierwszy zaczął programować, musiał tworzyć karty perforowane i planować czas na komputerze. Możesz mieć jedną szansę na uruchomienie swojego programu dziennie. Nie było dużo czasu, aby marnować kod budowania, pozwalając mu zawieść, a następnie naprawiając. Masz może 2 lub 3 strzały, a jeśli to nie działało, miałeś kłopoty.

Ryzyko to oznaczało, że bardzo ważne było poświęcenie dużej ilości dodatkowego czasu na zaplanowanie programu. Ludzie piszą swój kod ołówkiem, a następnie przenoszą go na perforowane karty. W miarę postępu technologii można było kodować bezpośrednio do terminala, ale nadal korzystano ze wspólnych zasobów, a procesor był drogi. Metodologia pierwszego testu byłaby całkowicie nie do utrzymania w tym świecie. Jeśli nie planowałeś z wyprzedzeniem, twoi rówieśnicy siedzieliby przy biurku z widłami.

Zasoby komputerowe stały się tańsze i lepsze w niewiarygodnym tempie. Wiele ograniczeń, na podstawie których opracowano wszystkie te praktyki, zostało całkowicie zatartych. Jak wskazuje Euphoric, odejście od tego naprawdę zaczęło się w latach 90. Kontynuacją dużej części dużego projektu z przodu była czysta bezwładność.

Tak, tak, poprawiona ekspresja języków programowania miała na to wpływ, ponieważ prosty ekspresyjny kod jest łatwiejszy do wykorzystania jako własnej dokumentacji. Koszt wytworzenia dokumentu, który mówi ci, co mówi kod, jest bardzo wysoki i ma swoją wartość (na pewnym poziomie jest nieuchronnie niepoprawny). Jednocześnie koszt rzucenia gówna na ścianę i zobaczenia, które drążki są w zasadzie nieistotne.

Myślę, że przede wszystkim zapomniałeś o celu posiadania dokumentów projektowych!

Dokumenty projektowe (wymagania, przypadki użycia, makiety itp.) Pozwalają nam opisywać, rozumieć i omawiać system na wysokim poziomie. Ilość szczegółów pominiętych w takich dokumentach sprawia, że ​​są one przydatne.

Nie ma potrzeby posiadania dokumentów opisujących dokładne zachowanie systemu systemowego we wszystkich szczegółach, ponieważ rzeczywiście sam kod źródłowy służy temu celowi.

Rozwój oprogramowania można uznać za proces przekształcania specyfikacji wysokiego poziomu czytelnych dla człowieka w jednoznaczne specyfikacje niskiego poziomu, które są wykonywane przez maszynę. Ale potrzebujesz wkładu w ten proces.

W idealnym przypadku nie powinno być opisu projektu oprogramowania poza samym kodem.

To jest dalej niż sugerujesz. Nawet rzeczy takie jak typy zależne (które, jak rozumiem, są dość obiecujące teoretycznie) są dostępne za kilka lat.

Weryfikacja formalna jest dość trudna, dlatego jedynym miejscem, w którym powszechnie stosuje się weryfikację formalną, są biblioteki kryptograficzne.

Testy jednostkowe

Jeśli testowanie nieruchomości nie znalazło się w głównym nurcie, nie sądzę, że będzie to praktyczne przez długi czas.

Co więcej, pisanie dobrych testów (które nie będą musiały być edytowane przy każdym refaktorze, ale nadal wychwycą wystarczającą liczbę błędów) jest dość trudne.

Aby upewnić się, że kod jest zgodny z twoimi dokumentami, musisz to sprawdzać raz za razem. W przypadku częstych zmian trudno jest zsynchronizować kod i dokumenty.

Prawdopodobnie łatwiej jest w tej chwili użyć narzędzia do testowania dokumentacji.

Jest jeden warunek konieczny do działania: kod musi być wystarczająco łatwy do odczytania i zrozumienia.

Niestety, projektowanie języków, które są nie tylko wyjątkowo wyraziste, ale także wyjątkowo czytelne, jest trudne. Języki takie jak Go nadają priorytet czytelności i kłóci się z myślami wyższego poziomu.

Wreszcie, z mojego doświadczenia, lepsze języki i narzędzia nie prowadzą do oprogramowania z mniejszą liczbą błędów, ale raczej do większych projektów. Tak naprawdę nie ma żadnego możliwego sposobu na pandocnapisanie w 1970 roku.