Проектування архітектури iOS: Мотивація

Давайте підходимо до теми створення власної архітектури в цій серії статей.

Що таке архітектура?

Архітектура - це найвищий рівень дизайну системи.

Дизайн системи - це спосіб полегшити виробництво коду для програми.

Додаток - це середовище, необхідне для досягнення (ділової) мети.

Чи можу я пропустити це?

Навіть коли ви не готуєте дизайн системи перед тим, як зробити додаток, вам все-таки потрібно подумати, перш ніж писати будь-який код, і це називається випадковим дизайном системи, що призводить до випадкової архітектури (AA).

Виявити випадкову архітектуру легко:
Питання: Чому наш код такий некрасивий?
A: Історичні причини ...

Що я здобуду?

Мета створення формальної архітектури, а не перехід на кодування матеріалів, полягає у встановленні керівних принципів, обмежень та шаблонів, відповідно до яких код буде рости.

Подумайте про створення архітектури як прокладку залізниці для коду, який рухатиметься по ній, як поїзд.

Чому я б стримувався?

Вказівки, обмеження та шаблони допомагають:

  • код, що дотримується принципу найменшого здивування;
  • зрозуміти, як працює існуюча система;
  • уникайте винаходити колесо;
  • поширювати робочі ідеї у громаді.

Чи можу я використовувати один із них з Інтернету?

Вам слід навчитися тому, але всі вони страждають від багатьох проблем:

  • не надавати стратегій зростання;
  • добре підходить лише для одного розміру програм та команди;
  • випадковий рівень абстрагування компонентів та зв'язку;
  • розпливчастий розподіл ролей (я дивлюся на вас «Робітник»);
  • невблаганний і фанатичний;)

Чи є у мене достатньо навичок, щоб його розробити?

Нікого не вистачає, але чим більше у вас є, тим легше бачити світло в кінці тунелю.
Ось що вам допоможе:

  • читати старі книги та довідки про дизайн системи та шаблони;
  • уникайте нових статей, які намагаються продати вам срібну кулю;
  • дізнайтеся, що працює на інших у виробництві;
  • використовувати інші платформи як джерело натхнення;
  • спробуйте ідеї вдома, якщо вони працюють, приведіть їх до роботи;
  • відкладіть рішення, якщо ви сумніваєтеся (зробіть тим часом тупу річ);
  • обговорювати ідеї та реалізацію з іншими.

З чого почати?

Ми завжди повинні починати з аналізу вимог (як у будь-якому зрілому починанні), які випливають з мети.

Функціональні вимоги.

У гіршому випадку ви можете отримати функціональні характеристики високого рівня, наприклад:

  • Заявка на список покупок;
  • Можливість співпрацювати за списками;
  • Можливість користуватися без підключення до Інтернету.

На цьому етапі бізнес може подумати, що вимоги є достатніми, і ви зобов'язані знайти відповіді на рій питань, які виникають, наприклад:

  • Як буде виглядати інтерфейс користувача?
  • Які пристрої має підтримувати додаток?
  • Чи потрібно також робити серверну сторону?

Коли ви не можете придумати інші запитання, настав час перейти до наступного етапу.

Організаційні вимоги.

Якщо це не greenfield проект, можливо, існує багато обмежень щодо вибору вашої архітектури, хоча б спробуйте відповісти на ці питання:

  • Хто моя команда?
  • Чого вони очікують від нашої архітектури?
  • Чи є у нас створені інструменти та мови?
  • Чи можемо ми використовувати повторно існуючу архітектуру?

Чи можу я нарешті почати робити архітектуру?

Так, ти можеш! Поставивши функціональні та організаційні вимоги разом, ви можете почати викладати свої ідеї, а потім, нарешті, скласти офіційну Архітектуру! Але це зовсім інша історія, щоб розповісти ...

Чи можу я зараз піти додому?

Перш ніж перенести свої ідеї в дику природу, я пропоную вам протестувати їх на вичерпному контрольному списку, який я склав для вашої зручності.

Як користуватися контрольним списком?

Візьміть архітектуру свого кандидата і притворіться, що він є його захисником, відповідаючи на запитання, як на пробі (уявляючи, що журі спільноти iOS допомагає).

Дякую за прочитання!

Повідомте мене у Twitter для зворотного зв'язку.

Куди піти звідси?

Огляд існуючих архітектур iOS.
Огляд схеми MVC.