Najważniejsza umiejętność, jaką może pozyskać programista

Nie, nie, nie i jeszcze raz nie. I jeszcze raz nie. Duże i wyraźne NIE. Wszystko, co musisz zrobić, to połączyć te trzy litery i wypowiedzieć to magiczne słowo.

Teraz wszyscy razem. NIEEEEEE! Dobry początek.

Ale chwileczkę. Mówimy NIE czemu? I kiedy? Cóż to jest właśnie ten ważny punkt, o którym większość programistów (nawet seniorzy) łatwo zapomina?

Jeśli jesteś programistą, to pisanie kodu jest największą częścią Twojej pracy. W życiu kodera będziesz musiał radzić sobie z różnymi rodzajami żądań kodu. Każde z nich zmusi Cię do podjęcia trudnych decyzji. To wszystko ma sens. Nie ma w tym nic złego. Jako od programisty, wszyscy oczekują od Ciebie właśnie tego: Pisania kodu. Oto jednak pytanie: czy na pewno powinieneś pisać każdy kod, o który Cię proszą?

To pytanie prowadzi nas do najważniejszej umiejętności, której programista może się nauczyć:

Wiedza, kiedy nie kodować, jest prawdopodobnie najważniejszą umiejętnością, której programista może się nauczyć. - Sztuka czytelnego kodu

Zgadzam się z tym absolutnie. Dlaczego?

Programowanie to sztuka rozwiązywania problemu. Tak więc programiści to rozwiązywacze problemów. Jako programiści, jesteśmy podekscytowani, kiedy mamy przed sobą nowy problem, który trzeba rozwiązać lub inny powód, by zacząć pisać kod.

I nie ma w tym nic złego, bo jesteśmy programistami. Kochamy pisać kod.

Jednak taka ekscytacja potrafi nas czasem oślepić. Powoduje to, że ignorujemy niektóre ważne fakty, które mogą powodować większe problemy w przyszłości, a z którymi będziemy musieli się zmierzyć.

Tak więc - co to za ważne fakty, które zwykle ignorujemy?

Każda linia kodu, którą piszesz to:

• kod, który musi zostać odczytany i zrozumiany przez innych programistów,
• kod, który musi zostać przetestowany i debugowany,
• kod, który zwiększy defekty Twojego oprogramowania,
• kod, który prawdopodobnie wprowadzi w przyszłości nowe błędy.

Jak napisał Rich Skrenta, kod jest naszym wrogiem:

kod jest zły. Gnije. Wymaga okresowej konserwacji. Zawiera błędy, które należy zlokalizować. Nowe funkcje oznaczają, że stary kod musi zostać dostosowany.

Im więcej masz kodu, tym więcej luk może on ukryć. Im dłużej trwa kasowanie, albo kompilacje, tym dłużej pracownik musi spędzić czasu nad zrozumieniem swojego systemu. Jeżeli zmuszony jesteś refaktoryzować, masz dużo więcej ruchomych części.

Ponadto więcej kodu często oznacza jego mniejszą elastyczność i funkcjonalność. Prostsze rozwiązanie jest szybsze i bardziej uniwersalne, niż bałagan kodu, produkowany przez mniej utalentowanego programistę.

Kod jest produkowany przez inżynierów. Aby wytworzyć więcej kodu, potrzeba więcej inżynierów. Inżynierowie mają koszty komunikacji n², a cały ten kod, który dodają do systemu, jednocześnie rozszerzając jego możliwości, zwiększa również całość kosztów.

Zgodzisz się, prawda? Programiści, którzy inspirują Cię swoją produktywnością i mentalnością kodowania, to ci, którzy wiedzą, kiedy powiedzieć „nie”, a kiedy tego nie powiedzieć. Łatwe w utrzymaniu oprogramowanie, które służy długo i pomaga swoim użytkownikom, nie zawiera niepotrzebnych linii kodu.

Najlepszy kod, to kod znikomej ilości, a najskuteczniejszym programistą jest ten, kto wie, kiedy nie kodować.

Skąd masz wiedzieć, kiedy nie kodować?

To naturalne, że ekscytujesz się, gdy pracujesz nad projektem i zastanawiasz się nad wszystkimi fajnymi funkcjami, które chciałbyś wdrożyć. Ale programiści mają tendencję do przeceniania, ile funkcji ma mieć ich projekt. Wiele funkcji jest niedokończonych lub nieużywanych albo po prostu powoduje nadmierną komplikację aplikacji. Powinieneś wiedzieć, co jest istotne dla Twojego projektu, aby uniknąć popełnienia tego błędu.

Zrozumienie celu oprogramowania i definicji jego rdzenia jest pierwszym krokiem do zrozumienia, kiedy nie należy kodować.

Dam Ci przykład. Powiedzmy, że masz oprogramowanie, które ma tylko jeden cel: zarządzanie e-mailami. W tym celu wysyłanie i odbieranie wiadomości e-mail to dwie podstawowe funkcje Twojego projektu. Nie możesz oczekiwać, że oprogramowanie będzie również zarządzać listą spraw do załatwienia, prawda?

Więc powinieneś powiedzieć NIE wszystkim możliwym żądaniom funkcji, które nie mają znaczenia dla tej definicji. To jest ten moment, w którym możesz być dokładnie pewien, że wiesz, kiedy nie pisać kodu.

Nigdy nie rozszerzaj celu swojego oprogramowania.

Gdy już wiesz, co jest istotne dla Twojego projektu, następnym razem będziesz świadomy w ocenie możliwych żądań kodu. Dokładnie poznasz swoje wymagania dotyczące pisania kodu. Która funkcja powinna zostać zaimplementowana? Który kod warto napisać? Będziesz kwestionować wszystko, ponieważ będziesz wiedział dokładnie, jak niepotrzebny kod może zabić Twój projekt.

Wiedząc kiedy nie kodować, utrzymujesz małą bazę kodu.

Sztuka pisania czytelnego kodu

Podczas uruchamiania projektu są tylko dwa lub trzy pliki źródłowe. Wszystko jest przejrzyste. Kompilacja i uruchomienie kodu zajmuje tylko kilka sekund. Wiesz, gdzie znaleźć dokładnie to, czego szukasz.

Następnie w miarę rozwoju projektu, coraz więcej plików źródłowych zbiera się w katalogu. Każdy plik kodu zawiera setki linii kodu. Aby to wszystko ogarnąć, będziesz wkrótce potrzebować wielu katalogów. Zapamiętywanie, które funkcje wywołują inne funkcje, jest trudniejsze, a śledzenie błędów wymaga nieco więcej pracy. Zarządzanie projektem staje się trudne i wymaga większej ilości programistów do pomocy. Koszty ogólne komunikacji rosną wraz ze wzrostem liczby osób na projekcie. Pracujesz wolniej i wolniej.

W końcu projekt staje się ogromny. Dodawanie nowych funkcji jest bolesne. Nawet małe zmiany wymagają godzin. Naprawianie obecnych błędów zawsze wprowadza nowe błędy. Zaczyna brakować terminów.

Raptem życie staje się walką. Jak to się stało?

Ponieważ nie wiedziałeś, kiedy nie kodować, powiedziałeś TAK na każde możliwe żądanie funkcji. Byłeś ślepy. Kodowanie czegoś nowego spowodowało, że zignorowałeś istotne fakty.

Oto, co się stanie, jeśli będziesz mówić na wszystko TAK. Wyeliminuj cały niepotrzebny kod ze swojego projektu.

Jednym z moich najbardziej produktywnych dni było wyrzucenie 1000 linii kodu. - Ken Thompson

Wiem, że wiedza, kiedy nie kodować, jest bardzo trudna. Nawet dla starszych programistów. Być może to, co napisałem w tym artykule, jest trudne do zrozumienia dla młodszych programistów.

Jeśli niedawno rozpocząłeś swoją podróż programistyczną i chcesz pisać kod, musisz być podekscytowany. To jest dobre uczucie. Nigdy nie trać tego podniecenia, ale też nigdy nie ignoruj ​​ważnych faktów. Poznasz je, popełniając własne błędy. Tak, będziesz je popełniać, ale będziesz się na nich uczył. Już teraz możesz stać się trochę bardziej świadomy, jeśli wyciągniesz wnioski z moich doświadczeń.