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

12

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

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

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

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

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

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

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

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

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

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

user1620696
источник
1. Вы уже понимаете все основные понятия C #, включая такие вещи, как разница между перегрузкой операторов и переопределением операторов, что такое абстрактный класс и чем он отличается от интерфейса, инкапсуляции, полиморфизма и т. Д.? Знание этих вещей в первую очередь необходимо для полного понимания ОО в C #. См. C-sharpcorner.com/technologies/oop-ood .
Роберт Харви
2
2. Старые приложения, написанные на Winforms, имеют тенденцию превращаться в большие шары грязи, если они не спроектированы должным образом. Разделение интересов становится первостепенным. Смотрите winformsmvp.codeplex.com
Роберт Харви
1
Там на самом деле нет процесса. Дизайн - это в основном умение организовывать, что приходит с опытом. Принципы SOLID - хорошее начало, но их недостаточно, и люди склонны теряться в SOLID и забывать, почему эти принципы существуют.
Роберт Харви
1
Начните немного. Требования - это проблемы. Одна проблема может быть такой же огромной, как «Мы ​​хотим разработать следующий сайт Stackexchange» или просто «мы хотим, чтобы у нашего следующего Stackexchange был логин». Превратите большую проблему во многих, но меньших. В целом, дайте себе шанс сначала сделать что-то «не так» и со временем улучшаться.
Laiv
1
Я одновременно хочу поднять голос и vtc это ...
svidgen

Ответы:

21

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

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

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

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

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

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

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

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

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

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

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

candied_orange
источник
2
Это отличный ответ. Я программирую 15 лет, и добавлю, что вся область разработки программного обеспечения (моя профессия) «нечеткая» - это сочетание искусства и функциональности, и в зависимости от разработчика больше, чем другое. Я могу придумать идею для архитектуры на бумаге, но я никогда не смогу проработать детали дизайна ОО, пока я не углублюсь в грязь, не разберусь и не найду, что работает, а что нет.
jropella
Спасибо за ответ! Итак, ваша точка зрения такова: если у нас есть хотя бы одно решение для реализации требования, и оно работает, мы реализуем его, а затем, как только мы увидим, как оно соотносится с другим кодом и другими требованиями, мы реорганизуем его, чтобы сделать его лучше? Но все еще бывают ситуации, когда я получаю некоторые требования, и я не знаю, с чего начать. В таких случаях, есть ли у вас какие-либо советы о том, как начать? Иногда я считаю, что лучше всего было бы обсудить требования и возможные реализации, но я работаю один. Есть ли какой-нибудь форум, где подобные обсуждения приветствуются?
user1620696
2
Ну, во-первых, перестань работать в одиночку. Даже иметь невежественного новичка, который замедляет вас, чтобы объяснить вещи, лучше, чем это. Во-вторых, научитесь разбивать требование на части. Продолжайте делать это до тех пор, пока у вас не появится что-то управляемое, на что вы можете рассчитывать. Напишите доказательство концепции кода в совершенно другой среде, если вам нужно. Просто сделайте то, что выражает ваше понимание того, что нужно. Затем проверьте это выражение. Вы можете сделать плохие предположения. Это хорошо. Будьте готовы изменить их.
candied_orange
1

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

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

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

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

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

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

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

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

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

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

Бен Коттрелл
источник
1
у нас никогда не было времени для написания автоматических тестов, но у нас всегда было время запускать ручные тесты снова и снова ...
Ник Кейли,
Кроме того, у нас никогда не было времени, чтобы написать код «правильно» и «чисто» в первый раз, но, кажется, у нас есть бесконечное время, чтобы продолжать возвращаться и исправлять его, снова и снова из-за ошибочного, но столь распространенного мышления, представленного в эта почта.
Данк
@ Данк Я не думаю, что реалистично ожидать, что код никогда не должен изменяться или пересматриваться. Практики модульного тестирования и руководства SOLID посвящены поощрению практики, которая приводит к тому, что код, который легко и дешево изменить, когда происходит неизбежное - например, кто-то находит действительно странную неясную ошибку, которую разработчик не учел в то время, или покупатель видит решение и изменение требований, или даже оригинальный код содержал ошибки, потому что разработчики - только люди; или, возможно, разработчик неправильно понял требования, или обнаружил ранее неизвестные технические ограничения ...
Бен Коттрелл
1
@BenCottrell - я полностью согласен. Код всегда нужно пересматривать. Однако, из-за этого, это заставляет людей указывать на то, что они тратят время на «предварительный дизайн» и пишут несколько «чистый код» как своего рода провал. Они используют мантру «вовремя» и «на бюджете», чтобы оправдать плохой код / ​​дизайн. Вы можете использовать все «практики», которые вы хотите, но это не приведет к покупке «кода, который легко и дешево изменить», не имея при этом хорошего дизайна и относительно «чистого кода». Хороший дизайн и «чистый код» будут побочным продуктом фактического достижения цели в срок и в рамках бюджета.
Данк
@ Dunk Похоже, вы говорите, что многим разработчикам просто не важно качество кода, что, как я не думаю, обычно имеет место. В действительности, я думаю, что есть две большие проблемы - во-первых, в то время как разработчики могут быть теми, кто предоставляет оценку для бюджета и срока, оценки могут легко оказаться неправильными. Во-вторых, заинтересованные стороны проекта получают окончательное решение о времени / стоимости, что означает, что риски, бюджеты и сроки перевешивают технические проблемы. Учитывая выбор между «определенно поздним / сверхбюджетным» или «потенциально плохим кодом», я обнаружил, что заинтересованные стороны часто выбирают последнее.
Бен Коттрелл