Cześć!

Każdy z nas ma w sobie pokłady kreatywności. Ja od zawsze lubiłem rysować, lubiłem robić efektowne zagrania w piłce nożnej, do dzisiaj grywam na gitarze, klepię newslettery do Ciebie. W żadnej z tych rzeczy nie jestem byłem wybitny, ale każda z tych form sprawiała mi przyjemność. Nie trzeba być w czymś świetnym, żeby być kreatywnym. Ma to plusy i minusy.

Dajmy na to programowanie. Swego czasu uważałem programowanie za sztukę. Do dzisiaj pamiętam kilka moich tyrad na ten temat, którymi zanudziłem kolegów przy piwie. Dobre ułożenie klas, zasady SOLID, DRY, te sprawy. Na szczęście nie wpadłem w skrajność by dać sobie rękę pokroić za spacje albo taby. Ludzie potrafią naprawdę długo dyskutować o tym czy powinno się zrobić wcięcia z dwoma spacjami czy czterema. Albo czy np. klamry w tej linii co if czy w innej. Czy używać dynamicznej zmiennej var czy ściśle otypowanej. Każdy język ma swoje konwencje, ba! Każdy programista ma swoje zdanie na ten temat i nie zawaha się go użyć!

Z biegiem lat dochodzę coraz bardziej do wniosku, że nasz zawód to jest tylko i aż rzemieślnictwo. Jesteśmy ludźmi, którzy mają wykonać swoją robotę tak aby klient był zadowolony. Czy to nam coś ujmuje? Bynajmniej. Czy oczekujemy kreatywności od mechanika samochodowego, albo spawacza? Kreatywność majstrów budowlanych, albo hydraulicznych przejściówek śni się wielu z nas po nocach.

Wydaje mi się, że spora część tej naszej kreatywności wynika wprost z tego dysonansu pomiędzy naszym wyobrażeniem o sobie a tym co faktycznie robimy. Nasze projekty nie są zwykle wielce unikalne albo szalenie ambitne. Stąd też i m.in. nasze kombinowanie w doborze technologii, w formatowaniu, w dyskusjach czy taka czy śmaka konwencja.

Ja sam jestem perfekcjonistą. Tato i Dziadek wbijali mi w głowę “albo rób coś porządnie, albo w ogóle”. Na pierwszy rzut oka jest to dobre podejście, na drugi ma w sobie coś z klątwy. Dlatego w pełni rozumiem osoby, którym zbędny enter w oczy kole. Nic mnie nie irytuje tak jak lenistwo i niechlujstwo. Gdy robię PR, to od razu rzucają mi się w oko zbędne spacje, nadmiarowe else ify i zbędne typowania.

Można powiedziec, że się czepiam. Będzie to pewnie racja, ale jest też druga strona medalu. Uważam, że niechlujstwo w takich prostych tematach jest brakiem szacunku dla współpracowników. Jeżeli każdy programista zacznie sobie wprowadzać sobie swoje konwencje to robi się po prostu patchwork, a nie kod źródłowy. Nie ma czegoś takiego jak kilka konwencji - albo jest jedna, albo nie ma jej w ogóle.

Poza walorem estetycznym, ma to jednak negatywne przełożenie na czas, a co za tym idzie pieniądz.

Kod, w którym każdy plik jest inny jest dużo trudniej przyswajalny. Większość z nas to wzrokowcy. Patrząc na coś podświadomie szukamy wzorów z tym co znamy. Jeżeli kod jest pisany jednolicie, to zaczyna być dla nas przezroczysty. Nie zastanawiamy się czemu ktoś to tak napisał albo inaczej. Po prostu patrzymy na niego i możem się skupić na zrozumieniu logiki, którą sobie reprezentuje.

Ma to znaczenie nie tylko gdy piszemy kod, ale też gdy robimy code review. Myślę, że możesz przywołać sobie dyskusje z review i komentarze typu “a czemu ta klamra jest tutaj?”, “a czemu nie dasz tutaj var?”, “a tutaj czemu nie sprawdzasz nulla?”. Często te spory są najbardziej zagorzałe i zupełnie nijak się mają do sedna sprawdzanych zmian. Obydwie strony tracą cenny czas, a przede wszystkim energię.

Co ciekawe nie tylko my ludzie, ale też i automaty lepiej radzą sobie z wzorcami. Narzędzia do diffów pokażą dużo lepiej różnice jeśli kod jest sformatowany wg tych samych reguł.

Kiedyś wprowadzenie tego było trudne. Skonfigurowanie narzędzi do statycznej analizy kodu to była droga przez mękę. Zwykle był jakieś narzędzie typu Sonar, które się odpalało raz na jakiś czas i potem próbowało się zrobić zalecenia jeśli był czas. Zwykle nie było. Dzisiaj praktycznie każdy język i IDE wspiera pliki .editorconfig gdzie można zdefiniować sobie reguły kodu źródłowego. Dodatkowo takie narzędzia jak ESlint, Prettier w JavaScript, analizatory kody w .NET, itd. itp. pozwalają na zautomatyzowanie tego procesu. Możemy teraz przy każdej zapisie zrobić autoformatowanie, sprawdzić reguły itd.

Ja jestem zdania, że jeśli wprowadzamy jakąś regułę i zasadę w projekcie, to musi być ona weryfikowalna. Nie może być tak, że coś ustalamy, a potem nie sprawdzamy czy faktycznie robimy tak jak się umówiliśmy. Nie ma nic gorszego długofalowo dla kultury organizacyjnej niż zasady, które są ustalane, żeby je łamać. Z tym, że powinniśmy robić realne ustalenia. Bardzo nie lubię podejścia “programista musi to wiedzieć i o tym pamiętać”. Jeśli tak myślimy to możemy mieć 100% pewności, że regularnie będzie zapominać. Jesli mamy w zespole 10 osób to najprawdopodobniej statystycznie codziennie ktoś o czymś zapomni. Dlatego procesty trzeba automatyzować.

Gdy w poprzednim projekcie zabiegałem o użycie Lintera i Prettiera spotkałem na początku duży opór. Artyści chcieli się wykazywać w tym jak postawią enter. Jednak repozytorium po repozytorium cierpliwa kropla wydrążyła skałę. W pewnym momencie nawet najbardziej zagorzali przeciwnicy zaczęli sami z siebie to dorzucać do swoich repo. Potem skończyło się dużo przepychanek na code review i niepotrzebnych dyskusji. To po prostu działa.

Oczywiście lintery to nie tylko ładny kod. Statyczna analiza kodu to coś co pozwala też unikać błędu, zmniejsza liczbę potrzebnych testów. Wychwytuje rzeczy, które łatwo przeoczyć. Brylowały w tym od zawsze IDE i pluginy od JetBrains (np. ReSharper).

Jeśli chcesz zobaczyć jak można to skonfigurować np. w TS to zapraszam do mojego repo: https://github.com/oskardudycz/EventSourcing.NodeJS. Możesz też zerknąć na reguły w kodzie w EventStore - https://github.com/EventStore/EventStore/blob/master/src/.editorconfig.

Naprawdę polecam ustalić sobie jakiś zestaw reguł. Najpierw postawić na kompromis, potem można ustalać kolejne bardziej kontrowersyjne reguły. To co też polecam to nie wdrażać zmian formatujących razem ze zmianami logiki biznesowej. Zróbmy osobnego PRa z poprawkami. Jak mówi Kent Beck “Make the change easy, make the easy change”. Gdy powiemy, że tutaj nic nie zmieniliśmy tylko linter i formatowanie to dużo łatwiej, żeby taki PR przeszedł w skończonym czasie

Jakie jest Twoje podejście w tym temacie?

Pozdrawiam Oskar

P.S. W zeszłym tygodniu opisałem moje przemyślenia o tym jak pieniądz w chmurze wpływa na architekturę https://event-driven.io/pl/how_money_in_cloud_impacts_architectural_decisions/.

P.S.2 Usprawniłem też moje repo z NodeJS i TS o konfigurację testów jednostkowych, akceptacyjnych API, CI oraz debug w VSCode - https://github.com/oskardudycz/EventSourcing.NodeJS#unit-tests-with-jest

A oprócz tego jak co tydzień nowe Architecture Weekly: https://github.com/oskardudycz/ArchitectureWeekly#22nd-march-2021