The Programmers` Stone (Программистский камень)

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

Глава 2. Мысли о программировании

Для чего служит программная инженерия?

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

Мы инженеры-программисты. Почему? Для чего служит программная инженерия? Что делают инженеры-программисты? Мы получаем самые курьезные ответы на этот вопрос. Один чудак сказал: "Они следуют процедурам Стандартов Программной Инженерии!" Другой добавил: "Они переформулируют (transliterate) требования!"

Боже. Мы предполагаем, что инженеры-программисты просто обеспечивают работу программ, которые нужны пользователям на их компьютерах. Это означает, что наши программы должны делать правильные вещи. Они должны быть устойчивыми. Иногда мы должны знать вполне определенно, что они устойчивы (надежны), а иногда нам требуется уметь это доказать. Нам всегда бы понравилось оказаться способными все это делать! Необходимые программы должны работать так же и завтра, что обычно означает, что наши программы сегодня должны быть поддерживаемыми. Мы должны делать нашу работу эффективно по стоимости, иначе не получим шанс написать эти программы вообще. Доставка должна быть вовремя.

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

Мы ничего не делаем ради этого.

Программная инженерия - распределенное программирование

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

Мы распределяем программирование по тем же причинам, по которым распределяем любой вид обработки: пригодность (availability), параллелизм и специализация.

Такой взгляд приносит понимание. Мы должны аккуратно выделить различия между задачами. Иногда мы можем получать преимущества от выполнения двух задач одним человеком, когда нас не должно волновать, что они объединены. Например, во многих организациях принята практика разделения идентификации требований и выбора архитектуры, но когда они переходят на технологию моделирования объектов в стиле Буча, то внимают совету и объединяют эти задачи. Когда мы разделяем навыки разработки и тестирования, мы можем извлечь из этого дополнительные преимущества, контролируя взаимодействие между стадиями таким образом, что мышлению инженера-тестера не угрожает мышление проектировщика. Был менеджер проекта, скорее всего паковщик. Он не имел ясного понимания того, что он делал и почему, а отсутствие какой-нибудь позитивной модели своей работы привело его к мысли, что ключевая цель состоит в предотвращении какого бы то ни было взаимодействия. Тестеры не должны были знать, как установить (создать) условия для компонентов, которые они должны были тестировать, а проектировщикам не дозволялось об этом говорить. Яростные споры продолжались днями. Это реально произошло тогда, когда мы потеряли ощущение большой картины.