Sytuacja kobiet w IT w 2024 roku
2.05.20203 min
Jakub Gutkowski

Jakub GutkowskiPrincipal Software Engineer / blog.gutek.pl

Pisz kod tak, jakbyś miał go wspierać do końca życia

Twój genialny projekt może mieć znikomą wartość dla firmy/klienta - czyli o tym, dlaczego warto stawiać na sprawdzone rozwiązania częściej, niż na te najmodniejsze.

Pisz kod tak, jakbyś miał go wspierać do końca życia

Dostałeś nowy projekt do rąk i aż nie możesz się doczekać, by się za niego zabrać. Rączki świerzbią, głowa pełna pomysłów, nic tylko JUŻ teraz zacząć pisać! To uczucie… czy to będzie projekt dla firmy, czy to domowa zabawa, czy też hackowanie. Tak naprawdę gdyby nie to, że jest już 23:00 to byś się za to zabrał TERAZ.

Pomysły przewalają Ci się przez głowę. To zrobię tak! A tamto tak! W końcu wyżyjesz się technologicznie. Zrobisz coś, czego jeszcze nikt nie zrobił, a do tego będziesz się świetnie bawił. Już widzisz te blog posty, które powstaną - opisujące Twoje doświadczenia (chwała i w ogóle).  Zabierasz się za pisanie i idziesz jak burza:

  • Tutaj automatycznie generujesz kontrolki Windows Forms
  • Przy okazji hakujesz zasoby, by apka była wielojęzyczna
  • Tam rozwiązujesz problem poprzez internal messaging
  • Odkrywasz ukrytą metodę, którą wykorzystujesz, by zapisać plik, który jest automatycznie wczytywany i wykonywany przez GO 
  • Zamiast zwykłej bazy bierzesz graph DB
  • Do podpytań danych używasz GraphQL
  • Do tego wszystko łączysz z OpenCV...
  • ... a uwierzytelnianie wywalasz do Auth0


Zrobiłeś coś niesamowitego! Czyste arcydzieło. Aplikacja z kilkoma mikroserwisami, dwoma funkcjami serverless, z zarządzana na starszych systemach przez Windows Forms, na nowszych przez web. Czujesz dumę z tego, co zrobiłeś - i DOBRZE. Dawno się tak nie wyżyłeś i w końcu możesz zająć się normalną pracą.

Tylko, że… stworzyłeś coś tak niesamowitego i fajnego, że jesteś jedyną osobą, która to może wspierać. Nikt nie ma czasu na to, by teraz siedzieć i uczyć się dwudziestu technologii. Pół biedy - wykorzystałeś jakieś wersje alpha, które już teraz są nieaktualne, a nowsze wersje zawierają breaking changes. Firma nie chce przeszkolić ludzi, bo woli ich wrzucić do innego projektu.

Stworzyłeś coś niesamowitego, ale jesteś z tym teraz sam. Jak sądzisz, jak długo taki projekt pożyje? Miesiąc? Dwa? Rok? U mnie żyje już dwa lata, ale wszyscy wiedzą, że powinien być ubity. Sytuacja była ciut inna, bo miał to być niby PoC, ale… no właśnie. PoC poszedł na produkcję. I to się zdarza.

By uniknąć takich sytuacji trzeba zawsze pisać kod tak, jakby miałby być on rozwijany przez osobę trzecią i zrozumiały przynajmniej przez osobę średniozaawansowaną. Jest to ciężkie i nie pozwala na wykorzystanie wszystkiego, co byś chciał. Ale dzięki temu stworzysz kod dużo bardziej przejrzysty, czytelniejszy i dokładniej określający swoją intencję. Nie będziesz stosował skrótów i hacków, które tylko Ty rozumiesz. Nie użyjesz też bibliotek, które nie są stabilne.

Na końcu skończysz z bardzo podobnie działającym projektem z podobnym, ale nie z tym samym stosem technologicznym. Jednak z projektem, który będzie mógł być wspierany i rozwijany. Co też znaczy - z projektem o dużo większej wartości dla firmy/klienta.

Zdradzę Ci zaś tajemnicę, że jeżeli do takiego projektu przemycisz trochę swojej szalonej pasji, to w następnym będziesz mógł znów dołożyć ją kolejny raz. Ludzie zaczną powoli opanowywać technologie, z których korzystasz. To takie małe zwycięstwo, które możesz odnieść na rzecz innych poświęceń.

Powodzenia :)

<p>Loading...</p>