Articles

Clean Swift

by admin

rezonați cu oricare dintre următoarele?

  • controlerele de vizualizare devin masive și greu de înțeles, remediază erorile și adaugă funcții noi?
  • Bine, ai mutat logica de afaceri la modele. Dar acum modelele tale devin prea grase.
  • aplicația dvs. utilizează un storyboard gigantic?
  • v-ați pierdut vreodată 4 ore pentru a încerca să reproducă un bug, și apoi o săptămână pentru a remedia problema? Și tot nu pleci nicăieri? Gata să-l doar maimuță patch-uri?
  • adăugarea unei noi caracteristici înseamnă regresie și mai mult re, re, re-factoring?
  • te simți vinovat când clientul tău spune”asta a funcționat”?
  • compromisul efort vs beneficiu cu TDD pur și simplu nu merită.

desigur, știm cu toții că testarea vindecă toate aceste probleme. Dar ai încercat să scrii teste unitare și ai renunțat.

motivul numărul unu pentru care oamenii renunță la TDD și la testare este pentru că scriu teste deasupra unei arhitecturi de aplicații proaste.

gândiți-vă la asta. Dacă poți construi cea mai frumoasă casă din lume, dar pe o fundație proastă, casa se va prăbuși. Același lucru este valabil și pentru arhitectura aplicației dvs.

am încercat în mod repetat de-a lungul anilor să lucrez cu teste unitare (în special cu iOS) și nu am reușit să găsesc o modalitate care să aibă sens și să o facă într-un mod în care timpul vs beneficiile se plătesc. Simt că am găsit-o în această arhitectură.
– Darren Ehlers

dar nu trebuie să fie așa. Nu trebuie să rămâi cu MVC. Deci, sunteți pe cale să căutați ceva mai bun.

  • sunteți convins că MVC nu este calea de a merge mai departe.
  • Deci ați încercat MVVM cu ReactiveCocoa, dar trebuie să învățați un lucru nou. Mai multe dependențe, Yikes!
  • sau chiar VIPER. Dar configurarea tuturor interfețelor în wireframe este atât de complexă. Și nu poți folosi segues.
am început să implementez arhitectura Swift curată doar pentru a o compara cu arhitectura originală VIPER. Trebuie să spun că ai făcut o treabă excelentă cu ea și îmi place foarte mult să citesc postările tale.
– Razvan

Ce se întâmplă dacă nu trebuie să învețe încă un alt cadru? Nu trebuie să adăugați nicio dependență nouă.

Imaginați-vă că puteți prelua controlul asupra codului. Puteți ști rapid și exact unde sunt lucrurile. Puteți remedia erorile și puteți adăuga noi funcții cu încredere. Puteți descompune fluxul de aplicații în mai multe storyboard-uri. Și da, puteți continua să utilizați segues. Și nu, nu există nici un cadru care să vă confunde.

În cele din urmă, puteți face clienții să spună da la plata pentru TDD și să le arătați dovezi solide cum se plătește investiția lor. Veți putea identifica cu încredere unde se află un bug și veți avea un răspuns fără vinovăție la cel mai temut comentariu-acesta funcționa.

o arhitectură bună a aplicațiilor facilitează testarea.

trebuie doar să introduceți numele și adresa de e-mail de mai jos. Veți face un prim pas uriaș pentru a vă nivela abilitățile de dezvoltare iOS și pentru a vă impresiona colegii cu cod și teste curate. Veți învăța cum să aplicați arhitectura curată a unchiului Bob în aplicațiile dvs. iOS.

Mă bucur să te am la bord.

acum că v-ați abonat, veți primi un link în căsuța de e-mail pentru a descărca șabloanele mele curate Swift Xcode pentru a genera automat toate componentele pentru dvs. Nu pierdeți timpul scriind același cod de șabloane. Concentrați-vă pe scrierea logicii dvs. de afaceri.

șabloanele dvs. funcționează ca un farmec. Totul este foarte îngrijit și prefer modelul de arhitectură curat decât VIPER.
– Augustin

de asemenea, ar trebui să citiți arhitectura iOS rapidă curată pentru fixarea controlerului de vizualizare masiv pentru a obține o introducere în curățarea Swift. Acest post demonstrează conceptele folosind un exemplu direct de la unchiul Bob însuși. De asemenea, vă conduce prin modul de utilizare a șabloanelor Xcode pentru a genera componentele Swift curate. Deci, veți începe să implementați logica de afaceri a aplicației dvs. în cel mai scurt timp.

în următoarele săptămâni, vom analiza și următoarele subiecte:

  • aplicați Clean Swift și ciclul VIP la codurile de probă ale Apple
  • puneți metodele delegate în vederea controlerului, interacatorului sau lucrătorului
  • router avansat cu mai multe storyboard-uri
  • scrieți teste rapide și întreținute cu încredere pentru a face modificări
  • o abordare exterioară a testării – de la acceptare la teste unitare
  • scriind propriile batjocuri și
  • compara Swift curat, MVVM + Reactivecocoa, și Viper
  • programare orientată spre protocol și Swift curat
  • conversia ta proiect existent pentru a curăța Swift
  • cum Clean Swift efectua într-un proiect mare
  • extragerea cod comun pentru reutilizare în lucrători și obiecte de serviciu
  • Cum de a rupe în jos logica de afaceri complexe folosind lucrătorilor

Dacă doriți mă să scrie oricare dintre aceste subiecte special în primul rând, sau dacă aveți alte subiecte întregi în minte, drop-mi un e-mail.

De asemenea, dacă lucrați cu Objective-C și doriți să mă ajutați să testez o versiune Objective-C a șabloanelor Xcode, trimiteți-mi un e-mail după ce vă abonați.

îmi place să aud cum aplicați Clean Swift proiectelor dvs. iOS.

trebuie să spun că arhitectura VIP este într-adevăr în creștere pe mine. Cu ajutorul șabloanelor, totul devine clar și foarte simplu, fără senzația că arhitectura produce prea mult cod de șabloane.
– Mihai