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


19

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”.

Odpowiedzi:


34

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.


2
Nie być gramatyka nazistowski albo coś ale „irrealistic” (W akapicie drugim) nie jest słowem. Myślę, że masz na myśli „nierealne”.

Mogę tylko wspierać kwestię „Junior”. Jestem jednym z nich i na pewno szkoda, że nie miał mentora, aby mi pomóc. Jest wdzięczny, że Internet jest tam do dziś, a Amazon a więc pomóc, ale ...
Matthieu M.

1
+1: Warto też wspomnieć, ze względu na szybkie zmiany i wzrostu w narzędzia / technologii / metodyki do pewnego stopnia jesteśmy wszyscy juniorzy co najmniej kilka razy w roku. Doświadczenie to pozwala niektórzy weterynarze, aby dostać się do prędkości szybciej niż niektóre Jrs.
Steven Evers,

I odmówić podjęcia tej kwestii poważnie, chyba że nie mamy żadnych formalnych zasad aby rozdzielić piękną kod z brzydkiego jeden.
shabunc

17

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.


1
+ Dla „długu technicznego” i referencje.
Amir Rezaei

10

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?


1
+1 Dobry punkt. Przez „dobrego kodu” nie odnoszą się do doskonałego kodu. Idealne kod nie istnieje. „Dobry kod” to kod, który nie powoduje bólu głowy, na przykład jest dobrze przemyślany.
Amir Rezaei

1
Doskonały punkt na temat tego, że „dobry kod” jest ruchomym celem. Jednak nie zgadzam się, że była to tylko osąd wartościujący. Uważam, że czysty kod jest łatwiejszy do testowania, rozszerzania i utrzymywania w czystości niż nieporządny kod, dlatego jest znacznie tańszy na dłuższą metę. Oczywiście, ponieważ zazwyczaj nie uruchomić testy metodą podwójnie ślepej próby z grupami kontrolnymi w projektach rzeczywistym SW ;-), jest tylko niepotwierdzone dowody na to, nie ma twardy dowód naukowy.
Péter Török

Wygląda na to, że obie nasze obecne definicje „dobrego kodu” się zgadzają. Jednak widziałem kilka gwiazd raczej przykłady dobrego projektu API, które złożyły swoje życie o wiele łatwiejsze - ale biblioteki nie mają testy jednostkowe. To nie znaczy, że nie był testowany, po prostu nie było niczego, co mogłoby zautomatyzować testowanie. Wyjeżdżam miejsce na to.
Berin Loritsch

8

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ść.


+1 Bardzo dobra uwaga, nowe narzędzia zwiększają produktywność, co może prowadzić do większej złożoności.
Amir Rezaei

1
+1. Znany również jako „prawo nieszczelnych abstrakcje”. :)
Bobby Stoły

6

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 jak ta odpowiedź, jeśli tylko nie zostały napisane w taki, fatalistyczną tonie pesymistycznym ...
Timwi

1
@Timwi: Nie bardzo pesymistyczny. Miał przynieść ci ulgę obciążeń. :)

4

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.


Nienawidzę, aby przejść off-topic, ale osobiście jestem zdania, że Windows 1.0 do 3.11 były rzeczywiście bardzo stabilny, dzięki przypuszczalnie na ich brak złożoności. W crashiest wersje Windows były 95, 98 i ME. Oczywiście, które wersje były „dobre” w inny sposób, to inna sprawa.
Timwi

Co o kodowanie na minikomputery lub mainframe zamiast układów małej mocy? Kwestie odwołać są związane z modelem Intel 8086 ...
Paul Nathan

@Paul, 8086 Problemy te były najbardziej zaangażowane byłem z, więc budzić duży niepokój w moim umyśle. Jednak narzędzia do pisania oprogramowania nawet na komputerach mainframe były niezwykle surowy współczesnych standardów. Redaktorzy byli generalnie bliżej Edlin niż były do Emacsa. Jeszcze w 1982 roku używałem NUROS (Uniwersytet Nebraska zdalnego systemu operacyjnego) na sprzęcie IBM. Praca zostały zaprogramowane i uruchomić za pomocą „wirtualnych” kart perforowanych. I nie zapominajmy błędy Y2K, wywołana głównie na wielkim żelaza przez postrzeganych ograniczeń dotyczących przechowywania.
Charles E. Grant

2

Nowoczesne aplikacje 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.


+1 „Nowoczesne aplikacje są bardziej skomplikowane niż były 20-30 lat temu”
Amir Rezaei

2

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)


1

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.


1
Nie zgadzam się z sugestią, że innowacje powinny być unikane, oraz staroświeckie technologie lub metody nie powinien być zastąpiony. Równie dobrze można przestać pisać żadnych programów wtedy i tylko wykorzystać to, co mamy ...
Timwi

Timwi: Ja nie polemizując innowacji. To tylko dlatego, że wydaje się tak trudne do napisania dobrego kodu.
user281377

1

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,


Wbudowane faceci systemowe pisać przyzwoitą kwotę montażu.
Paul Nathan

@Paul Nathan prawda
RobotHumans

0

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ć.


Brzmi jak młoda firma, która jeszcze nie nauczyła się, że najtańsze robi to dobrze za pierwszym razem ...

Thorbjorn: Zadziwiająco to już od prawie trzech dekad. I faktycznie ma się całkiem dobrze. Oczywiście istnieją modele biznesowe, które są bardzo wrażliwe na żądania klientów (nas), a niektóre są bardzo zorientowane na jakość. Naprawdę trudno być jednym i drugim.
Omega Centauri

0

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.



-2

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.


Dla mnie „kodeksu dobrych” jest taka, że zmniejsza liczbę błędów. Teraz, że można osiągnąć na wiele sposobów.
Amir Rezaei

@Amir Rezaei: „Definicja«dobrego»kodu jest indywidualna”. „„ dobry kod ”pozwala zmniejszyć liczbę błędów” Wybierz tylko jedną definicję i zaktualizuj pytanie, tak aby zawierała tylko jedną definicję.
S.Lott

Well „«kodeks dobrych»jest taka, że zmniejsza liczbę błędów” to moja osobista koncepcja „dobrego kodu”. Myślę, że każdy wie, kiedy projekt wymaga oczyszczenia, czy nie .
Amir Rezaei

@Amir Rezaei: To jest mój punkt widzenia. Jeśli nie mogą (lub nie chcą) określenie „dobry” w odpowiedzi na pytanie, czym nie możemy porównać. Możesz twierdzić, że liczba błędów jest taka sama. Inni mogą twierdzić, że koszty błędów spadają. Innym może twierdzić, że ryzyko biznesowe z powodu planowania błędy idzie w górę. Bez jednej definicji „dobrego” wszyscy możemy mówić o różnych rzeczach. Proszę zaktualizować pytanie.
S.Lott

Dobry kod: skompilował, przeszedł testy, otrzymał zgodę użytkownika i został wprowadzony do produkcji. Tylko nadzieja nikt nie chce go zmienić.
JeffO
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.