avl (avl) wrote,
avl
avl

Categories:

26. Повторное использование - это прежде всего люди

(В оригинале - Reuse is about people and education, not just architecture)

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

  1. Знают о том, что это существует;
  2. Знают, как это использовать;
  3. Уверены, что это лучше, чем если бы они это написали сами.


1. Знают о том, что это существует.

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

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

2. Знают, как это использовать.

Понимание того, как повторно использовать элементы, зависит от опыта, умений и тренингов. Разумеется, есть люди, «резонирующие» с кодом и дизайном (по терминологии Д. Кнута). Все мы сталкивались с такими людьми, которые схватывают все на лету. Но такие люди – редкость. Остальных людей требуется обучать.

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

3. Уверены, что это лучше, чем если бы они это написали сами.

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

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

Автор оригинала: Jeremy Meyer

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

  • Про интерфейсы

    Была у нас в офисе микроволновка. Старая, самая простая, вот такая: Весь интерфейс — два поворотных регулятора. Один задает…

  • О ценности и цене

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

  • Интуитивно-понятный интерфейс

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

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments