(przy założeniu kodu produkcyjnego)
Staram się iść trochę dalej. Pisałem o robieniu programów „idiotycznymi”, ale nie zawsze to kwalifikuję: piszę dużo kodu, którego inni ludzie nie zobaczą lub z którym nie będą pracować (przynajmniej takie są oczekiwania, kiedy zostaną napisane). jajestem idiotą, przed którym staram się obronić w tej sprawie. Dobrze jest, gdy Twój program wykrywa problemy, a problem został tak uproszczony, że oczywiste jest, że wystąpił błąd i jego pochodzenie. Prawda jest taka, że szczegóły implementacji są oczywiste, gdy piszesz program (chyba że wdrażasz go przedwcześnie), ale powinny być abstrakcyjne i odporne na błędy dla klientów (nawet jeśli istnieje lokalizacja modułu). Powodem jest to, że programy stają się bardzo złożone. Czasami możesz rozdzielić problemy, ale nie przez cały czas. Jeśli trzymasz swoje komponenty bardzo surowe, proste, dobrze zamknięte i idiotyczne, zwykle dobrze się skalują, a większość wad wykrywa się przed ich wysłaniem. Łatwiej jest ponownie użyć, a Ty masz więcej pewności siebie i łatwiejszego ponownego użycia programów. te złożone programy, które piszesz, stają się bardziej złożone (nawet dla ciebie) po pewnym czasie nieobecności w programie. Gdy przeczytasz go w ciągu 6 miesięcy, zrozumienie i debugowanie może potrwać absurdalnie długo w porównaniu z wersją idiotyczną. Jeśli składnik wprowadza przełomową zmianę, w przeciwnym razie może pozostać niewykryty przez długi czas. Programy są złożone; nie możesz uciec od tej rzeczywistości, ale możesz uczynić ją idiotyczną dowodem, co znacznie ułatwi ci życie, gdy coś pójdzie nie tak lub gdy trzeba go ponownie wykorzystać lub zmienić. Dlatego podejście idiotyzmu oznacza, że twoje oprogramowanie może być zrozumiane, ponownie użyte lub utrzymywane przez twoich juniorów lub osoby w zespole również (nie tylko kogoś tak dobrego / doświadczonego jak ty). Zastąpienie to osobny problem: jeśli ludzie uwielbiają pracować z twoimi programami, robisz dobrą robotę - nie martw się o wymianę. Jasne, mógłbym wymyślić scenariusze, w których niezrozumiałe programy mogłyby uratować twoją pracę, ale napisanie dobrego programu, z którego inni mogą korzystać i które jest utrzymywane, jest wyraźnie mniejszym złem (spójrz na odrodzenie się innych). Jeśli złapię się na pisaniu czegoś, co nie jest idiotycznym dowodem, staram się to naprawić.
Poza scenariuszem, w którym potrzebujesz dokumentacji dla siebie, aby kontynuować projekt po 6 miesiącach przerwy, wydaje się, że istnieje wyraźny konflikt interesów między deweloperem a firmą programistyczną.
Naprawdę nie masz pojęcia, co myślisz, kiedy wracasz do uśpionych implementacji. Kiedy jesteś naprawdę doświadczony, problem jest prostszy, ponieważ możesz polegać bardziej na ustalonych metodach lub podejściach, których używasz. To jednak zakłada również, że metody te są niezmienne. Mimo że dokumentacja może być luźna, nadal musisz być defensywny w swoich implementacjach (np. Wiesz, że w tym scenariuszu nie należy zdawać NULL - sprawdź ten warunek).
Jako programista powinieneś naprawdę napisać doskonałą dokumentację i czytelny kod dla wszystkich; czy też powinieneś napisać kod i dokumentację w taki sposób, aby spełniał zadanie i sam mógłbyś go zrozumieć, ale inna osoba może mieć problemy ze zrozumieniem?
Polecam idiotyczne podejście, które jest jeszcze jaśniejsze i bardziej odporne na błędy niż podejście oparte na współczynniku magistrali. Napisz swoje programy i dokumentację w taki sposób, aby były zrozumiałe dla osób spoza projektu - to też jest dobre dla ciebie. Takie postępowanie zwiększy twoją wartość dla twojej firmy i zespołu, nie będą chcieli cię zastąpić.