За всеки програмист концепция за "чист код" по-различно. В тази статия ще се опитам да предам своите мисли по въпроса, а може би в някои отношения дори да променят старите подходи.
Така че какви критерии се определя чистотата на кода?
назначаване
Понякога е много трудно и "философски" въпрос. Основни правила:
- Името на променливата трябва да бъде възможно най-кратък и възможно най-ясно, за да отговори на въпросите "какво се съхранява в променливата" и "как ще се използва променливата." Разбираемо е, има по-висок приоритет от краткост. Същото важи и за функции;
- camelCase да използват имена на променливи и функции, които се състоят от няколко думи;
- само на английски език. Това често се случва, че първата версия на проекта, пише разработчиците в една страна, а втората версия - от другата. И френскоговорящата разработчик не разбира това, което той искаше да каже bolgarskogovoryaschy именуване променливи Var moiTovary. Var диапазон. Var ssylka;
- кратки имена като «вариация, нека б» има смисъл да се използват само локални променливи в малка програмка.
Основните критерии, които следя, когато пишете функции:
- създаването на нови функции, вместо код дублиране. Ако в 2 места има същия код на 2-3 или повече линии, е необходимо да се направи тази част от кода в отделна функция.
форматиране
форматирането на кода е много важно както за удобство на подкрепа за проекта, както и за скоростта и удобството на ориентация в проекта структура, променливи и функции. Придържайки стил на форматиране, приета от дружеството, е по-лесно да се включи в работата на разработчиците, които се присъединиха към проекта в процес на развитие, защото развитието те се ръководят от същите принципи, както разработчиците, които са довели проекта от нулата.
Един пример за структура на проект:
Спазването на проекта единна структура ускорява търсенето на правилните файлове. Не по-малко важно е, класовете формат. неговите основни принципи:
Един файла - един клас (структура).
Подробности за покупки:
По-пълен списък на Pragma марки:
Код изглежда по-структуриран, ако функциите и променливите са форматирани с помощта PragmaMarks в определена последователност, а не случаен. Лично аз добавя списък в Xcode като откъси, за удобство.
Добра практика, когато една компания има документ, с имена като «IOS Код стилове Guidline», които се запознават новия служител, преди работа и след това да форматира кода в очакваното стил.
рефакториране
Рефакториране - се контролира от процеса на подобряване на кода си, без да се налага да пиша нова функционалност. Рефакториране задача - да направят кода чист.
Писане код може да бъде разделена на 2 точки: да се направи, за да кода, за да работят и да Преструктуриране на кода. Какво би могло да развали нашия код? Неща като:
архитектурни модели
Използването на архитектурни модели позволява балансирано разделение на отговорностите между лица. Идеята за "модел" може да се обясни като шаблон стил, предназначен за решаване на конкретен проблем. Архитектурен модел определя структурата на заявлението като цяло, определя разпределение на задълженията между класовете, всеки от които играе само роля. Архитектурният модел (също може да се нарече - модел дизайн) определя не само ролята на класове и обекти в приложения, но също така и как обектите да комуникират помежду си.
Основният дизайн модел в Apple (MacOS IOS) е MVC (Model-View-Controller). С течение на времето, имаше още няколко, а като резултат от днес, в списъка на основните архитектурни модели е, както следва:
- MVC (Model-View-Controller);
- MVP (Model-View-пасивен Presenter);
- MVVM (Model-View-ViewModel);
- Viper (CleanSwift).
Това е най-често използваният модел. Той класифицира обекти в съответствие с тяхната роля в проекта, който помага на чиста разделяне на код. Правилното прилагане на MVC модел означава, че обектът само един от 3 групи влиза.
Вижте - обекти, които са отговорни за визуално представяне на това, което вижда на потребителя. В IOS - всичко е от класовете, които имат UI префикс (и техните наследници).
Sontroller - посредник между Вижте аз модел. Координати цялата работа: в отговор на действията на потребителите, извършено на преглеждане и актуализация на гледката, с помощта на модела.
В идеалния случай, гледката е напълно отделна от модела и не знам нищо за този модел. Това ще позволи на мнение, за да се покаже други данни.
Използване на MVC, получаваме следните предимства:
- по-добро разбиране на класовете;
- повторно използване на класове, включително и в други проекти (най-вече по отношение на модел и изглед);
- тестване класове отделно един от друг;
- в сравнение с други модели на този модел е най-просто и ясно да се използват и по-малко разходи в контекста на времето.
Недостатъкът на MVC е, че с течение на времето, когато проектът постепенно се увеличава и променя, контролер софтуер се разраства и може да достигне нивото от 1000 реда код в някои проекти и повече, и все повече и повече усложнява подкрепата за проекта: bagfiksing или да добавите нова функционалност. Поради тази причина, някои предприемачи "декодиране" акронима MVC като «Масивна» ViewController :) Докато ние правим едно нещо, ние се страхуват да се прекъсне нещо друго. В резултат на това се работи с контролера, разработчикът не може да се оцени правилно задачата, не се побира в определеното време, губи доверието и репутацията от клиенти. Би могло да има виновен клиента, защото:
- клиентът не иска да разбере колко трудно е да се въведе такава голяма част от функционалността на един екран;
- клиентът не разбира, че не може да се промени, изисквания в техническото задание;
- клиент се опита на няколко пъти, за да обясни, че първо трябва да се съсредоточи върху UX, а не на UI-дизайн;
- ако клиентът в началото на проекта, посочи тази функционалност, че ще отнеме много по-малко време ...
- опцията си :)
Но всичко това не отрича факта, че ситуацията отново и отново да се повтори.
Как може да "разтоварят» ViewController?
MVP-модел "еволюира" от MVC и се състои от три компонента:
- Водещ (независим посредник UIKit);
- Пасивно View (UIView и / или UIViewController);
- Модел.
Този модел определя Преглед като получаването на UI-събития от страна на потребителя и след това призовава съответното Presenter, ако е необходимо. Водещ е отговорен за актуализиране на изгледа с новите данни, получени от модела.
Предимства: по-добро разделяне на код е добре изследвани.
Недостатъци: в сравнение с MVC е много по код развитие и подкрепа отнеме повече време.
Този модел е полезен при проекти, които използват рамки като ReactiveCocoa аз RxSwift, в които има понятието "задължителни данни" - данни, свързващи се с визуални елементи на двустранна основа. В този случай, използването на модела MVC е много неприятно, тъй като данните за свързване към изгледа (Изглед) - това е нарушение на принципите на MVC.
Преглед (ViewController) и модел са "посредник» - Преглед на модела. Преглед на модела - това не зависи от представянето UIKit View. Преглед на модела води до промени в модела и актуализира себе си с вече актуализиран модел, и като задължителен става чрез View, гледката е актуализиран, също.
Недостатъкът е, че "вместо 1000 реда в ViewController може да излезете от 1000 линии в ViewModel». Също така един от проблемите на рамки да се използва "реактивен програмиране" - просто смачка всички и може да се извърви много дълъг път, за да bagfiksing. За някои може да изглежда, че RxSwift, например, е по-лесно да се напише код, но просто погледнете стека на повикване друг метод "RX-", за да се оцени това "опростяване". Можете да добавите и тук проблемът с документацията и постоянни проблеми с автомобил пълен с Xcode.
Viper (CleanSwift)
Interaptor съдържа бизнес логиката, свързани с това (лица).
Водещ съдържа бизнес логиката, свързан с потребителския интерфейс (но UIKit-независими), извиква методи в Interaptor.
Entity - просто обекти с данни, те не са един слой за достъп до данни, тъй като тя е Interaptor на отговорност.
Router е отговорен за преходи между VIPER-модули.
Дори и с такъв повърхностен преглед става ясно, че по-добро разделение на труда се получава поради големия брой на класовете с малък брой отговорности.
Свързани статии