Як насправді з’ясувати, що потрібно зробити в об'єктно-орієнтованому дизайні?

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

Я навчився програмувати в 2009 році, коли вивчав PHP. Пізніше в 2012 році я перейшов на C # і .NET. У всякому разі, кодування - це не проблема, записування алгоритмів - це не моя проблема. Моя актуальна проблема полягає в тому, щоб знати, що потрібно закодувати для досягнення вимоги і де це потрібно закодувати.

Більшість курсів, доступних в Інтернеті, стосуються того, як - як писати код на певній мові, як використовувати деякі набори API та ін. Це не моя суть у цьому.

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

Але коли справа доходить до мене, я відчуваю, що я катастрофа. Деякий час тому мені потрібно було продовжувати розвиток фінансової системи, яку вже розробляв хтось інший. Це така "стара система", розроблена за допомогою C # та WinForms. Я вперше обрав проект із реальною складністю домену, з великою кількістю правил бізнесу тощо.

Зізнаюсь, що, коли я отримую вимоги більшість часу, я думаю, "як це можна зробити?" - Я не маю уявлення про те, як навіть почати працювати над вимогами, щоб зрозуміти, що потрібно зробити. Мої основні плутанини, на які я вважаю, - це те, що я повинен кодувати, які класи, інтерфейси і куди йде кожна логіка, на якому класі повинна бути кожна річ. Проблема в тому, що я не знаю, з чого почати.

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

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

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

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

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

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

Об'єктно-орієнтована парадигма неправильна. Він має певні переваги та недоліки. Це ідеал. Це не єдина наша. Це краще, ніж нічого, але це, звичайно, не все.

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

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

Проблема полягає в тому, що ми не отримуємо плату за все це. Ми все це робимо, тому що ми професіонали. Ми повинні робити все це, коли начальник не дивиться, тому що завжди є термін. Але ми хочемо повернутися через 5 років і сказати новачкам: "О так, я це написав. Все ще працює так? Круто".

Як ти потрапив туди? Практика. Не приймайте жодної ідеї дизайну на віру. Хтось не замовкне про те, як дизайн, керований подіями, спростить цей дизайн? Не впевнені, чи праві вони? Побудуйте свій власний проект іграшок вдома, який використовує шаблон спостерігача. Возитися з цим. Спробуйте знайти речі, з якими НЕ допомагає.

Прочитайте. Питання. Тест. Повторіть.

Коли ви доберетеся до того, що ви робите це протягом 80% свого життя, ви будете так само розгублені, як і я.

Зізнаюсь, що, коли я отримую вимоги більшість часу, я думаю, "як це можна зробити?" - Я не маю уявлення про те, як навіть почати працювати над вимогами, щоб зрозуміти, що потрібно зробити. Мої основні плутанини, на які я вважаю, - це те, що я повинен кодувати, які класи, інтерфейси і куди йде кожна логіка, на якому класі повинна бути кожна річ. Проблема в тому, що я не знаю, з чого почати.

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

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

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

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

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

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

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

Вам особливо не потрібно дотримуватися суворої методології розробки, такої як TDD / BDD, щоб в кінцевому підсумку вистачити автоматизованих тестів, які дозволять вам робити рефактор; вам просто потрібно достатньо для захисту коду від випадкових порушень змін у майбутньому.

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

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

Звичайно, іноді у вас немає часу і для написання одиничних тестів; однак якщо ви написали весь свій код, пам’ятаючи питання «Як мені написати автоматичні тести для цього?» (навіть якщо ви фактично не реалізували ці тести), ймовірно, вам також вдалося знайти конструкцію, яка є досить досяжною.