Jedyny Słuszny Sposób Programowania

laptop tęczowy

Co zrobić, gdy odkryjesz Jedyny Słuszny Sposób Programowania? Mówić o tym światu? Wytłumaczyć wszystkim innym, że się mylą? Czy zachować tajemną wiedzę tylko dla siebie? Sprawdź!


Ten wpis oryginalnie został wysłany jako mój newsletter – “Pretekst do rozmyślań”. Czytasz go teraz na blogu jako artykuł otwarty. Jeśli chcesz dostawać ode mnie regularnie wpisy tego typu jako maile, zapisz się na newsletter i czekaj na preteksty do rozmyślań w co drugi piątek rano. Do zobaczenia w Twojej skrzynce mailowej! 💌


✨ Pretekst do rozmyślań | Odcinek 13 – Jedyny Słuszny Sposób

Przeczytałam ostatnio odcinek newslettera “Computer Things” Hillela Wayne’a z radami dla początkujących programistów i jedna z uwag zatrzymała mnie na dłużej. A było to:

At some point you will discover the Right Way to program, the thing which makes this all *make sense*, and you’ll be convinced that the whole field would be so much better off if everybody else programmed the Right Way, too.

W moim wolnym tłumaczeniu:

W pewnym momencie odkryjesz Jedyny Słuszny Sposób programowania, taki, który sprawia, że w końcu to wszystko ma sens i będziesz przekonanx, że wszyscy by skorzystali, gdyby programowali w Jedyny Słuszny Sposób.

I dalej autor pisze:

I’m not going to tell you to not get swept up in the Right Way, because that’s pretty much impossible. And honestly it feels really great to discover the Right Way and life’s too short to not feel good. Just be mindful of the fact you’re getting swept up and try not to make your identity the Right Way Guy. Eventually the honeymoon will end and you’ll learn that programming is frustrating and messy regardless of which Right Way people use, and that you can also make great software without doing it the Right Way. Over time you’ll learn fifty other Right Ways and learn to mix and match them to the problem at hand.

Tłumacząc:

Nie poradzę ci, by nie dawać się wciągnąć w Jedyny Słuszny Sposób, bo to po prostu niemożliwe. I szczerze mówiąc, odkrycie Jedynego Słusznego Sposobu to naprawdę miłe uczucie, a życie jest za krótkie, żeby nie czuć się dobrze. Zdawaj sobie jednak sprawę z faktu bycia porwanym w Jedyny Słuszny Sposób. W końcu miesiąc miodowy się skończy i zrozumiesz, że programowanie zawsze jest frustrujące i niechlujne, nie ważne, w jaki sposób piszesz. Możliwe jest także pisanie dobrego kodu nie w Jedyny Słuszny Sposób. Z czasem poznasz pięćdziesiąt kolejnych Jedynych Słusznych Sposobów i nauczysz się je dopasowywać i miksować tak, by rozwiązać problem, który masz w danym momencie.

Miało być tak pięknie…

Przypomniały mi się momenty, gdy ja odkrywałam Jedyne Słuszne Sposoby. Numer jeden – React jest lepszy od Angulara. Dlaczego WSZYSCY nie piszą frontu w Reakcie? Numer dwa – testy. Dlaczego część kodu NIE MA testów. Dlaczego WSZYSCY nie piszą testów do WSZYSTKIEGO? (No dobra, to nadal uważam za słuszne). Numer trzy – refactoring. Dlaczego ktoś dodał nową funkcjonalność w STARYM kodzie bez PRZEPISYWANIA w nowy sposób? Przecież już wiadomo, że TAK się nie robi, dlaczego utrzymujemy taki STARY kod. Numer cztery – code coverage. Jak w ogóle inni BEZ TEGO funkcjonują? Przecież wystarczyłoby SPRAWDZIĆ pokrycie kodu testami, dopisać brakujące i już. Numer pięć – programowanie funkcyjne. Kod taki krótki, prosty, przyjemny. Dlaczego WSZYSCY tak nie piszą?

Mogę tak wymieniać dalej, bo było tych rzeczy wiele. Pewnie też masz listę takich Jedynych Słusznych Sposobów, jeśli dłużej programujesz. Z czasem odkryłam, że życie programist(k)i nie jest czarno-białe. Nie zawsze da się użyć Jedynego Słusznego Sposobu. Ba, czasem nawet inni uważają, że ten sposób wcale nie jest jedyny. Ani słuszny. A Ty, z bólem serca, przyznajesz im rację. Bo to zależy. Bo specyfika kodu, projektu, wymagań klienta. Bo kod ma przede wszystkim działać, nowy feature ma być dodany i Product Ownera czasem średnio się interesuje faktem, że na dodanie do danego fragmentu testów e2e potrzeba tygodnia (oj, byłam w takim projekcie!).

Nie namawiam do pisania złego kodu, nierobienia refactoru czy niepisania testów. Chodzi mi bardziej o to, że nie wszystko zależy od nas i to, że poznaliśmy jakiś nowy sposób na coś i uważamy, że jest fajny i przydatny, nie zawsze oznacza, że trzeba go wszędzie używać.

A potem ideał sięgnał bruku…

Pamiętam jak na jednej z rozmów kwalifikacyjnych zapytana o to, co zrobiłabym dostając projekt legacy, odpowiedziałam bez wahania “najpierw bym go przepisała na nowszą technologię”. Dziś śmieję się z samej siebie. I śmiałam się też dodając potem linijki kodu w Backbonie (if you know, you know). Moje podejście do refactoringu zmieniło się na przestrzeni lat. Zazwyczaj w sumie przestrzegam zasad, które zebrałam w tym artykule na dev.to. Czy zmienię kiedyś zasady, którymi się kieruję? Pewnie tak.

To, czego nauczyło mnie parę lat programowania to przede wszystkim to, że właściwie nie ma sposobów uniwersalnych. Pewnie, możemy stosować pewne zasady, techniki. Jednak kod to wiele zmiennych i jak wchodzimy w istniejący już projekt, nad wieloma tymi zmiennymi nie mamy możliwości panować. Frustrowanie się wtedy, że coś nie jest napisane “po naszemu” nie ma sensu.

Pretekst do rozmyślań na dziś to właśnie Jedyny Słuszny Sposób. Masz swój? Traktujesz go jak biblię? A może są rzeczy, w które kiedyś wierzyłxś, a dziś już nie są aktualne? Bardzo jestem ciekawa, jak do tego podchodzisz! Odpisz na tego maila i pogadajmy ✨


Ten wpis oryginalnie został wysłany jako mój newsletter – “Pretekst do rozmyślań”. Czytasz go teraz na blogu jako artykuł otwarty. Jeśli chcesz dostawać ode mnie regularnie wpisy tego typu jako maile, zapisz się na newsletter i czekaj na preteksty do rozmyślań w co drugi piątek rano. Do zobaczenia w Twojej skrzynce mailowej! 💌