Jakie konkretne praktyki można nazwać „kunsztem oprogramowania”, a nie „inżynierią oprogramowania”? [Zamknięte]

Chociaż nie jest to nowy pomysł , wydaje się, że w ciągu ostatnich kilku lat znacznie wzrosło zainteresowanie kunsztem oprogramowania (szczególnie często zalecanym tytułem książki Clean Code jest Clean Code: A Handbook of Agile Software Craftsmanship ).

Osobiście uważam, że kunszt oprogramowania jest dobrą inżynierią oprogramowania z dodatkowym zainteresowaniem zapewnianiem, że efekt końcowy jest przyjemnością w pracy (zarówno jako użytkownik końcowy, jak i ktoś, kto utrzymuje to oprogramowanie) - a także, że jego uwaga skupia się bardziej na poziomie kodowania rzeczy niż rzeczy przetwarzane na wyższym poziomie.

Aby narysować analogię - w latach 50. i 60. wybudowano wiele budynków w bardzo nowoczesnym stylu, które w niewielkim stopniu uwzględniały ludzi, którzy w nich mieszkali, ani tego, jak te budynki starzeją się z czasem. Wiele z tych budynków szybko przekształciło się w slumsy lub zostały rozebrane na długo przed przewidywaną długością życia. Jestem pewien, że większość programistów z kilkuletnim doświadczeniem będzie miała podobne bazy kodu.

Jakie są szczególne rzeczy, które może zrobić rzemieślnik oprogramowania, czego nie może zrobić inżynier oprogramowania (być może zły)?

Powiedziałbym, że jedyną różnicą między profesjonalistą a rzemieślnikiem jest troska z domieszką odrobiny pasji . Nie ma żadnej konkretnej, możliwej do zaobserwowania praktyki, która klasyfikowałaby człowieka jako rzemieślnika, ale raczej zbiór cech:

• Rzemieślnik dba o rzeczywistą jakość swojej pracy, a nie tylko o postrzeganą jakość.
• Rzemieślnik jest zainteresowany swoim rzemiosłem, który wykracza poza wykonanie pracy i naturalnie przyciąga ku swojemu rzemiosłu.
• Rzemieślnik dba o swój zawód, dążąc do doskonalenia swoich umiejętności, a nie tylko do rozwoju kariery .
• Rzemieślnik spędza trochę czasu poza płatnymi godzinami pracy (nawet jeśli jest to niewielka ilość czasu), robiąc coś ze swoim rzemiosłem, czy to dyskutując, ucząc się, czy nawet myśląc o tym.
• Rzemieślnik wie, jak mało naprawdę wie, i jest z tego powodu upokorzony.
• Rzemieślnik jest gotów uczyć tych, którzy są gotowi uczyć się, prowadzić tych, którzy szukają wskazówek i sam szukać tych rzeczy, kiedy ich potrzebuje.

Odrobina pasji obejmuje to wszystko, nie tracąc potu.

Osobiście uważam, że kunszt oprogramowania jest dobrą inżynierią oprogramowania z dodatkowym zainteresowaniem zapewnianiem, że efekt końcowy jest przyjemnością w pracy (zarówno jako użytkownik końcowy, jak i ktoś, kto utrzymuje to oprogramowanie) - a także, że jego uwaga skupia się bardziej na poziomie kodowania rzeczy niż rzeczy przetwarzane na wyższym poziomie.

Jak powiedział kiedyś mój profesor (parafrazując): „Jako inżynier oprogramowania dostarczanie oprogramowania to nie tylko twoja praca. Dostarczanie oprogramowania sprawia, że ​​klienci są zadowoleni”.

Jakie są szczególne rzeczy, które może zrobić rzemieślnik oprogramowania, czego nie może zrobić inżynier oprogramowania (być może zły)?

Nic - inżynier jest rzemieślnikiem ... ale więcej. Inżynieria opiera się na rzemiośle.

Jako rzemieślnik i inżynier jesteś wykwalifikowanym specjalistą dzięki połączeniu edukacji i doświadczenia. Przestrzegasz ustalonych procedur. Jesteś także pragmatyczny i zdajesz sobie sprawę z tego, co jest zepsute i musi być lepsze.

Jednak inżynier dodaje do tego obawy dotyczące ekonomii, teorii i nauki. Obawiasz się, aby uzyskać jak największe korzyści przy jak najmniejszych kosztach. Chcesz zastosować teorie z psychologii, socjologii, zarządzania, interakcji człowiek-komputer i informatyki, aby rozwiązać swoje problemy (zarówno interpersonalne, jak i techniczne). I zdecydowanie masz wykształcenie, aby poprzeć swoje doświadczenia.

Ruch tworzenia oprogramowania został zainicjowany w reakcji na awarie i niezadowalające wyniki „tradycyjnej” inżynierii oprogramowania, które (wraz z nieostrożnością niektórych programistów) prowadzą dziś do nieufności interesariuszy i użytkowników wobec naszego zawodu.

Jego cel jest dwojaki: przywrócenie programistom zaufania, a w tym celu podniesienie poprzeczki w zakresie jakości oprogramowania i umiejętności programistycznych.

Sw rzemiosło promuje praktyki techniczne, takie jak:

• SOLIDNE zasady projektowania
• Wzorce projektowe
• TDD (metafora „podwójnego zapisu”)
• ...

Oraz praktyki zespołowe / organizacyjne:

• Programowanie par
• Mentoring
• Kod katas
• Wycofanie dojo / kodu
• ...

Powiedziałbym więc, że różnica między nimi jest wyraźna: kunszt oprogramowania stara się rozwiązać dużą część problemów, jakie istniały w inżynierii oprogramowania od ponad 40 lat, przez co nasza dyscyplina wygląda na zawodną i kaleką z historią awarii.

Przechodząc przez http://manifesto.softwarecraftsmanship.org/ wywnioskowałbym następujące.

Rzemieślnik różni się od tradycyjnych wyobrażeń o „inżynierze”, ponieważ

• Koncentrują się na wartości, a nie tylko na spełnianiu wymagań.
• Koncentrują się na jakości nawet w stylu kodu, a nie tylko na spełnianiu wymagań.
• Uczestniczą w szerszej społeczności programistów, a nie tylko w miejscu pracy.
• Nie tylko rozumieją, że dzisiejszy stan wiedzy jest jutrzejszym śmieciem, ale aktywnie działają na tym poziomie.
• To nie tylko praca, to kim oni są .

Wujek Bob w jakiś sposób zasugerował, że programowanie jest bardzo młodą dyscypliną, która nie ma jeszcze stabilnego zbioru przepisów lub reguł uznawanych przez rządy (czy to był Frederick Brooks?). Nie piszę tutaj werbalnego cytatu.

Nie możesz odebrać nikomu pozwolenia na programowanie z powodu nadużyć. Programowaniu brakuje zbioru przepisów i zasad, które nie są prawnie egzekwowane przez ustawodawstwo zgodne z „zawodem”. Lekarz zabija pacjenta z powodu niekompetencji i ryzykuje, że zostanie mu odebrany tytuł lekarza lub pozwolenie.

Programista tworzy błędny program lub projekt kończy się niepowodzeniem z powodu niekompetencji i może kontynuować programowanie.

Myślę, że to właśnie sprawia, że ​​programowanie jest rzemiosłem. Producent glinianych garnków nie tworzy dwóch identycznych garnków. Nie słyszałeś też o wytwórcy gliny zmuszonej do wycofywania wadliwych garnków. Programowanie jest nadal bardzo ręcznym, osobistym rodzajem pracy. Czasami można nawet powiedzieć, kto napisał fragment kodu, oceniając jego styl.

Refaktoryzacja do wzorów.

Oznacza to, że zbuduj coś, co spełnia 90% wymagań oprogramowania, a następnie przekształć cały projekt w czysty, elegancki wygląd.

Zwykle inżynieria oprogramowania nie pozwala ci tego zrobić, ponieważ spełnienie 90% wymagań oznacza, że ​​oprogramowanie ma dla klienta wystarczającą wartość biznesową, aby nie można go w żaden znaczący sposób modyfikować (z wyjątkiem poprawek o wysokim priorytecie).

Zamiast tego inżynieria oprogramowania zaleca ustabilizowanie oprogramowania w tym momencie.

Ponadto, jeśli projekt nie zaczyna się od tego eleganckiego projektu od samego początku , zgodnie z inżynierią oprogramowania byłby uważany za projekt źle wykonany (niezależnie od wyniku projektu).

Spike Solution.

Projekt zainspirowany rozwiązaniem szczytowym jest zwykle nie do przyjęcia zgodnie z obowiązującą metodologią inżynierii oprogramowania.

Wycofanie z jakiegokolwiek powodu.

W inżynierii oprogramowania każde wycofanie może nastąpić dopiero pod koniec cyklu życia systemu oprogramowania. Należy to zaplanować w ramach SDLC.

W praktyce dość często zdarza się, że wady konkretnej części interfejsu oprogramowania są wykrywane kilka lat po rozpoczęciu produkcji, i że ta konkretna część może być przestarzała w połowie cyklu życia, bez unieważniania pozostałej części oprogramowania. Wymagałoby to ponownej certyfikacji całego systemu oprogramowania po wycofaniu, zgodnie z inżynierią oprogramowania.

Ostatecznie kunszt oprogramowania jest osobistym dążeniem do dobrego osądu osób, podczas gdy inżynieria oprogramowania jest konserwatywnym zasobem wiedzy. Umożliwienie dobrego osądu przy podejmowaniu decyzji w ramach projektu odróżnia kunszt oprogramowania od inżynierii oprogramowania.

Powiedziałbym, że testy jednostkowe obejmujące 100% kodu byłyby dobre. Dzięki temu nadmiar materiału można usunąć.

Czasami porównuję tworzenie oprogramowania do rzeźby. To nie to, co dodajesz, to to, co zabierasz.

Oczywiście możesz posunąć się za daleko. Nikt nie powie, że mały błyszczący kamyk to dobra rzeźba: S.