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

Между делом она обозначила, что воспитательные приёмы – а детей мы тоже затронули (в целом – своих нет) – это не что иное как манипуляция. А раз так, то и со взрослыми есть некоторая градация допустимости «грязных трюков». 

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

Спустя годы после выхода "Domain-Driven Design", идеи Эванса вошли мейнстрим. Разработка через моделирование должна была уменьшить неопределенность, позволить разрабатывать ПО за меньшее число итераций. Должна была, но ничего не вышло.

На собеседованиях и митапах я слышу

Мы пытались внедрить DDD, но у нас не получилось

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

Под катом: 5 способов провалиться на внедрении DDD

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

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

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

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

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

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

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

Рассмотрим несколько случаев.

Источник

Вводная

Предпосылки

Чуть-чуть дополнений и терминологии

Введение

Немного общей информации