"Istnieją dwa trudne problemy w informatyce: unieważnianie pamięci podręcznej, nazywanie rzeczy i błędy off-by-one".- Leon Bambrick

W 1986 roku, architekt komputerowy Fred Brooks opublikował pracę zatytułowaną "No Silver Bullet", w której zauważył, że inżynieria oprogramowania nie przynosiła takiego samego wzrostu produktywności w porównaniu z inżynierią sprzętu.

Brooks dowodził, że jeśli chodzi o tworzenie oprogramowania, istnieją dwie główne bariery do pokonania: przypadkowa złożoność i zasadnicza złożoność.

Przypadkowa złożoność odnosi się do wyzwań, które programiści nieumyślnie stawiają sobie w wyniku prób rozwiązania problemu. (Na szczęście, ten rodzaj złożoności może być również naprawiony lub ulepszony przez programistów).

Istotna złożoność jest po prostu naturą bestii, którą próbujesz oswoić. Przykład, którego używa Brooks jest taki, że jeśli użytkownicy potrzebują programu do zrobienia 30 rzeczy, to te 30 rzeczy jest niezbędnych; nie można po prostu usunąć kilku z nich, aby uczynić oprogramowanie mniej złożonym. Kiedykolwiek rozwiązujesz problem, są pewne obszary złożoności, których nie da się zredukować.

Podczas gdy Brooks odnosił się do złożoności i tego, jak wiąże się ona z tworzeniem i zmianą kodu, dotyczy to również produktu końcowego.

Prognozowanie sprzedaży, ważenie prawdopodobieństwa zamknięcia przewodów w rurociągu i analizowanie zachowania swojego lejka są niezbędne do CRM. Z drugiej strony, trudne do odczytania wykresy, matematyka umysłowa lub raporty, które nie są natychmiast aktualizowane w czasie rzeczywistym są przykładami przypadkowej złożoności.

Kiedy myślę o oprogramowaniu, które tworzymy, często zadaję sobie pytanie: Jak wiele z niego jest niezbędne do rozwiązania problemu, który próbujemy rozwiązać, i jak możemy usunąć wszelką przypadkową złożoność? Jak można uniknąć wszelkich przeszkód związanych z pisaniem oprogramowania i jego użytkowaniem?

Twój kod to twoja organizacja

Prawo Conwaya stwierdza, że "Każda organizacja, która projektuje system, wyprodukuje projekt, którego struktura jest kopią struktury komunikacyjnej organizacji." Innymi słowy, kod oprogramowania, który piszesz, będzie w zasadzie odzwierciedlał to, jak zorganizowana jest twoja firma.

programowanie

Powtarzam to tak często, że mój zespół ma już pewnie dość słuchania tego, ale wierzę, że stworzenie odpowiedniego środowiska organizacyjnego jest jedną z najważniejszych rzeczy, jakie możesz zrobić, aby tworzyć efektywny kod.

Dla mnie sprowadza się to do tego, aby zespół był bardziej płaski i otwarty, aby nie było żadnych barier w rozmowach z innymi członkami zespołu, czy też w aktualizowaniu i poprawianiu kodu. Ostatecznie celem jest zwiększenie szybkości, zredukowanie silosów wiedzy i ulepszenie produktu końcowego.

Wyzwanie, przed którym stoją wielkie firmy, takie jak Google czy Facebook, polega na tym, że mają one wszystkie te zespoły - czasami nawet konkurujące ze sobą w ramach tego samego produktu - z różnymi poziomami biurokracji, procesów i trudniejszymi kanałami komunikacji.

Wiąże się to z kompromisami, ponieważ wartość i skala tych produktów jest bezkonkurencyjna, ale złożoność ma swoje koszty, a izolowanie od niej architektury jest poważnym wyzwaniem dla zespołów programistycznych.

Nie ma miejsca dla bohaterów

Innym sposobem na zmniejszenie przypadkowej złożoności jest ograniczenie liczby "bohaterów zespołu" tak bardzo, jak to tylko możliwe.

Czasami w zespole znajdzie się jedna gwiazda rocka, która, gdy coś się zepsuje, mówi: "Nieważne, po prostu to naprawię". Jest to powszechna dynamika w wielu zespołach programistycznych, ale posiadanie takich kieszeni uwielbienia dla bohaterów może być bardzo szkodliwe dla dzielenia się wiedzą.

Może słyszałeś o "czynniku autobusowym" - jak duży wpływ na naszą firmę miałoby, gdyby tego gościa potrącił autobus? Można to odnieść do każdego działu w firmie, ale jest to szczególnie odczuwalne w dziale rozwoju oprogramowania. Ze względu na liczbę ruchomych elementów w rozwoju oprogramowania, ten bohater o wysokim współczynniku autobusowym może zostać niezauważony i nagle masz ukrytą pojedynczą zależność, która, jeśli zostanie utracona, wywoła niefortunne niespodzianki. To dopiero jest przypadkowa złożoność!

Na szczęście nie jesteśmy aż tak ryzykowni, ale jest to coś, czego staram się być świadomy. Dokonujemy przeglądów kodu, organizujemy lunch and learns i bazujemy na wypróbowanych i sprawdzonych technikach, starając się utrzymać stos technologiczny na przystępnym poziomie. Ponieważ zmniejszenie "czynnika autobusowego" to nie tylko natychmiastowe ograniczenie ryzyka, ale także poprawa wiedzy naszego zespołu, co prowadzi do lepszego produktu.

Potęga skupienia

Jest wiele taktycznych rzeczy, które możesz zrobić, aby uprościć i zredukować złożoność, od sposobu pisania kodu do sposobu jego wysyłania. Na przykład, lubimy wydawać rzeczy w małych, przyrostowych, iteracyjnych kawałkach, aby nie było dużego przejścia, które mogłoby spowodować wiele problemów, na które musielibyśmy zareagować.

Ale rzeczą, którą robimy, a która ma największy wpływ, jest po prostu zawężenie tego, co jest najważniejsze.

Jak zauważył Fred Brooks, zasadnicza złożoność powstaje, gdy użytkownik mówi, że jest 30 rzeczy, które oprogramowanie musi zrobić i nie ma sposobu, aby to obejść. Ale ja bym powiedział, no cóż, jak możemy skrócić listę do 30 funkcji, które są rzeczywiście niezbędne?

Jedną z naszych podstawowych wartości jest skupienie. W mojej roli oznacza to znalezienie najszerszego pokrycia istotnych rzeczy, które oprogramowanie musi zrobić i powiedzenie "nie" rzeczom, które są poza nim.

Nie możemy próbować realizować każdego pojedynczego żądania funkcji, które do nas przychodzą, ponieważ każdy marginalny wkład potencjalnie ma wykładniczy zasięg złożoności. Musisz mieć odwagę powiedzieć: "Cóż, po prostu nie zrobimy tego dla tego produktu".

Pomyśl o tym, jak byś wprowadzał firmę na rynek: Twoje komunikaty nie mają rezonować z absolutnie każdą istotą ludzką tam na zewnątrz - musisz wybrać rynki docelowe i persony, które najprawdopodobniej użyją i skorzystają z Twojego produktu.

W ten sam sposób patrzę na rozwój produktu. Musisz wybrać kilka person dla każdej funkcji, a to z natury oznacza, że będziesz musiał wykluczyć inne.

Zawężenie tego, co próbujesz zrobić, pozwoli Ci dopracować to, co istotne, i włożyć odpowiedni wysiłek w zmniejszenie złożoności. To nie jest tylko "miło mieć" w dobrym oprogramowaniu, to jest niezbędne.