rezonovat s některou z následujících?

• stávají se vaše ovladače zobrazení masivní a těžko pochopitelné, opravují chyby a přidávají nové funkce?
• dobře, přesunuli Jste obchodní logiku na modely. Ale teď jsou vaše modely příliš tlusté.
• používá vaše aplikace jeden gigantický storyboard?
• už jste někdy promarnili 4 hodiny, abyste se pokusili reprodukovat chybu,a pak týden ji opravit? A stále nikam? Jste připraveni to jen opravit?
• Přidání nové funkce znamená regresi a další re, re, re-factoring?
• cítíte se provinile, když váš klient říká „to fungovalo“?
• úsilí vs benefit kompromis s TDD prostě nestojí za to.

samozřejmě všichni víme, že testování všechny tyto problémy vyléčí. Ale Zkoušeli jste psát jednotkové testy a vzdali jste to.

důvodem číslo jedna, proč se lidé vzdávají TDD a testování, je to, že píší testy na špatnou architekturu aplikace.

Přemýšlejte o tom. Pokud můžete postavit nejkrásnější dům na světě, ale na špatném základu, dům se zhroutí. Totéž platí pro vaši aplikační architekturu.

Ale nemusí to tak být. Nemusíte se držet MVC. Takže jste na cestě hledat něco lepšího.

• jste přesvědčeni, že MVC není cesta vpřed.
• takže jste vyzkoušeli MVVM s ReactiveCocoa, ale musíte se naučit novou věc. Další závislosti, Yikes!
• nebo dokonce VIPER. Ale nastavení všech rozhraní v drátovém rámu je tak složité. A nemůžete použít segue.

Co když se nemusíte učit další rámec? Nemusíte přidávat žádnou novou závislost.

Představte si, že můžete převzít kontrolu nad svým kódem. Můžete rychle a přesně vědět, kde jsou věci. Můžete opravit chyby a přidávat nové funkce s důvěrou. Tok aplikací můžete rozdělit na více storyboardů. A ano, můžete pokračovat v používání segues. A ne, neexistuje žádný drátový model, který by vás zmátl.

a Konečně, můžete si klienti říkají, ano platí pro TDD, a ukázat jim důkaz, jak se jejich investice vyplatí. Budete moci s jistotou určit, kde leží chyba, a mít odpověď bez viny na nejobávanější komentář-to fungovalo.

dobrá architektura aplikace usnadňuje testování.

stačí zadat své jméno a e-mail níže. Uděláte obrovský první krok k tomu, abyste vylepšili své vývojové dovednosti pro iOS a zapůsobili na své vrstevníky čistým kódem a testy. Naučíte se, jak aplikovat čistou architekturu strýčka Boba na aplikace pro iOS.

jsem rád, že jste na palubě.

Nyní, že jste se zaregistrovali, budete mít odkaz v přijaté ke stažení můj Čistý Swift Xcode šablony automaticky generovat všechny komponenty pro vás. Neztrácejte čas psaním stejného kódu kotle. Zaměřte se na psaní své obchodní logiky.

měli byste Si také přečíst Čisté Swift iOS Stylu pro Upevnění Masivní View Controller, aby si úvod do Čisté Swift. Tento příspěvek demonstruje koncepty na příkladu přímo od samotného strýčka Boba. Také vás provede tím, jak používat šablony Xcode ke generování čistých komponent Swift. Takže začnete implementovat obchodní logiku vaší aplikace v žádném okamžiku.

během několika příštích týdnů se také hluboce ponoříme do následujících témat:

• Naneste Čistý, rychlý a VIP cyklu Apple ukázkové kódy
• Dát vaše delegát metody v view controller, někdo, kdo se zapojuje, nebo pracovníka
• Pokročilý router s více storyboardy
• Napsat rychle a udržovatelný testy s důvěrou, aby se změny
• vnější-v přístupu k testování – od přijetí na jednotku testy
• Psaní své vlastní zesměšňuje a pahýly
• Hluboký ponor do sebe Čisté Swift komponenty
• Porovnat Čisté Swift, MVVM + ReactiveCocoa, a VIPER
• Protokol-orientované programování a Čisté Swift
• Převod stávající projekt Čisté Swift
• Jak se Čistí Swift provádět ve velkém projektu
• Získávání společný kód pro opětovné použití v pracovníků a služby, objekty
• Jak rozložit složité obchodní logiky pomocí pracovníků

Pokud mi chceš psát nějaké z těchto konkrétních tématech poprvé, nebo pokud máte celou další témata v mysli, napište mi e-mail.

také, pokud pracujete s Objective-C a chtěli byste mi pomoci otestovat Objective – C verzi šablon Xcode, napište mi po přihlášení k odběru.

rád slyším, jak aplikujete Clean Swift na své projekty iOS.