Как на самом деле узнать, что нужно сделать в объектно-ориентированном дизайне?

Во-первых, отказ от ответственности: я не знаю, подходит ли этот вопрос к этому сайту, но я все еще считаю его актуальным не только для меня, но и для других начинающих людей. Если вопрос может быть улучшен, чтобы соответствовать здесь, пожалуйста, укажите в комментариях. Если это не подходит, дайте мне знать и, если возможно, дайте мне знать, где это можно обсудить, потому что я не нашел хороших форумов для этого.

Я научился программировать в 2009 году, когда я изучал PHP. Позже в 2012 году я перешел на C # и .NET. Во всяком случае, кодирование не проблема, записывать алгоритмы не моя проблема. Моя настоящая проблема заключается в том, чтобы знать, что должно быть закодировано для достижения требования и где оно должно быть закодировано.

Большинство доступных в Интернете курсов посвящены тому, как - как писать код на определенном языке, как использовать некоторые наборы API и т. Д. Это не моя точка зрения.

В эти годы я много читал о множестве вещей: объектно-ориентированный анализ и проектирование, шаблоны проектирования, доменный дизайн и так далее. Я понимаю, например, принципы SOLID, некоторые из основных идей DDD, такие как необходимость привлечения экспертов в предметной области, разработка повсеместно распространенного языка и так далее. Я бы осмелился сказать, что я теоретический фон хотя бы разумный.

Но когда дело доходит до практики, я чувствую себя катастрофой. Некоторое время назад мне нужно было продолжить развитие финансовой системы, которая уже была разработана кем-то другим. Это такая «старая система», разработанная на C # и WinForms. Это был первый раз, когда я выбрал проект с реальной сложностью домена, с большим количеством бизнес-правил и так далее.

Признаюсь, что, когда я получаю требования, большую часть времени я думаю: «Как, черт возьми, это можно сделать?» - Я понятия не имею, как начать работу над требованиями, чтобы выяснить, что нужно сделать. Я считаю, что мои основные недоразумения заключаются в том, что я должен кодировать, какие классы, интерфейсы и куда идет каждая часть логики, в каком классе должна быть каждая вещь. Проблема в том, что я не знаю с чего начать.

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

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

Итак, как я могу научиться действительно делать объектно-ориентированный дизайн? Я хочу узнать следующее: данные требования знают, как начать работу над ними в процессе, который приводит к выяснению того, что должно быть сделано и где принадлежит каждый фрагмент кода. Как я могу научиться судить, верна ли моя идея или нет?

Я полагаю, что полностью объяснить это как ответ здесь было бы невозможно. Однако то, что я ищу, может быть в соответствии со стилем сайта - это ответы, просто дающие обзор и указывающие на некоторые ссылки (книги, онлайн-курсы и т. Д.), Которые можно использовать для расширения идей и реального изучения этих вещей.

Итак, как я могу научиться действительно делать объектно-ориентированный дизайн? Я хочу узнать следующее: данные требования знают, как начать работу над ними в процессе, который приводит к выяснению того, что должно быть сделано и где принадлежит каждый фрагмент кода. Как я могу научиться судить, верна ли моя идея или нет?

Ну, во-первых, перестаньте думать об объектно-ориентированном дизайне как о правильном. Это все равно, что думать об английском как о правильном.

Объектно-ориентированная парадигма не верна. У него есть определенные преимущества и недостатки. Это идеал. Это не наш единственный. Это лучше, чем ничего, но это, конечно, не все.

Я кодирую уже десятилетия. Я изучал этот материал почти столько же, сколько существовали его идеи. Я все еще изучаю, что это значит. Эксперты все еще изучают, что это значит. Нашей целой области менее 100 лет.

Поэтому, когда вы берете кучу требований и получаете код, который их удовлетворяет, но чувствуете, что написанный вами код - трагический беспорядок, вы не одиноки. Рабочий код - это просто первый шаг к хорошему коду. Код, который не только работает, но который другие могут легко прочитать и понять. Код, который можно быстро адаптировать при изменении требований. Код, который заставляет вас сидеть сложа руки и говорить: «Ого, это так просто».

Проблема в том, что нам не платят за все это. Мы делаем все это, потому что мы профессионалы. Мы должны делать все это, когда начальник не смотрит, потому что всегда есть крайний срок. Но мы хотим вернуться через 5 лет и сказать новичкам: «О да, я написал это. Все еще работает, да? Круто».

Как ты доехал? Практика. Не принимайте ЛЮБЫЕ идеи дизайна на веру. Кто-то не будет молчать о том, как управляемый событиями дизайн упростит этот дизайн? Не уверен, что они правы? Создайте свой собственный игрушечный проект дома, который использует шаблон наблюдателя. Возиться с этим. Попытайтесь найти вещи, с которыми это НЕ помогает.

Читать. Вопрос. Тестовое задание. Повторение.

Когда вы дойдете до того, что занимались этим 80% своей жизни, вы будете так же смущены, как и я.

Признаюсь, что, когда я получаю требования, большую часть времени я думаю: «Как, черт возьми, это можно сделать?» - Я понятия не имею, как начать работу над требованиями, чтобы выяснить, что нужно сделать. Я считаю, что мои основные недоразумения заключаются в том, что я должен кодировать, какие классы, интерфейсы и куда идет каждая часть логики, в каком классе должна быть каждая вещь. Проблема в том, что я не знаю с чего начать.

Раньше я чувствовал то же самое. Тогда я обнаружил радость от рефакторинга. Будьте готовы адаптировать дизайн при написании кода. Попытка сделать все заранее на бумаге - трудный способ сделать это. Напишите код, который может оказаться ошибочным, докажите его и исправьте.

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

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

Как правило, код считается поддерживаемым, когда затраты, время и риски, связанные с изменением этого кода, пропорционально достаточно низки, чтобы исправление ошибок или внесение изменений в требования по-прежнему было рентабельным и что при реализации этих изменений вы не увековечили «спираль смерти». код-энтропии.

И наоборот, код считается не подлежащим ремонту, когда вы не можете с уверенностью изменить или выполнить рефакторинг без серьезного риска либо сломать что-либо, либо потратить слишком много времени / денег, чтобы убедиться, что ничего не сломано, то есть когда время, стоимость и риск, связанные с работой с этим кодом, непропорционально высокий по сравнению с преимуществами внесения изменений (т. е. ваш работодатель или клиент не теряют деньги, добавляя новые функции, исправляя ошибки и т. д.)

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

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

Вам не нужно особенно следовать строгой методологии разработки, такой как TDD / BDD, чтобы в итоге было достаточно автоматических тестов, чтобы вы могли провести рефакторинг; Вам просто нужно достаточно , чтобы защитить код от случайных изменений отключающих в будущем.

Если ваш код защищен автоматическими тестами, вы можете расслабиться относительно его дизайна и структуры, зная, что вы охвачены этими тестами; Вы можете агрессивно рефакторинг на более поздний срок, или даже выбросить его и начать заново.

Возникает вопрос: как написать легко тестируемый код? как правило, это основной аргумент для следования принципам SOLID; на самом деле, отличительной чертой кода, который придерживается принципов SOLID, является то, что его легко и экономично по времени писать модульные тесты.

Конечно, иногда у вас нет времени и для написания юнит-тестов; однако, если вы написали весь свой код, имея в виду вопрос «Как мне написать автоматические тесты для этого?» (даже если вы на самом деле не реализовали эти тесты), вам, вероятно, также удалось найти дизайн, который можно было бы обслуживать.