Программист-прагматик. Путь от подмастерья к мастеру

Стоит ли тратить время на разработку прототипа, чтобы определить лучший способ, который необходимо использовать (см. "Прототипы и памятные записки")? Стоит ли внедрять более совершенные процедуры тестирования (см. "Программа, которую легко тестировать" и "Безжалостное тестирование") или автоматизации (см. "Вездесущая автоматизация"), чтобы предотвратить дальнейшие неудачи? Возможно, вам понадобятся дополнительные ресурсы. Не бойтесь спрашивать или признаться, что нуждаетесь в помощи.
      Попытайтесь исключить неубедительные отговорки до того, как их озвучить. Если нужно, выскажите их сначала вашему коту. Ну а если ваш Мурзик возьмет вину на себя…

Другие разделы, относящиеся к данной теме:

      • Прототипы и памятные записки
      • Реорганизация
      • Программа, которую легко тестировать
      • Вездесущая автоматизация
      • Безжалостное тестирование

Вопросы для обсуждения:

      • Как вы отреагируете, когда кто-нибудь – кассир в банке, механик в автосервисе, или клерк придет к вам с подобными отговорками? Что в итоге можно подумать о них лично и об их фирме?

2
Энтропия в программах

      Разработка программного обеспечения обладает иммунитетом почти ко всем физическим законам, однако энтропия оказывает на нас сильное влияние. Энтропия – это термин из физики, обозначающий уровень «беспорядка» в системе. К сожалению, законы термодинамики утверждают, что энтропия во вселенной стремится к максимуму. Увеличение степени беспорядка в программах на профессиональном жаргоне называется "порчей программ".
      Существует много факторов, вносящих свой вклад в порчу программ. Похоже, что наиболее важным из них является психология или культура в работе над проектом. Даже если команда состоит лишь из одного-единственного сотрудника, психология проекта может быть весьма тонкой материей. При наличии наилучших планов и специалистов экстракласса, проект все же может рухнуть и сгнить в период разработки. Однако существуют и другие проекты, которые, несмотря на огромные трудности и постоянные неудачи, успешно борются с природной тенденцией к беспорядку и заканчиваются хорошо.

В чем же состоит разница?

      Некоторые здания, расположенные в старых кварталах города, находятся в хорошем состоянии и чистоте, тогда как другие являют собой жуткие развалины. Почему? Исследователи в области преступности и упадка больших городов открыли удивительный механизм, запускающий процесс быстрого превращения чистенького, нетронутого жилого дома в полуразрушенную и заброшенную трущобу [WK82]
      Причина – одно-единственное разбитое окно.
      Одно разбитое окно, стекло в котором не меняется в течение длительного времени, развивает в обитателях здания ощущение заброшенности – ощущение, что властям нет дела до того, что происходит со зданием. Затем разбивается другое окно. Люди начинают мусорить. На стенах появляются похабные надписи. Возникают серьезные повреждения строительной конструкции. За относительно короткое время здание портится, несмотря на стремление владельца отремонтировать его, и ощущение заброшенности становится реальностью.
      "Теория разбитого окна" дала полицейским участкам в Нью-Йорке и других больших городах стимул: навалиться всем миром на решение малых проблем ради сдерживания больших. И это срабатывает: сосредоточение усилий на первоочередном решении проблем разбитых окон, похабных надписей и других малых правонарушений, привело к сокращению уровня тяжких преступлений.
 

      Подсказка 4: Не живите с разбитыми окнами

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

Как погасить пожар

      И напротив, существует история абсурдного (до неприличия) опыта одного из авторов книги, Энди Ханта. Его дом был в идеальном порядке, великолепен, наполнен бесценным антиквариатом, произведениями искусства и прочими ценностями. Однажды гобелен, висевший в гостиной слишком близко от камина, загорелся. Пожарные примчались, чтобы спасти положение, а заодно и дом. Но перед тем как втащить в дом свои большие, грязные шланги, они остановились перед полыхающим огнем, чтобы раскатать специальный мат от входной двери до очага пожара. Они боялись испортить ковер.
      Конечно, это весьма экстремальный случай, но именно этот способ должен использоваться в случае с программным обеспечением. Одно разбитое окно – неудачно спроектированный фрагмент программы, неверное решение, принятое менеджером (действующее на протяжении всего проекта) – это все, что требуется дня того, чтобы началось отклонение от нормы. Если оказывается, что вы работаете над проектом с несколькими разбитыми окнами, то слишком легко сползти к умонастроению типа "Вся оставшаяся часть программы – это ерунда, я всего лишь следую примеру". Не важно, в каком состоянии находился проект до этого момента. В оригинальном эксперименте, приведшем к возникновению теории разбитых окон, заброшенный автомобиль стоял в течение недели нетронутым. Но как только одно-единственное окно было разбито, автомобиль был «раздет» и перевернут вверх колесами за несколько часов.
      К тому же, если вы находитесь в команде и работаете над проектом, тексты программ которого совершенны изначально – корректно написаны, хорошо спроектированы и элегантны – вы, вероятно, предпримете дополнительные усилия к тому, чтобы не испортить их, так как это сделали пожарные с ковром. Даже если речь идет о чрезвычайной ситуации (контрольные сроки, дата выпуска, демонстрационная версия для выставки и т. д.), вы не захотите быть первым среди тех, кто портит проект.

Другие разделы, относящиеся к данной теме:

      • Суп из камней и сварившиеся лягушки
      • Реорганизация
      • Команды прагматиков

Вопросы для обсуждения

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

3
Суп из камней и сварившиеся лягушки

      Трое солдат возвращались с войны и проголодались. Когда они увидели впереди деревню, их настроение поднялось – они были уверены, что крестьяне накормят их. Но как только они пришли в деревню, все двери оказались заперты, а окна – закрыты. После долгой войны крестьяне бедствовали и прятали все, что у них есть.
      Это не смутило солдат, они вскипятили котел воды и аккуратно положили в него три камня. Удивленные крестьяне вышли посмотреть.
      "Это суп из камней", – объяснили солдаты крестьянам. "И это все, что вы в него кладете?" – спросили крестьяне. "Абсолютно все – хотя на вкус он будет намного лучше, если положить в него немного моркови". Один из крестьян убежал и быстро вернулся с корзиной моркови из своего погреба.
      Через некоторое время крестьяне вновь спросили: "И это все?"
      "Да", – сказали солдаты, "но пара картофелин сделает суп посытнее", И другой крестьянин убежал.
      В течение следующего часа солдаты попросили у крестьян другие ингредиенты, которые сделали суп вкуснее: мясо, лук, соль и травы. И каждый раз крестьяне потрошили свои запасы.
      Так они сварили большой котел дымящегося супа. Затем солдаты вынули камни и уселись вместе со всей деревней, чтобы поесть досыта – первый раз за многие месяцы.

      В истории с супом из камней есть два важных урока. Солдаты обманывали крестьян, используя любопытство последних, чтобы добыть у них пищу. Но что более важно, солдаты явились катализатором, объединяя жителей деревни с тем, чтобы общими усилиями сделать то, что они не смогли сделать сами, – синергетический результат. В конечном итоге выигрывают все.
      Иногда в этой жизни вам бы хотелось оказаться на месте солдат.
      Вы можете оказаться в ситуации, когда вам точно известно, что нужно сделать и как это сделать. Перед глазами возникает общий план системы, и вы осознаете, что именно так это и должно быть. Но если вы попросите разрешения на проработку аспекта в целом, то столкнетесь с волокитой и пустыми глазами. Люди будут образовывать комиссии, бюджет должен быть одобрен, и все будет усложнено. Каждый будет держаться за свое кресло. Иногда это называется "изначальной усталостью". Пора вытаскивать камни из котла. Выработайте то, о чем вы реально можете попросить. Проработайте детали. Как только вы это сделаете, покажите людям и позвольте им удивиться. Они скажут: "Конечно, было бы лучше, если бы мы добавили". Положим, что это не важно. Расслабьтесь и подождите, пока они не начнут спрашивать вас о добавлении функциональных возможностей, которые вы задумали изначально. Людям легче присоединиться к грядущему успеху. Покажите им свет в конце туннеля, и они сплотятся вокруг вас .
 

      Подсказка 5: Будьте катализатором изменений

 
      С другой стороны, история с супом из камней – это история о ненавязчивом и постепенном обмане. Это история о шорах на глазах. Крестьяне думают о камнях и забывают обо всем остальном в мире. Все мы впадаем в подобное состояние ежедневно. Нечто просто подкрадывается к нам.
      Всем нам известны симптомы. Проекты медленно и неизбежно полностью выходят из-под контроля. Большинство программных катастроф начинаются с малозаметных вещей, и большинство проектов в один прекрасный день идут вразнос. Шаг за шагом система отклоняются от требований, при этом фрагмент текста программы обрастает «заплатами», пока от оригинала не остается ничего. Зачастую именно скопившиеся мелочи приводят к разрушению морали и команд.
 

      Подсказка 6: Следите за изменениями

 
      Сами мы, по чести, никогда этого не делали. Но говорят, что если взять лягушку и бросить ее в кипящую воду, то она сразу выпрыгнет наружу. Однако если бросить лягушку в кастрюлю с холодной водой, а затем медленно нагревать ее, то лягушка не заметит медленного увеличения температуры и останется сидеть в кастрюле, пока не сварится.
      Заметим, что проблема лягушки отличается от проблемы разбитых окон, обсуждаемой в разделе 2. В "теории разбитых окон" люди теряют волю к борьбе с энтропией, поскольку она никого не волнует. Лягушка же просто не замечает изменений.
      Не будьте лягушкой. Не сводите глаз с общей картины происходящего. Постоянно наблюдайте за тем, что происходит вокруг вас, а не только за тем, что делаете вы лично.

Другие разделы, относящиеся к данной теме:

      • Энтропия в программах
      • Программирование в расчете на совпадение
      • Реорганизация
      • Западня требований
      • Команды прагматиков

Вопросы для обсуждения

      • Просматривая черновик данной книги, Джон Лакос поднял следующий вопрос: солдаты постоянно обманывали крестьян, но в результате изменений, катализатором которых они стали, лучше стало всем. Однако, постоянно обманывая лягушку, вы наносите ей вред. Когда вы пытаетесь ускорить изменения, то можете ли определить, варите вы суп из камней или же лягушку? Является ли это решение субъективным или объективным?

4
Приемлемые программы

      Для лучшего добро сгубить легко.
У. Шекспир, Король Лир, действие 1, сцена 4

      Существует старый анекдот об американской фирме, которая заказала 100000 интегральных схем на предприятии в Японии. В условиях контракта указывался уровень дефектности: один чип на 10000. Несколько недель спустя заказ прибыл в Америку: одна большая коробка, содержащая тысячи интегральных схем, и одна маленькая, в которой находилось десять схем. К маленькой коробке был приклеен ярлычок с надписью "Дефектные схемы".
      Если бы у нас был такой контроль качества! Но реальный мир не позволяет производить многое из того, что является действительно совершенным – особенно программы без ошибок. Время, технология и темперамент – все находится в сговоре против нас.
      Однако это не должно вас обескураживать. По словам Эда Иордона, автора статьи в журнале IEEE Software [You95], вы можете обучиться созданию приемлемых программ – приемлемых для ваших пользователей, служб сопровождения и с точки зрения вашего же собственного спокойствия. Вы обнаружите, что производительность вашего труда повысилась, а ваши пользователи стали чуть-чуть счастливее. Кроме того, ваши программы станут лучше за счет сокращения инкубационного периода.
      Перед тем как пойти дальше, мы должны определиться в том, что собираемся сказать. Фраза «приемлемый» не подразумевает неаккуратную или неудачно написанную программу. Все удачные системы должны отвечать требованиям их пользователей. Мы просто призываем к тому, чтобы пользователям была дана возможность участвовать в процессе принятия решения, если созданное вами действительно приемлемо.

Находите компромисс с пользователями

      Обычно вы пишете программы для других людей. Часто вы вспоминаете о том, что хорошо бы получить от них требования . Но как часто вы спрашиваете их, а насколько хорошими они хотят видеть эти программы? Иногда выбирать не из чего. Если вы работаете над передовыми технологиями, космическим челноком, или низкоуровневой библиотекой, которая будет широко распространяться, то требования будут более строгими, а варианты – ограниченными. Но если вы работаете над новым продуктом, то у вас будут ограничения другого рода. Маркетологам придется сдерживать обещания, вероятные конечные пользователи могут строить планы, основанные на дате поставки программы, а ваша фирма, конечно, будет ограничена в денежных средствах. Профессионалы не могут игнорировать требования пользователей – просто добавить к программе новые средства или «отшлифовать» еще раз тексты программ. Мы не призываем к паническим настроениям: одинаково непрофессионально обещать невероятные сроки и срезать основные "технические углы" чтобы уложиться вовремя.
      Сфера действия и качество создаваемой вами системы должны указываться в части системных требований.
 

      Подсказка 7: Сделайте качество одним из пунктов требований

 
      Часто вы будете оказываться в ситуациях, когда необходимо идти на компромисс. Удивительно, но многие пользователи предпочтут использовать программы с некоторыми недоработками, но сегодня, чем год ожидать выпуска мультимедийной версии. Многие IT-департаменты, имеющие ограничения по бюджету, могли бы согласиться с этим утверждением. Хорошие программы (но сегодня) зачастую являются более предпочтительными по сравнению с отличными программами (но завтра). Если вы заранее дадите другим пользователям поиграться с вашей программой, то часто их отзывы будут способствовать выработке лучшего конечного решения (см. "Стрельба трассирующими").

Знайте меру

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

Другие разделы, относящиеся к данной теме:

      • Стрельба трассирующими
      • Западня требований
      • Команды прагматиков
      • Большие надежды

Вопросы для обсуждения

      • Обратите внимание на производителей инструментальных программных средств и операционных систем, которыми вы пользуетесь. Можете ли вы найти свидетельство тому, что эти компании не испытывают неудобства, поставляя программное обеспечение, хотя им известно, что оно несовершенно? Как пользователь, вы скорее: (1) подождете, пока они устранят все ошибки, (2) выберете усложненную версию программы и примете отдельные ошибки или (3) выберете упрощенную версию программы, но с меньшим числом дефектов?
      • Рассмотрите эффект разбиения на модули при поставке программного обеспечения. Больше или меньше времени потребуется для доведения монолитного программного блока до требуемого уровня качества по сравнению системой, спроектированной по модульному принципу? Можете ли вы привести коммерческие примеры?

5
Портфель знаний

      Инвестиции в знания окупаются лучше всего.
Бенджамин Франклин

      Ах, старина Франклин! Никогда не лез в карман за многозначительным наставлением. Если бы мы рано ложились и рано вставали, мы стали бы великими программистами, не так ли? Ранняя птичка никогда не остается без червячка, но что при этом происходит с червячком?
      Хотя в данном случае Бенджамин действительно попал в точку. Знание и опыт являются самыми важными профессиональными активами.
      К сожалению, знания и опыт представляют собой истекающие активы . Ваше знание устаревает по мере того, как разрабатываются новые методики, языки, технологии и операционные среды. Изменение расстановки сил на рынке может сделать ваш опыт устаревшим или полностью неприменимым. Принимая во внимание скорость, с которой промчались годы Интернета, это может произойти довольно быстро.
      По мере того как величина ваших знаний уменьшается, то же самое происходит с ценностью вас для фирмы-работодателя или заказчика. Мы хотели бы предотвратить возникновение подобной ситуации.

Ваш портфель знаний

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

Построение вашего портфеля

      •  Инвестируйте на регулярной основе.Как и в случае финансов, необходимо регулярно инвестировать в ваш портфель знаний. Даже если объем инвестиций невелик, сама по себе привычка важна, как, впрочем, и объемы. Несколько примеров на эту тему приводятся в следующем разделе.
      •  Инвестируйте в различные сферы.Чем больше вы знаете о различных вещах, тем большую ценность вы представляете. Как минимум вы обязаны знать плюсы и минусы конкретной технологии, с которой вы работаете в данный момент. Но не останавливайтесь на этом. Лицо информатики меняется быстро – новейшая технология сегодняшнего дня может оказаться почти бесполезной (или, по меньшей мере, не найти спроса) завтра. Чем больше технологий вы освоите, тем легче вам будет приспособиться к изменениям.
      •  Управляйте риском.Технология находится в некоем диапазоне – от рисковых и потенциально высокодоходных до низкорисковых и низкодоходных стандартов. Вложение всех ваши денег в высокорисковые акции, курс которых может внезапно обвалиться, и другая крайность – консервативное вложение и упущение возможностей – не самые лучшие идеи. Не кладите все "технические яйца" в одну корзину.
      •  Покупайте подешевле, продавайте подороже.Обучение передовой технологии до того, как она станет популярной, может быть столь же сложной задачей, как найти обесцененные акции, но отдача может стать наградой. Изучение языка Java, когда он только что появился, могло показаться рискованным, но оно щедро вознаградило тех, кто принял это раньше всех, и сегодня они занимают лидирующие позиции в данной области.
      •  Пересмотр и повторная балансировка.Информатика – очень динамичная отрасль. Новейшая технология, которую вы начали изучать в прошлом месяце, сегодня может устареть. Возможно, вам понадобится восстановление навыков по технологии баз данных, которой вы не пользовались какое-то время. А может быть, вы смогли бы стать лучшей кандидатурой на открывшуюся вакансию, если бы попробовали изучить другой язык…
      Из всех этих директив, самой важной и самой простой в исполнении является
 

      Подсказка 8: Инвестируйте регулярно в ваш портфель знаний

 

Цели

      Теперь у вас есть некоторые директивы, что и когда добавлять к вашему портфелю знаний, как лучше приобрести интеллектуальный капитал, который будет вложен в ваш портфель? Вот несколько предложений.
      •  Учите (как минимум) по одному языку программирования каждый год.Различные языки решают различные проблемы по-разному. Выучив несколько различных подходов, вы можете расширить мышление и избежать закоснелости. Вдобавок, изучать многие языки сейчас намного легче, благодаря богатому выбору бесплатно распространяющегося программного обеспечения в сети Интернет (см. Приложение А).
      •  Читайте по одной технической книге ежеквартально.В книжных магазинах полным-полно технической литературы по темам, интересующим вас или связанным с проектом, над которым вы работаете в настоящее время. Как только это войдет у вас в привычку, читайте по одной книге в месяц. После того как вы овладеете технологиями, которыми вы пользуетесь на данный момент, расширяйте круг своих интересов и изучайте другие технологии.
      •  Читайте книги, не относящиеся к технической литературе.Важно помнить, что пользователями компьютеров являются люди – люди, чьи потребности вы пытаетесь удовлетворить. Не забывайте о человеческом факторе.
      •  Повышайте квалификацию на курсах.Ищите интересные курсы в вашем районе, школе или университете, а может быть, и во время грядущей технической выставки, которая проводится в вашем городе.
      •  Участвуйте в собраниях локальных групп пользователей.Но не просто приходите и слушайте, а принимайте активное участие. Изоляция может оказаться смертельной для вашей карьеры; разузнайте, над чем работают люди за пределами вашей компании.
      •  Экспериментируйте с различными операционными средами.Если вы работали только в среде Windows, поиграйте со средой Unix дома (для этой цели прекрасно подходит бесплатно распространяемая версия Unix). Если вы использовали только сборочные файлы и редактор, попробуйте интегрированную среду разработчика и наоборот.
      •  Оставайтесь в курсе событий.Подпишитесь на профессиональные журналы и другие периодические издания (рекомендации приведены в Приложении А). Выберите из них те, которые покрывают технологии, отличные от вашего текущего проекта.
      •  Подключайтесь к информационным сетям.Хотите знать плюсы и минусы нового языка или технологии? Группы новостей отлично подходят для поиска практических результатов работы с ними других людей, используемого ими жаргона и т. д. Походите по Интернету в поисках статей, платных сайтов, и любых других доступных источников информации.
      Важно продолжать инвестирование. Как только вы почувствуете, что освоили новый язык или фрагмент технологии, двигайтесь дальше. Изучайте другой.
      Неважно, будете ли вы когда-либо использовать одну из этих технологий в проекте, или даже не упомянете о них в своем резюме. Процесс обучения расширит ваше мышление, открывая для вас новые возможности и новые пути в творчестве. "Перекрестное опыление" идей важно; попытайтесь применить выученные уроки к проекту, над которым вы работаете в настоящее время. Даже если в вашем проекте не используется некая технология, вы наверняка сможете позаимствовать некоторые идеи. К примеру, ознакомьтесь с объектно-ориентированным подходом, и вы напишете простые программы на языке С различными способами.

Возможности обучения

      Итак, вы жадно и много читаете, находитесь в курсе всех новейших разработок в вашей сфере (это не так-то легко) и кто-то задает вам вопрос. У вас нет даже намека на идею, каким должен быть ответ, но вы не признаете это открыто, как и многие.
      В этот момент не останавливайтесь. Примите это как брошенный вам вызов для поиска ответа. Спросите гуру (если в вашем офисе нет гуру, вы должны найти его в Интернете: см. следующую врезку.) Поищите в Интернете. Сходите в библиотеку .
      Если вы не можете найти ответ самостоятельно, найдите того, кто это может. Не бросайте поиски. Разговор с другими людьми поможет в построении вашей собственной сети, и вы можете удивиться, находя по пути ответы на другие, не относящиеся к делу проблемы. И этот старый портфель все утолщается и утолщается…
      Все это чтение и исследование требует времени, а времени уже не хватает. Так что вам придется планировать наперед. Запаситесь литературой на то время, которое может бездарно пропасть. Время, которое проходит в очередях на прием к врачам, можно с пользой потратить на чтение литературы – но убедитесь, что вы принесли с собой ваш журнал, а не замусоленную страницу из газеты 1973 года о положении в Папуа Новой Гвинее.

Критическое осмысление

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

      Подсказка 9: Критически анализируйте прочитанное и услышанное

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

Уход за гуру и их разведение

      С глобальным принятием сети Интернет, гуру внезапно стали ближе – на расстоянии нажатия клавиши Enter. Итак, как найти гуру и вызвать его на разговор?
      Здесь есть несколько простых уловок.
      • Знайте точно, что вы хотите спросить, и будьте конкретным, насколько это возможно.
      • Формулируйте ваш вопрос внимательно и вежливо. Помните, что вы просите одолжения; в противном случае может показаться, что вы требуете ответа.
      • Как только вы сформулировали вопрос, остановитесь и вновь поищите ответ. Выхватите несколько ключевых слов и поищите их в Интернете. Поищите подходящие списки часто задаваемых вопросов и ответов на них.
      • Решите, каким образом вы зададите вопрос: в открытой форме или же частным образом. Группы новостей Usenet – прекрасное место встреч для экспертов практически по любой теме, но некоторые опасаются открытого характера этих групп. Кроме того, вы всегда можете отправить сообщение непосредственно вашему гуру по электронной почте. В любом случае используйте строку темы сообщения со смыслом. (Сообщение "Нужна помощь!" не останется незамеченным.)
      • Расслабьтесь и наберитесь терпения. Люди заняты, и, возможно, потребуется несколько дней, чтобы получить конкретный ответ.
      И наконец, обязательно поблагодарите всех, кто ответил вам. И если вы видите людей, задающих вопросы, на которые вы можете ответить, ответьте взаимностью и примите участие.

Вопросы для обсуждения

      • На этой неделе начните учить новый язык программирования. Всегда программировали на С++? Попытайтесь выучить язык Smalltalk [URL 13] или Squeak [URL 14]. Работаете с Java? Попробуйте поработать с языком Eiffel [URL 10] или ТОМ [URL 15]. Информация о других бесплатных компиляторах и средах разработчиков содержится в Приложении А.