jak byste začali?
Pokud jste byli vývojářem v agilním týmu, vaším jediným cílem je splnit cíle sprintu. Pokud ano, v 80% případů se vám bude dařit tím, že začnete rozvíjet uživatelské rozhraní. Protože to dává celému týmu určitou validaci a pocit pokroku.
váš sólový vedlejší projekt se však nemusí spoléhat na Agile. Nesmíte se zodpovídat nikomu kromě sebe. Nejprve byste se měli pokusit udělat nejtěžší část. Mluvím o skutečném objetí bestie.
Chcete-li vytvořit kick-ass produkt, budete vždy potřebovat 1024 věcí kromě řešení základního problému. Musíte si být velmi vědomi správy závislostí.
Musíte udělat, správa uživatelů, protože je to vstupní bod pro data. Uživatelská data jsou a budou vaší nejcennější komoditou až do dne, kdy se rozhodnete prodat svůj podnik Facebook nebo Google.
s tím přichází síťování. Pamatujete si manipulaci s užitečným zatížením? Budete muset ukládat offline data a dodávat je prostřednictvím integrace mobilní aplikace / Dropbox, v případě, že se váš nejcennější spotřebitel přenese do Grónska nebo Konga.
a s tím, jak byste mohli zapomenout na náklady spojené s přenosem dat? Musíte definovat protokol, který nákladově efektivně nese vaše užitečné zatížení mezi stranami: HTTP, Websockets, TCP (Protobuffers) nebo něco jiného?
bezpečnost Dat je konec-závislost v řetězci jakmile jste definovali všechny ostatní závislosti (pokud vaše základní nabídka je řešit bezpečnostní problém).
Jak šifrujete data od začátku do konce? SHA? MD5? Jak budete implementovat handshake veřejného a soukromého klíče?
Pokud znáte tyto relevantní podmínky, je snadné hledat na Githubu nebo požádat o názory na fórech. Dobrým výchozím bodem je vyhledat některý z těchto výrazů na Wikipedii a odtud se propracovat nahoru.
dozvíte se o nich, dozvíte se o jejich alternativách a během krátké doby budete odborným soudcem v každé technologii, kterou si vyberete pro svůj projekt.
Další: implementujte je všechny. Bez psaní jediného řádku obchodní logiky, to je.
ujistěte se, že jste si to přečetli správně.
v kostce: udržujte ji co nejvíce oddělenou od vaší obchodní logiky. Psát s rozhraními, psát s abstraktními třídami / strukturami. Proveďte konkrétní testovací pahýly a vyzkoušejte je.
Ano, Chcete-li to vše otestovat pomocí uživatelského rozhraní primate, musíte napsat několik testovacích případů. Populární rada v softwaru je o začátku testovacích případů, než napíšete řádek kódu.
TDD poskytuje informace o vaší kódové základně, které odborný recenzent nemůže. Jakmile provedete další krok, uvědomíte si jeho obrovskou hodnotu.
vždy pamatujte: zde byste se mohli pokazit tisíci způsoby. Ale tento krok je mnohem víc než lekce.
práce zde není nikdy ztracena. Je opakovaně použitelný, protože je Agnostický pro obchodní logiku. Když tento projekt zničíte, nezapomeňte, že toto zvíře můžete vždy znovu použít, abyste urychlili všechny své budoucí projekty. Váš čas na rozvoj půjde dolů exponenciálně.