Kvalita kódu na pozici junior programátora

[Tomas-K]

Ahoj, potřebuji poradit ohledně kvality mého kódu.
Věnuji se programování v typescriptu zatím jenom sám pro sebe. Učím se podle kurzů na internetu.
Mám dokončený jeden menší projekt. Je veřejně dostupný na GitHub  https://github.com/koutnyt/Steam_measuring
Vše je funkční ale nevím jestli jsem ho kvalitně napsal alespoň na úrovni pozice junior programátora.
Rád bych dostal rady ohledně zlepšení kódu, dobrých praktik, ...  .

Děkuji

[Reklama]

[Tomáš Procházka]

Koukal jsem jen na telefonu, a asi by se hodil nějaký code formatter.

Jinak Junior se špatně definuje a každá firma tam vidí něco jiného: od člověka po škole, po seniora za mrzký peníz.

Za mě doporučení se podívat na práci s diskem, sítí (HTTP(S) ale i TCP), SQL databází, konkurence a data-race cond., návrhové vzory a datové struktury atd... Od juniora se úplná znalost neočekává, ale je fajn nemuset vysvětlovat základy. Zároveň to jsou přenositelné znalosti mezi jazyky.

[_Tomáš_]

máš tam chyby, které lze u juniora čekat, kód vypadá autentický a věřím, že jsi ho psal sám.

pár tipů:
- přidej v názvu souboru README příponu .md, ať se ti vykresluje jako formátované html a ne jak ascii
- vyhni se jakémukoliv použití undefined, zamysli se jak to udělat jinak
- sjednoť formátování kódu, máš to rozházené a různé

Pokud bych tě pohovoroval a přinesl bys tenhle kód, vybíral bych náhodně části kódu a chtěl od tebe popsat, co dělají, proč to dělají, jaké mají limity a jak by šly napsat lépe. Bylo by pro mě důležitější, že rozumíš tomu co tam je, než jak samotný kód teď vypadá.

[alex6bbc]

trochu moc odradkovani mezi metodami :-)

jako c++ mi chybi ty stredniky :-)

[Martin Poljak]

- vyhni se jakémukoliv použití undefined, zamysli se jak to udělat jinak

undefined má zrovna konkrétně v JavaScriptu své dost podstatné místo. Narozdíl od mnoha jiných krávovin se tam fakt nevyskytlo samoúčelně. A jestli rozdíl mezí tím, že něco (obvykle zatím) je undefined, nebo že je to defined ale null nevidíte, taky bych to chtěl od vás na pohovoru důkladně zdůvodnit.

[Reklama]

[pangolin]

"Kvalita" (ve smyslu "fit for purpose") se posuzuje těžko, když není úplně jasné, co všechno jsou reálné požadavky.

Na juniora je to tedy asi OK (kód asi funguje, a +/- se dá číst a pochopit), ale podle mého subjektivního názoru tam je zbytečně mnoho abstrakce a spousta zbytečných rozhraní, adaptérů a pod. Chápu, že ve škole se hodně učí o generickém návrhu, rozšiřitelnosti a pod, ale naučit se správně aplikovat KISS a YAGNI je podle mě mnohem důležitější.

Když to chápu správně jediná tři zajímavá místa programu jsou

• cron/scheduler zajišťující opakované volání
• parsování vstupu (BTW podle názvu mi vadí, že parsování vstupu je součást StorageAdapter-u (tj. buď nevhodně zvolený název třídy, nebo nevhodné umístění logiky)
• odesílání naparsovaných dat na ThingSpeak

Zbytek je "bordel", kterého by tam mělo být co nejméně.

Napsat co nejsložitější program za pomocí co nejvíce úrovní abstrakce (a často blbě) není žádné umění. Trik je naopak naučit se psát jednoduchý a čitelný kód, který je v případě potřeby možné jednoduše (...) upravit/rozšířit i za cenu, že tam generické adaptéry a rozhraní nejsou, když je teď nikdo nepotřebuje.

[_Tomáš_]

- vyhni se jakémukoliv použití undefined, zamysli se jak to udělat jinak

undefined má zrovna konkrétně v JavaScriptu své dost podstatné místo. Narozdíl od mnoha jiných krávovin se tam fakt nevyskytlo samoúčelně. A jestli rozdíl mezí tím, že něco (obvykle zatím) je undefined, nebo že je to defined ale null nevidíte, taky bych to chtěl od vás na pohovoru důkladně zdůvodnit.

Tak, já nemluvil o javascriptu obecně, ale o konkrétnímu kódu, který tady byl odkázaný, tam mi to nedává smysl a nabízí se lepší řešení, např., Promise<Response|undefined>. Nebo třeba kontrola vstupu process.env.STEAM_WEBSERVER == undefined, opět to lze řešit lépe a pohlídat i prázdný vstup atd.

[Zdenek Henek]

Ahoj, potřebuji poradit ohledně kvality mého kódu.
Věnuji se programování v typescriptu zatím jenom sám pro sebe. Učím se podle kurzů na internetu.
Mám dokončený jeden menší projekt. Je veřejně dostupný na GitHub  https://github.com/koutnyt/Steam_measuring
Vše je funkční ale nevím jestli jsem ho kvalitně napsal alespoň na úrovni pozice junior programátora.
Rád bych dostal rady ohledně zlepšení kódu, dobrých praktik, ...  .

Děkuji

Zkus si nainstalovat SonarLint https://www.sonarsource.com/products/sonarlint/

nebo rovnout SonarQube
https://docs.sonarsource.com/sonarqube/8.9/analyzing-source-code/languages/javascript-typescript/

Sonar dokáže detekovat, když používáš něco špatně. Používám to na Javu, Javascript ...
Pro Javascript máme naimplementovaný i vlastní pravidla

Jinak pokud se chceš zlepšovat ve čtení i psaní kodu tak doporučuji
https://www.manning.com/books/the-programmers-brain
Sonar Lint je plugin do

[Tomas-K]

máš tam chyby, které lze u juniora čekat, kód vypadá autentický a věřím, že jsi ho psal sám.

pár tipů:
- přidej v názvu souboru README příponu .md, ať se ti vykresluje jako formátované html a ne jak ascii
- vyhni se jakémukoliv použití undefined, zamysli se jak to udělat jinak
- sjednoť formátování kódu, máš to rozházené a různé

Pokud bych tě pohovoroval a přinesl bys tenhle kód, vybíral bych náhodně části kódu a chtěl od tebe popsat, co dělají, proč to dělají, jaké mají limity a jak by šly napsat lépe. Bylo by pro mě důležitější, že rozumíš tomu co tam je, než jak samotný kód teď vypadá.

Děkuji za rady

Soubor README má již příponu md.
Undefined nepoužívám na žádném místě. Doufám že současné řešení je lepší.
Formátování kódu mám sjednocené a kontrolované pomocí eslint.

Všem ostatním také děkuji

[snugar_i]

Na juniora za mě dobrý - laťka je, aby to fungovalo, a to jsi splnil.
Některý věci by ale šly udělat líp. Předesílám, že JS ani TS moc neznám, takže spíš z obecnýho pohledu:
- Je super, že máš test, ale chtělo by jich to víc.
- Interface s jednou implementací je zbytečná složitost, která nic nepřináší. Zvlášť pokud nejde interface i implementaci smysluplně pojmenovat (INěco nebo NěcoImpl se nepočítá), je to často známka toho, že interface nemá smysl. Klidně bych je všechny vyhodil.
- Palec nahoru za dependency injection, ale šla by použít víc. Například místo toho, aby si WebPageLoader vytahoval URL z globálního process.env, by to URL prostě měl dostat v konstruktoru. Stejně tak všechny ostatní použití process.env mimo main.ts
- Jak už zaznělo, StorageAdapter toho dělá moc. Do něj by měl lézt nejspíš už naparsovaný MeasureValue[] (btw proč ukládáš write_api_key? to působí docela divně). Větší smysl by to dávalo ve WebPageLoader nebo ideálně ještě v nějaké další krabičce, která zavolá WebPageLoader a naparsuje jeho výstup. Prostě něco jako "zdroj dat v příčetným formátu".
- Na testování věcí souvisejících s hodinama se mi osvědčilo místo přímýho vytváření Date a podobně mít interface TimeSource, který mi umí říct, kolik je hodin, a předávat ho v konstruktoru. V produkčním kódu tam dám skutečnou implementaci a v testu tam můžu strčit falešnou a nemusím používat mockovací knihovnu.

[Mlocik97]

Ako tu už zaznelo, mnoho zbytočných interface, zbytočne prekomplikované. Väčšinu vieš zmazať. Máš tam aj nejaké chyby v typoch, a pár kusov kódu, ktorý nie je optimálny. V celku je to na juniora nie špatný kód, ale keby si šiel viac cestou KISS namiesto tvorenia interface na každú drobnosť a kúskovania do extrémizmu.

[Tomas-K]

Ještě jednou díky za rady.
Změnil jsem kompletně strukturu programu aby byl co nejméně komplikovaný, smazal jsem zbytečnosti a nechal jsem pouze to nejdůležitější. Z mého pohledu musím říct že se mi to i lépe čte a i rozšíření nebo úprava by mohla být snadná
Struktura body http requestu je vyžadována službou ThingSpeak tzn. write api key musí zůstat v body, používá se při autorizaci.

[petersveter]

re: kvalita kodu na pozicii juniora - ziadna, preto je to junior. jedina rola juniora je ovladat jazyk ale samotne pisanie kodu je irelevantne, resp. jeho uroven.

re: repozitorar - irelevantne, firma ti poivie ako oni robia veci a tam to zacina aj konci.

[snugar_i]

Ještě jednou díky za rady.
Změnil jsem kompletně strukturu programu aby byl co nejméně komplikovaný, smazal jsem zbytečnosti a nechal jsem pouze to nejdůležitější. Z mého pohledu musím říct že se mi to i lépe čte a i rozšíření nebo úprava by mohla být snadná
Struktura body http requestu je vyžadována službou ThingSpeak tzn. write api key musí zůstat v body, používá se při autorizaci.

Jo, vypadá to mnohem líp :-)
Chápu, že API Key musí být v body, když to nahráváš do ThingSpeaku, ale to je čistě vnitřní záležitost Uploader-u. S tím, jak to máš rozdělený teď, když bys to najednou chtěl začít nahrávat jinam, tak musíš měnit i Parser, což nedává moc smysl. Uploader by měl dostávat MeasureValue[] a ne celou DataStructure (což je stejně poměrně nešťastnej název).

Jo a ty fieldy v MeasureValue by se měly jmenovat nějak popisnějc - zase, pokud ThingSpeak očekává názvy field1 až fieldN, tak bych to na ně přejmenovával až v Uploaderu. Ať nemusíš pak význam těch fieldů mít jenom někde v komentářích uvnitř Parseru.

[Tomas-K]

Jo, vypadá to mnohem líp :-)
Chápu, že API Key musí být v body, když to nahráváš do ThingSpeaku, ale to je čistě vnitřní záležitost Uploader-u. S tím, jak to máš rozdělený teď, když bys to najednou chtěl začít nahrávat jinam, tak musíš měnit i Parser, což nedává moc smysl. Uploader by měl dostávat MeasureValue[] a ne celou DataStructure (což je stejně poměrně nešťastnej název).

Jo a ty fieldy v MeasureValue by se měly jmenovat nějak popisnějc - zase, pokud ThingSpeak očekává názvy field1 až fieldN, tak bych to na ně přejmenovával až v Uploaderu. Ať nemusíš pak význam těch fieldů mít jenom někde v komentářích uvnitř Parseru.

Máš pravdu. Předělal jsem to podle tvého doporučení a dává to mnohem větší smysl