Jak upewnić się, że kod jest ponownie używany poprawnie?

Question

Często, gdy wprowadzamy nową funkcję do aplikacji, możemy tworzyć artefakty, takie jak przydatne metody lub klasy, które mogą być ponownie wykorzystane w innych obszarach naszych aplikacji. Te artefakty niekoniecznie są dokumentowane jako wymagania funkcjonalne, ponieważ są zwykle efektem ubocznym naszych wyborów dotyczących wdrażania. Ponieważ często rozwijamy się w zespołach, ważne jest, aby dzielić się tymi fragmentami kodu, aby zapobiec poprawkom i duplikacjom.

Przykłady:

• metody użytkowe i klasy
• klasy bazowej
• interfejs
• Kontrola GUI

Co znaleźliście się być najbardziej skutecznym sposobem udostępnianie tych artefaktów?

W jaki sposób przekazujesz założenia, które zrobiłeś podczas ich tworzenia?

Jak zapewnić, że są one spożywane poprawnie?

Jestem zainteresowany najlepszymi praktykami i sprawdzonymi technikami związanymi z dokumentacją, schematami kodów, spotkaniami (?), Aby zapewnić poprawne wykorzystanie kodu.

To pytanie jest bardzo podobne do: Finding Reusable code, ale interesuje mnie podejście bardziej proaktywne niż reaktywne.

Answer 1

Nasz zespół dysponuje wieloma pomocnymi bibliotekami, których używamy podczas całego rozwoju. Biblioteki te są przechowywane we wspólnym repozytorium w rodzaju metodologii "open-source". Jest jedna osoba, która nadzoruje każdą bibliotekę (lub wiele bibliotek), a programiści mogą przesyłać poprawki.

Biblioteki są następnie udostępniane/budowane we wspólnej lokalizacji (wdrażamy na serwerze internetowym), gdzie ludzie mogą je pobierać i wykorzystywać w dowolnym projekcie, który chcieliby. Jak dotąd działa całkiem nieźle. Jedyną rzeczą, na którą musimy zwrócić uwagę, jest to, że jeśli nastąpiła zmiana interfejsu API, musimy upewnić się, że upewnimy się, że wszyscy to rozumieją. Robimy to poprzez numery wersji i informacje z naszej biblioteki wiki.

Edycja: Dodatkowo publikujemy wygenerowane dokumenty dla naszych bibliotek (Javadoc, Crystal Report, cokolwiek), aby programiści mogli z nich korzystać.

Answer 2

Sprawdź swoje warunki wstępne za pomocą wskazówek.

Poza tym pomyśl o niektórych testach jednostkowych, aby sprawdzić, czy Twój kod jest wystarczająco solidny, aby poradzić sobie z rzadkimi lub niezamierzonymi sytuacjami.

Co do reszty, upewnij się, że wszyscy rozumieją, co robi kod, przynajmniej na poziomie czarnej skrzynki. Miej krótkie spotkanie z białą tablicą i zrób parę programowania, gdy ludzie zaczną używać nowego kodu.

Answer 3

Jesteśmy zespołem .Net, więc ten pracował dla nas ...

Stworzyliśmy własną bibliotekę klasy dla funkcji, które naszym zdaniem będą powszechnie stosowane. Rzeczy takie jak obliczanie cyfry kontrolnej Luhn Mod 3, tworzenie wyrażeń regularnych w celu sprawdzenia poprawności adresu, który będzie pasował do pola bazy danych, czyli znaków, itp. Sztuczka polega na rozpoznaniu kodu, który może zostać ponownie użyty i uzyskany to tam. I utrzymuj to w porządku.

Answer 4

Jesteśmy zespołem programistów Java i to samo dotyczy nas. Stworzyliśmy projekty użytkowe w naszym SVN pod różnymi nagłówkami, np. Analizy XML, przetwarzanie wektorowe i kod wielokrotnego użytku są sprawdzane w tych bibliotekach narzędzi i ponownie wykorzystywane w innych projektach.

Answer 5

Zapoznaj się z książką na temat sprawdzonych metod w swoim języku programowania. Zastosuj je i zobacz, co działa i odpowiednio dostosuj. Zasadniczo dobry, czysty i zwięzły interfejs/api ma długą drogę. Napisz również wiele testów jednostkowych, aby objąć różne funkcje. Zobacz również wbudowane biblioteki w swoim języku/platformie lub poszukaj dobrych przykładów bibliotek i zobacz, jak działają ich interfejsy.

Answer 6

Mówiąc z kompletnego braku doświadczenia w tej sprawie, idealną sytuacją jest prawdopodobnie stworzenie wspólnego systemu kontroli wersji między zespołami.Następnie, po kilku początkowych spotkaniach organizacyjnych/świadomościowych, potraktuj dzieloną dzielnicę jako otwarty projekt, do którego ludzie mogą się przyczynić. Więc patrząc na kilku przypadkach:

1. napisać trochę kodu do podziału: wymaga to stworzenia nowego obszaru w zajezdni do kodu, dodając niektóre podstawowe dokumentacji, testy, kod oczyścić, itp. ... ale istnieje zachęta, aby zrobić to dobrze, jeśli zostanie uznana za "publiczną".

2. Chcesz używać kodu i jego dobrej jakości: Brzmi jak dobra biblioteka, ale jest kilka ograniczeń. Dodajesz więcej dokumentacji, testów i dodatkowych funkcji, i tak dalej.

3. Chcesz użyć kodu, ale to śmieci: Musisz porozmawiać z oryginalnymi programistami. Następnie wykonaj dużą zmianę kodu, ale wciąż jest trochę lepiej niż wymyślanie koła. Oba zespoły odnoszą korzyści po zakończeniu.

Sztuczka polega na upublicznieniu wiedzy. Potrzebujesz czempionów w każdym zespole, aby zmusić ludzi do ponownego wykorzystania i wniesienia swojego wkładu. To właśnie dostajesz z początkowej rundy spotkań. Zakładając, że model open source jest sprawdzoną praktyką, nie ma powodu, aby nie działał, jeśli masz czempionów.

Answer 7

Użyj SOLID i utrzymuj swój kod w czystości. Sprawdź: http://www.lostechies.com/content/pablo_ebook.aspx

Jeśli zobaczysz coś, co najprawdopodobniej zostanie wdrożone, poproś o pomoc zespół. Zawsze pamiętaj o swojej wiedzy o poprzednich projektach, jeśli wiesz, że projekt x ma tę funkcję, zacznij od tego miejsca;)

Ponowne użycie jest ważne i pozwala uniknąć duplikowania, szczególnie gdy znajdujesz się w tym samym produkcie/może nawet w podsystemie. Ważne jest, aby zawsze go szukać, ale niech to nie przeszkadza w postępach w projektach.