Category: дизайн

Верхний пост :)

Основной мой вид деятельности на данный момент - разработка ПО в области embedded. Опыт работы - с 2001 года. Сайт-визитка по этой теме: http://avl2.info/.

Кроме этого, есть еще несколько направлений, мне интересных, в которых я в той или иной степени "продвинулся". Никак не связанных с программированием.

1. Естественные роды. Все - на основании собственного (почти :)) опыта рождения двух детей. Я оба раза присутствовал на родах, во второй раз мы вместе с женой составляли план родов, выбирали и общались с акушерками, ходили на курсы подготовки и многое-многое другое :) Опыт вылился в сайт http://ru.naravniporod.com/. Буду рад ответить на вопросы, если кого-то мой опыт заинтересует подробнее.

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

2. Фотография. Началось это увлечение еще с 1996 года, с фотоаппарата "Смена 8М" и черно-белой пленки, проявки ее в бачке и печати фотографий в ванной под увеличителем и красным фонарем. Кое-что из того, что получается сейчас, можно увидеть здесь по тегу "Фото". Коммерческое предложение с ценами и вариантами - на еще одном моем сайте http://www.lepitrenutki.com/, который, правда, на словенском языке - для целевой аудитории.

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

3. Гимнастика для новорожденных. С первым ребенком я открыл для себя динамическую гимнастику. Со вторым - познакомился с абсолютно другим подходом, автором которого является словенка Андрея Семолич, и который она назвала "Педокинетика". (Сайт тоже на словенском). Подход очень и очень интересный, отлично дополняет собой динамическую гимнастику, со вторым ребенком я прошел всю ее методику, начав с 6 недель и закончив моментом, когда малыш начал делать первые шаги. И очень доволен результатом. В мае 2013 года я получил сертификат инструктора "Педокинетики" первого уровня (после двух лет обучения, в том числе более 200 часов практики с реальными детьми и 6-часового экзамена на реальных и непростых группах). Впереди еще минимум три года обучения :) Так что в ближайшее время появится еще одно направление в моей деятельности :) По которому я тоже буду рад помочь тем, кого это заинтересует!

61. Единственный исполняемый файл

(В оригинале - One Binary)

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

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

Правило же здесь простое: создавать единственную версию исполняемых файлов, с возможностью идентификации этой версии и продвижения ее по «линии жизни» проекта. А специфику среды сохранять непосредственно в среде окружения (в файле или папке, например)

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

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

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

Автор оригинала - Steve Freeman

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

38. Основы bug tracking-a

(В оригинале - How to Use a Bug Tracker)

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

Хороший отчет об ошибке должен содержать три вещи:

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

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

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

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

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

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

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

Автор оригинала - Matt Doar

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

32. Инкапсулируйте не только состояние, но и поведение

(В оригинале - Encapsulate Behavior, not Just State)

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

Модули и пакеты инкапсулируют большие объемы и системы, а классы и функции – более тонкие аспекты. В течении многих лет я сталкиваюсь с тем, что именно классы являются самым проблемным местом для правильного использования инкапсуляции. Весьма часто можно увидеть класс, в котором присутствует единственный метод длиной в 3000 строк, или же класс, в котором реализованы лишь set() и get() методы для каждого атрибута. Эти примеры показывают, что разработчики не до конца понимают объектно-ориентированную модель, теряя возможность использовать всю ее мощь.

Объект инкапсулирует и состояние, и поведение, причем поведение зависит от актуального состояния. Представьте себе объект «Дверь». У него будет четыре состояния: «Открыто», «Закрыто», «Открывается», «Закрывается». И у него будет две операции: «Открыть» и «Закрыть». В зависимости от состояния, методы «Открыть» и «Закрыть» будут работать по-разному.

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

То, как это работает на практике, проще всего показать на примере. Пусть, например, у нас есть три класса: Customer, Order и Item. Объект Customer – естественное место для инкапсулирования кредитного лимита и правила его проверки. Объект Order знает об ассоциированном Customer, и его метод addItem делегирует саму проверку ему, вызывая customer.validateCredit(item.price()). Если условие не выполняется, генерируется исключение и покупка не выполняется.

Менее опытный ООП-разработчик может сделать по-другому – собрать все бизнес-правила в отдельный объект OrderManager (или OrderService). В таком дизайне Order, Customer, и Item рассматриваются лишь как набор данных. Вся логика же вынесена из них и сосредоточена в большом методе класса OrderManager, с большим количеством ветвей и условий внутри. Такие методы очень легко «сломать» и почти невозможно поддерживать. Причина? Нарушенная инкапсуляция.

Подведя итог: не нарушайте инкапсуляции и используйте свойства языка для ее поддержки.

Автор оригинала - Einar Landre

12. Программирование - это дизайн.

(В оригинале - Code Is Design)

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

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

Возможность прогнозировать сроки практически исчезнет. Стоимость строительства гораздо проще расчитать, чем стоимость дизайна. Мы примерно знаем, сколько стоит один кирпич, и сколько кирпичей нам понадобится. Если же предсказуемая часть задачи будет стремиться к нулю, на первый план выйдет непредсказуемая – дизайн. Результаты будут получаться быстрее, но за практически непредсказуемое время.

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

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

Думаю, не будет сюрпризом, если вы найдете аналогию с программированием. Если мы допустим, что программирование – это дизайн (креативный процесс, а не рутинная работа), то это хорошо объяснит кризис в отрасли. У нас кризис дизайна: требования к качеству дизайна превосходят наши возможности. Принуждение использовать незавершенный дизайн слишком высоко.

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

Автор оригинала - Ryan Brush

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

2. Применяйте принципы функционального программирования

(В оригинале - Apply Functional Programming Principles)

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

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

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

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

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

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

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

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

Автор оригинала - Edward Garson

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

33. Дайте разработчикам свободу

(В оригинале - Give developers autonomy)

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

Будучи разработчиком, вы вряд ли выделяли время на то, чтобы сесть и посмотреть, как стыкуются друг с другом все части системы. Теперь вы архитектор, и это ваша основная задача. Пока разработчики активно пишут классы, методы, тесты, интерфейсы пользователя и базы данных, вы должны следить за тем, чтобы эти куски подходили друг к другу. Прислушивайтесь к проблемным точкам и пытайтесь их улучшить. У людей возникают проблемы при написании тестов? Улучшите интерфейс и упростите зависимости. Вы точно не понимаете, где вам требуется абстракция, а где нет? Поработайте над пониманием предметной области. Не уверены, в каком порядке разрабатывать компоненты? Постройте план проекта. Разработчики делают одни и те же ошибки, используя API, вами разработанное? Сделайте его более стандартным. Люди не до конца понимают дизайн? Соберите людей и объясните им. Не уверены, где вам нужна расширяемость? Пообщайтесь с заказчиком и изучите его бизнес-модель.

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

Автор оригинала - Philip Nelson

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

28. Вид с высоты 300 метров

(В оригинале Get the 1000ft view)

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

На диаграммах дизайна обычно маленькие квадратики представляют целые системы, а линии между ними могут значить что угодно: зависимость, поток данных или общий ресурс типа шины. Эти диаграммы – вид с высоты 10 километров, как пейзаж из окна самолета. И часто единственный другой вид – это исходный код, что можно сравнить с видом с высоты 1 метра над землей. Оба эти вида не показывают достаточно информации о качестве ПО, один – слишком высокоуровневый, другой – слишком детальный. Нам требуется промежуточный, скажем, метров с 300.

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

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

Как только подходящий вид становится доступным, качество ПО становится чуть менее субъективным. Становится возможно сравнивать его с аналогичным. Сравнение различных версий позволит понять общую тенденцию, а сравнение различных подсистем – резкие отличия или отклонения. Даже имея единственную диаграмму, мы уже можем понядеяться на наше чувство прекрасного. Хорошо сбалансированное дерево, скорее всего, представляет отличную иерархию классов, гармонический набор квадратиков может означать, что код адекватно разбит по классам подходящего размера. В большинстве случаев можно доверять правилу: «Если что-то хорошо выглядит, то скорее всего, оно действительно хорошее».

Автор оригинала - Erik Doernenburg

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

24. Используйте неопределенность как мотиватор

(В оригинале Use uncertainty as a driver)

Оказавшись перед выбором из двух альтернатив, большинство думает, что главное – это сделать правильный выбор между ними. В проектировании (ПО и не только) это не так. Наличие двух возможностей – индикатор того, что вам нужно подумать о внесении неопределенности в дизайн. Используйте неопределенность как повод определить, где вы можете отложить принятие решения, или где вы можете снизить значимость этого выбора. Если вы привяжете себя к первому пришедшему в голову варианту, скорее всего, поменять его потом будет сложно, в результате случайный выбор станет значимым и гибкость продукта снизится.

Одно из самых простых и конструктивных определений архитектуры дал Гради Буч: «Вся архитектура – это дизайн, но весь дизайн – это не архитектура. Архитектура представляет значимые решения дизайна, формирующие систему, где значимость измеряется стоимостью изменения». Что из этого следует – это то, что эффективная архитектура должна снижать значимость решений. Неэффективная же архитектура значимость усиливает.

Когда решение в дизайне может развиваться двумя путями, архитектор должен сделать шаг назад. Вместо выбора альтернативы между А и В нужно задать себе другой вопрос: «Как сделать дизайн таким, чтобы выбор между А и В был менее значимым?». Самое интересное – не выбор между А и В, а само наличие такого выбора (и кстати, сам выбор далеко не всегда будет окончательным).

Архитектор должен пройти огонь и воду, чтобы научиться легко видеть дихотомию. Стояние у доски и энергичное обсуждение вариантов с коллегами? Пыхтение над кодом и размышление, попробовать ту или эту реализацию? Когда новое требование или уточнение старого перечеркивает текущую реализацию, это проявление неопределенности. Ответ на это – найти такую инкапсуляцию, которая могла бы изолировать решение от кода, сильно зависящего от этого решения. Без этого умения видеть ответ часто заключается во внесении хаотичных изменений в код и попытках компенсировать неопределенность множественными универсальными опциями. Или же, если решение принимается случайно, результатом может оказаться поворот в неправильном направлении.

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

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

Автор оригинала - Kevlin Henney

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

11. Строка работающего кода ценнее, чем 500 строк спецификации

(В оригинале One line of working code is worth 500 of specification)

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

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

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

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

Автор оригинала: Allison Randal

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