Лучшие практики - дизайн перед кодированием

Мне любопытно Как вы думаете? (Я имею в виду способ мышления) о архитектуре дизайна ваших библиотек, систем, рамок и т.д., Прежде чем начинать его кодирование.

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

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

Например, как вы решаете, какие интерфейсы вам понадобятся, или как все будет связано наилучшим образом?

(У меня была проблема день назад, мой друг попросил меня библиотеку, что я сделал некоторое время назад, и вместо того, чтобы дать ему всего один файл, мне пришлось дать ему около 3-4 файлов, а это потому, что они связаны каким-то образом.. но не в правильном, я думаю:) так что это была моя ошибка в дизайне.)

Ответ 1

Я обычно делаю достаточный анализ проблемной области на бумаге/белой доске, чтобы получить достаточно хорошее представление о проблемной области, чтобы начать писать код. Я редко рисую схемы выполнения или диаграммы классов на бумаге. Ключевой метод, который я нашел для достижения лучшего дизайна, - это не слишком привязываться к коду, который вы пишете. Если мне это не нравится, я удаляю, переименую, перемещаю и перетасовываю его, пока не вырастет достаточно хорошее решение для того, что я пытаюсь решить. Звучит просто? Не за что! Но с хорошими инструментами "кодирования", на самом деле писать код не является основным усилием. Напишите некоторые, рефакторинг, удалить, снова написать...

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

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

Это очень итеративные процессы.

Интересный вопрос, который следует задать при рассмотрении того, как программисты думают, заключается в том, как они развили свой образ мышления. Лично мой образ мышления развивался на протяжении многих лет, но несколько событий оказали глубокое влияние на то, как я разрабатываю программное обеспечение. Самыми важными из них были разработка программного обеспечения с людьми, которые являются экспертами-дизайнерами. Ничто не повлияло на меня больше, чем тратить итерации с великими дизайнерами. Другое событие, которое имеет и продолжает влиять на то, как я думаю, возвращается и смотрю на программное обеспечение, которое я написал некоторое время назад.

Ответ 2

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

Нарисовать на доске или большом листе бумаги, используя разные цвета для идентификации различных характеристик, также является хорошей идеей. Заметки Post-it также являются хорошим способом визуализации вашей модели.

Даже если я потрачу много времени, чтобы тщательно продумывать дизайн, я ВСЕГДА в конечном итоге меняю его, когда я иду. Поэтому имейте в виду, что ваш дизайн изменится, когда вы примете решение о том, как документировать ваш дизайн.

Ответ 3

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

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

Мысль о дизайне в основном записывается в тестах. Написано перед кодом для его реализации. Начните с конечных целей заинтересованных сторон, работайте оттуда назад до начала (Time-inversion). Это гарантирует, что вы сосредоточитесь на чем и меньше на том, как. Взаимодействие между объектами более важно, чтобы получить права, чем атрибуты объекта.

Другая часть находится в основном на белой доске. В наши дни компактная цифровая камера является стандартным оборудованием.

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

Смотрите:

Ответ 4

Я обычно посвящаю около 2 - 4 часов, чтобы сделать дизайн своего приложения, а затем записать его в блокнот.

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

Таким образом я избегаю "паралича анализа", который часто случается со мной. Много раз, когда я закончил разработку, я не использовал некоторые артефакты.

Таким образом, я принял этот более "подвижный" подход.

Нарисуйте дизайн очень быстро и "уточните" (путем рефакторинга) в перспективе.

Конечно, это возможно для небольших приложений (от 2 до 4 недель)

Я бы предложил вам прочитать эту статью: Является ли дизайн мертвым от Мартина Фаулера. Это немного длинный, но стоит читать.

ИЗМЕНИТЬ

Дополнительная ссылка _{(слегка offtopic)}Как создать хороший API и почему это важно Джошуа Блоха. Расскажите об актуальности дизайна, когда у вас есть аудитория для вашего API. Резюме, начинайте как можно более приватным и расти оттуда.

Ответ 5

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

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

Как я уже сказал, не ответ.

Ответ 6

Я следую очень свободной версии Rational Unified Process.

Первое начало документа видения, в котором четко указано, что вы пытаетесь сделать, кто вы это делаете и, возможно, некоторые ключевые сведения о предлагаемых методах/алгоритмах. Это не должно быть фантазией и даже может быть одним лайнером для простой системы "Система для прогнозирования выигрышных лотерейных номеров для личного использования только на основе последних исследований в школе Хогвартса". Для более сложной системы это могло бы около пяти страниц, но не более. Это не дизайн, а скорее как список пожеланий.

Затем выполните некоторые примеры использования/рассказы. Это должны быть простые текстовые описания естественного языка для всех взаимодействий с внешним миром. Здесь минимализм - это ключ; целью использования является определение всех необходимых функций и только требуемых функций. Также я нахожу, что здесь происходит большая часть творчества.

Пример использования может начинаться как:

  User presses the "magic" button.
  System displays next weeks winning number.
  User writes down number.
  User buys lottery ticket.
  Lottery draws winning number.
  User claims money
  lottery pays up.

После многого работы он заканчивается как: -

  User presses "magic" button
  System selects next weeks numbers.
  System logs on to lottery system.
  System enters winning numbers.
  Lottery selects winning numbers.
  Lottery transfers winnings to users account.
  User spends money.

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

Ответ 7

Это должен быть баланс.

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

Если вы начнете взламывать какую-то небольшую часть системы, вы, вероятно, потеряете из виду "большую картину" и получите плохой дизайн.

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

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

Ответ 8

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

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

Ответ 9

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

Оттуда мне нравится использовать подход DDD (Domain Driven Design). Опрос бизнес-пользователей, если необходимо, для создания модели домена. Как только модель домена и последующий DAL (уровень доступа к данным) позаботятся, я перехожу на уровень бизнес-логики (BLL).

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

Ответ 10

Открыть вопрос. Будут почти такие же ответы, как и плакаты. 1) взгляните на многие книги по разработке программного обеспечения. Некоторые спорят с хорошим дизайном, остальное - просто. Это ложь 2) Посмотрите, как навязчивые разнообразные рамки, вам лучше использовать их по назначению, иначе вы лучше будете использовать этот материал для своих нужд 3) Дизайн будет нуждаться в постоянном изменении, как в любом письме. Вы видите предложения, но вы чувствуете, что они не подходят полностью. Поэтому вы переписываете его. Поэтому каждый дизайн должен учитывать, что все по-другому, поскольку они выглядят так, как вы написали дизайн.

Отношения Friedrich

Ответ 11

При выполнении каких-либо крупных проектов, таких как разработка игр, я стараюсь тщательно структурировать свой код и с самого начала создавать нефункциональные фиктивные функции и классы. В основном файле кода я разбил все на классы в других модулях и подмодулях, если это необходимо. Например; Моя основная кодовая страница будет состоять из не более чем включений и вызовов инициализаторов классов для моих основных модулей. Вот пример init.py для игры, которую я сейчас делаю на Python;

из импорта commonheaders *

if arguements.debug:
    debug.init()

try:
    graphics.init()
    sound.init()
    physics.init()
    input.init()
    loop.start("scene1")
except Exception, e:
    print "Error!"
    print e

Это очень минимально и легко понять, но мне больше всего нравится то, что он дает очень четкое разделение между различными основными аспектами кода. Если я разочаруюсь в чем-то в графическом классе, я могу просто поработать над звуковым классом или чем-то еще, чтобы получить еще что-то, и оставить графику из моего ума на некоторое время, пока облака не пройдут. Для всех вызовов класса init() существуют необязательные аргументы, такие как widht/height для графики, но я обычно оставляю их там и либо устанавливаю их в файле commonheaders.py, либо через ключи командной строки.

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

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