Mam nadzieję, że nie jest to zbyt ogólne pytanie; Naprawdę przydałaby mi się wytrawna rada.

Jestem nowo zatrudniony jako jedyny „Inżynier SW” w dość małym sklepie naukowców, którzy spędzili ostatnie 10-20 lat na tworzeniu obszernej bazy kodu. (Został napisany w praktycznie przestarzałym języku: G2 - pomyśl Pascal z grafiką). Sam program jest fizycznym modelem złożonego zakładu przetwarzania chemicznego; zespół, który to napisał, ma niewiarygodnie głęboką wiedzę w dziedzinie, ale niewielki lub żaden formalny trening podstaw programowania. Niedawno nauczyli się trudnych wniosków na temat konsekwencji nieistniejącego zarządzania konfiguracją. Ich wysiłki konserwacyjne są również znacznie utrudnione przez ogromne nagromadzenie nieudokumentowanego „szlamu” w samym kodzie. Oszczędzę ci „polityki” sytuacji ( zawsze jest polityka!), ale wystarczy powiedzieć, że nie ma konsensusu co do tego, co jest potrzebne na przyszłej ścieżce.

Poprosili mnie, abym zaczął przedstawiać zespołowi niektóre zasady tworzenia nowoczesnego oprogramowania. Chcą, abym przedstawił niektóre standardowe praktyki i strategie dotyczące konwencji kodowania, zarządzania cyklem życia, wzorców projektowych na wysokim poziomie i kontroli źródła. Szczerze mówiąc, jest to dość trudne zadanie i nie jestem pewien od czego zacząć.

Początkowo jestem skłonny uczyć ich w niektórych głównych koncepcjach The Pragmatic Programmer lub Fowler's Refactoring („Code Smells” itp.). Mam również nadzieję na wprowadzenie szeregu metodologii Agile. Ale ostatecznie, aby być skutecznym, myślę, że będę musiał dopracować 5-7 podstawowych zasad; innymi słowy, jakie są najważniejsze zasady lub praktyki, które mogą realistycznie zacząć wdrażać, co zapewni im „huk za grosze”.

Więc to jest moje pytanie: Co by pan to na liście najbardziej skutecznych strategii, które pomogą wyprostować spaghetti (i zapobiec w przyszłości)?

Przedmowa

To naprawdę trudne zadanie i jest wiele do zrobienia. Dlatego pokornie sugeruję, że jest to dość obszerny przewodnik dla twojego zespołu, zawierający wskazówki dotyczące odpowiednich narzędzi i materiałów edukacyjnych.

Pamiętaj: są to wytyczne , które jako takie mają zostać przyjęte, dostosowane lub odrzucone w zależności od okoliczności.

Uwaga: zrzucenie tego wszystkiego na zespół najprawdopodobniej zakończy się niepowodzeniem. Powinieneś spróbować wybrać elementy, które dadzą ci najlepszy huk za pot i wprowadzaj je powoli, po jednym na raz.

Uwaga: nie wszystko to dotyczy bezpośrednio Visual Programming Systems, takich jak G2. Aby uzyskać bardziej szczegółowe informacje na temat radzenia sobie z nimi, zobacz sekcję Dodatek na końcu.

Streszczenie dla niecierpliwych

• Zdefiniuj sztywną strukturę projektu za pomocą:
  • szablony projektów ,
  • konwencje kodowania ,
  • znane systemy kompilacji ,
  • oraz zestawy wskazówek dotyczących użytkowania infrastruktury i narzędzi.
• Zainstaluj dobry SCM i upewnij się, że umie z niego korzystać.
• Wskaż im dobre IDE dla ich technologii i upewnij się, że wiedzą, jak ich używać.
• Wdróż kontrolery jakości kodu i automatyczne raportowanie w systemie kompilacji.
• Połącz system kompilacji z systemami ciągłej integracji i ciągłej kontroli .
• Za pomocą powyższego zidentyfikuj „punkty aktywne” jakości kodu i refaktoryzuj .

Teraz wersja długa ... Uwaga, przygotujcie się!

Sztywność jest (często) dobra

Jest to opinia kontrowersyjna, ponieważ sztywność jest często postrzegana jako siła działająca przeciwko tobie. Dotyczy to niektórych faz niektórych projektów. Ale kiedy zobaczysz go jako wsparcie strukturalne, ramy, które eliminują zgadywanie, znacznie zmniejsza ilość zmarnowanego czasu i wysiłku. Niech działa dla ciebie, a nie przeciwko tobie.

Sztywność = proces / procedura .

Opracowywanie oprogramowania wymaga dobrych procesów i procedur z dokładnie tych samych powodów, dla których zakłady chemiczne lub fabryki posiadają podręczniki, procedury, ćwiczenia i wytyczne w sytuacjach awaryjnych: zapobieganie złym wynikom, zwiększanie przewidywalności, maksymalizacja wydajności ...

Sztywność pojawia się jednak z umiarem!

Sztywność struktury projektu

Jeśli każdy projekt ma własną strukturę, ty (i nowicjusze) jesteś zagubiony i musisz odbierać od zera za każdym razem, gdy je otwierasz. Nie chcesz tego w profesjonalnym sklepie z oprogramowaniem i nie chcesz tego w laboratorium.

Sztywność systemów kompilacji

Jeśli każdy projekt wygląda inaczej, istnieje duża szansa, że ​​również zbuduje inaczej . Kompilacja nie powinna wymagać zbyt wielu badań ani zbyt wielu zgadnięć. Chcesz być w stanie zrobić coś kanonicznej i nie trzeba się martwić o specyfice: configure; make install, ant, mvn install, itd ...

Ponowne użycie tego samego systemu kompilacji i jego ewolucja z upływem czasu zapewnia również stały poziom jakości.

Musisz szybko READMEwskazać specyfikę projektu i z wdziękiem poprowadzić użytkownika / programistę / badacza, jeśli taki istnieje.

Ułatwia to również znacznie inne części infrastruktury kompilacji, a mianowicie:

• ciągła integracja ,
• ciągła kontrola .

Aktualizuj więc swoją kompilację (podobnie jak swoje projekty), ale z czasem zaostrzaj ją i wydajniej zgłaszaj naruszenia i złe praktyki.

Nie wymyślaj koła ponownie i wykorzystaj to, co już zrobiłeś.

Rekomendowane lektury:

• Ciągła integracja: poprawa jakości oprogramowania i zmniejszenie ryzyka (Duval, Matyas, Glover, 2007)
• Ciągła dostawa: Wydawnictwo Sotware wydaje poprzez automatyczną kompilację, testowanie i wdrażanie (Humble, Farley, 2010)

Sztywność w wyborze języków programowania

Nie można oczekiwać, zwłaszcza w środowisku badawczym, że wszystkie zespoły (a tym bardziej wszyscy programiści) używają tego samego języka i stosu technologii. Możesz jednak zidentyfikować zestaw „oficjalnie obsługiwanych” narzędzi i zachęcić do ich używania. Reszta bez dobrego uzasadnienia nie powinna być dozwolona (poza prototypowaniem).

Utrzymaj swój stos technologii prosty, a utrzymanie i szerokość wymaganych umiejętności do absolutnego minimum: mocny rdzeń.

Sztywność konwencji i wytycznych dotyczących kodowania

Konwencje i wytyczne kodowania pozwalają ci rozwijać zarówno tożsamość jako zespół, jak i wspólny język . Nie chcesz się mylić z terra incognita za każdym razem, gdy otwierasz plik źródłowy.

Nonsensyczne reguły, które utrudniają życie lub zabraniają jawnego działania w takim stopniu, w jakim odmowy popełnienia popełnienia przestępstwa na podstawie pojedynczych prostych naruszeń są ciężarem. Jednak:

• dobrze przemyślany zbiór zasad niweluje wiele marudzenia i myślenia: nikt nie powinien się łamać pod żadnym pozorem;

• a zestaw zalecanych zasad zapewnia dodatkowe wytyczne.

Podejście osobiste: jestem agresywny, jeśli chodzi o konwencje kodowania, niektórzy nawet mówią naziści , ponieważ wierzę w posiadanie lingua franca , rozpoznawalnego stylu dla mojego zespołu. Kiedy kod bzdury zostaje zameldowany, wyróżnia się jak zimna rana na twarzy gwiazdy Hollywood: automatycznie uruchamia recenzję i akcję. W rzeczywistości czasami posunąłem się nawet do tego, aby zalecać użycie haków wstępnego zatwierdzania w celu odrzucenia niezgodnych zmian. Jak wspomniano, nie powinno to być zbyt szalone i przeszkadzać w produktywności: powinno je napędzać. Wprowadzaj je powoli, szczególnie na początku. Ale jest to o wiele lepsze rozwiązanie niż poświęcanie tyle czasu na naprawianie wadliwego kodu, że nie można pracować nad prawdziwymi problemami.

Niektóre języki wymuszają to już z założenia:

• Java miała zmniejszyć ilość nudnych bzdur, które można z nim pisać (choć bez wątpienia wielu to robi).

• Struktura bloków Pythona według wcięć to kolejny pomysł w tym sensie.

• Idź z jego gofmtnarzędziem, które całkowicie zabiera wszelką debatę i wysiłek ( i ego !! ) nieodłącznie związane ze stylem: biegnij gofmtprzed popełnieniem.

Upewnij się, że zgnilizna kodu nie może się przedostać. Konwencje kodu , ciągła integracja i ciągła kontrola , programowanie par i przeglądy kodu to Twój arsenał przeciwko temu demonowi.

Ponadto, jak zobaczycie poniżej, kod jest dokumentacją , a to kolejny obszar, w którym konwencje zachęcają do czytelności i przejrzystości.

Sztywność dokumentacji

Dokumentacja idzie w parze z kodem. Sam kod jest dokumentacją. Ale muszą istnieć jasne instrukcje, jak budować, używać i utrzymywać rzeczy.

Korzystanie z jednego punktu kontroli w dokumentacji (jak WikiWiki lub DMS) to dobra rzecz. Twórz przestrzenie dla projektów, przestrzenie dla bardziej przypadkowych pogawędek i eksperymentów. Niech wszystkie przestrzenie ponownie wykorzystają wspólne zasady i konwencje. Staraj się, aby było to częścią ducha zespołu.

Większość porad dotyczących kodu i narzędzi dotyczy również dokumentacji.

Sztywność w komentarzach do kodu

Komentarze do kodu, jak wspomniano powyżej, są również dokumentacją. Programiści lubią wyrażać swoje uczucia na temat swojego kodu (głównie dumy i frustracji, jeśli mnie pytasz). Nie jest więc niczym niezwykłym, że wyrażają je w nieokreślony sposób w komentarzach (a nawet w kodzie), gdy bardziej formalny fragment tekstu mógł mieć to samo znaczenie przy mniej obraźliwych tekstach lub dramacie. Można pozwolić kilku prześlizgnąć się ze względów historycznych i zabawy: jest to również część rozwoju kultury zespołowej . Ale bardzo ważne jest, aby wszyscy wiedzieli, co jest dopuszczalne, a co nie, a ten komentarz jest po prostu: hałasem .

Sztywność w dziennikach zatwierdzania

Dzienniki zatwierdzania nie są irytującym i bezużytecznym „krokiem” cyklu życia SCM: NIE omijaj go, aby wrócić do domu na czas lub zająć się kolejnym zadaniem lub dogonić kumpli, którzy wyszli na lunch. Mają znaczenie i, podobnie jak (większość) dobrego wina, im więcej czasu mija, tym bardziej stają się cenne. Więc ZRÓB je dobrze. Jestem oszołomiony, gdy widzę współpracowników piszących jedno linijki dla gigantycznych zmian lub nieoczywistych hacków.

Zatwierdzenia są wykonywane z jakiegoś powodu, a ten powód NIE zawsze jest jasno wyrażony przez twój kod i wprowadzony przez ciebie jeden wiersz dziennika zmian. Jest w tym coś więcej.

Każda linia kodu ma historię i historię . Różnice mogą opowiadać swoją historię, ale musisz napisać jej historię.

Dlaczego zaktualizowałem ten wiersz? -> Ponieważ interfejs się zmienił.

Dlaczego interfejs się zmienił? -> Ponieważ biblioteka L1, która ją definiuje, została zaktualizowana.

Dlaczego biblioteka została zaktualizowana? -> Ponieważ biblioteka L2, której potrzebujemy dla funkcji F, zależała od biblioteki L1.

A co to jest funkcja X? -> Zobacz zadanie 3456 w narzędziu do śledzenia problemów.

To nie jest mój wybór SCM i może nie być najlepszy dla twojego laboratorium; ale Gitrobi to dobrze i próbuje zmusić cię do pisania dobrych dzienników więcej niż w większości innych systemów SCM, używając short logsi long logs. Połącz identyfikator zadania (tak, potrzebujesz go) i zostaw ogólne podsumowanie dla shortlogi rozwiń długi dziennik: napisz historię zestawu zmian .

To dziennik: służy do śledzenia i rejestrowania aktualizacji.

Ogólna zasada: jeśli później szukałeś czegoś na temat tej zmiany, czy Twój dziennik prawdopodobnie odpowie na twoje pytanie?

Projekty, dokumentacja i kod są ŻYWE

Trzymajcie je w synchronizacji, w przeciwnym razie nie tworzą już tej symbiotycznej istoty. Działa cuda, gdy masz:

• wyczyść dzienniki zatwierdzeń w SCM, w / linki do identyfikatorów zadań w narzędziu do śledzenia problemów,
• gdzie same bilety tego modułu śledzącego prowadzą do zestawów zmian w SCM (i ewentualnie do kompilacji w systemie CI),
• oraz system dokumentacji, który prowadzi do wszystkich z nich.

Kod i dokumentacja muszą być spójne .

Sztywność w testowaniu

Reguły kciuka:

• Każdy nowy kod powinien zawierać (przynajmniej) testy jednostkowe.
• Każdy refaktoryzowany starszy kod powinien być dostarczony z testami jednostkowymi.

Oczywiście potrzebują one:

• przetestować coś wartościowego (lub są stratą czasu i energii),
• być dobrze napisane i skomentowane (tak jak każdy inny kod, który się zameldujesz).

Są również dokumentacją i pomagają nakreślić kontrakt twojego kodu. Zwłaszcza jeśli korzystasz z TDD . Nawet jeśli nie, potrzebujesz ich dla spokoju ducha. Stanowią one twoją siatkę bezpieczeństwa, gdy wprowadzasz nowy kod (konserwacja lub funkcja) i swoją strażnicę, aby chronić przed gniciem kodu i awariami środowiska.

Oczywiście powinieneś pójść dalej i przeprowadzić testy integracyjne oraz testy regresji dla każdego powtarzalnego błędu, który naprawisz.

Sztywność w użyciu narzędzi

Czasami deweloper / naukowiec może wypróbować jakiś nowy moduł sprawdzania statycznego na źródle, wygenerować wykres lub model przy użyciu innego lub zaimplementować nowy moduł przy użyciu DSL. Ale najlepiej, jeśli istnieje kanoniczny zestaw narzędzi, który wszyscy członkowie zespołu powinni znać i używać.

Poza tym pozwól członkom korzystać z tego, czego chcą, o ile są WSZYSCY:

• produktywny ,
• NIE regularnie wymaga pomocy
• NIE regularnie dostosowując się do ogólnej infrastruktury ,
• NIE zaburzając infrastruktury (modyfikując wspólne obszary, takie jak kod, system kompilacji, dokumentacja ...),
• NIE wpływając na pracę innych ,
• MOGŁO terminowo wykonać każde zlecone zadanie .

Jeśli tak nie jest, wymuś przywrócenie wartości domyślnych.

Sztywność a wszechstronność, adaptowalność, prototypowanie i sytuacje awaryjne

Elastyczność może być dobra. Pozwolenie komuś od czasu do czasu użyć hacka, szybkiego i brudnego podejścia lub ulubionego narzędzia dla zwierząt domowych do wykonania zadania jest w porządku. NIGDY nie pozwól, aby stał się nawykiem i NIGDY nie pozwól, aby ten kod stał się rzeczywistą bazą kodów do obsługi.

Duch zespołu ma znaczenie

Rozwijaj poczucie dumy w swojej bazie kodu

• Rozwijaj poczucie dumy w kodzie
  • Użyj tablic ściennych
    • tablica liderów ciągłej gry integracyjnej
    • tablice ścienne do zarządzania problemami i liczenia wad
  • Użyj narzędzia do śledzenia problemów / śledzenia błędów

Unikaj obwiniania gier

• NALEŻY korzystać z gier Continuous Integration / Continuous Inspection: sprzyja dobrodusznej i produktywnej konkurencji .
• NALEŻY śledzić wady: to po prostu dobre utrzymanie domu.
• DO identyfikacji przyczyny : to tylko procesy przyszłość pulchne.
• ALE NIE przypisuj winy : to przynosi efekt przeciwny do zamierzonego.

Chodzi o kod, a nie o programistów

Poinformuj programistów o jakości swojego kodu, ALE spraw, aby widzieli kod jako odłączony byt, a nie rozszerzenie siebie, czego nie można krytykować.

To paradoks: musisz zachęcać do programowania bez ego dla zdrowego miejsca pracy, ale polegać na ego w celach motywacyjnych.

Od naukowca do programisty

Ludzie, którzy nie cenią i są dumni z kodu, nie tworzą dobrego kodu. Aby ta właściwość się pojawiła, muszą odkryć, jak cenna i zabawna może być. Sam profesjonalizm i chęć czynienia dobra nie wystarczą: potrzebuje pasji. Musisz więc zmienić naukowców w programistów (w szerokim tego słowa znaczeniu).

Ktoś argumentował w komentarzach, że po 10 do 20 latach projektu i jego kodu każdy poczuje przywiązanie. Może się mylę, ale zakładam, że są dumni z rezultatów kodu oraz pracy i jego dziedzictwa, a nie samego kodu lub samego jego pisania.

Z doświadczenia wynika, że ​​większość badaczy uważa kodowanie za konieczność, aw najlepszym razie za rozrywkową rozrywkę. Chcą tylko, żeby to działało. Ci, którzy są już dość obeznani z tym i którzy są zainteresowani programowaniem, łatwiej przekonać do przyjęcia najlepszych praktyk i zmiany technologii. Musisz je zdobyć w połowie drogi.

Utrzymanie kodu jest częścią pracy badawczej

Nikt nie czyta kiepskich prac badawczych. Dlatego są recenzowane, sprawdzane, dopracowywane, przepisywane i zatwierdzane od czasu do czasu, aż zostaną uznane za gotowe do publikacji. To samo dotyczy pracy magisterskiej i bazy kodu!

Wyjaśnij, że ciągłe refaktoryzowanie i odświeżanie bazy kodu zapobiega gniciu kodu i zmniejsza techniczne zadłużenie oraz ułatwia przyszłe ponowne wykorzystanie i dostosowanie pracy do innych projektów.

Po co to wszystko??!

Dlaczego zawracamy sobie głowę powyższym? Dla jakości kodu . Czy jest to kod jakości ...?

Te wytyczne mają na celu doprowadzić zespół do osiągnięcia tego celu. Niektóre aspekty robią to po prostu wskazując im drogę i pozwalając im to zrobić (co jest znacznie lepsze), a inne biorą ich za rękę (ale w ten sposób kształcisz ludzi i rozwijasz nawyki).

Skąd wiesz, kiedy cel jest w zasięgu?

Jakość jest mierzalna

Nie zawsze ilościowo, ale można to zmierzyć . Jak wspomniano, musisz rozwinąć w zespole poczucie dumy, a pokazanie postępów i dobrych wyników jest kluczowe. Regularnie mierz jakość kodu i wyświetlaj postępy między interwałami oraz ich znaczenie. Wykonaj retrospekcję, aby zastanowić się nad tym, co zostało zrobione i jak to poprawiło lub pogorszyło sytuację.

Istnieją świetne narzędzia do ciągłej kontroli . Sonar jest popularny w świecie Java, ale można go dostosować do dowolnej technologii; i jest wiele innych. Trzymaj kod pod mikroskopem i poszukaj tych irytujących irytujących błędów i drobnoustrojów.

Ale co, jeśli mój kod jest już gównem?

Wszystkie powyższe są zabawne i słodkie jak wycieczka do Never Land, ale nie jest to takie łatwe, gdy masz już (kupę parnego i śmierdzącego) bzdurnego kodu i zespół niechętnie się zmienia.

Oto sekret: musisz gdzieś zacząć .

Osobista anegdota: W projekcie pracowaliśmy z bazą kodu ważącą pierwotnie 650 000+ Java LOC, 200 000+ linii JSP, 40 000+ LOC JavaScript i ponad 400 MB zależności binarnych.

Po około 18 miesiącach jest to 500 000 Java LOC (MOSTLY CLEAN) , 150 000 linii JSP i 38 000 JavaScript LOC, z zależnościami do zaledwie 100 MB (i nie ma ich już w SCM!).

Jak to zrobiliśmy? Właśnie zrobiliśmy wszystkie powyższe. Lub bardzo się starał.

To wysiłek zespołu, ale powoli wprowadzamy nasze regulacje procesowe i narzędzia do monitorowania tętna naszego produktu, jednocześnie pośpiesznie usuwając „gruby”: bzdury, bezużyteczne zależności ... Nie zatrzymaliśmy całego rozwoju, aby róbcie to: od czasu do czasu mamy względny spokój i ciszę, w którym możemy zwariować na bazie kodu i rozerwać go na strzępy, ale przeważnie robimy to wszystko, domyślając się trybu „przeglądu i refaktoryzacji” przy każdej możliwej okazji : podczas kompilacji, podczas lunchu, podczas sprintu naprawiania błędów, w piątkowe popołudnia ...

Było kilka dużych „prac” ... Jednym z nich było przełączenie naszego systemu kompilacji z gigantycznej kompilacji Anta z ponad 8500 XML LOC na wielomodułową kompilację Maven. Następnie mieliśmy:

• przejrzyste moduły (a przynajmniej było już znacznie lepiej, a my wciąż mamy duże plany na przyszłość),
• automatyczne zarządzanie zależnościami (dla łatwej konserwacji i aktualizacji oraz w celu usunięcia bezużytecznych zasobów),
• szybsze, łatwiejsze i odtwarzalne kompilacje,
• codzienne raporty dotyczące jakości.

Innym był zastrzyk „Utility pasów narzędziowych”, chociaż staraliśmy się zmniejszyć zależności: Google Guava i Apache Commons odchudzić swój kod i oraz zmniejszyć powierzchnię za błędy w swoim kodzie dużo.

Przekonaliśmy również nasz dział IT, że być może korzystanie z naszych nowych narzędzi (JIRA, Rybie Oko, Tygiel, Zbieżność, Jenkins) było lepsze niż istniejące. Nadal musieliśmy poradzić sobie z niektórymi, którymi gardziliśmy (QC, Sharepoint i SupportWorks ...), ale było to ogólnie ulepszone doświadczenie, pozostawiając nieco więcej miejsca.

I każdego dnia istnieje od jednego do kilkudziesięciu zobowiązań, które dotyczą tylko naprawy i refaktoryzacji. Od czasu do czasu psujemy rzeczy (potrzebujesz testów jednostkowych i lepiej je wypisz, zanim dokonasz refaktoryzacji), ale ogólnie rzecz biorąc korzyść dla naszego morale ORAZ dla produktu była ogromna. Dostajemy tam jeden ułamek procentowej jakości kodu na raz. I fajnie jest widzieć, jak rośnie !!!

Uwaga: Znowu należy potrząsnąć sztywnością, aby zrobić miejsce na nowe i lepsze rzeczy. Według mojej anegdoty nasz dział IT częściowo ma rację, próbując narzucić nam pewne rzeczy, a inni źle. A może kiedyś mieli rację . Rzeczy się zmieniają. Udowodnij, że są lepszymi sposobami na zwiększenie produktywności. W tym celu są dostępne wersje próbne i prototypy .

Super-Secret Incremental Cykl refaktoryzacji kodu spaghetti dla niesamowitej jakości

       +-----------------+      +-----------------+
       |  A N A L Y Z E  +----->| I D E N T I F Y |
       +-----------------+      +---------+-------+
                ^                           |
                |                           v
       +--------+--------+      +-----------------+
       |    C L E A N    +<-----|      F I X      |
       +-----------------+      +-----------------+

Gdy masz już kilka narzędzi wysokiej jakości w swoim pasku narzędzi:

1. Przeanalizuj swój kod za pomocą sprawdzania jakości kodu.

   Linters, analizatory statyczne lub co masz.

2. Zidentyfikuj swoje krytyczne punkty dostępu ORAZ nisko wiszące owoce .

   Naruszenia mają poziomy dotkliwości, a duże klasy z dużą liczbą poważnych są dużą czerwoną flagą: jako takie pojawiają się jako „gorące punkty” w widokach typu grzejnik / mapa cieplna.

3. Najpierw napraw hotspoty.

   Maksymalizuje Twój wpływ w krótkim czasie, ponieważ mają najwyższą wartość biznesową. Idealnie, krytyczne naruszenia powinny być rozwiązywane, gdy tylko się pojawią, ponieważ stanowią potencjalne luki w zabezpieczeniach lub powodują awarie i stanowią wysokie ryzyko wywołania odpowiedzialności (aw twoim przypadku złej wydajności dla laboratorium).

4. Wyczyść naruszenia niskiego poziomu za pomocą automatycznych przeglądów baz kodów .

   Poprawia stosunek sygnału do szumu, dzięki czemu można zobaczyć znaczące naruszenia radaru, gdy się pojawiają. Często na początku jest duża armia drobnych naruszeń, jeśli nigdy się nimi nie zajęto, a twoja baza kodów została pozostawiona na wolności. Nie stanowią prawdziwego „ryzyka”, ale pogarszają czytelność i łatwość konserwacji kodu. Napraw je albo, gdy je spotkasz podczas pracy nad zadaniem, lub przez duże zadania porządkowe z automatycznymi przeglądami kodów, jeśli to możliwe. Zachowaj ostrożność przy dużych automatycznych przeglądach, jeśli nie masz dobrego zestawu testów i systemu integracji. Pamiętaj, aby uzgodnić ze współpracownikami odpowiedni czas na ich uruchomienie, aby zminimalizować irytację.

5. Powtarzaj, aż będziesz zadowolony.

   Które, najlepiej, nigdy nie powinieneś być, jeśli jest to nadal aktywny produkt: będzie się rozwijał.

Szybkie porady dotyczące dobrego utrzymania domu

• W trybie poprawek na podstawie żądania obsługi klienta:

  • Zazwyczaj najlepszą praktyką jest NIE zajmowanie się naprawianiem innych problemów, ponieważ możesz niechętnie wprowadzać nowe.
  • Przejdź do stylu SEAL: wejdź, zabij robaka, wyjdź i wyślij łatkę. To uderzenie chirurgiczne i taktyczne.

• Ale we wszystkich innych przypadkach , jeśli otworzysz plik, ustaw obowiązek:

  • zdecydowanie: przejrzyj go (rób notatki, zgłaszaj problemy z plikami),
  • może: wyczyść to ( porządki w stylu i drobne naruszenia),
  • najlepiej: przebuduj go (zreorganizuj duże sekcje i ich sąsiadów).

Po prostu nie daj się zwieść spędzeniu tygodnia od pliku do pliku i skończyć z ogromnym zestawem tysięcy poprawek obejmujących wiele funkcji i modułów - utrudnia to śledzenie w przyszłości. Jeden problem w kodzie = jeden bilet w twoim trackerze. Czasami zestaw zmian może wpływać na wiele biletów; ale jeśli zdarza się to zbyt często, prawdopodobnie robisz coś złego.

Dodatek: Zarządzanie wizualnymi środowiskami programowania

The Walled Gardens of Bespoke Programming Systems

Wiele systemów programowania, takich jak G2 OP, to różne bestie ...

• Brak kodu źródłowego

  Często nie dają ci dostępu do tekstowej reprezentacji twojego „kodu” źródłowego: może być przechowywany w zastrzeżonym formacie binarnym, a może przechowuje rzeczy w formacie tekstowym, ale ukrywa je przed tobą. Indywidualne systemy programowania graficznego nie są tak naprawdę rzadkością w laboratoriach badawczych, ponieważ upraszczają automatyzację procesów powtarzalnego przetwarzania danych.

• Bez narzędzi

  To znaczy poza ich własnymi. Często ogranicza Cię środowisko programistyczne, własny debugger, własny tłumacz, własne narzędzia i formaty dokumentacji. Są to ogrodzone murem ogrody , chyba że w końcu zainteresują kogoś wystarczająco zmotywowanego do inżynierii wstecznej swoich formatów i budowy zewnętrznych narzędzi - jeśli pozwala na to licencja.

• Brak dokumentacji

  Dość często są to niszowe systemy programowania, które są używane w dość zamkniętych środowiskach. Ludzie, którzy ich używają, często podpisują NDA i nigdy nie mówią o tym, co robią. Społeczności programowania dla nich są rzadkie. Zasoby są więc ograniczone. Utknąłeś z oficjalną referencją i to wszystko.

Ironicznym (i często frustrującym) elementem jest to, że wszystkie rzeczy, które te systemy robią, można oczywiście osiągnąć za pomocą głównego nurtu i języków programowania ogólnego przeznaczenia, i całkiem prawdopodobnie bardziej wydajnie. Wymaga to jednak głębszej wiedzy na temat programowania, podczas gdy nie można oczekiwać, że biolog, chemik lub fizyk (by wymienić tylko kilku) będzie wiedział wystarczająco dużo o programowaniu, a tym bardziej mieć czas (i chęć) na wdrożenie (i utrzymanie) złożone systemy, które mogą, ale nie muszą, być długotrwałe. Z tego samego powodu, dla którego korzystamy z DSL, mamy te systemy programowania na zamówienie.

Osobista anegdota 2:Właściwie sam nad jednym z nich pracowałem. Nie wykonałem połączenia z prośbą PO, ale mój projekt był zestawem połączonych ze sobą dużych elementów oprogramowania do przetwarzania i przechowywania danych (przede wszystkim do badań bioinformatycznych, opieki zdrowotnej i kosmetyków, ale także dla biznesu dane wywiadowcze lub dowolna dziedzina implikująca śledzenie dużych ilości wszelkiego rodzaju danych badawczych oraz przygotowywanie przepływów pracy przetwarzania danych i ETL). Jedną z tych aplikacji było, po prostu, wizualne IDE, które używało zwykłych dzwonków i gwizdków: interfejsy przeciągnij i upuść, wersjonowane obszary robocze projektu (używając plików tekstowych i XML do przechowywania metadanych), wiele podłączanych sterowników do heterogenicznych źródeł danych oraz wizualne płótno do projektowania rurociągów do przetwarzania danych z N źródeł danych, a na koniec generowania M przekształconych wyników, oraz możliwe błyszczące wizualizacje i złożone (i interaktywne) raporty online. Twój typowy system programowania na zamówienie, cierpiący na syndrom NIH pod pretekstem zaprojektowania systemu dostosowanego do potrzeb użytkowników.

I, jak można się spodziewać, jest to ładny system, dość elastyczny dla swoich potrzeb, choć czasem nieco przesadzony, więc zastanawiasz się „dlaczego zamiast tego nie używać narzędzi wiersza poleceń?” I niestety zawsze prowadzi w średniej wielkości zespoły pracujące nad dużymi projektami dla wielu różnych osób korzystających z różnych „najlepszych” praktyk.

Świetnie, jesteśmy zgubieni! - Co robimy z tym?

Cóż, w końcu wszystko powyższe nadal obowiązuje. Jeśli nie możesz wyodrębnić większości programów z tego systemu, aby korzystać z większej liczby narzędzi i języków głównego nurtu, musisz „po prostu” dostosować je do ograniczeń systemu.

Informacje o wersjonowaniu i przechowywaniu

W końcu możesz prawie zawsze zmieniać wersje , nawet w najbardziej ograniczonym i otoczonym otoczeniem środowisku. Najczęściej systemy te nadal mają własną wersję (która niestety często jest dość podstawowa i po prostu oferuje powrót do poprzednich wersji bez widoczności, zachowując poprzednie migawki). Nie używa dokładnie różnicowych zestawów zmian, jak Twój SCM, i prawdopodobnie nie nadaje się dla wielu użytkowników przesyłających zmiany jednocześnie.

Ale mimo to, jeśli zapewniają taką funkcjonalność, być może Twoim rozwiązaniem jest postępowanie zgodnie z naszymi ulubionymi standardami branżowymi powyżej i przeniesienie ich do tego systemu programowania !!

Jeśli system pamięci masowej jest bazą danych, prawdopodobnie udostępnia funkcje eksportu lub może zostać utworzony kopię zapasową na poziomie systemu plików. Jeśli używa niestandardowego formatu binarnego, być może możesz po prostu spróbować go zaktualizować za pomocą VCS, który ma dobrą obsługę danych binarnych. Nie będziesz miał drobiazgowej kontroli, ale przynajmniej będziesz miał ochronę pleców przed katastrofami i będziesz mieć pewien stopień zgodności z odzyskiwaniem po katastrofie.

O testowaniu

Zaimplementuj testy na samej platformie i użyj zewnętrznych narzędzi i zadań w tle, aby skonfigurować regularne kopie zapasowe. Prawdopodobnie uruchamiasz te testy tak samo, jak uruchamiałbyś programy opracowane z tym systemem programowania.

Jasne, to jest włamanie i zdecydowanie nie odpowiada standardowi, który jest wspólny dla „normalnego” programowania, ale pomysł polega na dostosowaniu się do systemu przy jednoczesnym zachowaniu pozorów profesjonalnego procesu tworzenia oprogramowania.

Droga jest długa i stroma ...

Jak zawsze w niszowych środowiskach i na zamówienie systemach programistycznych, i jak ujawniliśmy powyżej, masz do czynienia z dziwnymi formatami, tylko ograniczonym (lub całkowicie nieistniejącym) zestawem potencjalnie niezręcznych narzędzi i pustką w miejscu społeczności.

Zalecenie: Spróbuj wdrożyć powyższe wytyczne w jak największym stopniu poza własnym systemem programowania. Gwarantuje to, że możesz polegać na „wspólnych” narzędziach, które mają odpowiednie wsparcie i motywację społeczności.

Obejście: Jeśli nie jest to opcja, spróbuj ponownie zainstalować tę globalną strukturę w swoim „pudełku”. Pomysł polega na nałożeniu tego schematu najlepszych praktyk branżowych na system programowania i jak najlepszym wykorzystaniu. Nadal obowiązuje rada: zdefiniuj strukturę i najlepsze praktyki, zachęcaj do zgodności.

Niestety oznacza to, że może być konieczne zanurkowanie i wykonanie ogromnej pracy nóg. Więc...

Słynne ostatnie słowa i pokorne prośby:

• Dokumentuj wszystko, co robisz.
• Podziel się swoim doświadczeniem.
• Open Source dowolne narzędzie do pisania.

Robiąc to wszystko, będziesz:

• nie tylko zwiększa twoje szanse na uzyskanie wsparcia od osób w podobnych sytuacjach,
• ale także pomagać innym ludziom i zachęcać do dyskusji na temat stosu technologii.

Kto wie, można być na samym początku nowej aktywnej społeczności Obscure Język X . Jeśli nie ma, uruchom jeden!

• Zadawaj pytania dotyczące przepełnienia stosu ,
• Może nawet napisz propozycję nowej witryny StackExchange w obszarze 51 .

Może w środku jest pięknie , ale do tej pory nikt nie ma pojęcia , więc pomóżcie zburzyć tę brzydką ścianę i pozwólcie innym spojrzeć!

Bardzo pierwszym krokiem byłoby wprowadzenie systemu kontroli wersji (SVN, Git, Mercurial, TFS, etc.). Trzeba to mieć w przypadku projektu, który będzie miał faktoring.

Edycja: dotyczy VSC - Każdy pakiet kontroli źródła może zarządzać plikami binarnymi, choć z pewnymi ograniczeniami. Większość narzędzi na rynku ma możliwość korzystania z niestandardowej przeglądarki i edytora różnic, skorzystaj z tej możliwości. Binarne pliki źródłowe nie są wymówką, aby nie używać kontroli wersji.

Jest podobny post na temat postępowania ze starszym kodem , może być dobrym odniesieniem do naśladowania - Porady na temat pracy ze starszym kodem

Kiedy muszę pracować z kodem spaghetti, pierwszą rzeczą, nad którą pracuję, jest modularyzacja . Znajdź miejsca, w których możesz narysować linie i wyodrębnić (mniej więcej) niezależne fragmenty bazy kodu. Prawdopodobnie nie będą bardzo małe, ze względu na wysoki stopień wzajemnych połączeń i sprzęgania, ale niektóre linie modułów pojawią się, jeśli ich szukasz.

Kiedy już będziesz mieć moduły, nie będziesz musiał stawić czoła zniechęcającemu zadaniu czyszczenia całego niechlujnego programu. Teraz zamiast tego masz kilka mniejszych, niezależnych, niechlujnych modułów do wyczyszczenia. Teraz wybierz moduł i powtórz na mniejszą skalę. Znajdź miejsca, w których możesz wyodrębnić duże funkcje na mniejsze funkcje lub nawet klasy (jeśli G2 je obsługuje).

To wszystko jest o wiele łatwiejsze, jeśli język ma wystarczająco silny system pisania, ponieważ można zmusić kompilator do wykonania dużego ciężaru. Dokonujesz zmiany gdzieś, która (celowo) zepsuje kompatybilność, a następnie próbujesz skompilować. Błędy kompilacji doprowadzą Cię bezpośrednio do miejsc, które należy zmienić, a kiedy przestaniesz je otrzymywać, znajdziesz wszystko. Następnie uruchom program i przetestuj wszystko! Ciągłe testowanie jest niezwykle ważne przy refaktoryzacji.

Nie wiem, czy jest to dla ciebie opcja, ale zacznę próbować przekonać ich do zatrudnienia większej liczby profesjonalnych programistów . W ten sposób mogą skoncentrować się na problemach z domeną (jestem pewien, że mają tam dość).

Wierzę, że są to bardzo mądrzy ludzie, ale bycie dobrym programistą wymaga dużo czasu. Czy są gotowi poświęcić tyle czasu na działalność, która nie jest ich głównym przedmiotem działalności? IMHO, to nie jest sposób na osiągnięcie najlepszych rezultatów.

Łał. Wygląda na to, że czeka Cię naprawdę duże wyzwanie! Zrobiłbym coś według następujących zasad:

• Przede wszystkim: ustal priorytet . Co chcesz najpierw osiągnąć? Co jest najważniejsze dla aktualnego stanu projektu? Co zyskasz najwięcej w porównaniu z tym, ile czasu zajmie Ci dotarcie.
• Upewnij się, że masz system kontroli wersji . Na przykład Git lub Mercurial .
• Uruchom system ciągłej integracji (np. Jenkins ).
• Otrzymuj śledzenia błędów systemu i działa. Modliszka jest moim zdaniem całkiem miła.
• Spójrz na analizę kodu statycznego (jeśli coś jest dostępne dla języka, z którym obecnie pracujesz).
• Staraj się osiągnąć jak największą spójność we wszystkim, od nazewnictwa zmiennych po ogólne konwencje i wytyczne w bazie kodu.
• Przetestuj system . Moim zdaniem jest to niezwykle ważne w przypadku dużego systemu takiego jak ten. Użyj przypadków testowych, aby udokumentować istniejące zachowanie , bez względu na to, czy zachowanie wydaje się dziwne, czy nie (zwykle istnieje powód, dla którego kod wygląda pewnie, dlaczego, może być dobry lub zły, lub oba; P). Michael Feathers skutecznie współpracujący ze starszym kodem jest do tego doskonałym źródłem.

Mówią, że pierwszym krokiem w rozwiązaniu problemu jest przyznanie, że go masz. Mając to na uwadze, możesz zacząć od wygenerowania wykresu zależności, który ilustruje rozległą plątaninę, która jest twoją bieżącą bazą kodu. Dobre narzędzie do generowania diagramu zależności? ma kilka lat, ale zawiera pewne wskazówki do narzędzi, które mogą pomóc w tworzeniu takich wykresów. Wybrałbym jeden wielki, brzydki wykres, który pokazuje jak najwięcej, aby doprowadzić punkt do domu. Porozmawiaj o problemach, które wynikają ze zbyt wielu współzależności i być może rzucisz linię od Buckaroo Banzai :

Możesz sprawdzić swoją anatomię, jak chcesz, i chociaż może istnieć normalna zmienność, jeśli chodzi o to, to tak głęboko w głowie wszystko wygląda tak samo. Nie, nie, nie, nie ciągnij tego. Nigdy nie wiadomo z czym może być związane.

Stamtąd przedstaw plan rozpoczęcia prostowania bałaganu. Podziel kod na moduły, które są możliwie najbardziej samodzielne. Bądź otwarty na sugestie, jak to zrobić - ludzie, z którymi rozmawiasz, lepiej znają historię i funkcjonalność kodu. Jednak celem jest wzięcie jednego dużego problemu i przekształcenie go w pewną liczbę mniejszych problemów, które można następnie ustalić jako priorytet i rozpocząć sprzątanie.

Niektóre rzeczy, na których należy się skupić:

• Utwórz czyste interfejsy między modułami i zacznij z nich korzystać. Stary kod może z konieczności nadal nie używać tych nowych, przyjemnych interfejsów - to jest problem, który zaczynasz rozwiązywać. Ale poproś wszystkich, aby zgodzili się korzystać tylko z nowych interfejsów. Jeśli czegoś potrzebują, czego nie ma w interfejsach, napraw interfejsy, nie omijaj ich.

• Poszukaj przypadków, w których powtórzono tę samą funkcjonalność. Pracuj w kierunku unifikacji.

• Od czasu do czasu przypominaj wszystkim, że zmiany te mają ułatwić życie, a nie utrudnić. Przejście może być bolesne, ale ma to dobry cel, a im więcej wszyscy są na pokładzie, tym szybciej przyniosą korzyści.

Po dłuższym spojrzeniu na Gensym G2 wygląda na to, że sposób rozwiązania tego problemu będzie wysoce zależny od tego, jak duża część kodu wygląda następująco:

albo to:

w porównaniu z tym, dzięki uprzejmości 99 butelek piwa :

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall"; 
        end 
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then 
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall"; 
           end
    end
end

W przypadku tego ostatniego pracujesz z kodem źródłowym, który jest faktycznie znaną ilością, a niektóre inne odpowiedzi oferują bardzo mądre rady, jak sobie z tym poradzić.

Jeśli większość kodu bazowego to ta ostatnia, lub nawet jeśli jest to znaczna część, napotkasz interesujący problem z kodem, którego prawdopodobnie nie da się zrefaktoryzować z powodu jego bardzo specjalizacji lub, co gorsza, czegoś, co wygląda jak może być usuwalny, ale jeśli nie zostanie odpowiednio udokumentowany, nie wiesz, czy usuwasz krytyczny kod (pomyśl coś w rodzaju operacji scram ), który na pierwszy rzut oka nie wydaje się taki.

Chociaż, oczywiście, twoim pierwszym priorytetem będzie uzyskanie kontroli wersji online, jak zauważył ElYusubov , i wydaje się, że kontrola wersji jest obsługiwana od wersji 8.3 . Ponieważ G2 jest kombinacją kilku różnych metodologii językowych, prawdopodobnie najbardziej efektywne byłoby użycie dostarczonej z nim kontroli wersji, zamiast próbować znaleźć coś innego i sprawić, by działała.

Następnie, chociaż niektórzy prawdopodobnie opowiadaliby się za refaktoryzacją, jestem zdecydowanym zwolennikiem upewnienia się, że w pełni rozumiesz system, z którym pracujesz, zanim zaczniesz dotykać dowolnego kodu, szczególnie w przypadku kodu i diagramów wizualnych opracowanych przez programiści bez formalnego szkolenia (lub doświadczenia) w zakresie metodologii inżynierii oprogramowania. Powód tego jest kilkakrotnie, ale najbardziej oczywistym powodem jest to, że pracujesz z aplikacją, która potencjalnie ma w sobie ponad 100 osobolat pracy i naprawdę musisz upewnić się, że wiesz, co ona robi i ile dokumentacja jest w nim. Ponieważ nie powiedziałeś, w jakiej branży jest wdrożony system, na podstawie tego, co czytałem o G2, wydaje się, że można bezpiecznie założyć, że jest to aplikacja o kluczowym znaczeniu dla misji, która może nawet potencjalnie mieć wpływ na bezpieczeństwo życia. Dlatego bardzo ważne będzie zrozumienie, co dokładnie robi. Jest kod, który nie jest udokumentowaną pracą z innymi członkami zespołu, aby upewnić się, że dokumentacja jest wdrożona, aby ludzie mogli ustalić, co robi kod.

Następnie rozpocznij owijanie testów jednostek wokół jak największej liczby baz kodu i schematów wizualnych. Muszę przyznać się do pewnej niewiedzy dotyczącej tego, jak to zrobić za pomocą G2, ale może być prawie warte stworzenia własnego środowiska testowego, aby to zrobić. Jest to również idealny moment, aby zacząć przedstawiać innych członków zespołu, aby przyzwyczaili się do niektórych bardziej rygorystycznych praktyk inżynierskich związanych z jakością kodu (tj. Cały kod musi zawierać testy jednostkowe i dokumentację).

Kiedy już przeprowadzisz testy jednostkowe na sporej ilości kodu, możesz zacząć zbliżać się do refaktoryzacji w sposób taki jak sugerowany przez Haylem ; Pamiętaj jednak, aby pamiętać, że masz do czynienia z czymś, co jest przeznaczone do rozwijania systemów eksperckich, a refaktoryzacja może być ciężką walką. W rzeczywistości jest to środowisko, w którym można coś powiedzieć o tym, że czasami nie pisze się bardzo ogólnego kodu.

Na koniec pamiętaj, aby zwracać baczną uwagę na to, co mówią inni członkowie zespołu, tylko dlatego, że jakość kodu i diagramu nie jest najlepsza, niekoniecznie odbija się na nich źle. W ostatecznym rozrachunku będą oni prawdopodobnie wiedzieć więcej o tym, co robi aplikacja niż ty, dlatego tym bardziej ważne jest, aby usiąść i upewnić się, że rozumiesz, co robi przed wprowadzeniem gruntownych zmian.

Zwykle skargi, które słyszysz z góry, nie mają nic wspólnego z ważnymi problemami. W końcu to normalne, aby usłyszeć o tych skargach w projektach oprogramowania.

Trudno zrozumieć kod? Czek. Ogromna baza kodu? Czek.

Prawdziwy problem polega na tym, że ludzie odchodzą, a kiedy nowa osoba dołącza do organizacji, następuje typowa dezorientacja. Ponadto istnieje problem nierealnych oczekiwań i problemów z jakością kodu.

Oto, co chciałbym rozwiązać, aby:

1. Kopie zapasowe, zarówno wersja serwerowa, jak i lokalna
2. Skonfiguruj narzędzie do śledzenia błędów
3. Skonfiguruj system kontroli wersji
4. Skonfiguruj FAQ / Wiki
5. Pierwsze spotkanie wszystkich naukowców / programistów
   • Przypomnij im o zasadzie 80/20. 20% błędów jest odpowiedzialnych za 80% problemów.
   • Skoncentruj się na największych problemach i utrzymuj prośby o ulepszenia itp.
   • Nie chodzi tu o to, by straszyć ludzi z dużą listą, ale o listę małych osiągalnych wygranych. W końcu musisz udowodnić swoją wartość.
6. Skonfiguruj system kompilacji
   • Rozpocznij pracę nad uzyskaniem niezawodnych kompilacji (może to chwilę potrwać)
   • zidentyfikuj i nazwij każdy projekt
   • identyfikować zależności cykliczne
   • jeśli istnieją pliki binarne z niektórych projektów typu open source, spróbuj uzyskać źródła
7. Zidentyfikuj, w jaki sposób można zmodularyzować kod G2, np. API, usługi
8. Zidentyfikuj, w jaki sposób można przetestować, udokumentować kod G2.
9. Skonfiguruj system sprawdzania kodu
10. Drugie sprawozdanie
    • Jak wygląda idealny moduł?
    • Jak odgrodzić stary kod
    • Jak owinąć nowy moduł wokół starego kodu (patrz Wzorzec Dusiciela http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-pattern-of-choice-for.html )
11. Znajdź zespół lepszych programistów i współpracuj z nimi, aby zawinąć swoje moduły.
12. Na tym etapie znajdują się recenzje kodu w celu usprawnienia komunikacji i dokumentacji. Na tym etapie zachowaj spokój. Rozwiąż wszelkie problemy z procesem.
13. Rozwiń system innym programistom. Niech członkowie zespołu crack zostaną mentorami rówieśników dla reszty. Pamiętaj, że problemem jest tutaj skalowanie. Jesteś skutecznie na stanowisku kierowniczym.

Takie pytania są jedynym powodem, dla którego istnieje projekt Software Carpentry .

Przez ostatnie 14 lat uczymy naukowców i inżynierów podstawowych umiejętności tworzenia oprogramowania: kontroli wersji, testowania, jak modulować kod i tak dalej. Wszystkie nasze materiały są bezpłatnie dostępne na licencji Creative Commons, a każdego roku organizujemy kilkadziesiąt bezpłatnych dwudniowych warsztatów, aby pomóc ludziom zacząć.

Na tej podstawie uważam, że najlepszym punktem wyjścia jest prawdopodobnie doskonała (krótka) książka Roberta Glassa Fakty i błędy inżynierii oprogramowania : oparte na dowodach podejście jest dobrym sposobem przekonania naukowców, że mówimy im o dobrych praktykach programistycznych więcej niż tylko opinia.
Jeśli chodzi o konkretne praktyki, dwie osoby, które są najbardziej chętne do przyjęcia, to kontrola wersji i testowanie jednostkowe; po ich wdrożeniu mogą zająć się systemem systematycznego refaktoryzacji opisanym przez Michaela Feathersa w Skutecznej pracy ze starszym kodem .
Nie polecam już Pragmatycznego programisty (wiele nawoływań, trudnych do zastosowania przez nowicjuszy) i uważam, że kod McConnella jest kompletny to za dużo na początek (choć wspaniale jest dać im sześć miesięcy lub rok, kiedy opanują podstawy).

Gorąco poleciłbym także znakomity artykuł Paula Dubois „Utrzymanie poprawności programów naukowych” ( Computing in Science & Engineering , maj-czerwiec 2005 r.), W którym opisano podejście „dogłębnej obrony” łączące tuzin różnych praktyk w logiczny, spójny sposób droga.

Myślę, że przede wszystkim musisz wyjaśnić swoją sytuację. Czego oni chcą od ciebie?

• Jest bardzo mało prawdopodobne, że chcą, abyś nauczył się starożytnego języka, ponieważ wydaje się to ślepym zaułkiem: istnieje malejąca szansa na znalezienie kogoś, kto zna lub chce się uczyć G2, więc wiedza zostanie zakopana w zawalającej się masie kodu, gdy obecni naukowcy odchodzą lub cały łatany kod zawodzi coraz częściej.
• Czy naukowcy (lub niektórzy z nich) są gotowi nauczyć się nowego języka i wielu paradygmatów programowania? Czy też chcą w dłuższej perspektywie oddzielić działalność programistyczną i naukową, a może w razie potrzeby mieć więcej programistów? Wydaje się to racjonalnym i bardziej wydajnym rozdziałem wiedzy specjalistycznej.

Myślę, że podstawowym wymogiem tutaj jest „zapisanie wiedzy w systemie”, więc musisz ją odkryć!

Pierwszym zadaniem jest napisanie dokumentacji.

Przeanalizuj strukturę i wymagania, jakby to było nowe zadanie, ale z pomocą istniejącego systemu. Będą zadowoleni, ponieważ najpierw zadajesz pytanie zamiast NAUCZANIA - i szybko zdobędziesz wystarczającą, ale bardziej uporządkowaną wiedzę z punktu widzenia programisty: „co tu się dzieje?”. Dokumenty (struktura statyczna systemu, przepływ pracy, komponenty, problemy) będą dla nich natychmiast cenne i być może pokażą im bardziej odpowiednie informacje niż tobie (niektórzy z nich mogą mieć „AHA!” I natychmiast zaczną naprawiać niektóre kody ) ...

Powinieneś zacząć pytać, gdzie chcą iść?

Jeśli są gotowi odejść od G2, jaki system chcą widzieć (platforma, język, interfejs, ogólna struktura)? Możesz zacząć pisać zewnętrzne opakowanie wokół systemu, jeśli to w ogóle możliwe, mając strukturę docelową, ale zachowując oryginalne komponenty, a tym samym powoli uruchamiając rodzaj struktury, która pozwala na implementację nowych komponentów w tym docelowym środowisku. Musisz znaleźć podstawowe usługi (trwałe połączenia danych i „zestawy narzędzi”: podstawowe obliczenia, rysowanie, ... biblioteki), a więc zapewnić im znajome środowisko w nowej platformie i języku, który pozwala na przejście przez ciebie lub je: weź stare kody jeden po drugim, zaimplementuj je ponownie (i WYCZYŚĆ!) w nowym środowisku. Kiedy to będzie gotowe, znają nowy język; a warstwa usług (przeważnie tworzona przez Ciebie, przepraszam) jest gotowa na hostowanie nowych komponentów.

Jeśli się nie poruszają , musisz nauczyć się G2 i stworzyć tam modułową strukturę, do której ty lub oni powinniście przenieść elementy (z czyszczeniem). W każdym razie język jest po prostu serializacją danych i drzewa algorytmów ...

Analizując i pisząc dokumenty, czytaj, używaj i reklamuj wzory GoF Design! :-)

... moje 2 centy

Właśnie skończyłem robić serię prezentacji na temat SOLIDNYCH zasad Roberta Martina dla moich współpracowników. Nie wiem, jak dobrze te zasady przekładają się na G2, ale ponieważ szukasz 5-7 podstawowych zasad, wydaje się, że są to dobrze ugruntowane zestawy na początek. Jeśli chcesz zaokrąglić w górę do 7, możesz zacząć od OSUSZANIA i rzucić Szybko.

Jedyny problem z produkcją brzmi jak problem z zarządzaniem zmianami. Jeśli tak jest, a oprogramowanie wykonuje to inaczej, pierwszą radą, jaką dałbym, jest powstrzymanie się od chęci zbyt szybkiego działania.

Kontrola źródła, refaktoryzacja, lepiej wyszkoleni deweloperzy są dobrymi sugestiami, ale jeśli po raz pierwszy musiałeś poradzić sobie z tego rodzaju problemami poruszającymi się powoli i wprowadzanie kontrolowanych zmian nie może być wystarczająco podkreślone.

Chęć zniszczenia bałaganu będzie czasem świetna, ale dopóki nie dokonasz inżynierii wstecznej na tyle, byś wiedział, że możesz odpowiednio przetestować swoją wersję zamienną, musisz być bardzo ostrożny.

Najważniejsze zasady działania w takiej sytuacji to:

1. Bądź cierpliwy. Dziura, której wykopanie zajęło 20 lat, nie zostanie wypełniona za kilka tygodni.

2. Bądź pozytywnie nastawiony. Oprzyj się pokusie narzekania i narzekania.

3. Bądź pragmatyczny. Spójrz na pozytywną zmianę, której możesz dokonać w ciągu jednego dnia, i zrób to już dziś. Masz już system kontroli wersji? Wdrażaj go i trenuj ludzi. Następnie sprawdź, czy możesz zautomatyzować testowanie (testowanie jednostkowe lub coś podobnego). Wypłukać. Powtarzać.

4. Bądź modelką. Pokaż (nie mów tylko) ludziom, jak działa zwinność, będąc zwinnym. Pierwsze trzy punkty powyżej to klucze do bycia dobrym facetem, który jest poprzednikiem bycia skutecznym facetem zwinnym. Moim zdaniem ludzie, którzy są godnymi podziwu programistami, są nie tylko sprytni, ale także dobrzy, modelują pracowników i współpracowników.

5. Mapuj swoje terytorium. Mam technikę mapowania gigantycznych baz kodowych. Klonuję repozytorium, robię kopię roboczą, a następnie próbuję coś zmienić i zobaczyć, co jeszcze się psuje. Badając sprzężenie (za pośrednictwem stanu globalnego lub uszkodzonych interfejsów API lub braku spójnego interfejsu API lub jakichkolwiek abstrakcyjnych interfejsów lub programów do obsługi) i czytając kod, który pęka, gdy zmieniam rzeczy, odkrywam cruft, zadaję pytania, które prowadzą do spostrzeżenia od reszty zespołu (Och, dodaliśmy, że ponieważ Boss X 5 lat temu tego zażądał, to nigdy nie zadziałało!). Z czasem pojawi się mapa mentalna terytorium. Gdy dowiesz się, jak duży jest, dowiesz się wystarczająco, aby zrobić mapę i wrócić do domu. Zachęcaj innych do mapowania terytorium twojej gigantycznej bazy kodów i do budowania wiedzy technicznej zespołu. Niektóre osoby nie zgadzają się na „dokumentację” ponieważ nie jest zwinny. Cokolwiek. Pracuję również w środowisku naukowym, a dokumentacja jest dla mnie królem, zwinne manifesty niech będą przeklęte.

6. Twórz małe aplikacje. Kiedy pracuję ze starszą bazą kodu, okazuje się, że mam miazgę. Odzyskuję ducha, budując małe aplikacje pomocnicze. Może te aplikacje pomogą Ci przeczytać, zrozumieć i zmodyfikować tę gigantyczną bazę kodów G2. Może uda ci się stworzyć mini IDE lub narzędzie do analizowania składni, które pomoże ci pracować w twoim środowisku. Istnieje wiele przypadków, w których Metaprogramowanie i budowanie narzędzi nie tylko pomoże ci wyjść z gigantycznych impasów, które narzucają ci starsze bazy kodów, ale także da mózgowi zdolność latania bez ograniczeń przez język G2. Napisz swoje narzędzia i pomocników w jakimkolwiek języku, w którym możesz zrobić to najszybciej i najlepiej. Dla mnie te języki to Python i Delphi. Jeśli jesteś facetem w języku Perl lub faktycznie lubisz programować w C ++ lub C #, napisz swoje narzędzia pomocnicze w tym języku.

1. Kontrola wersji : pokaż ekspertom domeny korzyść z możliwości przywrócenia, zobacz, kto co zmienił itp. (Jest to trudniejsze w przypadku plików całkowicie binarnych, ale jeśli zawartość jest rzeczywiście kodem, z pewnością istnieje pewien rodzaj G2-to- konwerter tekstu, który może włączyć diff.)

2. Ciągła integracja i testowanie : zaangażuj ekspertów domeny w tworzenie kompleksowych testów (łatwiej, ponieważ muszą już gdzieś mieć dane wejściowe i oczekiwane wyniki) i małych testów jednostkowych (trudniejsze, ponieważ kod spaghetti prawdopodobnie zawiera wiele zmiennych globalnych), które obejmują prawie całą funkcjonalność i przypadki użycia.

3. Przekształć wspólny kod w procedury i komponenty wielokrotnego użytku. Osoby niebędące programistami bez kontroli wersji prawdopodobnie kopiują i wklejają setki linii jednocześnie, aby tworzyć procedury. Znajdź je i popraw je, pokazując, że wszystkie testy przeszły pomyślnie, a kod jest krótszy. Pomoże to również nauczyć się jego architektury. Jeśli masz szczęście, zanim zaczniesz podejmować trudne decyzje architektoniczne, być może spadniesz do 100KLOC.

Politycznie , jeśli w tym procesie znajdziesz opór ze strony starych liczników czasu, zatrudnij konsultanta, który przyjdzie i opowie o dobrej metodologii oprogramowania. Upewnij się, że znajdziesz dobrego, z którym zgadzasz się z poglądami, i poproś kierownictwo, aby wykupiło konieczność konsultanta, nawet jeśli eksperci w tej dziedzinie nie. (Powinni się zgodzić - w końcu cię zatrudnili, więc najwyraźniej zdają sobie sprawę, że potrzebują specjalistycznej wiedzy inżynierskiej). To oczywiście marnowanie pieniędzy, ale powodem jest to, że jeśli ty - nowy gorący programista - powiesz im muszą coś zrobić, mogą to zignorować. Ale jeśli zarząd zapłaci konsultantowi 5000 $, aby przyszedł i powiedział im, co musi zrobić, w to uwierzy. Punkty bonusowe: poproś konsultanta o doradzenie dwa razy tyle zmian, ile naprawdę chcesz, wtedy możesz być „dobrym facetem” i współpracować z ekspertami w dziedzinie, kompromisując jedynie zmianę o połowę mniej niż sugerował konsultant.

„Sam program jest fizycznym modelem złożonego zakładu przetwarzania chemicznego ...”

„Ponieważ G2 jest jak nie-kod, ale raczej automatyczny kod napisany przez gadżety GUI ...” - Erik Reppen

Zakładając, że głównym celem twojego oprogramowania jest symulacja (być może optymalizacja, przeprowadzenie oszacowań parametrów) złożonej instalacji chemicznej lub jej części ... wtedy chciałbym przedstawić inną sugestię:

Warto rozważyć użycie wysokopoziomowego języka modelowania matematycznego do wyodrębnienia esencji, podstawowych modeli matematycznych z ręcznie kodowanego oprogramowania.

Język modelowania polega na oddzieleniu opisu problemu od algorytmów zastosowanych do rozwiązania problemu. Algorytmy te mają ogólne zastosowanie do większości symulacji / optymalizacji danej klasy (np. Procesów chemicznych), w którym to przypadku tak naprawdę nie powinny być ponownie opracowywane i utrzymywane wewnętrznie.

Trzy komercyjne pakiety szeroko stosowane w twojej branży to: gPROMS, Aspen Custom Modeller i (jeśli twoje modele nie zawierają zjawisk rozproszonych wzdłuż domen przestrzennych), istnieją pakiety oprogramowania oparte na Modelice, takie jak Dymola.

Wszystkie te pakiety obsługują „rozszerzenia” w taki czy inny sposób, więc jeśli masz części swoich modeli, które wymagają niestandardowego programowania, można je zamknąć w obiekcie (np. .DLL), do którego mogą odnosić się równania w Model. Tymczasem większość twojego modelu pozostaje zwięzła, opisana w formie łatwo czytelnej dla naukowców. To znacznie lepszy sposób na przechwycenie wiedzy i adresu IP firmy.

Większość tych programów powinna również umożliwiać „uruchamianie małych” i przenoszenie małych części (podmodeli) kodu monolitycznego do ich formatu, poprzez ich zewnętrzne wywołanie. Może to być dobry sposób na utrzymanie działającego systemu i sprawdzenie go pojedynczo.

Pełne wyłączenie odpowiedzialności: Przez 8 lat pracowałem jako inżynier oprogramowania w firmie stojącej za gPROMS. W tym czasie widziałem (i czasami włączałem) przykłady niestandardowego oprogramowania (np. Pochodzącego ze środowisk akademickich), które zaczęło się małe i uporządkowane, wdrażając sprytne rozwiązanie lub algorytm, ale potem eksplodowało z biegiem lat dzięki rozszerzeniom i modyfikacjom - bez pomocnych wskazówek inżynier oprogramowania, aby utrzymać go w czystości. (Jestem wielkim fanem zespołów multidyscyplinarnych.)

Mogę więc powiedzieć z pewnym doświadczeniem, że niektóre kluczowe wybory dokonane źle na wczesnym etapie rozwoju oprogramowania (takie jak język lub biblioteka kluczy) mają tendencję do pozostawania w pobliżu i powodowania bólu przez długi czas ... Już „ukształtowali” oprogramowanie wokół nich. Brzmi dla mnie tak, jakbyś miał przed sobą wiele lat czystego czyszczenia kodu. (Waham się przed użyciem liczb, ale myślę, że od ponad 10 lat osobiście, może więcej, jeśli nie możesz przenieść kodu z G2 do czegoś, co obsługuje dobre automatyczne narzędzia do refaktoryzacji, takie jak Eclipse / Java quick-smart.)

Chociaż moim domyślnym statusem jest „refaktoryzacja i utrzymanie działającego systemu”, myślę również, że gdy problem stanie się „zbyt duży”, wówczas bardziej radykalna zmiana / ponowne zapisanie staje się ogólnie szybsza. (I prawdopodobnie przynosi dodatkowe korzyści, takie jak przejście na bardziej nowoczesną technologię.) Mówię, że z pewnym doświadczeniem w przenoszeniu na nową platformę oprogramowania, ale z tego, co zbieram, jest jeszcze bardziej dramatyczny z portem do pakietu modelowania matematycznego.

Aby dać perspektywę, możesz być zaskoczony zmniejszeniem rozmiaru. Np. 200 000 LoC może być w rzeczywistości reprezentowane przez 5000 linii równań (OK, zgaduję tutaj, ale mógłbym spróbować uzyskać prawdziwe opinie od znajomych z branży); plus kilka stosunkowo niewielkich modułów funkcyjnych napisanych w czymś takim jak C (na przykład obliczenia właściwości fizycznych - chociaż znowu, w zależności od procesu chemicznego, mogą istnieć opakowania gotowe). Wynika to z tego, że dosłownie wyrzucasz kod rozwiązania algorytmicznego i pozwalasz ciężkiemu działaniu „stosu” solverów matematycznych. Po uruchomieniu symulacji możesz z nimi zrobić znacznie więcej, np. Zoptymalizować proces - bez zmiany wiersza kodu.

Na koniec powiedziałbym: jeśli jedyną wiarygodną dokumentacją różnych modeli matematycznych (i algorytmów) jest sam kod, będziesz potrzebować pomocy naukowców i oryginalnych autorów, aby pomóc w wydobyciu tych modeli, JAK NAJSZYBCIEJ, a nie lat później, gdy niektóre z nich mogły przejść dalej. Powinni odkryć, że język modelowania matematycznego jest bardzo naturalnym sposobem na uchwycenie tych modeli - mogą nawet (szokujący horror) cieszyć się (ponownym) pisaniem go.

Wreszcie, ponieważ moja odpowiedź może być nie na miejscu, chciałbym dodać jeszcze jedną książkę do listy dobrych książek, o których już tu jest mowa: Clean Code autorstwa Roberta Martina. Pełne prostych (i uzasadnionych) wskazówek, które są łatwe do nauczenia się i zastosowania, ale które mogą zmienić świat ludzi tworzących nowy kod w Twojej firmie.

Zrzuciłbym następujące:

1. Jest tutaj jeden programista. Pieprzyć politykę. Znają swój zawód. Znasz swój. Oznacz to terytorium, nawet jeśli musisz się na niego sikać. Oni są naukowcami. Mogą szanować takie rzeczy lub powinny, ponieważ prawie same robią to samo. Za pomocą wszelkich dostępnych środków oznacz teraz granice. To naprawię. Za to nie mogę być odpowiedzialny.

2. Naukowcy piszą / testują algorytmy. Naukowcy, którzy chcą pisać własne algorytmy w 1-3 językach, wszyscy mogą wyrazić zgodę na konwersję do kodu podstawowego. To nakłada na nie testowanie ich rzeczy. Poza tym będą musieli pomóc ci odizolować ważne rzeczy naukowe od dobrego boga-wie-co zrobili dla architektury. Baza kodów jest ukryta. Trzeba będzie wykonać wiele cięć i poparzeń. Daj im opcje, aby przekazać ci działające wersje rzeczy, które wykorzystują to, co wiedzą najlepiej, abyś mógł robić to, co robisz najlepiej. Umieść swoją wiedzę w polu, za które są odpowiedzialni, ale z którym możesz pracować.

3. Jeśli to możliwe, używaj przyjaznego dla zdarzeń języka z pierwszorzędnymi funkcjami. Gdy wszystko inne zawiedzie, wywołanie zdarzenia lub odrzucenie wywołania zwrotnego do jakiegoś obiektu za pomocą interfejsu i mechanizmu stanu, który faktycznie ma sens, może być ogromną oszczędnością czasu, gdy jesteś głęboko w kodzie, co nie ma cholernego sensu i prawdopodobnie nigdy będzie. Naukowcy wydają się lubić Python. Nietrudno skleić z tym matematykę C na niższym poziomie. Tylko mówię'

4. Poszukaj kogoś, kto rozwiązał ten lub podobny problem. Poświęć trochę czasu na badania. Ci faceci słyszeli o G2 od kogoś.

5. Wzorce projektowe. Adaptery Użyj ich. Używaj ich dużo w takich sytuacjach.

6. Dowiedz się, co możesz z nauki. Im więcej wiesz, tym lepiej możesz określić zamiary w kodzie.

Najpierw wykonaj analizę.

Zrobiłbym analizę przed podjęciem decyzji, czego nauczać. Dowiedz się, gdzie są największe punkty bólu. Skorzystaj z nich, aby ustalić, jakie praktyki należy pominąć.

Wprowadź tylko kilka zmian na raz (w podobnej sytuacji ćwiczyłem 2-3 ćwiczenia co 2 tygodnie) .

Ograniczę praktyki do ~ 3 w zależności od poziomu zmiany do stylu programowania SDLC; dopóki nie zaczną się z nimi czuć komfortowo (nalegałbym, aby wprowadzać 1 nową zmianę co ~ 1-2 tygodnie, ponieważ czują się bardziej komfortowo z myślą o nauce nowych podejść). Dobrym pomysłem jest również określenie, jakie są kryteria sukcesu. Co powinna osiągnąć praktyka (nawet jeśli jest to miękki cel, taki jak morale zespołu). W ten sposób możesz pokazać, czy jest skuteczny, czy nie.

• Po co ograniczać liczbę zmian?

Nawet jeśli zakładasz, że ci ludzie chcą być lepszymi programistami i są otwarci na naukę, istnieją ograniczenia co do tego, ile i jak szybko ludzie mogą się uczyć nowych koncepcji i stosować je; szczególnie jeśli nie mają podstaw CS lub wcześniej uczestniczyli w cyklu życia oprogramowania.

Dodaj cotygodniowe spotkanie podsumowujące, aby omówić wpływ tych praktyk na nich.

Spotkanie powinno być wykorzystane do omówienia, co poszło dobrze i co wymaga pracy. Pozwól im mieć głos i współpracować. Dyskutuj i planuj rozwiązywać problemy, które mają, i przeglądaj nadchodzące zmiany. Koncentruj spotkanie na praktykach i ich zastosowaniu. Zrób trochę ewangelizacji na temat korzyści, które powinni zacząć widzieć od stosowania praktyk.

Niektóre praktyki mają pierwszeństwo.

Właściwe użycie systemu kontroli wersji (IMO) przebija wszystko inne. Tuż za nim znajdują się lekcje modularyzacji, sprzężenia / spójności i śledzenia cech / błędów.

Usuń praktyki, które nie działają.

Nie bój się pozbyć praktyk, które nie działają. Jeśli istnieje wysoki koszt i niewiele lub nie ma korzyści, usuń praktykę.

Ulepszenie jest procesem.

Przekaż, że trwałe, konsekwentne doskonalenie jest procesem. Zidentyfikuj największe punkty bólu, zastosuj rozwiązanie, poczekaj / trenuj, a następnie powtórz. Będzie początkowo odczuwał bolesne powolność, dopóki nie nabierzesz tempa. Skoncentruj wszystkich na nadchodzących ulepszeniach i udoskonaleniach, które już są udane.

Wydaje się, że pierwszym krokiem jest sprzedaż zespołowi potrzeby inwestowania w nową metodologię oprogramowania. Zgodnie z twoim stwierdzeniem, w zespole nie ma concensusu, a będziesz go potrzebował, aby móc orać się z powolnym „ulepszaniem” kodu.

Chciałbym (jeśli mogę) osobiście wziąć ciężkie wyciągnięte lekcje i przedstawić każdą z kluczowych koncepcji, które chcesz rozwiązać jako rozwiązanie problemu w branży oprogramowania.

Np. Dwóch programistów miało różne kopie i ostatecznie wdrożyło hybrydowe nieprzetestowane wydanie -> Wprowadzenie kontroli wersji, rozgałęziania i testowania.

Ktoś usunął kilka wierszy kodu, których nie rozumiał i spowodował awarię -> wprowadź DDD.

Jeśli ciężkie lekcje nie są dzielone z tobą wystarczająco szczegółowo, po prostu pokaż własne przykłady, jak poszło nie tak, gdy dyscyplina ta nie była przestrzegana.

Kontrola kodu źródłowego jest krokiem 1, jak już wielokrotnie wspomniano. Podczas gdy ludzie, z którymi pracujesz, mogą nie być profesjonalnymi programistami i nie będą reagować na wiele dużych lub zwinnych mumbo jumbo. Nie są też małpami kodowymi niskiego poziomu i próbują traktować je w ten sposób, zmuszając je do robienia rzeczy „po swojemu”.

Musisz zbadać, co tam jest. Jeśli nie użyli kontroli kodu źródłowego, to po prostu określenie odpowiednich wersji kodu (jeśli to możliwe) i tego, co wszystkie możliwe elementy dostarczą, zajmie dużo czasu. Następnie masz za zadanie nauczyć kolegów, jak korzystać z kontroli kodu źródłowego i przekonać ich, że warto poświęcić im czas. Zacznij od korzyści!

Podczas gdy to robisz, znajdź inne nisko wiszące owoce i napraw te problemy.

Przede wszystkim słuchaj, co mają do powiedzenia, i pracuj nad poprawą ich sytuacji. Nie martw się, że spróbujesz umieścić znaczek na tym, co robią.

Powodzenia!