Czy dobry kod jest niemożliwy we współczesnym tworzeniu oprogramowania? [Zamknięte]

Wydaje się, że nawet jeśli narzędzia programistyczne stały się bardziej solidne i niezawodne, pisanie dobrego kodu stało się wyzwaniem. Nawet jeśli narzędzia są bardziej wydajne, jakość kodu nie poprawiła się. Wymyślam dwa ważne czynniki, jest mniej czasu, a projekty są bardziej złożone. Ponieważ narzędzia, których używamy dzisiaj, są bardziej wydajne, łatwiej jest napisać bardziej złożony kod, ale nie mając czasu na planowanie i bez patrzenia w przeszłość obniża jakość kodu oraz zwiększa błędy i konserwację. Nie jest tak, że nie pisaliśmy wcześniej skomplikowanego kodu. Chodzi o to, że piszemy bardziej złożony kod.

Moje pytanie brzmi: Biorąc pod uwagę, że mamy mocniejszy język i narzędzia.

• Dlaczego pisanie dobrego kodu jest trudniejsze?
• Czy przyczyniają się do tego czynniki, czas i złożoność?
• Czy metody nie są właściwie stosowane?

Uważam, że typem projektu jest aplikacja korporacyjna o dużej złożoności i logice biznesowej. Definicja „dobrego kodu” jest indywidualna, nie utknij w interpretacji „dobrego kodu”.

Jak stwierdzili DeMarco i Lister w Peopleware około 20ish lat temu, ogromna większość nieudanych projektów oprogramowania kończy się niepowodzeniem nie z powodu problemów technicznych, ale problemów socjologicznych . Nie zmieniło się to w ciągu ostatnich dziesięcioleci, bez względu na to, jak bardzo ulepszono nasze narzędzia.

Niewłaściwe zarządzanie, nierealistyczne oczekiwania, niedostosowanie odpowiednich ludzi do pracy i / lub niedopuszczenie do wykonywania pracy, w konsekwencji ich nie dotrzymanie; miejsca pracy i narzędzia, które nie są odpowiednie do prac programistycznych; nierozwiązane konflikty osobiste; polityka ; to tylko kilka typowych problemów, które od samego początku mogą skazać projekt na niepowodzenie.

Dlaczego pisanie dobry kod jest trudniejszy?

Nie jestem do końca przekonany, że naprawdę trudniej jest teraz napisać dobry kod niż dziesięć lat temu. W rzeczywistości, w porównaniu do kodu maszynowego lub zestawu, wszystko, co mamy teraz w głównym nurcie, jest o wiele łatwiejsze w obsłudze. Może właśnie musimy produkować więcej.

Czy to tylko ze względu na wspomniane czynniki, czas i złożoność?

Tak, na pewno osiągalne złożoność wzrosła (i ciągle rośnie) jako moc naszych narzędzi wzrasta. Innymi słowy, ciągle przekraczamy granice. Który mi tłumaczy tak, że równie trudno rozwiązać dzisiejsze największe wyzwania, jak to było 30 lat temu, aby rozwiązać ten dzień największe wyzwania.

OTOH ponieważ pole wzrosła tak ogromnie, istnieje sposób bardziej „małe” lub „znany” problemy teraz niż było 30 lat temu. Problemy te są technicznie (powinien) nie (być) to wyzwanie już, ale ... tu wejdzie wyżej maksyma :-(

Także liczba programistów od tego czasu wzrosła ogromnie. A przynajmniej moja osobista percepcja jest taka, że ​​przeciętny poziom wiedzy i doświadczenia zmalała, po prostu dlatego, że jest o wiele więcej juniorzy przyjeżdżający nieprzerwanie do pola niż istnieją seniorzy, którzy mogliby je kształcić.

Czy metodologie nie są praktykowane poprawnie?

IMHO na pewno nie. DeMarco i Lister mają ostre słowa na temat dużych metodologii. Mówią, że żadna metodologia nie może doprowadzić do sukcesu projektu - tylko ludzie w zespole mogą. OTOH Small-m metodologie chwalić są dość zbliżone do tego, co obecnie znamy jako „agile”, który rozprzestrzenia się szeroko (IMHO dobrego powodu). Nie wspominając już o takich wzorców jak testowanie jednostkowe i refaktoringu, który zaledwie 10 lat temu nie były powszechnie znane, a obecnie nawet wielu absolwentów wiedzieć nich.

Zagadnienia związane z programowaniem pod nierealnych terminów i radzenia sobie z długiem technicznym były znane od Weinberg '71 i '72 także Brooks. Literatura staje się trudne do kopania się online przed tym, ale jestem pewien, że są dość stare raporty CDC, IBM, a NASA mówią to samo.

Myślę, że każdy z nas ma własne pomysły i progi dla „dobrego kodu”. Istnieje jednak wiele problemów, które przyczyniają się do:

• Niewłaściwe zastosowanie „Get to działa następnie go poprawić” oznacza wyjeżdżamy martwego kodu i 10 różnych wariantów tej samej metody, gdzie każdy jest używany tylko raz w bazie kodu. Te rzeczy nigdy nie wydaje się być czyszczone.
• Brak czasu i budżetu. Klient chce 100 nowych funkcji w ciągu 3 miesięcy, niektóre z nich nie są trywialne i nie chcą wydawać żadnych pieniędzy na rzeczy, których bezpośrednio nie widzą.
• Brak opieki. Spójrzmy prawdzie w oczy, niektórzy deweloperzy dbają o sposób wygląda i zachowuje się kod więcej niż inni. Zobacz pierwszy podpunkt dla przykładu.
• Naprawdę nie wiemy, jak stworzyć „dobry kod”. Moja koncepcja dobrego kodu ciągle się rozwija. Co moim zdaniem było dobre dziesięć lat temu nie jest tak dobra, nic więcej.
• „Dobry code” to osąd wartościujący. Poza „działa” i nie ma znanych błędów, wszelkie inne kryteria dobrego kodu są w zasadzie kwestią opinii.

W końcu myślę, że najlepiej jest dążyć lepiej niż „dobra” lub „najlepsza”. Jeśli widzieliśmy najlepszy kod tam, by rozpoznać je jako takie?

Dlaczego pisanie dobry kod jest trudniejszy?

Ponieważ oprogramowanie jest coraz częściej opierają się na górze warstwy abstrakcji. Każda nowa technologia, która ma ułatwiać i przyspieszać programowanie, powoduje tylko jeden poziom złożoności, który deweloper musi zrozumieć. Teraz ta abstrakcja może mieć ogromną korzyść dla produktywności, ale jeśli nie rozumiesz, co próbują ukryć, oznacza to, że oprogramowanie jest bardziej podatne na błędy i słabą jakość.

Czy dobry kod jest niemożliwy we współczesnym tworzeniu oprogramowania?

Rzeczywiście, nie jest to możliwe. Ale nie dla każdego z powodów to już słyszałem.

Zakres zdecydowanej większości projektów jest dobrze poza możliwości ludzkiego mózgu. To dlatego ludzie mają pochodzić z ideą abstrakcji , czyli zachować szczegóły Ukrywanie i wspiąć się wyżej drzewa abstrakcji aż gęstości oddziałów (ilość informacji do uchwytu) zmniejsza się do akceptowalnej cenie.

Robiliśmy to, że rozwiązał problem złożoności, ale nie usunęła większy problem mieliśmy wcześniej.

Jest jeszcze zbyt skomplikowane dla nas obsłużyć.

Aby stworzyć rozwiązanie wysokiej jakości, musimy być w stanie jednocześnie widzieć i rozumieć wszystko w tym samym czasie, to wszystkie moduły w dużej i wszystkie drobne szczegóły realizacji. Wszystko na raz pojawiają się rozbieżności, zobaczyć każdy kawałek kodu w kontekście wszystkich możliwych scenariuszy i optymalizacji całego kodu bazowego w tym samym czasie.

My nigdy nie będzie w stanie tego zrobić.

A jeśli my nie możemy nigdy nie produkują kod jakości.

Menedżerowie zobaczą roztrzaskanie modułów, ale nie będą znać wewnętrznych problemów i ograniczeń na moduł.

Programiści modułów znają lokalne ograniczenia, ale nie będą w stanie ich zoptymalizować w kontekście większego obrazu.

Nie ma sposobu, aby komunikować zrozumienia pomiędzy menedżerów i programistów (a nawet między programistów). A nawet gdyby było, zdolność ludzkiego mózgu nie mógł sobie z tym poradzić.

Istnieje niewiele możemy zrobić oprócz próbować (a jałową). tylko kod keep Chodźmy mniej lub bardziej sprawne i cieszyć się życiem.

I zaprzecza założeniu na swoje pytanie. Jest to łatwiejsze niż kiedykolwiek napisać dobry kod, i dlatego jesteśmy rozwiązywanie problemów znacznie trudniejsze, że mamy rozwiązać wcześniej.

Nie chcę, aby podnieść na danym dostawcą, ale porównać Windows 1.0 do Windows 7. Ten ostatni zawiera tysiące razy więcej kodu, ale średni czas między wypadków wzrosła stokrotnie. Byliśmy powinien móc zamieścić arkusza kalkulacyjnego Excel w dokumencie programu Word od Windows 3.1, ale te dni to rzeczywiście bardziej lub mniej roboty.

Nie chcąc wpaść „ty dzieci te dni z typowania kaczki i VM” sentymentalizmu, chciałbym zaproponować, że nie masz pojęcia, jak trudno było napisać dobry kod z powrotem w latach 80-tych: tiny, mały, i ogromny modele pamięci, nakładki , non-rentrant wywołania systemowe (Dreszcz). Dobry riddance na wszystko.

Nowoczesne aplikacje są bardziej skomplikowane niż były 20-30 lat temu, ponieważ ich środowisko jest bogatsza i bardziej wszechstronny.

Zazwyczaj program DOS siedział w ciasnej pętli i czekał na kolejne naciśnięcie klawisza od użytkownika, a następnie wywoływał odpowiedni kod i wracał do oczekiwania na kolejne naciśnięcie klawisza.

Wszelkie nowoczesna aplikacja, gdzie nie można użyć myszy w ogóle do niczego, ma poważny problem wyjaśnienia. I wszystko może się zdarzyć w dowolnej kolejności, ponieważ użytkownik może pisać, klikać myszą i kontynuować pisanie, podczas gdy kanały RSS są aktualizowane w aplikacji, pokazując użytkownikowi najnowsze wpisy podczas pisania.

Wszystkie te wielozadaniowe rzeczy są z natury znacznie bardziej złożone niż wtedy, gdy trzeba było tylko pomyśleć o kluczach od użytkownika. To sprawia, że ​​coraz trudniej jest pisać prawdziwie dobrego kodu.

Mam nadzieję, że kiedy naukowcy odkryją, w jaki sposób możemy uczynić programy wielozadaniowe bardziej użytecznymi z punktu widzenia programistów, może to się złagodzić, ale na razie utknęliśmy w sytuacji, gdy wszyscy starają się to zrobić dobrze, ale nie do końca wiedzą, jak to zrobić to.

Wydaje mi się, że oprogramowanie zostało rozszerzone, aby wypełnić dostępną szybkość procesora, pamięci, dysku, a czas programisty. Można twierdzić, że to dlatego, że program realizuje wiele więcej. Cóż, jestem pewien, że ma osiągnąć dużo więcej, ale nie na tyle, aby uzasadnić uwędzić.

Myślę, że starożytne prawo nauka warto pamiętać:

Natura nie znosi próżni.

Francois Rabelas (francuski mnich i satyryk 1494/53)

W rzeczywistości, myślę, że stało się łatwiejsze do napisania dobrego kodu, czyli programy, które działają zgodnie z oczekiwaniami i są w utrzymaniu, w ciągu ostatniej dekady. Dostępne narzędzia są lepiej teraz, gdy libs są bardziej dojrzałe i kompleksowe, wyroby metalowe stało się znacznie szybciej, więc nie trzeba używać sztuczek optymalizacji.

Dlaczego więc nie my?

IMO głównym powodem jest to, że stale poszukują sposobów i wymówek do nadużyć rzeczy. Zamiast iść staromodny, łatwe, prawdopodobnie nudny sposób, jak tworzenie wykonywalny Windows możemy przesunąć granice tego, co możliwe i szukać sposobów na przykład odtworzyć coś podobnego PhotoShop jako aplikację internetową. Dlaczego? Ponieważ możemy. A przynajmniej tak nam się wydaje.

Kiedy ostatni raz KTOŚ nie pisanie exploit lub nauki, aby to zrobić goofed wokół z zespołu (nie licząc hakerów jądra i ASIC facetów)? Ile błędów wykryto w bibliotekach podstawowych C? Prawie żaden, a kilka z nich. Mówię tylko, że ludzie są w stanie doskonale kodować. Lepsze narzędzia i języki sprawiają, że jest to mniej „wymagane”, a bardziej „opcjonalne”. Nie dlatego, że myślę, że powinniśmy pisać kod wszystko naprawdę okropne, ale kiedy myślę o skomplikowanych konstrukcji logicznych ... nikt nie marzył o napisaniu czegoś z tablic hash w montażu. Musi istnieć „lepszy” sposób obsługi logiki zamiast stosowania skomplikowanej konstrukcji. Nawet jeśli kod jest piękny, czasami podejście nie jest tak eleganckie. Myślę, że to w pewien sposób rozwiązuje wspomniany problem. Dobry kod nie jest zawsze tak zorganizowane,

Myślę, że to dlatego, że lepsze narzędzia i szybsze komputery bardziej czułe myśli spodziewamy się uzyskać znacznie więcej czasu ostatecznego złożoność produktów perunit niż my kilka lat (lub kilkadziesiąt lat) z powrotem. Tak więc złożoność aplikacji stale wzrasta, a nasze założenia dotyczące co rozsądny poziom wydajności jest wciąż rośnie.

Tam, gdzie pracuję, programiści zawsze się spieszą (ponieważ zawsze jest więcej rzeczy, których klienci chcieliby, niż mają czas). Tak wiele bloków kodu kopiowane z minimalnym edycji i bez wysiłku wykonane naprawdę je zrozumieć. I oczywiście popełniane są błędy. Właśnie zobaczyłem błąd, który został naprawiony, w którym programista skopiował kod, który zoptymalizowałem, nie zdając sobie sprawy, że założenia, które usprawniły optymalizację, nie były prawdziwe w miejscu, w którym je umieszczał.

To wszystko sprowadza się do oczekiwania, zarówno wewnętrzne (nasze własne oczekiwania), a od naszych organizacji. Staramy się zrobić jak najwięcej w jak krótkim czasie, jak to możliwe. Błędy nieuchronnie wynikają.

Również reagowanie komputer zachęca szybki szybki edytować, a następnie bieg kompilacji i testowania. W dawnych dawnych czasach (jak 35years temu) Zwrot był tak powolny, że chciałbym wydrukować kod (źródło było karty dziurkowane wtedy), a nie ręczne stepthrough kodu przed złożeniem moją talię. Teraz, po prostu edycja kompilacji i uruchamiania. Tak więc wiele błędów, które zauważylibyśmy, poprzez metodyczne omawianie kodu, teraz liczymy na kompilator i / lub pakiet testów jednostkowych, aby go złapać.

W jaki sposób ludzie coraz gorzej w produkcji dobrego kodu?

Zażycie .NET i język jak C #, na przykład (i zdaję sobie sprawę, że nie jest to jedyna platforma / język), będę argumentować, że kodowanie dobrze stało się znacznie, znacznie łatwiej ze względu na automatyzację wielu rzeczy w Visual Studio środowisko.

Jeśli już, to po prostu fakt, że mamy teraz bardzo wyrafinowane IDE, które są w stanie przeprowadzić nas przez proces kodowania i programowania, sprawia, że ​​łatwiej jest osiągnąć „dobry kod”.

Programiści mogą teraz skupić się na tworzeniu dobrej struktury zamiast spędzać tyle czasu na pisaniu nawiasów klamrowych i nawiasów klamrowych i nowych linii oraz zapamiętywaniu wywołań metod i nazw klas.

Moje dwa centy.

Tak, my jako przemysł nie praktykuje tego, co jest znane jako dobre methodolgies. Numer referencyjny: Construx oprogramowania Steve McConnell za rozwój oprogramowania w zasięgu ręki .

jakość kodu nie poprawiła się

proszę nie utknąć w interpretacji „dobrego kodu”

Wielka logiczna tautologia.

Kod nie poprawia się, ponieważ ludzie ciągle zmieniają definicję „dobrego”.

Jeśli można”dyskutować«dobry kod», to nie można porównać i naprawdę nie mogę się zdecydować, czy jest to«wyzwanie», czy nie.