7 kluczowych praktyk kodowania dla zwinnych programistów

Zwinne tworzenie oprogramowania to nie tylko zwinne zasady i praktyki. Aby odnieść sukces w wydawaniu oprogramowania, które pozytywnie wpływa na użytkowników końcowych, radzi sobie z zadłużeniem technicznym i jest niezawodnie wdrażane, zespół programistów musi również wziąć pod uwagę swoje praktyki kodowania i standardy architektury zapewniające elastyczność.

Jeszcze ważniejsza kwestia dotyczy organizacji technologicznych. Tworzenie oprogramowania jest trudne, ale wdrażanie ulepszeń i uaktualnień regularnie przez dłuższy czas jest jeszcze trudniejsze. Praktyki Devops CI / CD i IAC (infrastruktura jako kod) częściowo rozwiązują jeden krytyczny czynnik, ponieważ automatyzacja umożliwia niezawodne i powtarzalne sposoby wdrażania aplikacji. Dodaj ciągłe testowanie, a zespoły programistyczne mają sposób na sprawdzenie, czy zmiany kodu nie wpływają na istniejące funkcje.

Jednak w miarę starzenia się aplikacji pierwotni programiści przechodzą do innych projektów, a czasem do innych firm. Gdy nowi programiści dołączają do zespołu, muszą poznać architekturę oprogramowania i zrozumieć kod, zanim będą mogli niezawodnie i skutecznie go zmienić.

Ponadto programiści, którzy tworzą aplikacje, często chcą tworzyć nowe. Być przywiązanym do tworzonych aplikacji może być wygodne i bezpieczne, ale przywiązanie do kodu nie jest zdrowe dla Twojej kariery ani organizacji.

Najlepszym sposobem, aby przejść do nowych i ekscytujących inicjatyw związanych z tworzeniem oprogramowania, jest ułatwienie obsługi architektury, aplikacji i kodu przez innych programistów. Zwinne zespoły i programiści muszą ustanowić i egzekwować praktyki kodowania, które wspierają ciągły rozwój oprogramowania.

1. Nie wynajduj koła na nowo

Pierwsza zasada kodowania: nie koduj czegoś, co nie musi być kodowane! W jaki sposób?

  • Rozważ zadawanie pytań dotyczących wymagań. Dlaczego funkcja jest ważna? Kto korzysta? Dokładniej, zbadaj opcje niekodujące, aby rozwiązać problem. Czasami najlepszym rozwiązaniem jest brak rozwiązania.
  • Czy ktoś w Twojej organizacji zakodował już podobne rozwiązanie? Być może istnieje mikrousługa, która wymaga tylko ulepszenia lub biblioteka oprogramowania, która wymaga niewielkiej aktualizacji? Pamiętaj, aby przejrzeć bazę kodu swojej organizacji przed napisaniem czegoś nowego.
  • Czy istnieją rozwiązania innych firm, w tym niedrogie narzędzia SaaS lub opcje open source, które spełniają minimalne wymagania?
  • Czy spojrzałeś na otwarte repozytoria kodowania, takie jak GitHub, pod kątem przykładów kodu i fragmentów, które spełniają wymagania Twojej organizacji dotyczące zgodności?

2. Rozważ opcje programowania o niskim kodzie

Jeśli potrzebujesz zakodować rozwiązanie, być może alternatywne platformy o niskim kodzie mogą umożliwić wydajniejsze rozwijanie funkcji w porównaniu z kodowaniem w językach programowania, takich jak Java, .Net, PHP i JavaScript.

Platformy o niskim kodzie, takie jak Caspio, Quick Base, Appian, OutSystems i Vantiq, zapewniają narzędzia do tworzenia aplikacji z niewielką ilością kodu, a czasem nawet bez kodowania. Każda platforma specjalizuje się w innych możliwościach i dlatego jest odpowiednia dla określonej klasy zastosowań. Na przykład Caspio ułatwia osadzanie formularzy i przepływów pracy w witrynach internetowych. Quick Base ma solidne możliwości w zakresie przepływu pracy i automatyzacji, a architektura sterowana zdarzeniami Vantiq jest odpowiednia dla IoT i innych aplikacji danych w czasie rzeczywistym.

Czasami kodowanie jest wymagane, ale programiści powinni również być biegli w jednej lub kilku opcjach programowania o niskim kodzie i rozważyć je w odpowiednich przypadkach użycia.  

3. Zautomatyzuj testowanie

Oprócz pisania kodu spełniającego wymagania, jedną z najważniejszych rzeczy, które programiści muszą zrobić, jest przetestowanie go. Praktyki programistyczne oparte na testach i zautomatyzowane narzędzia testujące dojrzały, a zespoły programistyczne powinny uwzględniać testy jednostkowe, regresyjne, wydajnościowe i testy bezpieczeństwa jako część swoich elastycznych oszacowań.

Oprócz testów sprawdzających poprawność kompilacji i wydań, testy te pomagają również uczynić kod bardziej obsługiwanym. Testy to dokumentacja i ustalenie kontraktu opisującego, jak kod ma się zachowywać. Gdy nowi programiści dołączają do zespołów i nieumyślnie wprowadzają złą zmianę, ciągłe testowanie zatrzymuje kompilację i dostarcza deweloperowi znaczących informacji zwrotnych w celu szybkiego rozwiązania problemu.

4. Udostępnić wszystkie parametry konfiguracyjne na zewnątrz

Programiści nie powinni mieć wymówki, aby kiedykolwiek na stałe zakodować w kodzie ustawienia systemu, nazwy użytkowników i hasła lub inne informacje konfiguracyjne. Widziałem, jak programiści idą na skróty podczas opracowywania prototypów, które trafiają do środowisk produkcyjnych. W dzisiejszych architekturach nigdy nie powinno się tego robić. Twarde kodowanie nie jest długiem technicznym, ale leniwą, nieodpowiedzialną praktyką kodowania, która może mieć poważne konsekwencje. Jeśli kod zostanie przypadkowo dostępny, tworzy lukę w zabezpieczeniach, jeśli punkty końcowe lub poświadczenia dostępu zostaną ujawnione.

Idąc o krok dalej, gdy trwają prace nad starszym kodem, zajęcie się wszelkimi zakodowanymi na stałe konfiguracjami i parametrami powinno być niezbywalnym priorytetem długu technicznego.

5. Przestrzegaj konwencji nazewnictwa i dołącz komentarze, aby kod był czytelny

Kiedyś pracowałem z niesamowicie utalentowanym programistą, który nie znał dobrze angielskiego i nie był najlepszym maszynistą. Tworzyłby obiekty o nazwach takich jak a , b i c, a następnie tworzył zmienne lokalne o nazwach zz , yy , xx . Zobowiązał się do uporządkowania tego przed zwolnieniem, ale rzadko kiedy to robił.

Nie powinieneś mieć programowania w parach lub mobach, aby rozpoznać, że to okropna praktyka.

Zespoły powinny przyjąć konwencje nazewnictwa, takie jak Przewodnik po stylach języka JavaScript i Przewodnik po stylach języka Java, i zobowiązać się do komentowania kodu przynajmniej na poziomie modułowym, a najlepiej na poziomie klasy. Ponadto organizacje powinny rozważyć użycie narzędzi do statycznej analizy kodu, które dostarczają programistom informacji zwrotnych, gdy kod wymaga refaktoryzacji pod kątem czynników struktury i czytelności.

6. Często sprawdzaj kod w kontroli wersji

Jeśli nie sprawdzasz kodu do kontroli wersji codziennie lub częściej, może to powodować konflikty i inne blokady, które mają wpływ na zespół. Jeden mały błąd może spowodować, że zespoły zwinne przegapią swoje zobowiązania dotyczące sprintu lub stworzą dodatkową pracę w celu rozwiązania zależności.

Zespoły powinny uzgodnić konwencje dotyczące sprawdzania kodu, który nie jest gotowy do produkcji. Konwencjonalne podejścia obejmują flagi funkcji i rozgałęzienia Git.

7. Unikaj kodowania heroizmu i zawiłości

Większość programistów, których znam, została zawodowymi inżynierami oprogramowania, ponieważ uwielbiają rozwiązywać wyzwania związane z kodowaniem. Kodowanie to sztuka, nauka i rzemiosło, a lepsi programiści szukają prowokujących do myślenia zadań związanych z kodowaniem i eleganckich implementacji.

Z wyjątkiem tego, że istnieje szara granica między rozwiązywaniem trudnych zadań biznesowych i technicznych a heroicznymi kodami, które pozostawiają kolejnym programistom kod trudny do zrozumienia i skomplikowany w utrzymaniu.

Ci z nas, którzy od jakiegoś czasu zajmują się programowaniem, pamiętają wygodę jednolinijkowych Perla lub używania zagnieżdżonych szablonów w C ++. Czasami istnieją dobre powody, aby zastosować takie podejście, ale jeśli nowa grupa programistów nie rozumie tych technik, trudniej jest zmienić kod. Czasami proste, ale mniej eleganckie praktyki kodowania są lepsze.

Zwiększanie elastyczności w zwinnym tworzeniu oprogramowania

Rytuały osadzone w Scrum i Agile Development, w tym zobowiązania, stand-upy, przeglądy sprintu i retrospektywy, są teraz sprawdzonymi praktykami umożliwiającymi współpracę zespołową i napędzaniem udanej implementacji. Jednak aby wykazać się zwinnością przez długi czas, programiści muszą wziąć na siebie odpowiedzialność i praktyki kodowania, które umożliwiają długoterminowe wsparcie i rozszerzalność tworzonego przez nich kodu.

Zespoły programistyczne muszą krytycznie spojrzeć na swoje praktyki kodowania. Nie wystarczy już dziś demonstrować i wydawać; ważne jest również, aby umożliwić innym łatwe utrzymanie aplikacji i kodu.