Wpis z mikrobloga

#programista15k #programowanie

Zbiór moich mini przemyśleń co do rozwoju oprogramowania:

unikaj używania zewnętrznych bibliotek jak tylko możesz, a jak za biblioteką nie stoi fundacja albo wielka korporacja to zastanów się dodatkowo jeszcze 10 razy. dlaczego? ponieważ biblioteki open source umierają, umierają cały czas, jak pewnie piszę tego posta to już kilka zmarło. chcesz mieć projekt który nie możesz łatwo zupgradować bo musisz połowę rzeczy przepisywać? to śmiało, do każdej rzeczy używaj czyjegoś githuba, najlepiej z słabą dokumentacją i utrzymywaną przez jedną osobę po godzinach.

kopiuj kod, tworzenie generycznych abstrakcji ma sens tylko wtedy jak ich potrzebujesz, unikaj używania wzorców programowania/projektowania chyba, że naprawdę ich potrzebujesz i rozwiązują twój problem, ale traktuj to jako ostateczność

typuj i unikaj języków dynamicznie typowanych

używaj narzędzi których abstrakcja jest zbliżona do tego co pod maską jest implementowane. co mam na myśli? typowy przykład to ORM; ORMy które mają zbliżoną składnie do SQLa są dużo lepsze niż ORMy które mają własną unikalną abstrakcję oderwaną od bazy. Gdy poznasz jeden ORM bazujący na SQLu to szybko jesteś wstanie nauczyć się kolejnego, natomiast ORM który jest za bardzo abstrakcyjny robi z ciebie kalekę życiowego i przykuwa cię do danego jednego ekosystemu.

lepiej robić coś explicite, nawet duplikując kod, niż posiadać masę magicznych handlerów z jeszcze bardziej magiczną składnią

mikroserwisy są naprawdę przereklamowane, większość nie jest netflixem i googlem i nie ma ich problemów. w 99% dobrym startem jest modularny monolit, wolne części systemu można wydzielić później na jakiś mikroserwis

nie bądź tumanem i naucz się co najmniej tych 2-3 języków programowania. nie bądź imbecylem który zna pythona czy jsa i wszystko pisze w tych językach mimo że to nie ma żadnego sensu. języki są do siebie zresztą bardzo podobne.

każda technologia, biblioteka czy narzędzie dodana do stacku to kolejny magiczny klocek który może się pewnego rodzaju w-----ć. to że ty coś dobrze rozumiesz nie znaczy, że kolejne osoby po tobie tak dobrze to ogarniają.

kod typu "rozwiązanie tymczasowe", "do przepisania" przeważnie zostaje na lata z projektem jak coś takiego piszesz a czasami trzeba to przynajmniej udokumentuj cały kontekst, czyli dlaczego i po co.
  • 4
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@tubkas12: po co modularny monolit, skoro można odje*ać stary, dobry, niemodularny monolit, którego wszyscy doskonale znamy i rozumiemy? ( ͡° ͜ʖ ͡°)
  • Odpowiedz