Dobre programerske prakse

Do sedaj sem delal samo v manjših firmah, kjer je eden lead developer in ima pod sabo max 3 "support" developerje. Povsod sem opazil, da nimajo uveljavljenih nekih "dobrih praks". Vedno je šlo samo, da bo spletno mesto / aplikacija čim prej izdelana, da bo čim prej zaslužek. Nikjer pa se ni gledalo na kakovost kode - zasledil sem primere, kjer se je copy-pastalo in na koncu je bil rezultat programska koda združena iz treh podobnih mest, vmes zakomentirano, kar se ni potrebovalo, ali pa zakomentirani deli kode, ki "v prvo" niso delovali in je bilo treba spisati drugače. Poleg tega je bila koda zelo redko opremljena s kakšnimi komentarji. Kakšne pripadajoče dokumentacije nisem nikjer zasledil. Rezultat je potem to, da dobiš junior programerja, ki ima za sabo kar nekaj (zelo prepričljivih!) lastnih projektov, ampak ko vidi takšno kodo, je praktično neuporaben - napreduje zelo počasi in cela firma je nezadovoljna/razočarana.

Kako programirate pri vas? Imate uveljavljene kakšne smernice, se držite dobre prakse? Ali samo mečete kodo skupaj, toliko da se rešitev čim prej proda stranki?

Utk je 13. jul 2023 ob 10:46 izjavil:

ko vidi takšno kodo, je praktično neuporaben

Jah...če bi bil tak maher, bi se znašel tudi tu.

True :)

Utk je 13. jul 2023 ob 10:46 izjavil:

zasledil sem primere, kjer se je copy-pastalo in na koncu je bil rezultat programska koda združena iz treh podobnih mest, vmes zakomentirano, kar se ni potrebovalo, ali pa zakomentirani deli kode, ki "v prvo" niso delovali in je bilo treba spisati drugače.

Kaj je pa s tem narobe?

Komentarji so namenjeni komentiranju. Neka stara koda, za katero noben ne ve zakaj tocno zakaj je tam, verjetno ni komentar.

user4683 je 13. jul 2023 ob 11:03 izjavil:

Komentarji so namenjeni komentiranju. Neka stara koda, za katero noben ne ve zakaj tocno zakaj je tam, verjetno ni komentar.

Jaz dostikrat kakšno staro kodo zakomentiram, v smislu "to je bilo prej, pa ne dela prav" ali "tako je bilo prej, zdaj pa je zakonodaja drugačna" ali "to je bilo prej, zdaj pa tega ne rabimo več".
Ponavadi zraven še ena vrstica z datumom odstranitve in zelo na kratko razlog.

Ja, to potem ni vec zgolj zakomentirana koda, ampak dejansko postane nek uporaben komentar (s kodo).

V praksi sem veckrat videl zgolj zakomentirane odseke kode brez dodane razlage, pa sem videl ze ogromno kode. Na sreco se veliko firm zapleza, ko jim one-man-band app preraste v 10+ ljudi in jih zacne osnovna zgresena arhitektura tako bremzati, da jim lahko ogromno racunas za svetovanje

Jure14 je 13. jul 2023 ob 11:15 izjavil:

user4683 je 13. jul 2023 ob 11:03 izjavil:

Komentarji so namenjeni komentiranju. Neka stara koda, za katero noben ne ve zakaj tocno zakaj je tam, verjetno ni komentar.

Jaz dostikrat kakšno staro kodo zakomentiram, v smislu "to je bilo prej, pa ne dela prav" ali "tako je bilo prej, zdaj pa je zakonodaja drugačna" ali "to je bilo prej, zdaj pa tega ne rabimo več".
Ponavadi zraven še ena vrstica z datumom odstranitve in zelo na kratko razlog.

Povsem odvisno od situacije ampak sam bi kodo najverjetneje vrgel ven in pustil samo komentar. Commit bo itak vezan na pull request (in ticket), kjer so te spremembe argumentirane in se tudi precej bolje vidi before/after. Razen ce se PRje uporablja bolj za okras :)

Jaz sem "one man team" in se trudim držat dobrih praks. Imam recimo temu nadrejenega kateri mi odredi kaj in do kdaj mora biti narejeno, nato sem prepuščen samemu sebi. Rezultat mora biti delujoča (spletna) aplikacija.

Smernic katerih se trudim držat so:
- identacija kode kot se spodobi za lažjo berljivost
- PSR12
- PHP_CodeSniffer
- PHP_MessDetector
- https://github.com/alexeymezenin/larave...
- TSLint
- auto deployment (ročno mi je velikokrat delalo preglavice ker sem vedno nekaj pozabil)
- če se je odstranilo kakšno ključno funkcionalnost, jo zakomentiram in dodam komentar ter datum zakaj je bilo odstranjeno in po možnosti še link do ticketa
- smiselno komentiranje kode, vsaj kolikor toliko

Testov ne pišem ker povečini zmanjka časa, spišem jih samo ene par za osnovne stvari. Kar me je že večkrat teplo, ampak sem že izkusil da potrebuješ nekako x3 več časa da spišeš vse teste, v primerjavi koliko časa potrebuješ za pisanje kode. Da ne omenjam da se ponavadi dokumentacija za pisanje testov ne ujema z realnostjo ali pa pač preprosto ne deluje in se grem bolj "trial-and-error". Za kar se mi pa ne da več izgubljati časa in pač raje ročno potestiram zadevo. (Konkreten primer: OpenAPI sintaksa za uporabo v PhpStormu. Zato je vsa moja dokumentacija za APIje v Postmanu.) TDD sem probal in hitro opustil, mi pač logika ne potegne oz. ne ustreza.

Včasih sem samo klamfal kodo skupaj in ko pogledam tisto, mi je še danes slabo. Je res da sem pisal v core PHPju in če se tam ne držiš nekih pravil, imaš zelo hitro špagete. In to zelo dolge ... tudi preko 10k vrstic! Potem se pa znajdi tam notri, sploh ko se enkrat navadiš na MVC sintakso.