Jak promować ponowne wykorzystanie kodu i dokumentacji? [Zamknięte]

Jako lider zespołu ponad 10 programistów chciałbym promować ponowne użycie kodu. Napisaliśmy dużo kodu - wiele z nich jest powtarzalnych w ciągu ostatnich kilku lat. Problem polega na tym, że wiele z tych kodów jest po prostu duplikatem jakiegoś innego kodu lub jego niewielką odmianą.

Rozpocząłem ruch (dyskusja) na temat przekształcania kodu w komponenty, aby można je było ponownie wykorzystać w przyszłych projektach, ale problem polega na tym, że obawiam się, że nowi programiści lub inni programiści, którzy nie znają komponentów, pójdą naprzód i pisać własne rzeczy.

Czy w ogóle ma przypominać programistom o ponownym użyciu komponentów / poprawie dokumentacji / wsparciu dla komponentu bazowego zamiast kopiowania istniejącego kodu i poprawiania go lub po prostu pisania własnego?

Jak sprawić, by komponenty były łatwe do odkrycia, łatwe w użyciu, aby wszyscy mogli z nich korzystać?

Myślę, że każdy programista wie o zaletach komponentów wielokrotnego użytku i chce ich używać, po prostu nie wiemy, jak je odkryć. Poza tym programiści piszący kod wiedzą, że powinni pisać kod wielokrotnego użytku, ale nie mają na to wystarczającej motywacji.

Potrzebujesz odpowiedniej dokumentacji. Powinno być łatwe do znalezienia i nawigacji. Potrzebujesz także dyscypliny. Jeśli w bibliotekach kodów znajduje się już rozwiązanie, ale programista zdecyduje się na użycie własnego rozwiązania (bez odpowiedniego powodu), powinieneś cofnąć jego rozwiązanie i powiedzieć mu, aby używał istniejącego rozwiązania.

Zgadzam się również z komentarzem Euphoric do pytania. Często niemożliwe jest ponowne użycie czegokolwiek między różnymi projektami (zwykle wszystkie operacje CRUD wyglądają tak samo, ale zwykle nie można ich ponownie użyć).

Oprócz wspomnianych już czynników, „dokumentacja”, „łatwa do znalezienia i nawigacji”, „dyscyplina” i „podgląd kodu”

kod wielokrotnego użytku musi być

• łatwy w użyciu (= potrzebujesz przykładów, np. unittests)
• bez zbyt wielu zależności od innych modułów i
• musi mieć stabilny interfejs API, więc nie muszę aktualizować aplikacji, aby korzystać z biblioteki.

bez dwóch ostatnich elementów o wiele łatwiej jest użyć „kopiowania i przeszłego dziedziczenia”, którego nie chcemy.

Myślę, że najlepszym sposobem, aby sprawić, by ponownie wykorzystali kod, jest motywacja. Jeśli wkładasz komponenty wielokrotnego użytku w dodatkowe projekty, jak sugerował Euphoric, włóż w to wiele wysiłku. Tam, gdzie pracuję, stworzyliśmy projekt, który uruchamia zestaw predefiniowanych interfejsów w konfigurowalnych planach wykonania i zapewnia kilka usług (np. Różne klasy dla DB_interaction, usługa FTP, ...). Projekt jest dużym sukcesem, ponieważ nasi programiści naprawdę chcą korzystać z mikro-frameworka, ponieważ oszczędza im to dużo czasu na pisanie kodu dla podobnych projektów. To samo dotyczy bibliotek narzędzi dla list, ciągów itp., Ale w tym przypadku chciałbyś użyć istniejącego już raz. (po co wymyślać weel?)

Wniosek: pozwól swoim programistom poznać zalety dobrze przetestowanych komponentów wielokrotnego użytku. Ale zgadzam się również z odpowiedzią Andrzeja Bobaka: Wiele rzeczy nie nadaje się do ponownego użytku, ponieważ są podobne, ale nie takie same.

Będzie to trudne, ponieważ ludzie lubią pisać nowy kod dla prostych komponentów i lubią robić to po swojemu . Znacznie trudniej jest wykorzystać istniejące rozwiązanie i rozszerzyć je, niż napisać zupełnie nową implementację z nowymi wymaganiami. Jak już powiedziano, musisz rozpocząć proces przeglądu kodu w zespole, aby pomóc zidentyfikować sytuacje, w których istniejące komponenty powinny zostać użyte / rozbudowane zamiast nowego.

Musisz także prowadzić bardzo dobrą i dokładną dokumentację, aby ludzie mogli się do niej odwoływać i łatwo znajdować to, czego potrzebują. Jeśli dokumentacja jest niekompletna lub nie jest zsynchronizowana z rzeczywistością, ludzie nie będą zmotywowani do jej przeszukiwania lub ulepszania.

Kierownik zespołu powinien również zachęcać ludzi do zadawania sobie pytań, czy istnieje podobny komponent przed utworzeniem własnego i kierować go do dokumentacji, aby mogli go sprawdzić. Upewnij się, że proces przeglądu kodu złapie go, jeśli ktoś przegapi istniejący komponent, ale co, jeśli już włożył 10 godzin rozwoju we własną realizację? Tych sytuacji należy unikać, egzekwując dobre zachowanie badawcze w zespole.

Ten problem napotkaliśmy przy dużym projekcie, nad którym obecnie pracuję. W ciągu ostatnich kilku miesięcy mieliśmy pewną rotację programistów, jest to również dość duża baza kodu, a nawet ci, którzy byli w projekcie od samego początku, nie znają go w każdym calu.

Chociaż kod jest często dobrze napisany i podzielony na małe części z pojedynczymi obowiązkami, a dokumentacja istnieje, dość łatwo jest przeoczyć coś, co zostało zrobione. Spójne konwencje nazewnictwa bardzo pomagają, ponieważ łatwo jest znaleźć coś w dowolnym środowisku IDE. Dokumentacja może być obszerna, ale ponieważ rośnie, czytanie jej jest trochę uciążliwe.

Jedną z rzeczy, które zrobiliśmy, moim zdaniem, znacznie poprawiło sytuację, było wprowadzenie czegoś, co nazywamy rozmowami Błyskawicy . Ilekroć ktoś pisze kod, który jego zdaniem powinien być znany zespołowi, organizowana jest krótka (zwykle 5-15 minut) prezentacja. Staramy się to robić raz w tygodniu. Tematy są różne, od nowych funkcji i sposobów radzenia sobie ze złożonymi problemami, które ostatnio pojawiły się, poprzez podejście do testowania / kodowania, komponentu wielokrotnego użytku, po rozmowy o podstawach aplikacji i jej refaktoryzacji.

Niektóre tematy są wspomniane w podobnych rozmowach w całej firmie. Odkryliśmy, że jest to dość skuteczny sposób na pobudzenie wymiany wiedzy. O wiele łatwiej jest zobaczyć i zapamiętać krótką prezentację i wiedzieć, gdzie szukać dodatkowej dokumentacji lub do kogo zwrócić się o pomoc, niż uczestniczyć w bardzo długich i rzadko odbywających się szkoleniach lub po prostu usiąść i czytać dokumenty od początku do końca.

Najważniejsze były rozmowy w całej firmie. Właśnie przyjęliśmy to podejście do dzielenia się wiedzą na temat konkretnych projektów i myślę, że działa całkiem dobrze.

Programowanie w parach znacznie przyspiesza przepływ wiedzy.

Myślę, że to właściwie dwa pytania w jednym - postaram się odpowiedzieć na oba.

1) Jak zmniejszyć duplikat kodu w bazie kodu?
Pomaga przypomnieć sobie o korzyściach płynących z robienia tego: powoduje mniej błędów z powodu zduplikowanej logiki biznesowej i wymaga mniejszej ilości kodu. Najlepszym sposobem na ograniczenie tego zjawiska jest komunikacja - jak wspomniano w innych odpowiedziach. Zdecydowanie zgadzam się z zaleceniem używania recenzji kodu z dodatkowym zastrzeżeniem, że powinieneś równo dzielić obowiązki związane z przeglądaniem kodu, aby właściwie rozpowszechniać wiedzę. Powinieneś także używać codziennych stand-upów, aby programiści często rozpoznawali, kiedy ktoś próbuje rozwiązać problem, dla którego istnieje przydatny kod. Należy również rozważyć parowanie kodów, ponieważ zwiększa to dzielenie się wiedzą i pomaga utrzymać dyscyplinę programistów.

Polecam również zbliżenie programistów jak najbliżej siebie, najlepiej do tego samego pokoju. Z dużą ilością wspólnych tablic i miejsca. Następnie wyślij je razem na posiłki. Im więcej twoi programiści „łączą”, tym lepiej będą się ze sobą komunikować.

Nie zgadzam się z zaleceniem używania wiki lub podobnego do kodu dokumentu. Bez względu na to, jak zdyscyplinowani programiści starają się być dokumentacją, odchodzi od oryginalnego kodu. Bardziej efektywnym podejściem byłoby zastosowanie specyfikacji przez przykładowe testy stylu. Dokumentują one kod w sposób, który wyjaśnia, jak należy go używać, a testy zakończą się niepowodzeniem, jeśli ktoś zmieni kod bez zmiany przykładów.

Masz już dużą bazę kodów z dużą ilością zduplikowanego kodu, więc prawdopodobnie powinieneś pracować nad refaktoryzacją tego. Znalezienie duplikatu kodu, który nie został wycięty i wklejony, może być trudne. Zamiast tego sugeruję przeanalizowanie historii zmian. Szukaj plików, które często się zmieniają w tym samym czasie. Prawdopodobnie będzie to oznaczać problemy z enkapsulacją, jeśli nie wskaże faktycznego duplikatu kodu i jest warte wyczyszczenia. Jeśli możesz także przeanalizować historię poprawek błędów pod kątem zmian w kodzie, możesz znaleźć konkretne punkty aktywne, w których poprawki są często konieczne. Przeanalizuj te hotspoty, a prawdopodobnie zauważysz, że wiele z nich wynika z powielonej logiki biznesowej, którą programista zmienił tylko w jednym miejscu, nie zdając sobie sprawy, że trzeba go dwukrotnie zmienić.

2) Jak powinniśmy podejść do tworzenia wspólnych widżetów, komponentów, bibliotek itp., Które mogą być następnie wykorzystane w innych projektach .
W takim przypadku nie powinieneś próbować owijać logiki biznesowej, ale udostępniać użyteczny kod frameworka. Może to być trudna równowaga, ponieważ koszt utworzenia i utrzymania zestawu wspólnych komponentów może być dość duży i trudno przewidzieć, w których przypadkach warto to zrobić. Podejście, które tutaj zasugerowałem, to zasada trzech ostrzeżeń. Nie przejmuj się pisaniem podobnego fragmentu kodu dwa razy, ale gdy musisz to zrobić po raz trzeci, przekształć go we wspólny komponent. W tym momencie możesz być całkiem pewny, że będzie on użyteczny i masz dobre pojęcie o szerszych wymaganiach dla komponentu. Oczywiście niezbędna jest tutaj komunikacja między programistami.

Zastanów się, aby jak najwięcej udostępnionego komponentu było typu open source. To nie jest logika biznesowa, więc nie da konkurentom dużej przewagi, ale oznacza, że ​​zyskasz dodatkowych recenzentów i opiekunów za darmo.

IMMO klucz to nie dokumentacja ani narzędzia, klucz to KOMUNIKACJA. Ponad 10 programistów to mało ludzi, niektóre rzeczy, które poprawiają tę komunikację:

• programowanie parami: dwie osoby wprowadzają więcej zmian niż jedna z nich wie, że problem został już rozwiązany w innej części projektu i można go ponownie wykorzystać.

• Wspólne posiadanie kodu: wszyscy ludzie pracują z różnymi częściami systemów, w ten sposób o wiele łatwiej jest wiedzieć, że coś już zostało zrobione w innej części projektu, dla mnie jest to podstawowa praktyka w zespole.

• Daj czas na pracę nad projektami poziomymi: na przykład jeden piątek lub dwa w miesiącu, a programiści mogą w tym czasie pracować nad własnymi projektami, które mają pewne zastosowanie do projektu Twojej firmy. W ten sposób programiści mogą pisać biblioteki i komponenty wielokrotnego użytku, czasem kod, który już istnieje, ale wymagają czyszczenia i dokumentacji.

• Rób rozmowy i warsztaty: Zarezerwuj czas na rozmowy programistów i warsztaty, programiści mogą porozmawiać o swoich bibliotekach, a może możesz zrobić warsztaty refaktoryzacyjne i wziąć duplikat kodu i usunąć duplikację, tworząc komponent wielokrotnego użytku.

Dokumentacja prawdopodobnie jest potrzebna, ale to tylko niewielka część prawdziwej rzeczy, której potrzebujesz: popraw komunikację w zespole.

Co z wykorzystaniem lokalnej wyszukiwarki, takiej jak Lucene (lub czegoś bardziej specyficznego dla kodu źródłowego) do indeksowania kodu? Kiedy ktoś zaczyna pisać nową klasę lub nową funkcję (na przykład), musi spróbować (zgodnie z polityką wewnętrzną) kilku wyszukiwań przed napisaniem własnego kodu. W ten sposób możesz uniknąć zbyt dużej komunikacji i możesz polegać na dobrych komentarzach, metodach i nazwach klas. Robię to z wyszukiwarkami open source dostępnymi w Internecie: nie wiem, kto napisał, co lub jak nazywa się metoda lub klasa, ale przy kilku wyszukiwaniach lub synonimach zawsze znajduję to, czego potrzebuję.

Potrzebujesz narzędzia, które pomoże programistom zrobić to bezproblemowo. Jeśli programiści odkryją, ile czasu mogą zaoszczędzić, ponownie wykorzystując fragmenty kodu (nie tylko w zakresie pisania kodu, ale oczywiście w celu zapewnienia jakości, integracji itp.), Co pomaga wydajne narzędzie, które jest łatwe w użyciu i bezpośrednio zintegrowane ze środowiskiem programistycznym, MÓDLĄ SIĘ o przyjęcie takiego narzędzia!

Uważaj, aby wiele razy realizacja bibliotek do ponownego użycia kodu nie przyniosła ogromnej przewagi (stają się zbyt potężne i duże ...); zamiast tego chciałbym skupić się na prostych fragmentach, tj. kilku wierszach kodu, które skutecznie rozwiązują dane zadanie.

W ten sposób możesz wymusić stosowanie wytycznych i najlepszych praktyk, podając prawdziwe przykłady, które mogą być bezpośrednio wykorzystane przez programistów.

Istnieje kilka narzędzi do zarządzania fragmentami, polecam to: http://www.snip2code.com .

(Oświadczenie: Jestem jednym z założycieli Snip2Code i byłem razem z moimi współzałożycielami w tym samym myśleniu jakiś czas temu: dlatego postanowiliśmy rozpocząć ten projekt, który zbiera wszystkie funkcje, które ja wspomniane powyżej, tj. udostępnianie fragmentów zespołowi, integracja z IDE, takimi jak Visual Studio, Eclipse, IntelliJ, Notepad ++ itd.)