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

11

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)?

FinnNk
źródło
1
Analogia wydaje się nie pasować. Zarówno kunszt oprogramowania, jak i inżynieria oprogramowania mają ten sam cel (i żywotny interes), jakim jest poprawa długoterminowej użyteczności oprogramowania.
rwong,
3
Myślę, że ta kwestia dotyczy głównie tego, czy uważasz „inżyniera”, czy „rzemieślnika” za fajniejszy tytuł, a obecne odpowiedzi wydają się to potwierdzać. Niezależnie od tego, który tytuł wolisz, oczywiście oznacza to, że dana osoba wie, co robi.
Ben Brocka
Powiedziałbym, że różnica między nimi polega na tym, że rzemieślnik pracuje sam, inżynier pracuje w zespole. W szerokich pociągnięciach wydaje się, że spełnia to główne opisy dwóch ról, nie dlatego, że albo mają różne umiejętności, ale ich podejście pochodzi z różnych pozycji.
gbjbaanb
To po prostu brzmi jak pretensjonalny tytuł.
michaelsnowden,

Odpowiedzi:

13

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.

Allon Guralnek
źródło
Myślę, że ostatni jest szczególnie ważny
Lovis
7

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.

Thomas Owens
źródło
2
I zdecydowanie masz wykształcenie, aby poprzeć swoje doświadczenia - cieszę się, że nie powiedziałeś „formalny”.
treekoder
@greengit W wielu miejscach, aby użyć tytułu „inżynier”, musisz mieć formalne wykształcenie. W Europie oznacza to ukończenie studiów inżynierskich. Włochy dodają również wymóg zdania egzaminu certyfikacyjnego. W Ameryce Północnej, Teksasie, na Florydzie i w Kanadzie osoby, które używają tytułu „inżynier” (w tym inżynierowie oprogramowania), muszą zdać egzamin licencyjny.
Thomas Owens
Chociaż to nie znaczy, że ktoś bez tego formalnego wykształcenia nie może ćwiczyć inżynierii. Po prostu nie mogą się nazywać inżynierem jako tytuł zawodowy.
Thomas Owens
1
Nie zgadzam się, inżynier nie musi być rzemieślnikiem.
Nicole,
2
@Reneesis Z definicji inżynieria to rzemiosło. Definicja rzemiosła: „sztuka, handel lub zawód wymagający specjalnych umiejętności, zwłaszcza umiejętności manualnych”. Inżynieria to zawód, który wymaga specjalnych umiejętności, dlatego jest rzemiosłem. Jednak jest to również zastosowanie teorii naukowej (między innymi), co czyni ją bardziej.
Thomas Owens
2

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.

guillaume31
źródło
1
Nie zgadzam się - przyczyną niepowodzenia oprogramowania było to, że nie miał inżynierów, tylko rzemieślników udających inżynierów. NASA nie wysłała statku kosmicznego na Księżyc za pomocą rzemieślników!
gbjbaanb
@gbjbaanb Myślę, że jest wręcz przeciwnie - mieliśmy inżynierów i dlatego próbowali przenieść tradycyjny model inżynierii i sposób myślenia z innych branż na oprogramowanie, ale to nie zadziałało.
guillaume31
Statki kosmiczne nie są wykonane z niematerialnych rzeczy, które można przebudowywać, przeprojektowywać i ponownie rozmieszczać w kółko. Prawa, których przestrzegają, w dużej mierze różnią się od przepisów dotyczących oprogramowania.
guillaume31,
Wahadłowiec ma przynajmniej przenośne wzmacniacze i bez wątpienia ponownie wykorzystał fragmenty (lub przynajmniej wiedzę) z poprzednich rakiet. I statki kosmiczne mają w sobie dużo oprogramowania. Nie sądzę, że zaczynają od zera z każdym nowym satelitą lub sondą i prawie nigdy nie stosują aktualizacji po wdrożeniu. Inżynieria oprogramowania może i oczywiście działa - ale tylko wtedy, gdy podchodzisz do niej z nastawieniem inżyniera, a nie rzemieślnika.
gbjbaanb
Proszę zdefiniować „nastawienie inżyniera” w kontekście oprogramowania.
guillaume31
1

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 .
MIA
źródło
4
Szczerze mówiąc, wszystkie te punkty opisują dobrego inżyniera. Zwłaszcza 1, 2 i 4.
Thomas Owens
@ThomasOwens A co ze złym inżynierem? Czy on też jest rzemieślnikiem? A może dobry kontra zły rzemieślnik?
Euforii
@Euphoric Nie sądzę, że możesz być dobrym inżynierem bez bycia dobrym rzemieślnikiem. To jest jak inscenizacja. Musisz osiągnąć „dobrego rzemieślnika”, zanim osiągniesz „dobrego inżyniera”. Możesz jednak być dobrym rzemieślnikiem i nie być dobrym inżynierem.
Thomas Owens
1

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.

Tulains Córdova
źródło
0

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.

rwong
źródło
-1

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.

Antony Scott
źródło
3
Jak błyszczący tutaj mówimy? :-)
Chris
1
Przez większość czasu się z tym zgadzam - ale nie jestem pewien, czy ścisłe 100% jest zawsze warte zachodu - np. Pobierający / ustawiający, gdzie nie mają logiki. Również generowany kod lepiej jest pozostawić bez testów jednostkowych (chociaż testy integracyjne mogą być odpowiednie)
FinnNk 24.10.10
@FinnNk - zgadzam się. Ostatnio używałem dotCover i to mówi, że getter / setter jest objęty, jeśli jest używany w innym teście. Tak naprawdę nie miałem na myśli metody testowania dla każdego gettera i setera
Antony Scott,