Нещодавно я закінчив університет і почав працювати програмістом. Мені не важко вирішити "технічні" проблеми або не налагоджувати речі, які, як я б сказав, мають 1 рішення.

Але, здається, існує клас проблем, який не має одного очевидного рішення - такі речі, як архітектура програмного забезпечення. Ці речі мене бентежать і завдають мені великого лиха.

Я витрачаю години і години, намагаючись вирішити, як "архітектувати" свої програми та системи. Наприклад - я поділяю цю логіку на 1 або 2 класи, як я називаю класи, чи потрібно це робити приватним чи загальнодоступним і т. Д. Такі питання займають стільки мого часу, і це мене сильно засмучує. Я просто хочу створити програму - проклята архітектура.

Як я можу швидше пройти фазу архітектури та перейти до фази кодування та налагодження, яку мені подобається?

Досконалий - ворог добра.

Однак, не слід вирізати кути. Дизайн програмного забезпечення матиме більш тривалий вплив і заощадить вам (та вашим колегам) тонни часу та зусиль у майбутньому. Це займе більше часу, щоб вийти правильно. Більшість часу, витраченого на програмування , не забивається на клавіатурі, а на дошці, яка з'ясовує, як вирішити проблему.

Але ви також не повинні турбуватися про досконалість. Якщо два дизайни борються за тупикову ситуацію, це означає, що вони, ймовірно, приблизно однакові. Просто піди з одним. Це не так, ніби ви не можете змінити речі, коли з’ясуєте недоліки в дизайні.

(І, сподіваємось, це також допоможе з'ясувати, коли ви дізнаєтесь, що не існує лише одного способу налагодження / вирішення технічних проблем.)

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

чи я поділяю цю логіку на 1 або 2 класи, як я називаю класи, чи потрібно це робити приватним чи загальнодоступним тощо. Ці питання займають стільки мого часу

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

Порівняйте це з багатьма проектами безкоштовного програмного забезпечення (навіть великими, такими як ядро ​​Linux). Розробники не витрачали значних зусиль на "архітектуру" на ранніх стадіях. UML майже ніколи не використовується у вільному програмному забезпеченні . Крім того, ви дізнаєтесь зовсім небагато, вивчаючи вихідний код кількох безкоштовних програмних програм.

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

Як я можу швидше пройти фазу архітектури та перейти до фази кодування та налагодження, що мені подобається?

Для невеликих програмних проектів, які займають менше року роботи, дуже легко: не займайтеся архітектурою. Витратьте, можливо, півгодини мозковий штурм на загальний дизайн. Потім починайте писати код з ітеративним та інкрементальним підходом до розробки : запишіть кілька десятків рядків, компілюйте їх (з усіма попередженнями та інформацією про налагодження, наприклад, g++ -Wall -Wextra -gз GCC для C ++), поки не отримаєте попереджень (і передайте їх у якесь просте статичне джерело аналізатор коду, якщо він у вас є, наприклад, аналізатор кланг ), протестуйте цей код за допомогою налагоджувача , введіть його у свій контроль версій (наприклад git), промийте та повторіть. Однак обов'язково уникайте технічної заборгованості: коли щось погано пахне, робіть роботу (рефакторинг і повторне доповнення), щоб покращити це.

З іншого боку, в командному середовищі робота з архітектури тягне за собою початкове обговорення, щоб визначити відповідальність кожного члена команди. Це обговорення веде старший розробник (який не є новачком). Прочитайте про гнучку розробку програмного забезпечення та The Mythical Man-Month .

Я просто хочу створити програму, архітектура заслана.

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

У деяких випадках думати про метапрограмування підході: бувають ситуації , коли ви хотіли б зробити такий собі «вихідний файл» (приклади включають використання аналізатора генераторів , як зубр , клей кодогенератор як SWIG , Google Protobuf , а іноді ви можете написати простий скрипт - або використовувати такий загальний препроцесор, як GPP - щоб випромінювати частину свого C ++ або Java-коду, щоб уникнути повторного кодування).

PS. Я інженер-дослідник, маю доктор наук з інформатики та 40-річний досвід роботи, і ніколи не займався "архітектурою", як підказує ваше запитання, працюючи успішно над декількома середніми проектами та кількома великими (сам компілятор GCC ). Для мене "архітектура" - це лише фаза планування роботи наступних днів чи тижнів (і я зазвичай це роблю, коли мрію чи сплю, і, звичайно, без будь-якого комп’ютера, а зазвичай навіть без олівця). Також при написанні дослідницьких грантів я якось і неповно проектую архітектуру.

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

Є три девізи, які я люблю пам’ятати.

• "Все повинно бути зроблено максимально просто, але не простіше"

  Якщо взяти ваш приклад "один клас чи два?", Я б запитав: "яке простіше рішення?"

• "Без очевидних помилок" проти "Очевидно, що немає помилок"

  Останнє бажано!

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

  1. Код повинен працювати теоретично (тобто у вашій голові).
  2. Тоді, якщо це не працює на практиці, ви можете налагоджувати його, поки практика не відповідає теорії.

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

• Закон Галла

  Це також "рефактор".

  На практиці це означає:

  1. Почніть з [ny] простої системи, яка працює
  2. Тепер прийшов час додати нову функцію
  3. Переробляйте існуючу систему так, щоб нову функцію легко було додати (тобто до тих пір, поки)

  4. Додайте нову функцію

  5. ... і повторити, як зазначено вище

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

Що ви можете зробити - почати з мінімальної кількості абстракцій, які вам потрібні. Наприклад, клас Person в одному файлі. Тепер, продовжуючи додавати код і функції, ви починаєте бачити речі, які потрібно перемістити до іншої абстракції. Наприклад, принцип єдиної відповідальності (S of SOLID) говорить вам про відсутність методів, пов'язаних з розбором адрес у класі Person. Отже, тепер ви знаєте, що вам потрібен клас адреси.

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

редагувати: @Basile відповідь дає приклад того, як ви можете ітератувати та покращити мінімальну архітектуру.

Час, витрачений на роздуми архітектури системи, не витрачається даремно.

Я вважаю, що ваше запитання можна переосмислити як "як я можу бути більш ефективним у прийнятті архітектурних рішень?".

Моєю короткою відповіддю на це було б: вам потрібно розкрити основні принципи, які дозволять вам надійно та ефективно приймати рішення, а потім вам потрібно фактично вийти та сформувати реальне програмне забезпечення. Це буде довгий шлях пошуку знань, спроб і помилок та особистісного розвитку.

-

І для довшої відповіді ...

Спершу слід уточнити поняття: я використовую архітектуру слів для опису структури складної програмної системи, коли я працюю з процесами, службами, API та базами даних. Я використовую слово дизайн, щоб описати структуру лише одного фрагмента із складнішої системи, коли я працюю з класами, функціями та бібліотеками. Це мої визначення, деякі люди мають різні визначення. Але в цьому контексті, я вважаю, ви говорите про дизайн .

Я думаю, що слід обговорювати 3 важливі речі, обговорюючи цю тему:

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

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

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

Щоб перегортати вищезазначене, дуже важливо знати про те, що ви будете приймати дизайнерські рішення під час написання коду, свідомо чи ні. Вам слід прагнути до прийняття такої більшості рішень свідомо та критично, оскільки будь-яке прийняте злегка рішення може мати великий вплив на подальшу роботу (цей вплив, як правило, проявляється в кодовій базі, що стає дуже важко змінити для виправлення помилок або реалізації функцій). Роберт К. Мартін це чудово ілюструє це, з даними, у своїй книзі «Чиста архітектура» (яку я настійно рекомендую).

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

• набір дуже простих, але потужних прийомів кодування можна підібрати, прочитавши книгу Мартіна Фаулера "Рефакторинг: вдосконалення дизайну існуючого коду". Тут перелічено дуже багато, але це дуже низькі рівні кодування за часом, які ви можете прийняти, щоб значно покращити структуру коду та допомогти приймати дизайнерські рішення. Книга також є вагомим приводом для інтеграції тестування одиниць у ваш особистий робочий процес та написання тестового коду.

• спеціально для OOP, ви повинні подивитися на принципи SOLID . Вони трохи абстрактні і важко спочатку обернути свій розум, але дуже потужні. Я пропоную почати з перших 2, щоб швидко отримати максимальну користь:

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

Принцип відкритого / закритого типу : "програмні об'єкти ... повинні бути відкриті для розширення, але закриті для модифікації".

• поняття складу над спадщиною

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

• поняття сполучення ("ступінь взаємозалежності між програмними модулями") та згуртованості ("ступінь, до якого елементи всередині модуля належать разом")
• DRY (не повторюватися) концепція
• концепція поділу команд / запиту ( «кожен метод повинен бути або команда , яка виконує дію, або запит , який повертає дані для абонента, але не обидва»)
• концепція " державна проти системи без громадянства" (моє правило: уникайте поводження з державою; максимально будуйте системи без громадянства).

Звичайно, це просто поняття, а не правила. Перший крок - розуміння їх та усвідомлення їх. Далі йде фактично їх використання на практиці та набуття досвіду, коли ви повинні слідувати за ними, а коли не слід. І тоді відбувається безперервний процес уточнення вашого розуміння цих понять, їх негативних сторін та їх складних взаємодій між собою.

Я думаю, що найцінніша порада, яку я можу вам дати, - це набратися терпіння. Ви щойно почали довгу, але повну дорогу. Продовжуйте практикуватися та експериментувати, враховуйте, що працює, а що - ні, і з часом ви будете покращуватися.

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

Там, де архітектура необхідна, ПЕРЕД ПРОЕКТУ:

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

2. Якщо це можливо, визначте обмежені контексти вашої системи та переконайтеся, що ваш словниковий запас є прямим, наприклад, якщо бізнес говорить про "Frobbels", переконайтесь, що ви називаєте класи / інтерфейси тощо з "*** Frobbels". Звучить тривіально, але якщо говорити про робочі процеси, тоді як бізнес говорить про операції, переклад стає дратує дуже швидко.

3. Якщо ви працюєте з декількома особами / командами, опишіть свої інтерфейси рано та переконайтесь, що всі припущення та проблеми зрозумілі всім - якщо у вас немає спільного контексту, інтеграція буде "веселою". Наприклад, ви створюєте генератор бананових зображень, але ваш інтерфейс-розробник потребує генератора яблучних зображень. Або ви будуєте щось, що може відповісти на 100 запитів в секунду, але потрібно 10000 об / сек.

Примітка. На це сильно впливає моя робота з архітектури мікросервісу. Те, як сервіси побудовані всередині, МОЖЕ бути також архітектором, але більшість часу це менш важливо, ніж правильне отримання великої картини.

Я не збираюся накидати на вас купу термінів і скорочень (більшість з яких навряд чи погоджена більшістю кодерів / програмних інженерів). Замість цього врахуйте наступне:

1. Ви навчаєтесь - не витрачаєте час, ви випробовуєте різні підходи та дізнаєтесь, що працює. Це можна зробити, не будуючи багато заздалегідь планувати, занурившись у проблему з першим рішенням, яке спадає на думку, і змінивши його, якщо або коли воно не працює. Якщо це працює добре, чудово! Ви знайшли просте рішення проблеми. Прості рішення просто чудові, якщо вони працюють добре, а іноді й досить добре .

2. Все є компромісом - ви можете спроектувати одну і ту ж систему різними способами, торгуючи поза часом та простором, складністю та гнучкістю, абстрагуванням та читальністю чи будь-яким із багатьох можливих компромісів. Жодне рішення не є ідеальним у всіх відношеннях і жодне правило не обходиться без винятку в інженерії програмного забезпечення. Хто вам скаже інакше, або наївно, або щось продає.

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

4. Я заперечую, що створення програмного забезпечення - це більше мистецтво / ремесло, ніж інженерія. Велике мистецтво стосується не лише окремих мазків, а, скоріше, рішень та компромісів на високому рівні, зроблених художником / майстром.

Я спробую відповісти на це питання з точки зору веб-розробки (мається на увазі: з поля, де люди сильно агонізують архітектуру). Почну з пояснення, чому люди піклуються про архітектуру, а потім викладу способи швидшого проходу частини архітектури.

Архітектура робить для вашого коду дві речі:

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

Стиль коду полегшує читання певної частини коду, надаючи вам умовні позначення, які ви можете розпізнати та використовувати для навігації по ньому. Так само хороша архітектура допомагає визначити, де ви насправді знайдете код, який обробляє певну особливість. Наприклад, у більшості веб-проектів архітектура тісно пов'язана з тим, як сортуються папки та файли. З іншого боку, хороша архітектура насправді повинна допомогти вам менше думати про код, оскільки він уже повинен мати інтуїтивне місце, де належить будь-який фрагмент коду.

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

Тепер частина, яку ви насправді тут:

Що ви можете швидше пройти через частину архітектури:

1. Не робіть цього

Як багато відповідей уже вказано. Спочатку запитайте себе, чи справді вам потрібна архітектура. Якщо у вас не буде багато коду (і ви можете бути впевнені, що проект не зростатиме в найближчому майбутньому), ви можете просто пропустити частину архітектури і обмотати разом щось, що просто працює. ЯКЩО, якщо ви на початку своєї кар'єри, я б скористався можливістю займатися, коли зможете. У якийсь момент ви будете робити більші проекти, і тоді, мабуть, пізно вчитися.

З цим не виходить, що ви можете зробити, щоб архітектура була менш болючою:

1. Робіть це рано
2. Красти
3. Навчіться / дотримуйтесь цього
4. Не перестарайтеся

Вибір рішення про архітектуру має бути ранньою частиною процесу планування. Як тільки у вас з’явиться уявлення про те, який саме додаток / програму / веб-сайт ви будете робити, вам слід задуматися про те, яка архітектура це підтримувала б.

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

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

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

(PS: Останнє речення не є приводом для того, щоб лінуватися. Визначення пріоритетності робочого програмного забезпечення не означає, що вам не доведеться вчитися хорошому кодуванню коли-небудь.)

Відповідь дуже проста,

• Створення прототипу (у вікні часу)
• Refactor (витрачайте стільки часу, скільки хочете, або базуючись на широкому спектрі факторів)

Під час створення прототипу слід зосередити увагу на мінімально життєздатному продукті, а під час рефакторингу слід зосередити увагу на тому, щоб зробити ваш проект чи рішення масштабованим.

Як я можу швидше пройти фазу архітектури та перейти до фази кодування та налагодження, що мені подобається?

Переклавши це завдання (або попросивши про допомогу) у своїх більш досвідчених колег.

Вам просто не вистачає досвіду, необхідного для швидкого прийняття таких рішень. Uni отримав вам приємне теоретичне підґрунтя, але це лише приведе вас до стартової лінії. Немає іншого способу судити про дану архітектуру в тій чи іншій ситуації, ніж знати, як подібні архітектури поводилися в подібних ситуаціях в минулому.

Робота з людьми, які краще працюють, ніж ви, - це найшвидший спосіб дізнатися речі. Якщо у вас немає до кого звернутися, вам потрібна краща робота. "Краще", як у "кращому задоволенні ваших потреб". Потреба в знаннях і досвіді є вашою найбільш гострою потребою в цей момент, про що свідчить ваша дилема. Вам подобається фаза кодування та налагодження? Звучить як ідеальний молодший. Але молодший потребує керівництва старшого. У цьому суть цих посадових інструкцій. Чужі люди в Інтернеті можуть допомогти вам лише поки що, вам потрібен наставник.

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

Як перестати витрачати час на проектування архітектури

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

Аналогічно, так само, як можна витрачати час на архітектуру (за рахунок надмірного архітектури), ви також можете витрачати час на надмірну розробку та перекодування (кодуючи речі набагато складнішими, ніж це потрібно, або не виконавши код необхідних речей.)

Власна архітектура має на меті запобігти відходженню в кодуванні. Це робиться шляхом обмеження, звуження та документування можливих шляхів створення складної системи: 1) спроектовано, 2) кодує та випробує її, 3) доставить, 4) підтримує, 5) відновить після відмови та 6) врешті-решт виведене з експлуатації.

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

Але я відволікаюсь ...

У цьому справа: для систем досить простої архітектури є само собою зрозумілими і випливають із здорових практик проектування та впровадження.

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

Нещодавно я закінчив університет і почав працювати програмістом. Мені не важко вирішувати "технічні" проблеми або робити налагодження, а речі, які я б сказав, мають 1 рішення.

Це мінімум, необхідний для цієї професії, і я радий, що у вас немає проблем їх виконувати (я б хвилювався, якщо ви це зробили.)

Але, здається, існує клас проблем, який не має одного рішення

Це хліб і масло нашої професії, тип проблем, за які роботодавці готові платити наші (як правило) набагато вище середньої зарплати.

Власне кажучи, проблеми, які варто вирішити, - це ті, які можуть мати більше одного рішення. Проблеми з реальним світом, вони такі. І світ вимагає від нашого досвіду, як розробників програмного забезпечення, придумати прийнятні компроміси.

- такі речі, як архітектура програмного забезпечення.

Архітектура речей - неминуча характеристика складної системи, будь то віртуальна / програмна чи в конкретному світі. Кожна система, яка працює, яка приймає вклад і виробляє вихід, вона буде складною і матиме архітектуру.

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

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

Ці речі мене бентежать і завдають мені великого лиха.

Що це нормально. Вивчити чи викладати це непростий предмет, не без багато практики.

Я витрачаю години і години, намагаючись вирішити, як "архітектувати" свої програми та системи. Наприклад, чи я поділяю цю логіку на 1 або 2 класи, як я називаю класи, чи повинен я зробити це приватним чи загальнодоступним і т. Д. Такі питання займають стільки мого часу, і це сильно мене засмучує. Я просто хочу створити програму, архітектура буде проклята.

На жаль, це не архітектура програмного забезпечення.

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

Як я можу швидше пройти фазу архітектури та перейти до фази кодування та налагодження, що мені подобається ?

Мені важко знайти спосіб відповісти на це, бо це досить емоційно.

Ми намагаємося влаштуватися на роботу чи намагаємось просто насолоджуватися практикою? Чудово, коли обидва є одними і тими ж, але в реальному житті багато разів це не так.

Чудово робити речі, які нам подобаються, але в такій складній такій професії, як наша, орієнтуватися лише на те, що нам подобається, це не веде до плідної кар’єри.

Ви не будете прогресувати, не дозрівати чи здобувати нові знання.

У армії є така приказка: «обійми смоктання».

Інші фрази мають подібні поради. "Якщо вона не смокче, не варто", і моя улюблена, "Якщо вона смокче (і це важливо), робіть це, поки вона не перестане смоктати".

Мої рекомендації:

Мені здається, ви все ще намагаєтесь зрозуміти відмінності між

1. кодування (як кодувати свої класи, модулі чи що ні, називати конвенції, видимість доступу, область застосування тощо),

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

3. архітектура (як це зустрічається у складних системах, що вимагають тисяч, якщо не сотень тисяч людино-годин.)

Тому я б запропонував вам глибоко заглибитися в перший предмет (кодування), щоб перейти на наступний рівень.

Чистий код

"Чистий код" Роберта "Дядько Боб" - це гарне місце для початку.

Згуртованість програмного забезпечення

Додатково я пропоную ознайомитись із конкретною метрикою програмно-орієнтованого програмного забезпечення під назвою LCOM, а точніше LCOM4.

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

http://www.aivosto.com/project/help/pm-oo-cousion.html#LCOM4 https://www.computing.dcu.ie/~renaat/ca421/LCOM.html

Принципи програмного забезпечення

Це тісно пов'язане з "Принципом єдиної відповідальності" або СРЮ, з яким ми всі повинні бути знайомі. SRY - один із 5 "твердих", з якими ми всі повинні бути знайомі, якщо ми хочемо стати досвідченими в кодуванні.

Коли ми рухаємося через принципи SOLID, нам також потрібно ознайомитись з принципами "GRASP" , які керуються, а точніше - керувати тим, як ми кодуємо класи.

Додаткові книги

Нарешті, я також пропоную наступне:

• "Рефакторинг" Мартіна Фаулера та Кена Бека був би наступною книгою, яку я прочитав у цьому списку.

• "Дизайн за контрактом, за прикладом" Річарда Мітчелла, Джима Маккіма та Бертран Мейєра (пізніше про славу Ейфеля.) Ця книга вийшла з друку, але ви можете знайти дешеві, використані примірники в Амазонії.

З цим ви повинні добре зрозуміти, як почати кодування та дизайн, а також на практиці перемістити та опанувати (або принаймні зрозуміти) архітектуру програмного забезпечення.

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

Все, що я можу сказати, це - ярликів немає.

Все найкраще.

Тут багато інформації і відверто TL; DR. Є одне головне, що, на мою думку, люди помиляються, намагаючись навчитися проектувати систему: вони намагаються думати про це в порядку, коли робота буде виконана. Натомість вам потрібно працювати назад. Тобто головна мета дизайну / архітектури - визначити, яким повинен бути кінцевий результат.

Як аналогію розглянемо архітектуру будинку. Архітектор не починає задавати собі запитання на кшталт: "скільки вікон повинен мати цей будинок?", "Де слід розмістити перший цегла?". Ці деталі реалізації не є дизайном, вони походять від проекту. Архітектура починається із бачення, можливо, ескіз того, як може виглядати готовий будинок. Це односімейний будинок, дуплекс? Це розкішний будинок чи легкодоступний? Так само, чи є змінні приватними та чи розділили ви клас, дуже мало стосується архітектури.

Почніть спочатку з з'ясування, які цілі вашого дизайну. Наприклад, це одноразове рішення? Чи буде вона розширюватися і переглядатись та підтримуватися протягом десятиліть? Відповідь на це вказуватиме на дуже різні проекти, і це суть архітектури. Після того, як ви зрозуміли, що вам потрібно зробити, деталі дизайну випливають природним чином. Не те, щоб ці деталі були очевидними чи легкими, але саме на високому рівні планується цей вибір.

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

Що стосується називання речей, то для мене це частина "написання", але це, безсумнівно, дуже важлива частина програмування: не соромтеся добре думати про те, як ви називаєте речі, і думати складніше, чим більший обсяг назви.

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