Tworzenie nowych funkcji a może dokształcanie się? Nie, najwięcej czasu pochłania zrozumienie jak to działa.

Utrzymanie było czasochłonne od zawsze

Już w książce Zelkowitza, Shawa i Gannona z 1979 roku zatytułowanej Principles of software engineering and design stwierdzono, że większość czasu pracy programista poświęca na konserwację (67%). Inne wartości to:

• Testy jednostkowe – 8%
• Testy integracyjne – 7%
• Kodowanie – 7%
• Design – 5%
• Specyfikacja – 3%
• Określenie wymagań – 3%

To prawda, że książka nie określa, w jaki sposób uzyskano tę liczbę. Mimo to uznano to za na tyle ważny problem, że już w tamtych czasach przyciągnął znaczną uwagę badaczy.

Gdzie jesteśmy teraz, ponad 4 dekady później?

Spójrzmy na niedawny artykuł Xia, Bao, Lo, Xing, Hassan i Li zatytułowany Measuring Program Compression: A Large-Scale Field Study with Professionals i opublikowany w IEEE Transactions on Software Engineering, 44, 951-976, 2018. Artykuł jest interesujący ponieważ opisuje szczegółowo w jaki sposób uzyskuje się dane o tym w jaki sposób programiści spędzają czas. I mówi, że zrozumienie tego jak dany kod działa (comprehension) zajmowało średnio 58% czasu. Pozostałe rezultaty badania wyglądają tak:

• Nawigowanie po projekcie – 23,96%
• Edycja – 5,02%
• Pozostałe czynności – 13,40%

W szczególności spójrz na to, że nawigowanie to prawie 1/4 wysiłku a gdzie jeszcze zrozumienie! Po zsumowaniu obu wartości mamy ok. 72%. Tak więc po czterech dekadach możemy zaobserwować, że niewiele się zmieniło poza nauką mierzenia czasu zużywanego przez programistę.

Optymalizuj to co zajmuje najwięcej czasu

Cóż, wychodzi na to, że zrozumienie i utrzymanie systemu to największy pojedynczy wydatek, jaki mamy do poniesienia. Jeśli chcemy zoptymalizować cokolwiek w naszej dyscyplinie, powinniśmy najpierw przyjrzeć się tej części. Często rozmawiamy o tym, jak tworzymy systemy, ale jak często wymiana doświadczeń między deweloperami dotyczy tego jak spędzasz czas na „zastanawianiu się”? Jeśli o tym nie rozmawiamy, to pewnie nie jest to optymalizowane bo np. nie wiemy jak sobie z tym radzić albo radzimy sobie samodzielnie, bez sięgania po doświadczenia innych.

Dlaczego programiści czytają kod?

Ponieważ chcą zorientować się w sytuacji na tyle, aby wiedzieć, co robić dalej. Intencja jest ważna. To jest podejmowanie decyzji. Z tej perspektywy czytanie jest tylko środkiem, za pomocą którego informacje są gromadzone z danych. Jest to również najbardziej ręczny (niezautomatyzowany) sposób, aby to zrobić, więc stwarza nam to sporą okazję do optymalizacji.

Może więc sięgnąć po tzw. rozwój formowalny? Czytanie nie skaluje się a oprogramowanie jest już samo w sobie wystarczająco trudne. Brak wiedzy o obecnym systemie nie powinien być dopuszczalną zmienną w równaniu. Kiedy zaakceptujemy, że systemy są danymi, staje się oczywiste, że powinniśmy podchodzić do tego jak do danych. Nauka o danych mówi nam, że najpierw zaczynasz od problemu, a następnie wnioskujesz za pomocą narzędzia dopasowanego do kontekstu.

Ponieważ oprogramowanie jest wysoce kontekstualne, nie możemy przewidzieć konkretnych problemów. Możemy tylko przewidzieć klasy problemów. Aby sobie z tym poradzić, kluczową ideą rozwoju formowalnego jest to, że narzędzie powinno być formowalne po poznaniu problemu. W ten sposób poradzi sobie z tym, co ważne w kontekście problemu. Wtedy ograniczymy konieczność czytania rzeczy, które – jak się potem okazuje – nie były potrzebne do rozwiązania problemu. Przykładem takiego „formowalnego” środowiska programistycznego jest Glamorous Toolkit, umożliwiający tworzenie niestandardowych narzędzi dla systemów oprogramowania.

Może więc powinniśmy zacząć od zastanowienia się nad tym, jak nie czytać kodu, którego nie musimy zrozumieć do rozwiązania problemu? Zainteresował Cię temat? To zerknij jeszcze tutaj.