W necie każdy pisze co i jak robić, aby pisać lepszy kod. Ja dam Ci rady co robić, aby zostać super fajnym dobrym programistą (tylko stosuj tylko te rady na opak), a więc do dzieła:

  1. Nie dziel się wiedzą, po co tworzyć sobie konkurencję
    Po co tracić czas na przekazywanie wiedzy, przecież pisanie bloga, występowanie na konferencjach to tylko strata czasu. Oprogramowanie teraz tworzą spece, którzy są zawsze przed innymi.
    Wykładałem na bootcampach, występowałem na konferencjach: publicznych lub w firmach, mam kilka projektów na githubie – mówię wam szkoda czasu, wiedzę zachowujcie dla siebie.
  2. Nie chodź na spotkania firmowe
    Po co rozmawiać z ludźmi, lepiej zaszyć się w piwnicy. Życie pokazuje że, kontakty są niepotrzebne. Ty najlepiej wiesz co i jak ma działać, jesteś zajebistym programistą.

  3. Jednym testem załatwiaj o testowanie kodu, niech zawsze się świeci na zielono
    Testy to tylko strata czasu, przecież tobie płacą za funkcjonalności i działający kod, a nie za testy. Przykład:

def "super test"() {

   given:
   def json = "{}"

   when:
   superparser.fromJSON(json)

   then:
   json != null
}
  1. Nie pisz testów
    Najlepiej testować na produkcji. Pisanie testów to strata czasu. Po co do kodu pisać testy jednostkowe, integracyjne, e2e. Przecież to co robisz zawsze działa, jesteś zajebistym programistą.

  2. Zmiany w kodzie tylko kommituj na koniec sprintu
    Po co się przemęczać, przecież code review zrobi się na koniec sprintu. Wypychasz wtedy za jednym zamachem kilka dni roboty. Oszczędzasz swój czas, jak również czas środowisk testujących i budujących. Pomyśl sobie, jak co chwilę będziesz commitował to będziesz dostawał feed back i ciągle coś poprawiał, a tak to masz spokój.

  3. Nie pisz małych klas/metod dawaj wszystko do jednego lub kilku plików
    Wyobraź sobie kilkadziesiąt plików, albo kilka tysięcy takich małych po 10-200 linii kodu, przecież to się skacze po drzewie katalogów jak powalony. Dlatego lepiej mieć w projekcie kilka plików które mają po kilka tysięcy linii. Możesz wtedy powiedzieć, ze pracujesz przy np. ośmiotysięczniku. Przykład: https://github.com/ocornut/imgui/blob/master/imgui.cpp w sumie fajna bioteka do wyświetlania GUI w c++

  4. Twórz jak najkrótsze zmienne
    Taka ciekawostka w Basic z Commodore 64 nazwy zmiennych mogły mieć do 80 znaków, ale system rozróżniał tylko 2 pierwsze litery. Wiec najlepsze zmienne to te najkrótsze. Kod zmieście się w jedej linni, edytor podpowie do czego ona służy i gdzie jest używana. Wyobraź sobie że masz zmieną typu $superCiekawaZmiennaCoNicNieRobi i w PHP robisz literówkę w $superCiekawaZmiennaCoN1cNieRobi. Życzę powodzenia w szukaniu dlaczego program nie działa. Dlatego najlepsze zmienne to te jednoliterowe typu x, y, z, itd.

  5. Im więcej komentarzy tym lepiej
    Każda linijka kodu powinna być o komentowana, za kilka mc wrócisz do kodu i nic nie będziecie pamiętać, dlatego im więcej komentarzy tym lepiej:

Przykład prawidłowego komentowania kodu:

// create a for loop // <-- comment
for // start for loop
(   // round bracket
    // newline
int // type for declaration
i    // name for declaration
=   // assignment operator for declaration
0   // start value for i

Source

  1. Stosuj copy-paste programming
    Każdy fragment kodu jest inny, nawet jeżeli wygląda podobnie. Dlatego zamiast wydzielać metod robiących to samo, po prostu kopiuj fragmenty kodu. Lepiej będzie to też wyglądać w statystykach, że jesteś produktywnym programistą.
  • Bądź jedyną wiedzą na temat projektu co się tam dzieje
    Mówi się o takim wskaźniku „Ile potrzeba autobusów aby położyć dany projekt” najlepiej jak wynosi jeden. Dlatego nie dziel się wiedzą, nie mów jak co działa, nie pisz dokumentacji i testów. Gwarantujesz sobie tym, że zostaniesz alfą i omegą w danym projekcie i zawsze będę z tobą współpracowali.

  • Nie używaj statycznych analizatorów kodu
    Ty piszesz najlepszy kod, który zawsze działa. Dlatego stosowanie takich narzędzi jak np.: ktint – https://pinterest.github.io/ktlint/ , SNYK.io, Check Style lub nawet analizatora kodu z InteliJ mija się z celem, zajmuje czas i tylko ostrzeżeniami rzuca.

  • Ps. Stosowanie tych punktów zrobi z ciebie złego, a nie dobrego programistę dlatego unikaj stosowania ich.