Sztuka wojny stosowana w tworzeniu oprogramowania

Jeśli pracujesz w branży oprogramowania, prawdopodobnie słyszałeś o paradygmacie projektowania dziel i zwyciężaj , który zasadniczo polega na rekursywnym dzieleniu problemu na dwa lub więcej podproblemów ( dziel ), aż staną się one na tyle proste, że można je rozwiązać bezpośrednio ( podbić ).

Być może nie wiesz, że ten paradygmat wywodzi się ze starej strategii politycznej (nazwa pochodzi od łacińskiego powiedzenia „ dziel i impera ”), która sugeruje, że możliwe jest utrzymanie kontroli nad podwładnymi lub poddanymi poprzez zachęcanie do niezgody między nimi.

Strategia ta była stosowana przez niezliczonych polityków i przywódców wojskowych na przestrzeni dziejów, takich jak Juliusz Cezar (który używał jej podczas wojen galijskich do pokonania silnych militarnie Galów) i Napoleon (francuski ekspert od artylerii podzieliłby wrogie wojska, aby żadna część nie była silniejsza niż jego własne wojska, a następnie zakłócać ich komunikację, utrudniając wrogiemu wysiłkom koordynację i przeprowadzanie ataków).

Sztuka wojny: starożytne zasady stosowane w rozwoju

Jednak zasada dziel i rządź nie jest jedyną strategią polityczną, którą można zastosować do tworzenia oprogramowania. Chociaż polityka i działania wojenne mają niewiele wspólnego z tworzeniem oprogramowania, podobnie jak politycy i generałowie, programiści muszą kierować podwładnymi, koordynować wysiłki między zespołami, znajdować najlepsze strategie rozwiązywania problemów i administrować zasobami.

Sztuka wojny to starożytny traktat wojskowy napisany w V wieku pne i przypisywany Sun Tzu, starożytnemu chińskiemu strategowi wojskowemu, którego teorie wywarły głęboki wpływ zarówno na filozofię Wschodu, jak i Zachodu.

Pomimo swojego wieku tekst nadal znajduje się w programie nauczania w wielu szkołach wojskowych w Azji Wschodniej i jest wymieniany jako lektura zalecana w niektórych akademiach wojskowych na Zachodzie. Tekst podzielony jest na 13 rozdziałów, z których każdy poświęcony jest innemu aspektowi działań wojennych.

Jednak oprócz działań wojennych zasady i nauki Sun Tzu mają praktyczne zastosowanie w polityce, biznesie, sporcie i, wierzcie lub nie, w tworzeniu oprogramowania. W rzeczywistości możesz po prostu stosować niektóre z tych zasad w swojej codziennej rutynie, nawet nie znając ich pochodzenia.

Szczegółowo poniżej znajdziesz krótką listę podstawowych taktyk i wskazówek wyjaśnionych w Art of War. Prawdopodobnie można je zastosować w swojej pracy w branży oprogramowania lub w wielu innych branżach.

Czas jest kluczowy w każdej kampanii

Rozdział II, paragraf 2

Kiedy zaangażujesz się w rzeczywistą walkę, jeśli zwycięstwo nadejdzie długo, wtedy broń mężczyzn stępi się, a ich zapał osłabnie.

Zasadę tę można zastosować do tworzenia oprogramowania, z reguły opisując związek między długością cykli rozwojowych a morale programisty.

Jeśli grupa programistów pracuje przez kilka miesięcy nad tymi samymi projektami, bez jasnych celów i nie widać końca, mogą się popaść w frustrację, a ich produktywność może spaść.

Tworzenie oprogramowania jest przedsięwzięciem intelektualnym, więc motywacja jest głównym paliwem zwiększającym produktywność. Codzienna praca bez dostrzegania, że ​​Twoja praca przynosi realne rezultaty, może być bardzo demotywująca.

Jak wskazano w niektórych metodykach zwinnych, plan rozwoju powinien być podzielony na kilka celów i kamieni milowych, które zespół może osiągnąć w krótkich ramach czasowych i które dadzą im poczucie postępu i osiągnięć.

Rozdział II, paragraf 18

Na wojnie niech waszym wielkim celem będzie zwycięstwo, a nie długie kampanie.

To zdanie można interpretować na dwa sposoby:

Po pierwsze, może być postrzegany jako prekursor filozofii UNIX: pisz programy, które robią jedną rzecz i robią to dobrze . Tworząc oprogramowanie, należy zawsze pamiętać o głównym celu programu, kluczowej funkcji, którą zapewnia, lub największym problemie, który rozwiązuje, i zapewnić prawidłową implementację.

Czasami możesz się zainspirować i wymyślić naprawdę fajną funkcję do dodania, ale nie zapominaj, że aplikacje, które mają wiele rzadko używanych funkcji, mają lekceważącą nazwę: bloatware .

Po drugie, stwierdzenie może być również uważane za prekursora jednej z zasad szczupłego tworzenia oprogramowania: Dostarczaj tak szybko, jak to możliwe .

Im szybciej dostarczysz oprogramowanie bez większych wad, tym szybciej otrzymasz informację zwrotną od klienta i będziesz mógł wprowadzić zmiany do kolejnej iteracji.

Z drugiej strony, jeśli dostarczysz niedziałające oprogramowanie, stracisz cenne informacje zwrotne, ponieważ klienci nie będą mieli szansy na jego prawidłowe przetestowanie. To sprawi, że kolejny etap rozwoju będzie trudniejszy lub niemożliwy w sytuacjach, w których kolejna iteracja zależy od opinii klientów.

Bez przywództwa, bez wyników

Rozdział III, paragraf 11

Teraz generał jest bastionem państwa; jeśli bastion będzie kompletny we wszystkich punktach, państwo będzie silne; jeśli przedmurze jest wadliwe, państwo będzie słabe.

Ten cytat opisuje znaczenie roli menedżera w zespole deweloperskim: sukces projektu zależy od siły wszystkich zaangażowanych osób , a menedżer jest ostoją projektu. Odpowiedzialność zaczyna się na górze.

Mimo że programiści często pracują sami (każdy siedzi za komputerem, z ograniczoną komunikacją ze współpracownikami), nie oznacza to, że nie potrzebują dobrego przywództwa. Kierownicy projektów są odpowiedzialni za utrzymanie zespołu na dobrej drodze, zapewnienie skutecznej komunikacji i rozwiązywania sporów, a liderzy oczywiście określają priorytety projektu (m.in. zadania), więc ich rola nie powinna być lekceważona. Ani ich odpowiedzialność, jeśli coś pójdzie nie tak. Wyobraź sobie, co by się stało z dowódcą wojskowym, którego jednostka nie wypełniła swoich obowiązków na polu bitwy?

Zespół może tworzyć świetne oprogramowanie, nawet jeśli ma kilka złych jabłek na stanowiskach programistycznych, ale jest to mało prawdopodobne, jeśli kierownik projektu jest złym jabłkiem , bez względu na to, ilu programistów rockstar ma zespół.

Rozdział VI, paragraf 28

Nie powtarzaj taktyki, która przyniosła ci jedno zwycięstwo, ale pozwól, aby twoje metody były regulowane przez nieskończoną różnorodność okoliczności.

Czasami, rozpoczynając projekt, kuszące jest wykorzystanie tego samego zestawu technologii, które zastosowaliśmy we wcześniej udanych projektach (ten sam język programowania, te same biblioteki, ten sam serwer itp.). Jednak o ile wymagania nowych projektów nie są dokładnie takie same jak w poprzednich, może to być błędne podejście.

W programowaniu, jak w większości dziedzin, nie istnieje panaceum (domniemane lekarstwo zdolne do leczenia wszystkich chorób). Nie ma jednej kombinacji technologii, których można użyć do rozwiązania wszystkich problemów; każda technologia ma swoje zalety i wady.

Oczywiście nauka nowego języka programowania lub korzystanie z nieznanego interfejsu API może początkowo być kosztowne, ale w dłuższej perspektywie jakość oprogramowania będzie lepsza i staniesz się lepszym programistą.

Rozdział XIII, paragraf 27

Dlatego tylko oświecony władca i mądry generał użyje najwyższej inteligencji armii do celów szpiegowskich i dzięki temu osiągają wspaniałe rezultaty. Szpiedzy są najważniejszym elementem wojny, ponieważ od nich zależy zdolność poruszania się armii.

Ta fraza może być interpretowana jako znaczenie korzystania z narzędzi monitorujących i bibliotek rejestrujących w fazie konserwacji.

Chociaż czasami klienci mogą tak nie myśleć, rozwój nie kończy się, gdy otrzymasz stabilne i w pełni przetestowane wydanie. Oprogramowanie nieustannie ewoluuje, naprawiając błędy, dodając nowe funkcje lub poprawiając wydajność.

A nie ma lepszego źródła informacji, aby wiedzieć, jakie zmiany należy wprowadzić, niż posiadanie szpiegów monitorujących oprogramowanie w środowiskach produkcyjnych, sprawdzających, które funkcje są najczęściej używane, najczęstsze błędy i najdłuższe operacje.

Raporty o błędach, wpisy do rejestrowania i dane dotyczące użytkowania mają fundamentalne znaczenie dla wykrywania błędów, identyfikowania wąskich gardeł i innych problemów, ponieważ nie zawsze jest możliwe odtworzenie tych samych warunków w kontrolowanych środowiskach testowych.

Praca zespołowa i motywacja

Rozdział X, paragraf 24

Ten, który awansuje bez szukania sławy, Który wycofuje się nie uciekając od winy, Ten, którego jedynym celem jest ochrona swego ludu i służenie swemu panu, Ten człowiek jest klejnotem Królestwa.

Zasadniczo jest to starożytna chińska wersja „nie ma ja w zespole” . Ważniejsza jest współpraca z innymi niż dążenie do osobistych korzyści.

Tworzenie oprogramowania to złożona czynność, która wymaga od programistów efektywnej pracy zespołowej. Dobry programista to nie ten, który naprawia najwięcej błędów, wdraża najwięcej funkcji lub kończy zadania przed terminem; dobry programista to ten, który pomaga zespołowi osiągnąć jego cele.

Żądanie uznania za wszystko, co zrobiłeś, nierozpoznawanie swoich błędów lub obwinianie za nie innych lub nazywanie siebie ninja kodu może oszukać niektórych niedoświadczonych menedżerów i może nawet dać ci podwyżkę, ale staniesz się nieproduktywnym członkiem swojego zespołu.

Rozdział VII, paragraf 21

Zastanów się i zastanów, zanim wykonasz ruch.

To zdanie wskazuje na znaczenie spotkań rozwojowych zespołu, takich jak te proponowane przez metodyki zwinne.

Podczas pracy w zespole ważne jest omówienie wszelkich większych zmian przed ich wdrożeniem. Nie ma znaczenia, czy jesteś liderem zespołu, czy osobą z największym doświadczeniem w temacie, zawsze powinieneś porozmawiać lub przynajmniej poinformować resztę zespołu.

Pamiętaj, że inni programiści mogą dać ci wgląd w nieznane części oprogramowania. Oznacza to, że mogliby rozpocząć wdrażanie zmian szybciej niż oczekiwano, ponieważ mogliby być w pełni świadomi skutków tych zmian.

Rozdział X, paragraf 25

Traktuj swoich żołnierzy jak dzieci, a pójdą za tobą w najgłębsze doliny; patrz na nich jak na swoich własnych umiłowanych synów, a staną przy tobie aż do śmierci.

Ten cytat wskazuje na znaczenie motywacji, zasady zarządzania, o której czasami zapominają menedżerowie i liderzy zespołów. Zmotywowani programiści będą pisać lepszy kod, pracować szybciej, popełniać mniej błędów i chętniej poświęcać dodatkowe godziny.

Motywację muszą generować menedżerowie, szczerze interesując się podwładnymi, słuchając ich, dbając o równowagę między pracą a życiem prywatnym, budując pozytywne środowiska pracy i dbając o ich ścieżki kariery.

Nie należy też mylić motywacji z wynagrodzeniem. Ostatnie badania pokazują, że pieniądze nie motywują większości pracowników, pieniądze są w większości dobre w przyciąganiu i zatrzymywaniu pracowników, ale nie w uszczęśliwianiu ich z pracy. Dlatego podwyżki i awanse nie powinny być postrzegane jako narzędzia motywacyjne.

Myśleć poza szablonowo

Rozdział V, paragrafy 7, 8 i 9

Nut jest nie więcej niż pięć, ale kombinacje tych pięciu dają początek większej liczbie melodii, niż kiedykolwiek można usłyszeć.

Istnieje nie więcej niż pięć podstawowych kolorów, ale w połączeniu dają więcej odcieni niż kiedykolwiek można zobaczyć.

Istnieje nie więcej niż pięć kardynalnych smaków, ale ich kombinacje dają więcej smaków, niż kiedykolwiek można skosztować.

Jedną z dobrych rzeczy w programowaniu jest to, że możliwości są nieograniczone; możesz rozwijać się w zasadzie gdziekolwiek chcesz (przynajmniej tak długo, jak nie jest to problem NP-zupełny).

Aplikacje mobilne, strony internetowe, gry, aplikacje desktopowe… jeśli znasz się na programowaniu, wszystkie są w Twoim zasięgu.

Rozdział III, paragraf 1

W praktycznej sztuce wojennej najlepszą rzeczą jest zabranie kraju wroga w całości i nietkniętego; rozbić i zniszczyć to nie jest tak dobre. Więc też lepiej jest zdobyć całą armię niż ją zniszczyć, zdobyć cały pułk, oddział lub kompanię, niż je zniszczyć.

Podczas pracy nad projektem z dużą bazą kodu często można znaleźć moduły lub sekcje kodu, które zostały zaimplementowane przy użyciu złych praktyk lub przy użyciu przestarzałych bibliotek. Chociaż może być kuszące, aby usunąć (lub zniszczyć) ten kod, może nie być najlepszym pomysłem z kilku powodów:

• Starszy kod niekoniecznie jest zły, czasami jest to dobry kod, który został napisany, gdy inne metodologie i technologie były rozważane. Jednak to, że jest stare, nie oznacza, że ​​nie działa.

• Możesz stracić czas na naprawę kodu, który nadal działa, zamiast skupiać się na naprawianiu innych, bardziej krytycznych części kodu.

• Jeśli nie jesteś naprawdę pewien tego, co robisz, zastąpienie działającej sekcji kodu oznacza, że ​​ryzykujesz wprowadzeniem nowych błędów lub błędów.

Nie oznacza to, że zdanie „Jeśli nie jest zepsute, nie naprawiaj” jest dobrą strategią, ale że każdy projekt ma priorytety, cele i ograniczenia czasowe. Jeśli więc znajdziesz kod, który można poprawić, omów go z resztą zespołu lub kierownikiem projektu, aby dowiedzieć się, kiedy go zoptymalizować.

Rozdział VIII, paragraf 3

Są drogi, których nie wolno chodzić, armie, których nie wolno atakować, miasta, których nie wolno oblegać, pozycje, których nie można kwestionować, rozkazy władcy, których nie wolno słuchać.

Nawet jeśli nie mówi tego wprost, moglibyśmy zinterpretować tę zasadę jako przestrogę, by unikać antywzorców.

Chociaż użycie antywzorca może rozwiązać krótkoterminowy problem, należy pamiętać, że w dłuższej perspektywie przyniesie to efekt przeciwny do zamierzonego. Tak więc, bez względu na to, ile czasu zaoszczędzisz, ile błędów naprawisz lub jak jest to dla Ciebie wygodne, unikaj ich.

Mimo to czasami możesz ulec pokusie użycia antywzorca, aby rozwiązać pilne zadanie, obiecując sobie, że zaimplementujesz odpowiednią poprawkę, gdy będziesz miał więcej czasu, ale pamiętaj o jednym z praw Murphy'ego: wszystkie szybkie poprawki stają się trwałymi zmianami.

Wniosek

Chociaż tworzenie oprogramowania różni się od dowodzenia żołnierzami na wojnie lub dowodzenia krajem, wszystko to musi rozwiązywać problemy wymagające pracy zespołowej, dobrego przywództwa, wydajności i długoterminowych rozwiązań.

Jednak Art of War nie jest jedyną książką, która zawiera zasady, które można zastosować do tworzenia oprogramowania. Przykładem jest Książę Niccolo Machiavelliego.

Oto lista cytatów z Machiavelli, które wciąż są aktualne. Spróbuj zgadnąć, jakie są odpowiednie zasady w świecie tworzenia oprogramowania.

1. Lew nie może uchronić się przed pułapkami, a lis nie może obronić się przed wilkami. Trzeba więc być lisem, by rozpoznać pułapki, a lwem, by straszyć wilki.
2. Nigdy nie próbuj wygrać na siłę tego, co można wygrać przez oszustwo.
3. Nigdy nie osiągnięto niczego wielkiego bez niebezpieczeństwa.
4. Kto pragnie nieustannych sukcesów, musi z czasem zmieniać swoje postępowanie.
5. Mężczyźni na ogół oceniają bardziej na podstawie pozorów niż rzeczywistości. Wszyscy mężczyźni mają oczy, ale niewielu ma dar penetracji.
6. Kto chce być posłuszny, musi umieć rozkazywać.
7. Mądrość polega na tym, że umiemy rozróżnić naturę kłopotów i wybrać mniejsze zło.
8. Nie da się uniknąć wojny; można go odłożyć tylko na korzyść wroga.
9. Natura tworzy niewielu odważnych ludzi; przemysł i szkolenia sprawiają, że wiele.