it-swarm-eu.dev

Jaké populární „osvědčené postupy“ nejsou vždy nejlepší a proč?

„Nejlepší postupy“ jsou všude v našem odvětví. Odpověď vyhledávání Google na téma „doporučené postupy kódování“ přinese téměř 1,5 milionu výsledků. Zdá se, že tato myšlenka přináší útěchu mnoha; postupujte podle pokynů a vše dopadne dobře.

Když jsem četl o osvědčeném postupu - například jsem nedávno přečetl několik v Clean Code nedávno - jsem nervózní. Znamená to, že bych měl vždy tuto praxi používat? Jsou k tomu připojeny podmínky? Existují situace, kdy by to nebylo dobrým postupem? Jak mohu vědět s jistotou, dokud jsem se o problému nedozvěděl více?

Několik praktik uvedených v Clean Code se mnou nesedělo, ale upřímně si nejsem jistý, jestli je to proto, že jsou potenciálně špatné, nebo jestli je to jen moje osobní zaujatost mluvící. Vím, že mnoho prominentních lidí v technologickém průmyslu si myslí, že neexistují žádné osvědčené postupy , takže alespoň moje otravné pochybnosti mě staví do dobré společnosti.

Počet doporučených postupů, o kterých jsem četl, je prostě příliš velký na to, abych je mohl uvést zde, nebo položit jednotlivé otázky, proto bych to rád vyjádřil jako obecnou otázku:

Které postupy kódování, které jsou obecně označovány jako „osvědčené postupy“, mohou být za určitých okolností suboptimální nebo dokonce škodlivé? Jaké jsou tyto okolnosti a proč dělají z této praxe špatnou?

Raději bych slyšel o konkrétních příkladech a zkušenostech.

100
Steven Evers

Myslím, že jste s tímto tvrzením narazil do hřebu na hlavě

Nerad bych bral věci v nominální hodnotě a nemyslel na ně kriticky

Ignoruji téměř všechny osvědčené postupy, když nepřichází s vysvětlením, proč existuje

Raymond Chen to říká nejlépe v tento článek , když říká

Dobrá rada přichází s odůvodněním, takže můžete říct, kdy se stane špatnou. Pokud nechápete, proč by se mělo něco dělat, pak jste upadli do pasti programování kultů nákladu a budete to dělat i tehdy, když už to není nutné nebo dokonce bude škodlivé.

125
Conrad Frix

Může to také hodit do kruhu:

Premature optimization is the root of all evil.

Ne, není.

Kompletní nabídka:

"Měli bychom zapomenout na malou efektivitu, řekněme asi 97% času: předčasná optimalizace je kořenem všeho zla. Přesto bychom neměli předávat naše příležitosti v tomto kritickém 3%."

To znamená, že využíváte specifická, strategická vylepšení výkonu během celého procesu návrhu. To znamená, že používáte datové struktury a algoritmy, které jsou v souladu s výkonnostními cíli. To znamená, že jste si vědomi konstrukčních aspektů, které ovlivňují výkon. Znamená to však také, že při tom neopatrně optimalizujete, což vám dá menší zisky na úkor udržovatelnosti.

Aplikace musí být dobře navrženy, aby na konci, když na ně trochu zatěžujete, nespadly a poté je přepisovaly. Nebezpečí se zkrácenou nabídkou je, že vývojáři ji až příliš často používají jako výmluvu, aby neuvažovali o výkonu až do konce, kdy by bylo příliš pozdě na to s tím něco dělat. Je lepší stavět v dobrém výkonu od začátku, pokud se nezaměřujete na markanty.

Řekněme, že na vestavěném systému stavíte aplikaci v reálném čase. Jako programovací jazyk si vyberete Python), protože „Předčasná optimalizace je kořenem všeho zla.“ Nyní nemám nic proti Pythonu, ale je interpretovaný jazyk. Pokud je výpočetní výkon omezený a určité množství práce musí být provedeno v reálném čase nebo téměř v reálném čase, a vyberete si jazyk, který vyžaduje větší výpočetní výkon pro práci, než máte, jste royálně zašroubovaní, protože nyní musí začít od schopného jazyka.

95
Robert Harvey

Jeden návrat na funkci/metodu.

94
iMacUwhAK

Neotevírejte kolo je široce zneužívané dogma. Její myšlenkou je, že pokud existuje vhodné řešení, použijte jej místo vytváření vlastního; Kromě úspory úsilí je stávající řešení pravděpodobně lépe implementováno (bez chyb, efektivní, testováno) než to, s čím byste původně přišli. Zatím je vše dobré.

Problém je, že 100% vhodné řešení existuje zřídka. Může existovat 80% vhodné řešení a jeho použití je pravděpodobně v pořádku. Ale co asi 60% vhodné? 40%? Kde nakreslíte čáru? Pokud čáru nenakreslíte, můžete do projektu začlenit nafouklou knihovnu, protože využíváte 10% jeho funkcí - jen proto, že se chcete vyhnout „znovuobjevení kola“.

Pokud kolo znovu objevíte, dostanete přesně to, co chcete. Naučíte se také naučit se vyrábět kola. Učení pomocí by nemělo být podceňováno. Nakonec může být vlastní kolo lepší než běžný generický kotouč.

87
Joonas Pulakka

"Testuj všechno."

Slyšel jsem, že se často říká, že všechny kódy by měly mít jednotkové testy, s čím nesouhlasím. Pokud máte test na metodu, musí být každá změna výstupu nebo struktury této metody provedena dvakrát (jednou v kódu, jednou v testu).

Jednotkové testy by proto měly být podle mého názoru přiměřené strukturální stabilitě kódu. Pokud píšu vrstvený systém zdola nahoru, moje vrstva přístupu k datům bude mít testy mimo wazoo; moje obchodní logická vrstva bude velmi dobře otestována, moje prezentační vrstva bude mít několik testů a mé pohledy budou mít jen málo nebo žádné testování.

78
Fishtoaster

Vždy program na rozhraní.

Někdy bude pouze jedna implementace. Pokud zpozdíme proces extrakce rozhraní až do doby, kdy uvidíme jeho potřebu, často zjistíme, že to není nutné.

57
Eric Wilson

Nepoužívejte nic open-source (nebo non-Microsoft pro vás. NET vývojáři)

Pokud to Microsoft nevyvinul - nepoužíváme ho zde. Chcete použít ORM - EF, chcete použít IOC - Jednota, chcete se přihlásit - aplikační blok podnikového protokolování. Existuje tolik lepších knihoven - přesto jsem vždy nalepený objednávání z nabídky dolaru vývojového světa. Přísahám pokaždé, když uslyším Microsoft Best Practices, myslím, že „McDonald's Nutritional Guidelines“. Jistě, pravděpodobně budete žít, pokud je budete dodržovat, ale budete také podvyživení a nadváhou.

  • Všimněte si, že to nemusí být váš osvědčený postup, ale je to běžný postup, který následoval téměř všude, kde jsem pracoval.
46
Watson

Orientace objekt

Existuje předpoklad, protože kód je „objektově orientovaný“, je magicky dobrý. Takže lidé pokračují ve stlačování funkcionality do tříd a metod, jen aby byli objektově orientovaní.

40
LennyProgrammers

Celý kód by měl být komentován.

Ne, nemělo by to být. Nějaký čas máte zřejmý kód, například setters by neměl být komentován, dokud neudělají něco zvláštního. Proč bych to měl komentovat:

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);
35
Vladimir Ivanov

Metodiky, zejména scrum. Když slyším dospělé používat frázi „Scrum Master“, nemůžu si udržet přímou tvář. Jsem tak unavený z toho, že vývojáři sluchu protestují, že některé aspekty metodologie X pro jejich společnost nefungují, pouze aby jim to řekl Guru So-and-že důvod, proč to nefunguje, je, že ve skutečnosti nejsou skutečnými praktikujícími. Metodologie X. "Scrum těžší, musíte, můj Padawanský žák!"

V agilních metodikách jsou nugety moudrosti - spousta z nich ---, ale často jsou natolik hnoji, že nedokážu bojovat s mým reflexem. Vezměte tento bit z Wikipedia's scrum page :

V Scrumu je definováno několik rolí. Všechny role spadají do dvou odlišných skupin - prasat a kuřat - podle povahy jejich zapojení do procesu vývoje.

Opravdu? Prasata a kuřata, říkáte? Fascinující! Nemůžu se dočkat, až to postavím mému šéfovi ...

32
evadeflow

Objektové relační mapování ... http://en.wikipedia.org/wiki/Object-relational_mapping

Nechci, aby mě někdo odstrkoval od svých dat, ani nechci ztratit tu přesnou kontrolu a optimalizaci. Moje zkušenost s těmito systémy byla nesmírně špatná ... Dotazy generované těmito abstrakčními vrstvami jsou ještě horší, než to, co jsem viděl na dálku.

25
Fosco

Psaní názvů funkcí, jako by šlo o anglické věty:

Draw_Foo()
Write_Foo()
Create_Foo()

atd. Může to vypadat skvěle, ale je to bolest, když se učíte API. Jak je snazší prohledat index „Vše, co začíná na Foo“?

Foo_Draw()
Foo_Write()
Foo_Create()

atd.

22
Colen

YAGNI

( Nepotřebujete to )

Tento přístup mi stál hodiny a hodiny, když jsem musel implementovat funkce do existující kódové základny, kde by pečlivé plánování obsahovalo tyto funkce předem.

Myšlenky byly kvůli YAGNI často odmítnuty a za toto rozhodnutí se většinou musel platit někdo později.

(Samozřejmě by se dalo argumentovat, že dobře navržená kódová základna by později umožnila přidání funkcí, ale realita je jiná)

22
Sean Patrick Floyd

MVC - často zjišťuji, že mnoho problémů s webovým designem v přístupu MVC je více o tom, jak udělat rámec (Rails atd.) Šťastným, než o jednoduchosti nebo struktuře. MVC je favoritem „astronautů architektury“, kteří podle všeho oceňují nadměrné lešení nad jednoduchostí. ymmv.

class-based OO - - podle mého názoru podporuje komplexní struktury proměnlivého stavu. Jedinými přesvědčivými případy, které jsem našel pro třídu OO v průběhu let jsou příklady typu „tvar-> obdélník-> hranatý“, které tvoří kapitolu 1 jakékoli knihy OO kniha)

22
Brad Clawsie

Pro SQL

  1. Nepoužívejte spouště
  2. Vždy skrývejte tabulky za pohledy

V pořádku:

  1. Jsou to funkce, které mají své místo. Máte několik aktualizačních cest k tabulce nebo vyžadujete 100% audit?

  2. Proč jen? Chtěl bych, kdybych refactoring udržoval smlouvu, ale ne když jsem četl, že lid mění pohled tak, aby odpovídal jakýmkoli změnám tabulky

Upravit:

Číslo 3: Vyhněte se * EXISTY. Zkuste 1/0. Funguje to. Seznam sloupců není vyhodnocen podle standardu SQL. Strana 191

20
gbn

Designové vzory většinou. Jsou nadužívané a nedostatečně využívané.

20
Geek

Zásada jednotné odpovědnosti

("Každá třída by měla mít pouze jednu odpovědnost; jinými slovy, každá třída by měla mít jednu a pouze jednu, důvod ke změně")

Nesouhlasím. Myslím, že metoda by měla mít pouze jeden důvod ke změně a všechny metody ve třídě by měly mít logický vztah k sobě navzájem , ale třída sám může skutečně dělat několik (souvisejících) věcí.

Podle mých zkušeností se tento princip příliš často aplikuje příliš horlivě a vy skončíte s mnoha malými třídami jedné metody. Oba agilní obchody, na kterých jsem pracoval, to dokázaly.

Představte si, že tvůrci rozhraní .Net API měli tento druh mentality: spíše než List.Sort (), List.Reverse (), List.Find () atd., Měli bychom mít třídy ListSorter, ListReverser a ListSearcher!

Místo toho, abych se hádal proti SRP (což samo o sobě není teoreticky hrozné) , podělím se o několik mých dlouhodobých neoficiálních zkušeností:


Na jednom místě, kde jsem pracoval, jsem napsal velmi jednoduchý max flow solver , který se skládal z pěti tříd: uzel, graf, tvůrce grafů, grafový řešič a třída pro použití grafu - tvůrce/řešitelé k řešení problému v reálném světě. Žádný nebyl zvlášť složitý nebo dlouhý (řešitel byl zdaleka nejdelší na ~ 150 řádcích). Bylo však rozhodnuto, že třídy mají příliš mnoho „odpovědností“, takže se moji spolupracovníci pustili do refactorování kódu. Když byly hotové, moje 5 tříd bylo rozšířeno na 25 tříd, jejichž celkový počet řádků kódu byl více než trojnásobný oproti původním. Tok kódu již nebyl zřejmý a nebyl ani účelem nových testů jednotek; Teď jsem měl těžké přijít na to, co můj vlastní kód udělal.


Na stejném místě měla téměř každá třída pouze jednu metodu (její jediná „odpovědnost“). Sledování toku v rámci programu bylo téměř nemožné a většina jednotkových testů spočívala v testování, které tato třída nazývala kód z jiné třídy , jejichž obojí bylo pro mě stejně záhadou. Doslova existovaly stovky tříd, kde mělo být (IMO) jen desítky. Každá třída udělala pouze jednu "věc" , ale i při pojmenování konvencí jako "AdminUserCreationAttemptorFactory" , bylo obtížné zjistit vztah mezi třídami.


Na jiném místě (které také mělo třídy-měla-mít-pouze-jedna-metoda mentalitu) jsme se snažili optimalizovat metodu, která zabírala 95% času během určitá operace. Po (trochu hloupě) optimalizaci to trochu, obrátil jsem svou pozornost k , proč to bylo nazýváno bajillion krát. To bylo voláno ve smyčce ve třídě ... jehož metoda byla volána ve smyčce v jiné třídě .. která byla také volána ve smyčce ..

Všichni říkali, že ve 13 třídách (vážně) bylo rozloženo pět úrovní smyček. To, co každá třída ve skutečnosti dělala, nebylo možné určit pouhým pohledem na to - museli jste načrtnout mentální graf toho, jaké metody to nazývalo a jaké metody tyto metody volaly atd. Kdyby to všechno bylo soustředěno do jedné metody, byla by dlouhá pouze asi 70 řádků s naší problémovou metodou vnořenou do pěti okamžitě zjevných úrovní smyček.

Moje žádost o přeřazení těchto 13 tříd do jedné třídy byla zamítnuta.

Nyní, když jste zmínili Čistý kód, ačkoliv obsahuje několik dobrých nápadů, myslím si, že jeho posedlost přeměňovat všechny metody do podoblastí a ty na dílčí metody atd. Je příliš daleko. Namísto několika desetiriadkových metod byste měli upřednostnit dvacet (pravděpodobně dobře pojmenovaných) jednořadých linií. Je zřejmé, že si někdo myslí, že je čistý, ale zdá se mi, že je mnohem horší než původní verze.

Také, nahrazování jednoduchých elementárních věcí takový jak

0 == memberArray.length

v rámci třídy s voláním do vlastní metody třídy, jako je

isEmpty()

je diskutabilní „vylepšení“ IMHO. Sčítání: Rozdíl je v tom, že první kontrola provede přesně to, co říká: zkontroluje, zda je délka pole 0. 0., isEmpty() může zkontrolovat také délku pole. Mohlo by se však také implementovat takto:

return null != memberArray ? 0 == memberArray.length : true;

To znamená, že zahrnuje implicitní nulovou kontrolu! Pro veřejnou metodu to může být jemné chování - pokud je pole nulové, pak je něco určitě prázdné - ale když mluvíme o interních třídách, není to tak v pořádku. Zatímco zapouzdření ven je nutností, interní třídy musí přesně vědět, co se ve třídě děje. Nemůžete zapouzdřit třídu od sebe . Explicitní je lepší než implicitní.


To neznamená, že rozebrání dlouhých metod nebo logických srovnání není dobré; samozřejmě to je, ale , do jaké míry to udělat - tam, kde je sladká skvrna - je samozřejmě otázka vkusu. Rozdělení dlouhé metody má za následek více metod, a to nepřichází zdarma. Musíte se přeskočit kolem zdrojového kódu, abyste viděli, co se skutečně děje, když jste to mohli na první pohled vidět, kdyby všechny tyto věci byly v jediné metodě.

Dokonce bych zašel tak daleko, abych řekl, že v některých případech je 1-line metoda příliš krátká , aby si zasloužila být metodou.

14
Joonas Pulakka

"Buďte liberální s komentáři"

Komentáře jsou určitě dobrá věc, ale příliš mnoho je stejně špatných, ne-li horších, než nedostatečných. Proč? Lidé mají tendenci vyladit komentáře, pokud vidí příliš mnoho zbytečných. Neříkám, že můžete mít dokonale samokumentující kód, ale je lepší než kód, který potřebuje komentáře pro vysvětlení.

13
Jason Baker

GoTo považováno za škodlivé

Pokud implementujete státní počítač, příkaz GOTO může mít větší smysl (čitelnost a efektivní kód) než přístup „strukturovaného programování“. Někteří spolupracovníci se opravdu obávali, když první část kódu, kterou jsem napsal v novém zaměstnání, obsahovala nejen jedno, ale několik goto prohlášení. Naštěstí byli dostatečně inteligentní, aby si uvědomili, že v tomto konkrétním případě to bylo skutečně nejlepší řešení.

Jakýkoli „osvědčený postup“, který neumožňuje rozumné a zdokumentované výjimky z jeho pravidel, je prostě děsivý.

12
MZB

Oběti, které děláme, aby byl testovatelný

Proskočím spoustou obručí, aby se můj kód stal otestovatelným, ale nepředstírám, že bych nedostal, kdyby dostal volbu. Často však slyším lidi prosazující myšlenku, že se jedná o „osvědčené postupy“. Tyto postupy zahrnují (napsané v jazyce .Net, ale platí i pro jiné jazyky) :

  • Vytvoření rozhraní pro každou třídu. Tato zdvojnásobí počet tříd (souborů), s nimiž se má jednat, a duplikuje kód. Ano, programování rozhraní je dobré, ale k tomu jsou určeny veřejné/soukromé specifikátory.
  • Každá třída, která není při spuštění instalována, potřebuje továrnu. Je zřejmé, že new MyClass() je mnohem jednodušší než psaní továrny, ale nyní je to metoda, která vytváří, že jej nelze izolovat. Pokud ne pro tuto skutečnost, udělal bych jen 1/20 z počtu továrních tříd, které teď dělám.
  • Zveřejnit každou třídu , což znemožňuje vůbec mít přístup ke specifikátorům tříd. K neveřejným třídám však nelze přistupovat (a tedy testovat) z jiných projektů, takže jedinou další možností je přesunout veškerý testovací kód do stejného projektu (a tedy jej uvolnit s konečným produktem).
  • Dependency Injection. Je zřejmé, že musím dát každou jinou třídu, kterou používám, pole a konstruktor-parametr je podstatně více práce, než jen jejich vytvoření, když je potřebuji; ale pak už nemohu tuto třídu izolovat.
  • Zásada jednotné odpovědnosti , která mi způsobila tolik bolesti hlavy, přesunula jsem ji na její vlastní odpověď .

Co bychom tedy mohli udělat? Potřebujeme drastickou změnu jazykové architektury:

  • Potřebujeme schopnost zesměšňovat třídy
  • Potřebovali bychom možnost otestovat soukromé metody interních tříd z jiného projektu (může to vypadat jako chyba zabezpečení, ale nevidím problém, pokud je testovaná osoba nucena pojmenovat svého testera -třídy).
  • Závislost injekce (nebo umístění služby), stejně jako něco ekvivalentního našemu stávajícímu továrnímu vzoru, by musela být jádrem součástí jazyka.

Stručně řečeno, potřebujeme jazyk navržený od základů s ohledem na testovatelnost .

Rozdělení aplikací do úrovní; datová vrstva, obchodní vrstva, vrstva uživatelského rozhraní

Hlavním důvodem, proč se mi nelíbí, je to, že většina míst, která sledují tuto metodu, používá k tomu velmi křehké rámce. TJ. UI Layer je ručně kódován pro práci s objekty obchodní vrstvy, objekty obchodní vrstvy jsou ručně kódovány pro řešení obchodních pravidel a databáze, databáze je SQL a je již poměrně křehký a je řízen skupinou "DBA", která nemá ráda změnu.

Proč je to špatné? Nejběžnějším požadavkem na vylepšení je pravděpodobně „Potřebuji pole na obrazovce X, které má Y.“ Bang! Máte pouze novou funkci, která ovlivňuje každou jednotlivou vrstvu, a pokud oddělíte vrstvy s různými programátory, stala se z velké části problémem více lidí a skupin, a to pro velmi jednoduchou změnu.

Navíc nevím, kolikrát jsem byl v argumentech, které jdou něco takového. "Pole názvu je omezeno na maximální délku 30, jedná se o vrstvu uživatelského rozhraní, obchodní vrstvu nebo datovou vrstvu?" A existuje sto argumentů a žádná správná odpověď. Odpověď je stejná, ovlivňuje všechny vrstvy, nechcete, aby bylo UI hloupé a muselo projít všechny vrstvy, a selhat v databázi, jen aby uživatel zjistil, že jeho vstup je příliš dlouhý. Pokud jej změníte, ovlivní to všechny vrstvy atd.

„Vrstvy“ mají sklon k úniku; Pokud je jakákoli vrstva fyzicky oddělena hranicemi procesu/stroje (I.E. webové uživatelské rozhraní a podniková backend logika), pravidla se duplikují, aby vše fungovalo přiměřeně dobře. Tj. některá obchodní logika končí v uživatelském rozhraní, i když je to „obchodní pravidlo“, protože uživatel potřebuje, aby uživatelské rozhraní reagovalo.

Pokud je použitá struktura nebo použitá architektura odolná vůči malým změnám a únikům, tj. Na základě metadat, a dynamicky upravená ve všech vrstvách, může být méně bolestivá. Ale většina rámců je to královská bolest, vyžadující změny uživatelského rozhraní, změny obchodní vrstvy a změny databáze, pro každou malou změnu a způsobující více práce a méně pomoci, než by tato technika měla přinést.

Pravděpodobně na to narazím, ale je to :)

10
Jay

JavaBeans

Použití JavaBeans v Javě. Viz moje otázka Proč bych neměla používat neměnné POJO místo JavaBeans? na StackOverflow.

9
Jonas

Příběhy uživatelů/Pouzdra/Personas

Chápu, že je to zapotřebí, když programujete odvětví, které neznáte, ale myslím si, že když jsou implementovány v plné síle, stanou se příliš korporátní a ztrácí se čas.

7
riwalk

80 znaků na řádek je hloupé

Chápu, že je třeba učinit určité kompromisy, aby odpovídaly tempu nejpomalejšího běžce na straně GUI (omezení rozlišení obrazovky atd.), Ale proč se toto pravidlo vztahuje na formátování kódu?

Viz ... Byl to malý vynález zvaný horizontální posuvník, který byl vytvořen pro správu prostoru virtuální obrazovky mimo hranici pravého pixelu. Proč vývojáři, kterým se podařilo vytvořit skvělé nástroje zvyšující produktivitu, jako je zvýraznění syntaxe a automatické dokončení, nepoužívají?

Jistě, existují editory CLI nábožensky používané dinosaury * nix, které sledují unavená stará omezení svých terminálů VT220, ale proč jsme my ostatní drženi na stejné úrovni?

Říkám, zašroubujte limit 80 znaků. Pokud jsou dinosauři dost epičtí na to, aby celý den pronikli na emacs/vim, proč by neměli být schopni vytvořit rozšíření, které automaticky zalomí řádky nebo poskytne jejich IDI CLI horizontální rolování?

Monitory pixelů 1920 x 1080 se nakonec stanou normou a vývojáři na celém světě stále žijí pod stejnými omezeními bez ohledu na to, proč tomu tak je, kromě toho, o čem jim řekli starší, když právě začali programovat.

80 znakových limitů je ne osvědčeným postupem, ale zvláštním postupem pro velmi menšinu programátorů a mělo by se s nimi zacházet jako s nimi.

pravit:

Je pochopitelné, že mnoho devs nemá rád vodorovný posuvník, protože vyžaduje gesto myši, takže ... Proč nezvýšit limit šířky sloupce na vyšší číslo (než 80) pro ty z nás, kteří používají moderní displeje.

Když se počítačové monitory 800x600 staly normou pro většinu uživatelů, vývojáři webu zvýšili šířku svých webových stránek, aby vyhověli většině ... Proč vývojáři nemohou dělat totéž.

7
Evan Plaice

Měření, měření, měření

Tak v pořádku, změřte je, ale pro izolaci chyby ve výkonu, měření prací a následné odstraňování. Zde je metoda, kterou používám.

Snažil jsem se vystopovat zdroj míry-moudrosti. Někdo s dostatečně vysokou mýdlovou schránkou to řekl a teď to cestuje.

5
Mike Dunlavey

Použijte Singletons

Když byste měli mít jen jednu instanci něčeho. Nemohu nesouhlasím další. Nikdy nepoužívejte singleton a přidělte jej pouze jednou a podle potřeby projeďte kolem ukazatele/objektu/odkazu. Neexistuje absolutně žádný důvod to nedělat.

5
user2528

Můj učitel požaduje, abych začal všechny své identifikátory (bez konstant) malými písmeny, např. myVariable.

Vím, že se to jeví jako malá věc, ale mnoho programovacích jazyků vyžaduje proměnné začíná velkými písmeny. Vážím si konzistence, takže je zvykem začít všechno velkými písmeny.

5
Maxpm

Použití nepodepsané int jako iterátor

Kdy se dozví, že používání podepsané int je mnohem bezpečnější a méně náchylné k chybám. Proč je tak důležité, aby index pole mohl být pouze kladným číslem, že každý je rád, že přehlédne skutečnost, že 4 - 5 je 4294967295?

5
AareP

Metody by neměly být delší než jedna obrazovka

Plně souhlasím se zásadou jediné odpovědnosti, ale proč ji lidé vnímají jako „funkci/metodu, která může mít jen jednu odpovědnost na nejvyšší úrovni logické granularity“?

Myšlenka je jednoduchá. Funkce/metoda by měla splnit jeden úkol. Pokud lze část této funkce/metody použít jinde, nasekejte ji na vlastní funkci/metodu. Pokud by mohl být použit kdekoli na projektu, přesuňte jej do své vlastní třídy nebo třídy užitečnosti a zpřístupněte jej interně.

Mít třídu, která obsahuje 27 pomocných metod, které se v kódu nazývají jen jednou, je hloupé, plýtvání prostorem, zbytečné zvyšování složitosti a masivní časové klesání. Zní to spíš jako dobré pravidlo pro lidi, kteří chtějí vypadat rušným refaktorským kódem, ale neprodukují moc.

Tady je moje pravidlo ...

Napište funkce/metody k dosažení něčeho

Pokud zjistíte, že se chystáte zkopírovat/vložit nějaký kód, zeptejte se sami sebe, zda by pro tento kód bylo lepší vytvořit funkci/metodu. Je-li funkce/metoda volána pouze jednou v jiné funkci/metodě, existuje skutečně smysl ji mít na prvním místě (bude v budoucnu častěji nazýván). Je užitečné přidat další skoky do/z funkcí/metod během ladění (tj. Usnadňuje nebo ztěžuje přidaný skok ladění?

Plně souhlasím s tím, že funkce/metody větší než 200 řádků je třeba podrobně prozkoumat, ale některé funkce splňují pouze jeden úkol v tolika řádcích a neobsahují žádné užitečné části, které by mohly být odebrány/použity ve zbytku projektu.

Dívám se na to z pohledu API dev ... Pokud by se nový uživatel měl podívat na diagram třídy vašeho kódu, kolik částí tohoto diagramu by mělo smysl v rámci celého projektu a kolik by existovalo pouze jako pomocníci k dalším částem vnitřním pro projekt.

Kdybych si měl vybrat mezi dvěma programátory: první má tendenci psát funkce/metody, které se snaží udělat příliš mnoho; druhá přeruší každou část každé funkce/metody na nejjemnější úroveň granularity; Vybral bych první ruce dolů. První by dokázal dosáhnout více (tj. Napsat více masa aplikace), jeho kód by se dal lépe ladit (kvůli menším skokům v/z funkcí/metod během ladění) a ztrácel méně času tím, že by vykonával náročnou práci a zdokonaloval jak kód vypadá vs zdokonalení toho, jak kód funguje.

Omezte zbytečné abstrakce a neznečišťujte automatické doplňování.

4
Evan Plaice

Absolutistické, přísné, zapouzdření

Většinou souhlasím se zapouzdřením, ale bylo skutečným osvoboditelem dočasně porušit toto pravidlo, aby byl nějaký procedurální kód převeden na OOP pomocí Refactoring pole . ( Potřeboval trochu Push, aby se trochu uvolnil. Díky, Martin Fowler)

  • Pole

    ->

  • nová třída s maticí jako veřejná vlastnost

    ->

  • projít klientský kód/přidat přístupové jednotky

    ->

  • pouze tehdy zapouzdřit a učinit jej soukromým/chráněným

2
JW01

Přes generalizaci.

Čtvercový blok NEPATŘÍ do kruhového otvoru!

1
PMV

Pouze jeden, na který mohu myslet, formátuje příkazy Java if) takto:

if (condition) ...

namísto

if(condition) ...

Z velké části jsem zjistil, že nejlepší postupy jsou nejlepší, a jakékoli počáteční výhrady, které mám s nimi, bývají nesprávně umístěny nebo potlačeny závažnějšími obavami.

1
Armand

"Pokud se to nerozbije, neopravujte to." Kód je vždy zlomený. Důvod, proč původní vývojář nikdo neříká, je ten, že

  1. myslím, že je to jejich vlastní chyba,
  2. nevím, koho kontaktovat,
  3. nemůžu získat podporu mluvit s "techie",
  4. nelze obtěžovat, nebo
  5. nevím, jak problém popsat dostatečně podrobně.
1
l0b0

Vždy dávejte přednost zkráceným tvarům dlouhých, explicitních, proměnných a rutinních jmen

např. upřednostňování autentizace před AuthN

This bit me , když cesty k souborům MS dostaly tak dlouho, že se moje pracovní kopie Subversion nemohla načíst do mého PC.

Viz: https://stackoverflow.com/questions/3282303/my-choice-of-class-names-is-hampered-by-windows-xp-max-path-length-issues-with-sv

1
JW01

Mám sklon ignorovat téměř všechny osvědčené postupy, když dělám relativně malý jednorázový projekt, jako je psaní parseru potřebného k migraci souborů. Když vše, co potřebuji, je výsledek, jednou mi nezáleží na readablitiy, škálovatelnosti, udržovatelnosti atd.

1
user281377

Threading je odpovědí na všechny problémy s výkonem

S tím nesouhlasím z mnoha důvodů.

  • Obecně indexování a dočasné ukládání do mezipaměti poskytuje mnohem větší podporu výkonu. Samozřejmě budete možná muset použít "špinavé vlajky" .. Aby byl váš návrh chaotický a tak ..

  • Problémy, které přicházejí z vícevláknové nadváhy, jsou časově i finančně výhodné.

  • Technologie s více jádry nás ve skutečnosti přinesla lépe ve více úlohách (spuštění několika aplikací stejně rychle jako jedna). Využití dovedně psaných multithreadingových programů je jen vedlejším účinkem.

0
AareP

POKRAČOVÁNÍ POKRAČOVÁNÍ IS BAD

Zde se budu odkazovat na normy kódování C++ Joint Strike Fighter Air Vehicle C++:

AV Rule 190 (MISRA Rule 57) Bude použito pokračovatnesmí být.

a můj profesor:

„POKRAČOVÁNÍ POKRAČOVÁNÍ IS BAD“

Jejich logika spočívá v tom, že narušuje kontrolní tok a činí kód méně čitelným. Použití vnořených pokud příkazů je čistší přístup.

Přesto to považuji za čitelnější:

 
for(int i = 0; i < CONST_FOO; ++i) {
    if(aTwo[i] == NULL) continue;
    aTwo[i]->DoBar();
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
}
 

Než tohle:

 
for(int i = 0; i < CONST_FOO; ++i) {
    if(aTwo[i] != NULL) {
        aTwo[i]->DoBar();
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
    }
}
 

Toto je velmi zjednodušující příklad (představte si, že vnořené ifs jde mnohem více než na jednu úroveň), ale je to podobné směšnému „pouze jednom návratovému prohlášení za nejlepší“ praktickou funkci. Zabraňuje debuggeru přeskakovat (asi několik stránek), menší odsazení obecně umožňuje snadno čitelný kód atd.

0
Casey

V JavaScriptu mnozí považují za nejlepší postup psát všechny středníky, které by potřebovali v jiných pobočkových jazycích C (a mnoho z nich se nebojí poukázat na „chybu“, kdykoli uvidí kód, který by mohl mít více středníků). Nikdy jsem je nepotřeboval, jejich role vizuálního markeru je již naplněna posuny čar.

Na vedlejší poznámce je docela zábavné vidět kompilátor vyžadující středníky, ale stále s jistotou vyvolá chybu „Chybějící středník“. "Oba víme, co jste chtěli napsat, ale vaši žádost musím zamítnout, protože jsem formálně nesměl rozlišovat mezi mezerami a posuny řádků."

Rozšiřuje se řada dalších osvědčených postupů ve stylu JavaScriptu, ale žádný z nich se blíží, pokud jde o humbuk, bez kvalifikovaných argumentů.

Edit: Je možné minifikovat kód bez středníků Closure Compiler vloží je podle potřeby.

0
aaaaaaaaaaaa

Jedno z mých horkých tlačítek je analýza výkon . Lidé říkají

Předčasná optimalizace je kořenem všeho zla.

A pak říkají, že kompletní nabídka je:

Měli bychom zapomenout na malou efektivitu, řekněme asi 97% času: předčasná optimalizace je kořenem všeho zla. Přesto bychom v tomto kritickém 3% neměli předávat své příležitosti.

Což dává perfektní smysl, když diskutujete o „algoritmech“ - chytré akademické věci, kde 3% programu mohou být dva řádky kódu.

Pracuji v 10 ^ 6 řádkových aplikacích, s 10 ^ 5 metodami v 10 ^ 4 třídách, na kterých jsem pracoval přes tucet programátorů a testerů, prošel četnými revizemi a vydáními, kde tento citát nemá vůbec žádný význam. Obvykle jsou časové odtoky jediné řádky kódu, což mohou být „příležitosti“, ale nikdo by nikdy nemohl hádat, kde jsou.

OTOH, lidé říkají „profil“, nebo říkají „opatření“. Tak dobře. Říkají to, ale často to nedělají. Mohlo by to být proto, že to nedělají , že to nefunguje dobře .

Tato odpověď říká o tom více a poukazuje na to, co funguje .

0
Mike Dunlavey

Databinding

Nesnáším to a miluji to. (Závisí na složitosti projektu)

0
Amir Rezaei