Jak dobry programista powstrzymuje się od tworzenia kodu z niskim współczynnikiem hit bus? [zamknięte]

Powiedziałbym kod, który ma dobre testy jednostkowe . Dla dewelopera zastępczego przystępującego do projektu ważna jest świadomość, że ich zmiany nie łamią innych części systemu.

Najtrudniejszą częścią utrzymania IMO jest niewiedza, co oprogramowanie robi i jak to robi: to jest wiedza, co oprogramowanie ma robić.

Jeśli wiem ...

• Do czego ma służyć oprogramowanie (czyli Specyfikacja funkcjonalna... Nie koniecznie potrzebuję specyfikacji projektu)

• Jak zbudować, jak uruchomić i (zgodnie ze specyfikacją funkcjonalną) jak przetestować istniejące oprogramowanie

... to jest najważniejsze. Inna dokumentacja (np." design": która opisuje jak specyfikacja funkcjonalna jest implementowana przez oprogramowanie) może być przyjemna, ale jest stosunkowo opcjonalna i mniej ważna niż powyżej.

Większość programistów odpowie na twoje pytanie, mówiąc: "komentarze w kodzie, dobrze nazwane identyfikatory, Kontrola źródła itp." ... ale myślę, że ważniejsze jest " jako programista, jeśli piszesz oprogramowanie, które nie ma pisemnej specyfikacji funkcjonalnej, następnie napisz trochę specyfikacji funkcjonalnej, aby przejść do oprogramowania."FS będzie przydatny nawet zanim ktoś spróbuje utrzymać oprogramowanie: będzie przydatny dla QA, którzy chcą wiedzieć, jak przetestować oprogramowanie.

A kto jest odpowiedzialny za zapewnienie, że programiści, sprowadzeni do zachowania odrobiny kodu, są w stanie go zrozumieć?

Zazwyczaj jest to nowy lider zespołu programistów( tj. starszy programista, który zna już istniejący kod); ale w przeciwnym razie (jeśli nie ma takiego lidera zespołu) może to być Menedżer (Menedżer produktu lub projektu lub "inżynier wydania"), jeśli ten menedżer wie, gdzie znaleźć specyfikacje funkcjonalne i instrukcje budowania oprogramowania.

Regularne peer code reviews pomoc. Oznacza to, że co najmniej jedna inna osoba musiała przejrzeć każdą linijkę kodu i powinna była zażądać, aby w razie potrzeby została zmieniona dla jasności.

Nieustannie dążę do przejrzystości kodu nad zwięzłością, która powinna pomóc przyszłym programistom. Jednak są sytuacje, w których nie można pomóc, ale napisać kod, który jest nieco rozwarty. W tym przypadku zbieram zespół razem na 30 minut, aby przejść przez wysoki poziom idei, jak działa kod, jeśli nie pełne wyjaśnienie.

Zestaw testów jednostkowych pomaga również innym programistom mieć pewność, że zmienią Kod, ponieważ będą wiedzieli, kiedy wprowadzą zmianę, która łamie część systemu. Jeśli są dobrze napisane, mogą również wyjaśnić, w jaki sposób części systemu mają działać poprzez nazewnictwo, a nie wyłącznie poprzez kod.

Kiedy pracowałem jako student programista na mojej uczelni podczas mojego licencjata mój bus Hit Factor musiał być ściśle zarządzany. Pracowałem przy dużych projektach, ale moje zatrudnienie tam było tylko do dnia, w którym ukończyłem szkołę. W tym momencie inni programiści z działu będą musieli odebrać mój projekt i zarządzać nim stamtąd. udało mi się to z wiadrami dokumentacji.

Odkąd zacząłem pracę, starałem się zachować specyfikacje, kod i inne dokumenty tak aktualne i czyste, jak to możliwe, aby każdy kompetentny współpracownik mógł uzyskać solidne zrozumienie mojej pracy w ciągu kilku dni (z moją pomocą lub bez niej). Każdy mój projekt miałby odpowiednią Wiki Confluence, gdzie przechowywałbym całą dokumentację, diagramy, specyfikacje i małe "ciekawostki"dla innych programistów.

Pomaga również, jeśli masz dobry czysty styl kodowania. Jeśli twój kod ma sens i jest łatwy dla oczu, inni programiści powinni być w stanie odebrać go po nieszczęśliwym wypadku autobusowym.

W organizacji zawsze powinno być powielanie wiedzy.

Tak jak zawsze wykonywałbyś kopię zapasową swojego dysku twardego (prawda???), nie chcesz, aby jedna osoba była jedynym posiadaczem ważnych informacji. jednym ze sposobów na złagodzenie tego problemu jest współpraca programistów .

To, o czym wspominasz jako problem "autobusu", jest bardziej praktycznie czynnikiem "co jeśli Joe odejdzie / zdecyduje się odejść" . Ogólnie rzecz biorąc, zatrudnienie jest do woli, a każdy może odejść w dowolnym czas.

Prężna organizacja nie może polegać na pojedynczym deweloperze posiadającym całą ważną wiedzę.

Kontrola źródła i dobrze przemyślany i skomentowany kod są kluczowe.

Ludzie odpowiedzialni za zapewnienie, że tak się nie stanie, to naprawdę wszyscy zaangażowani w kod. Menedżerowie Dev i PMs to ludzie, którzy powinni mieć na to oko, ale kierownictwo wykonawcze musi wprowadzić zasady, aby je wspierać i mieć dostępne zasoby, aby zapewnić, że wiele osób o nakładających się obszarach wiedzy jest możliwe.

Programowanie par zmniejsza to ryzyko w dość wysokim stopniu. Jeśli nie możesz tego zrobić (wielu z nas nie ma luksusu, aby dopasować się do każdego projektu), zawsze możesz zaplanować regularne recenzje i dokumentować swój kod , gdy idziesz, w przeciwieństwie do dokumentowania na końcu.

Debugowanie jest trudne. Tak więc, jeśli jesteś kodowanie tak sprytnie, jak to możliwe, jesteś to będzie zbyt głupie, żeby debugować kod.

• prosty kod poprawia łatwość konserwacji
• Kontrola kodu dla prostoty
• kierownicy projektów ponoszą odpowiedzialność

C2 wiki miało kiedyś artykuł o nazwie "nie ufaj deweloperowi w pokoju przez miesiąc" . Nawiązaniem były plany projektu z pozycji linii jak "implementation System, Fred, six weeks", gdzie zarządzanie projektem składa się z rozmów Typu " Jak leci Fred? Nadal jesteśmy w porządku przez sześć tygodni?"i Fred mówi:" tak, myślę, że jesteśmy tam w 80%."

Zdrowy numer autobusu to efekt uboczny kultury, która unika " dewelopera w pokoju przez miesiąc" syndrom. Myślę, że to kwestia bardziej kulturalna niż techniczna - numer autobusu jest atrybutem organizacji, a nie bazy kodowej - a standardy muszą być ustalane od góry do dołu. Cechy charakterystyczne tej kultury to:

• powszechnie rozumiane cele organizacyjne i procesy biznesowe, tak aby programiści mieli coś innego niż wąsko-techniczna perspektywa podejmowania decyzji i aby mieli ramy do dyskusji za i przeciw z interesariusze nietechniczni.
• konkretne wyznaczanie celówi weryfikowalne wskaźniki postępu, unikanie rzeczowników abstrakcyjnych, takich jak "system", do którego każdy przywiązuje swoje znaczenie, słowne raporty "prawie zrobione" lub "80% zrobione" rozumiane jako nie zrobione w żaden widoczny sposób, dzwonki alarmowe wyłączają się, jeśli kilka dni upłynie bez obiektywnego postępu ze strony dewelopera (nowe testy, nowa wersja demo itp.).
• audyt i odpowiedzialność : jesteś nie tylko odpowiedzialny za wykonywanie swojej pracy, jesteś odpowiedzialny za renderowanie konta dla swoich kolegów. Poproszenie o renderowanie konta nie jest w żaden sposób krytyką, jest środkiem wsparcia i sposobem "sprawdzenia" swojej wiedzy w organizacji.
• ciekawość, chęć wspierania kolegów . Problemy z numerami autobusów są często pogarszane przez niechęć innych programistów do pomocy ich kolegom narażonym na awarię autobusu w przypadku, gdyby zostali zainfekowani przez rozległość tego kolegi obowiązki i zaległe prace konserwacyjne.
• nieformalnekanały podnoszenia problemów i wątpliwości (na przykład koledzy jedzą razem lunch) oraz formalne procesy logowania i eskalacji problemów.

W kolejności ważności (oczywiście jest to moja własna opinia):

• wyraźnie nazwane obiekty, zmienne i nazwy funkcji
• jasne komentarze
• Kontrola Źródła
• Code Reviews
Rozsądne oprogramowanie do śledzenia błędów, z prawdziwymi notatkami o tym, co się stało.
• dokumentacja tam, gdzie jest to konieczne (ale tylko tam, gdzie jest to konieczne; zbyt wiele sprawia, że trudno znaleźć to, czego potrzebujesz)

A osoba za to odpowiedzialna? Ty, z oczywiście.

Poprzez stosowanie zwinnych procesów programistycznych, które promują "własność" całego kodu przez cały zespół.

Dobrze napisany kod jest prawdopodobnie optymalnym rozwiązaniem. Przez dobrze napisane, mam na myśli, że instrukcje są zwięzłe, nazwy zmiennych i metod znaczące, a system dobrze zaprojektowany. I co bardzo ważne-nie powinno to zaburzać bieżących procesów dewelopera.

Obszerna dokumentacja będzie przeszkodą - zarówno dla obecnego, jak i przyszłego kodera.

Sformalizowane procesy (jak testy jednostkowe) są przeszkodą w bieżącej szybkości rozwoju (chyba że oczywiście in house coder jest zwolennikiem tego procesu).

Armia maszeruje w tempie najwolniejszego marszu. Sparowanie innego programisty z kimś, kto jest bardzo produktywny, spowolni go. Bardzo rzadko sklep ma więcej niż 1 super wydajny koder.

Każdy w firmie jest albo częścią rozwiązania, albo częścią problemu.

Jeśli ktoś zostanie potrącony przez autobus, a ty nie masz przerąbane, to znaczy, że ten ktoś był częścią problemu. Nie chcesz rozszerzać obszaru problemu w swojej firmie tylko po to, aby zapobiec wzrostowi współczynnika uderzeń autobusów.

I vice versa-jeśli ktoś użyteczny zostanie potrącony przez autobus, zawsze masz przerąbane, bez względu na wszystko. Im bardziej spóźniona osoba przyczyniała się do firmy, tym bardziej jesteś pieprzone.

Bus hit factor nie jest czymś szczególnym istniejącym tylko w tworzeniu oprogramowania, ale raczej ogólnym ryzykiem biznesowym.

Więc odpowiedź brzmi: nie oczekuj, że czyste ryzyko biznesowe może być rozwiązane magicznie za pomocą technologii, narzędzi lub metodologii. Pomyśl o wanilli business 101. Oszacuj ryzyko, oszacuj koszt jego złagodzenia, porównaj liczby, działaj odpowiednio.

Mam teraz ten problem. Zasadniczo termin jest szalony i nie ma czasu rozruchu w lewo dla innych deweloperów.

Myślę, że rozwiązaniem jest mieć więcej niż 1 deweloper zaprojektować system od początku. Zawsze. Trzech programistów jest lepiej(Wiem, że to ulubiony rozmiar zespołu Google). W ten sposób więcej niż jedna osoba rozumie ten system od samego początku, dokładnie, wiedząc, jak działa i dlaczego został zaprojektowany w ten sposób.

Można powiedzieć " ale co z zasoby w małej firmie?"Szkoda, jeśli masz dwóch programistów i trzy projekty jednocześnie, obaj programiści powinni przenosić się między wszystkimi trzema z nich, wymieniając pomysły i dzieląc się obciążeniem pracą, nawet jeśli jest to bardzo kosztowne i nieefektywne, aby mieć taki transfer. Ale na dłuższą metę, cały zespół będzie jednym ekspertem we wszystkich częściach kodu.

W Przeciwnym Razie w pewnym momencie wejdzie na pokład ktoś zupełnie nieznający kodu i zniszczy go, z najlepsze intencje, oczywiście. I proszę bardzo, doskonały system, może nawet klejnot w koronie firmy, schodzący ze wzgórza. Puf.

Poprzez zastosowanie wzorca projektowego, który reguluje styl kodowania, konwencje i ogólną niskopoziomową architekturę techniczną. W ten sposób każdy koduje "tak samo", więc jeśli ktoś nowy musi wejść na pokład, może po prostu podążać za wzorcem projektowym.

Może to być irytujące dla kreatywnych umysłów (ponieważ elastyczność jest zagrożona), ale zapewnia spójną bazę kodu, a także promuje spójne, wyrównane testy jednostkowe.

Podsumowując:

• Wzorzec(y) projektowy (y)) upewnienie się, że każdy programista jest zgodny ze wzorcem (możesz nawet użyć zasad kodu w visual studio team foundation, aby wyegzekwować te zasady)

• Testowanie jednostkowe, które obejmuje więcej niż 80% pokrycia kodu (co również toruje drogę do rozwoju opartego na testach)

Znalazłem ten wpis na blogu , który zawiera kilka ciekawych punktów:

1. Keep things simple: Keep processs as simple as possible (but nie prościej!). Zapewnia to, że procesy są łatwe w utrzymaniu i stąd łatwo uczyć innych. Prostota zwykle sprowadza się do dwóch rzeczy: a) za pomocą odpowiedniego narzędzia do właściwej pracy, a b)przy użyciu najbardziej prosty sposób na osiągnięcie tego, co potrzebne. Widziałem kilka procesów które są niepotrzebnie skomplikowane przez nieodpowiednie technologie lub wykorzystanie technologie. Aby rozwinąć temat te ostatnie, procesy są nadprogramowane często nie z innego powodu niż wykazać się sprytem twórca procesu. Unikaj tworzenia takich Rube Goldberg przetwarza za wszelką cenę! Ważna, prostota związana czynnikiem (z punktu widzenia magistrali) jest aby korzystać z technologii, które są znane do więcej niż jednej osoby w zespole. To buduje wysoki współczynnik magistrali z początek.
2. dokument, dokument, dokument: to jest bezmyślne, ale ludzie wciąż myślą, że ujdzie im to na sucho najpierw i Później." Dokumentacja wykonana po fakcie jest często mniej niż przydatne, ponieważ autor zapomina o niektórych (wielu?) mały szczegół(y), które, oczywiście, obracają się być krytycznymi w czasach kłopoty. Jaki powinien być proces dokument zawiera? Wystarczy, aby pomóc niech ktoś wykombinuje co, jak, gdzie, kiedy-co robi; jak to działa; gdzie siedzi (serwery itp.); a gdy i jak często jest uruchamiany. Na dokumentacja powinna również zawierać niektóre podstawowe informacje o rozwiązywaniu problemów i odniesienia do odpowiednich sekcji podręczniki. Innym ważnym punktem jest synchronizować dokumentację z procesu - czyli aktualizacji wszystkich odpowiednie dokumenty, gdy Proces jest modyfikowany. Jest to niezbędne ponieważ dokumentacja procesu jest Twoim tylko wtedy, gdy właściciel procesu z autobusem factor 1 idzie pod autobus zamiast się tym zająć.
3. małe słowo o stylu jest być może w kolejności - proces dokumentacja powinna być zgodna z 3CS jasności, zwięzłości i zrozumiałość. Tak, jest to możliwe pisać w sposób, który osiąga wszystkie trzy, choć nie jest to widoczne w moje pismo. Zachęcaj ludzi do wybierania up secondary skills: the first two punkty rozpatrywane w procesie i dokumentacja. Jednak w końcu to czy ludzie, którzy tworzą rzeczy się zdarzają. Pomimo dobrze zaprojektowanego i udokumentowanego procesów, można jeszcze mieć niskie bus factor jeśli zespół nie ma redundancja umiejętności. Who ' ll care after bazy danych, gdy dba idzie Pod (lub jest przejechany) przez autobus? To pytanie nie musiałoby być zadawane, gdyby ktoś został przeszkolony w podstawowe zadania DBA. W miarę możliwości, każdy w zespole powinien mieć w przynajmniej jedna Drugorzędna umiejętność, która będzie pozwól im kryć kogoś innego.

Kontrola źródła z komentowanymi logami zmian jest prawdopodobnie kluczowym komponentem.

Nie kodując w izolacji. Porozmawiaj z innymi członkami zespołu o kodach, które piszesz. Miej recenzje kodu. Wdrożenie wspólnych strategii rozwiązywania problemów. Jeśli jesteś na tej samej stronie, co wszyscy w zespole, współczynnik trafienia w autobusie będzie niski.

Jeśli jednak jesteś samotnym programistą, kilka innych postów tutaj już obejmuje idee standardów kodowania, dokumentacji itp.

Projekt powinien być łatwy do sprawdzenia i konfiguracji. W naszej firmie wszystkie projekty to CVS i Eclipse i Maven, więc przy kasie robisz "maven eclipse" i jesteś gotowy.

Od tego momentu potrzebujesz dobrego podręcznika dla programistów (Nie 500-stronicowego dokumentu, tylko niezbędnych rzeczy, aby zacząć). Podręcznik dev wskazuje na różne dokumenty, w których programiści mogą znaleźć informacje na temat projektu i innych rzeczy.

System śledzenia błędów jest koniecznością, a dobre opisy w błędach są muszę.

Spróbuj skomentować swój kod i bądź na bieżąco z javadoc.

Pomagają również dobre testy jednostkowe. Staraj się, aby testy jednostkowe były prostym pakietem, w którym możesz po prostu uruchomić je wszystkie bez konieczności konfigurowania wszelkiego rodzaju rzeczy.

Mam nadzieję, że to pomoże.

Po prostu przez posiadanie więcej niż jednego dobrego programisty...

Myślę, że to powinno zostać przeformułowane. Dobry deweloper nie powinien przejmować się bus factor. Jeśli jego projekt umrze, to dobrze. Dobry zespół z drugiej strony powinien mieć bardzo niski współczynnik autobusowy.

Jako dobry deweloper nie powinieneś dbać o swój współczynnik uderzeń w autobus. Ważne jest to, że Ty decydujesz, kiedy biegać przed autobusem, a nie twój pracodawca.