Основа программирование - полное проектирование

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

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

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

Конечно, давление конкуренции остается в силе. При минимальной стоимости строительства лидером на рынке станет та компания, которая сможет организовать самое быстрое проектирование. Таким образом, ускорение процесса проектирования становится главной задачей инженеров. Безусловно, некомпетентный в данной области человек при виде непроверенной, но выпущенной раньше других конструкции может сказать: "Это выглядит достаточно хорошо".

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

Нас не должна удивлять и аналогичная проблема при разработке ПО. Если мы признаем, что разработка ПО - это пректирование, творческий процесс, а не механическое кодирование, то сможем объяснить так называемый "кризис ПО". Сейчас у нас кризис проектирования: спрос на качество проектов превышает наши возможности для его обеспечения. Слишком велик соблазн использовать неполное или некачественное проектирование.

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

Перевод: Протченко Алексей a.k.a Severyanin
Лицензия: [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Оригинал: Code Is Design
Автор [[Райан Браш]]
Лицензия: [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Пишите на языке предметной области

Сравните две нотации написания кода.

В одной вы увидите:

if (portfolioIdsByTraderId.get (trader.getId ())
  . ContainsKey (portfolio.getId ())) {...}

Не сразу можно понять, что делает этот код. Кажется, это - получение идентификатора объекта trader, с его дальнейшим использованием для получения карты, то есть, по-видимому, карты карт, и проверка на существование в этой внутренней карте идентификатора объекта portfolio. Вы чувствуете, что надо думать дальше. Объявление portfolioIdsByTraderId выглядит следующим образом:

Map <int, Map <int, int>> portfolioIdsByTraderId;



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



В другой нотации вы столкнетесь со следующим:



if (trader.canView (portfolio)) {...}



Не нужно чесать голову в раздумьях. Также Вам не нужно знать, что представляет собой объект trader. Может быть, одна из этих карт, состоящих из карт, спрятана где-то внутри. Но это забота объекта trader, а не Ваша

Итак, с какой из этих нотаций записи кода Вы предпочли бы работать?

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

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

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

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

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

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



Перевод: Протченко Алексей a.k.a. Severyanin

Лицензия: [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] 

Оригинал: Code_in_the_Language_of_the_Domain

Автор [[Dan North]]
Лицензия: [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]