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

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

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

перестань думати про код

почніть думати про шари, функції, модулі, послуги та інші абстракції вищого рівня

ти перевантажений тим, що ти думаєш на занадто низькому рівні

Зробити склад простим просто ; зачекайте, подумайте, це навпаки.

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

Оскільки ви не перераховували це у своїх питаннях, моя пропозиція буде:

Зосередьтеся на функціональній згуртованості за допомогою:

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

Якщо ви Google це серед результатів на першій сторінці, ви знайдете два чудові ресурси:

• " Принцип єдиної відповідальності " Роберта К. Мартіна (лютий / 2002): Цей принцип обговорює необхідність розміщення речей, що змінюються з різних причин, в різних класах.
• " Закон Керлі: зроби одну річ " Джеффа Етвуда (березень 2007 р.): Принцип єдиної відповідальності говорить, що клас повинен мати одну, і лише одну, причину для зміни.

Що таке згуртованість в інформатиці?

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

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

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

Якщо у вас є якісь питання, повідомте мене.

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

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

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

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

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

Спеціалізовані заняття не є злими, вони є природним наслідком продуманого програмного забезпечення.

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

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

Нарешті, ще одна ДУЖЕ важлива річ, яку я б шукав, якби я був ти, - це дизайнерські зразки. Шаблони дизайну - це те, як люди розумніші за вас чи мене вирішують проблеми програмування. Ідея, що лежить в основі шаблонів, вгадайте, що? Не полягає в тому, що вони не повинні використовуватися як кулінарні книги, рецепти, які ви просто тупаєте там, але вдумливо і розуміючи домен додатків у першу чергу.

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

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

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

Сподіваюся, це має сенс для вас!

Андреа

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

Кілька простих кроків, які допомогли мені

• Використовуйте аналізатор подібності (наприклад, Simian), щоб знайти повторювані кодові блоки в кодовій базі. Багато повторюваного коду означає менше абстрагування.
• Контролювати розмір класів і методів; великі класи та методи означають, що мало служб або контролерів стають богами.
• Зробіть тести для блоку / інтеграції обов'язковими, надає впевненість у рефактори, а також діє як специфікація.
• Назад ретроспектива з бізнесом зрозуміє, чи використовуються технічні / бізнес / доменні терміни в назвах класів. Це допомагає зрозуміти та отримати імена для колекцій першого класу, а не представляти як прості набори та списки. Деякі абстракції, про які ми ніколи не думали, також з'являться, коли ми сідаємо з діловими людьми.