Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: jpu 26. 01. 2018, 08:17:07
-
Zaujimalo by ma, ake best-practices pouzivate pri programovani, popr. doporucit nejaku literaturu.
1.) Pouzivate static namiesto singletonu, popr. opacne a preco? Popr. volite sposob Factory?
2.) Dependency injection, inversion of control?
3.) Mockovanie?
4.) Clenenie do viacerych tried (napr. X partial class)?
5.) Podmienene vykonavanie prikazov (if/switch)?
6.) napr. v C# pouzivate syntactic sugar alebo radsej rozpisujete?
Budem rad za konstruktivnu debatu, ktora nieco aj niekomu da :)
Dakujem.
-
A proc chces zase strucnou odpoved? Proc nevenujes cas samostudiu a cetbe? Tady si moc nepomuzes.
-
Nejlepší je se na to vysrat a přejít na nějaký funkcionální jazyk :)
-
A proc chces zase strucnou odpoved? Proc nevenujes cas samostudiu a cetbe? Tady si moc nepomuzes.
Strucnu odpoved nechcem. Skor mi ide o skusenosti ludi, co pouzivaju, comu sa naopak vyvaruju (vid. static vs. singleton).
-
Pokud máš static, nemůžeš mockovat, takže samozřejmě injektovaný singleton. Takže otázky 1, 2, a 3, jsou vlastně jednou otázkou.
-
Na rootu konstruktivní debatu nečekej, jen se dozvíš, že jsi lopata.
-
Ono také záleží co programuješ, jiný postup se volí na embeded zařízeních a úplně jiný na servrech a jiný pro GUI na desktopu.
-
tak predpokladam, ze injectovanie, static/singleton, factory pattern popr. ine patterny, podmienky, clenenie do tried bude +/- rovnake ci pre server, gui. o embedded neviem, s tym som nepracoval.
-
1.) Singleton sa usilujem nepouzivat. Preferujem pomenovane instancie v DI frameworku.
2.) Ano, spring, o springu je milion literatury. Treba si najst vzdy aktualnu, lebo sa to neustale meni. (EJB sa mi osobne az tak nepaci, je to krapatek zaprdene)
3.) Easymock.
4.) Java to neumoznuje, tak to nepouzivam. Ale da sa tym paradne robit separation of concerns.
5.) Nemam best practices. Hlavne to je robit tak, aby sa to dalo citat a nevnarat zbytocne vela if-ov a a switchov do seba.
6.) Ano, pouzivam, aby som to potom vedel citat po druhych. Osobne si myslim, ze kazde pouzitie syntactic sugar zabije steniatko, ale co narobim.
-
Nejlepší je se na to vysrat a přejít na nějaký funkcionální jazyk :)
No jenze kdyz mas klasicky deklarativni ci OOP jazyk 3.5te generace tak mas v podstate jedno v cem kodujes, lisi se jen detaily. Ale vybrat funkcionalni jazyk je beh na dlouhou trat protoze kazdy ma jinou filosofii, dogmata a stado militantnich vericich.
-
Zaujimalo by ma, ake best-practices pouzivate pri programovani, popr. doporucit nejaku literaturu.
1.) Pouzivate static namiesto singletonu, popr. opacne a preco? Popr. volite sposob Factory?
2.) Dependency injection, inversion of control?
3.) Mockovanie?
4.) Clenenie do viacerych tried (napr. X partial class)?
5.) Podmienene vykonavanie prikazov (if/switch)?
6.) napr. v C# pouzivate syntactic sugar alebo radsej rozpisujete?
Budem rad za konstruktivnu debatu, ktora nieco aj niekomu da :)
Dakujem.
1 - jak kdy, nevěřím na silver bullet ale singletonem via DI se moc nezkazí
2 - DI a o moc raději Dagger než Spring
3 - Ano, Mockito, ušetří to spoustu práce, ale vždycky je otázka jestli se náhodou nemokuje až moc vzhledem k tomu, co vlastně chci testovat.
4) tohle asi v Javě nemáme a nemám na to názor. Teď si nedovedu představit že by to byl extra velký přínos.
5) Nechápu otázku :) If používám, switch méně, ale některé situace si o něj řeknou.
6) Čím víc kódu jsem viděl, opravil a napsal, tím více je můj kód ukecanejší. Je to daný i tím, že vlastním psaním kódu strávím možná 20% času, zbytek jde na přemýšlení a čtení kódu.
-
A mate nejaku politiku kodu, ktoru dodrzujete, resp. musite dodrziavat napr. vo firme? Ja na pomoc pouzivam resharper, dobry nastroj, ktory celkom dost napovie, aj ked niekedy je "blby" :). My nejaku politiku v praci nemame zauzivanu, ale napr. "this" musim pisat, aj ked taky resharper to povazuje za nadbytocne.
-
Po té co vytvořím půl request z branche mého forku do hlavního repa, to projede statická analýza zdrojaku podle setu pravidel a na build serveru se branch zkompiluje a spustí se unit testy. Pokud je zdrojak zelený, někdo z kolegů se ujme code review.
Žádná raketová věda, jen si z codebase nechceme dělat úplnou stoku.
Ano, v default levelech statické analýzy bylo pár pravidel, která dělala víc škody než užitku, ale ty jsme postupně vypnuli.
-
Mnohé sa používajú preto, lebo sú súčasťou frameworku, ktorý využívame. Keď si na to človek zvykne, DI je veľmi pohodlné používať. Single responsibility principle je všeobecne zaužívaný postup. Na webe zasa MVC, resp. MVVM.
Nie vždy sa to striktne dodržiava, ale dobrým postupom je nemixovať viac jazykov do jedného súboru, trebárs SQL v
Java kóde. Populárne je tiež defenzívne programovanie. Nedôverujte vstupu od užívateľa je dobrý imperatív.
Convention over configuration je jedným z najpopulárnejších a najefektívnejších postupov pri vývoju softvéru.
Potom je celá rada netechnických dobrých postupov, napr. menej skúsený vývojár musí mať mentora,
špecializácia programátorov, neustále vzdelávanie atď.
-
Convention over configuration
Tymto sa co mysli?
U nas vo firme sa nejake best practices nedodrzuju. Clovek si musi vsetko sam skusat a ked tak to praktizovat na vlastnych projektoch.
-
Convention over configuration
Tymto sa co mysli?
U nas vo firme sa nejake best practices nedodrzuju. Clovek si musi vsetko sam skusat a ked tak to praktizovat na vlastnych projektoch.
Convention over configuration je prístup, spopularizovaný Ruby on Rails, kde sú nastavené určité
východzie hodnoty, ktoré potom netreba v kóde alebo v konfiguračných súboroch nastavovať. Šetrí to veľmi
veľa úsilia a času. Napríklad Spring predpokladá, že šablóny sú uložené v súbore src/main/resources/templates, alebo
ak Spring vidí Freemarker závislosť v pom.xml súbore, automaticky sa zvolí Freemarker šablónovací systém a prípony šablón majú príponu ftl.
To je veľmi zlé, ak firma v roku 2018 nemá best practices.
-
Dakujem, pozriem si tom trosku viac.
No ja som nadobudol dojmu, ze u nas sa programuje, ako sa komu zachce a robi podla svojho uvazenia, ale napr. nejake DI som v kodoch inych ludi nenasiel.
-
Zaujimalo by ma, ake best-practices pouzivate pri programovani, popr. doporucit nejaku literaturu.
1.) Pouzivate static namiesto singletonu, popr. opacne a preco? Popr. volite sposob Factory?
2.) Dependency injection, inversion of control?
3.) Mockovanie?
4.) Clenenie do viacerych tried (napr. X partial class)?
5.) Podmienene vykonavanie prikazov (if/switch)?
6.) napr. v C# pouzivate syntactic sugar alebo radsej rozpisujete?
Budem rad za konstruktivnu debatu, ktora nieco aj niekomu da :)
Dakujem.
1) DI
2) Ano, casto ano.
3) Velmi casto.
4) Ne. Moje prostredi to nepodporuje, ale i jinak bych u toho byl spis opatrny.
5) Cim dal mene. Naopak cim dal casteji trebas mapovani nad optional. Ale neni duvod se tomu vyhybat.
6) Radeji cukr, pokud je k dispozici.
-
1) singletonu se zcela vyhýbám, považuji ho za anti-pattern
2) DI
3) ano, občas
4) ano
5) if i switch (???)
6) v C# nepíšu
Většinou dělám v PHP a na osobních projektech mám:
+ kontrolu code-style definovaný v XML - jak je kód formátovaný (mezery/taby, docblocky, a spoustu dalšího)
+ statickou analýzu kódu - odhalí nepoužité nebo špatně použité proměnné, chybějící třídy, špatná volání metod atd.
+ testy
Toto vše si samozřejmě pouštím před pushem, jamile se to dostane do Gitu, spouští se CI, kde se tyto kroky provedou.. Většina věcí je v Docker kontejnerech.
Takhkle to dělám já na svých projektech, byl bych rád kdyby to tak měli i firmy pro které dělám, realita je hodně různá - někde ano, někde částečně a někde jsou stále 10 let pozadu, vystavují přes FTP a neštítí se modifikovat kód přímo na serveru.
Aktuálně firma pro kterou dělám má chuť tohle zlepšovat, ale u zhruba poloviny vývojářů mi přijde, že o to nemají zájem a dělají si to po svém bez nějaké vize zlepšení procesů a kvality. Osobně myslím, že by to firma měla nadiktovat a vývojáři by měli mít možnost to rozumně ovlivňovat. Tedy pokud je vše rozumně zadokumentované/popsané, jinak to může být chaos.