Читать онлайн «The Programmers Stone (Программистский камень)». Страница 33

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

Держа в уме недопустимость деквалифицирующих программ, мы можем исследовать ряд мифов. Даже в сфере массового материального производства трудно сравнивать похожее с похожим. Например, мы можем сравнивать производство автомобилей за этот месяц и за прошлый месяц, и посмотреть в каком из них оно было лучше. А за прошлый год? Мы использовали тогда три разных вида блоков фар и предлагали пять окрасок. А десять лет назад? Каждый аспект технологии — антиблокировка тормозов, система управления автомобилем, воздушные мешки, состав топлива — все изменилось. Требуется настоящее озарение, чтобы просто рассказать, насколько мы богаче, чем предшественники! Академические попытки сравнения отношения заработной платы к цене за большой период времени скатываются к затратам на покупку кирпичей и хлеба, поскольку на протяжении многих столетий только эти вещи можно было всегда пойти и купить! Ну что мы можем поделать с поразительным экспоненциальным ростом «улучшения производительности», связанным с каждым новым «прорывом в технологии», который позволит вам набрать в штат проекта орангутангов и получать от них по 10 миллионов строк кода (10 MLOCS) в секунду. С чем на Земле можно сравнить этот рост? Нам приходится делать вывод о том, какие ужасные кучи мусора вываливают на нас в каждой статистически убогой работе.

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

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

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

Мы предполагаем, что более эффективен следующий подход:

Во-первых, правильно разбейте на уровни. Выясните суть API каждого выявленного уровня. Во-вторых, примените совет Кена Томпсона (Ken Thompson), `Если сомневаетесь, применяйте грубую силу.' Определите раздутый, дорогой, неэффективный, тяжелый в реализации и ужасный способ обеспечения функциональности на каждом уровне. Не важно, что вся система в целом может просто не работать, если реализовать ее именно таким способом, поскольку этого не будет. В-третьих, обеспечьте достижение плато качества на каждом уровне. Пересматривайте время от времени свою незрелую методику и добавляйте в нее те хорошие части, которые у вас уже есть, а остальное заполняйте по возможности различными грубыми методами. В-четвертых, когда начнутся трудности, исходя из краткосрочных и среднесрочных потребностей заказчика и имеющегося времени сделайте на свой риск оптимальный выбор, какие части будут поставлены сырыми, а какие стоит сделать максимально хорошо.

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

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

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

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

Никогда не совершайте ошибку, заботливо обеспечивая им стол, стул, рабочую станцию, но не предоставляя бюджет (account) и конкретного дела. Хуже всего, когда приходящий на новый проект становится похожим на лимон[16], а каждая следующая минута кажется длиннее предыдущей.

На BT (British Telekom) очень эффективно использовалась очень удачная практическая идея, которая состоит в представлении новичка официальному «назначаемому другу». Этот назначаемый друг — равный ему по должности, кто уже давно работает в команде, и явно представляется как источник информации, которого «можно беспокоить» по поводу всего, что нужно узнать новичку. Одно из замечательных свойств этого подхода в том, что будучи равным, назначаемый друг будет знать правильные ответы на вопросы новичка. Бумага обычно лежит в коричневом шкафу, а листы A3 для больших диаграмм — в зеленом ящике внизу.

Для любого, кто желает принести на рабочее место силу картостроителя, будет очень полезным изучение жизни и работы физика Ричарда Фейнмана (Richard Feynman). Он рассказывал историю. Отец показал ему одну из певчих птиц (Spencers' Warbler — певчая птица Спенсера). Ее название было придуманным. Затем отец привел ему названия этой птицы на многих других языках, и оказалось, что маленький Фейнман узнал не больше, чем в начале. Механически запомненные названия вещей ничего не значат. Только посмотрев на саму птицу, о ней можно будет сказать хоть что-то.

Он был чрезвычайно честным и видел сквозь искусственную сложность, всегда настаивая на простоте и фактах. Посмотрите на его личную версию отчета о расследовании гибели «Челленджера» (The Challenger Report), которая приведена в его книге «Почему тебя беспокоит, что другие думают?» (What Do You Care What Other People Think?) [17]

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

Недавно были опубликованы его «Лекции по вычислениям» (Lectures on Computation), и их стоит почитать, как и все, что он писал, начиная с «Шести легких частей» (Six Easy Pieces) до «Красных книг лекций» (Red Book Lectures). Книги Джеймса Глейка «Гений» (James Gleick's Genius) и Джона Гриббена «Ричард Фейнман» (John Gribben's Richard Feynman) — прекрасно написанные биографии.

Добудьте эти книги и прочтите.

«Законы формы» (The Laws of Form) Джорджа Спенсера-Брауна (George Spencer-Brown) — это небольшая книжка по математике с комментариями, которая, по мнению современных логиков, содержит форму «модальной логики» ('modal logic'), характеризуемую тем, что в ней есть правила логической системы, которые по-разному применяются в разных местах в манере, определяемой правилами самой логики.