Текст книги "Программист-фанатик"

Автор книги: Чед Фаулер

сообщить о нарушении

Текущая страница: 7 (всего у книги 17 страниц) [доступный отрывок для чтения: 7 страниц]

Совет 17
На плечах гигантов

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

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

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

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

Чтобы проникнуть в суть, анализируй чужой код.

Дизайн и программирование ПО в этом отношении во многом похожи на различные области искусства. В поисках шаблонов и трюков приходится анализировать огромные объемы готового кода. Образцы разработки, с которыми можно познакомиться в книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования» (Design Patterns: Elements of Reusable Object-Oriented Software) появились как попытка обнаружить и документировать допускающие многократное использование решения часто возникающих при разработке программного обеспечения проблем. Они формализовали изучение существующего кода, сделав его доступным большому количеству профессионалов в области ПО. Тем не менее это всего лишь небольшой фрагмент обучающих практик, которыми мы можем воспользоваться посредством чтения кода.

Какими алгоритмами пользуются другие программисты для решения отдельно взятых задач? Как со стратегической точки зрения они именуют переменные, функции и структуры? Если бы я захотел реализовать протокол мгновенных сообщений Jabber на другом языке, как это можно было бы сделать? Какие нестандартные способы существуют для управления взаимодействием UNIX– и Windows-процессов? Изучение чужого кода позволит тебе найти ответы на эти и другие подобные вопросы.

Чужой код не только позволяет найти ответы на конкретные вопросы, но и служит своего рода увеличительным стеклом для рассмотрения собственного стиля и способностей. Прослушивание записей Джона Колтрейна (John Coltrane) всегда напоминает мне о моем уровне игры на саксофоне, аналогичный смирительный эффект несет чтение трудов выдающихся разработчиков программного обеспечения. Но это нужно не только для того, чтобы вспомнить про свое место. В процессе чтения их кода обнаруживаются вещи, с которыми ты сам вряд ли когда-либо справился бы. Ты может обнаружить даже то, о чем ты, скорее всего, никогда не додумался бы. Почему? О чем именно думал этот разработчик? Какой была его мотивация? Подобное придирчивое и углубленное изучение результатов чужого труда позволяет учиться даже на примере плохого кода.

Используй чужой код для оценки собственных способностей.

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

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

Критически анализируя этот код, ты постепенно начнешь вырабатывать собственный вкус, как это бывает в музыке, живописи и литературе. Различные стили и приемы тебя позабавят, удивят, рассердят и (надеюсь) стимулируют к работе. Ищущий найдет тут всё – от трюков, повышающих продуктивность работы, до парадигм проектирования, полностью меняющих подход к целому классу проблем. Как и в искусстве, изучая особенности чужих работ и учась на них, ты выработаешь свой ни на кого не похожий стиль разработки ПО.

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

Сэр Исаак Ньютон сказал: «Если я видел дальше других, то лишь потому, что стоял на плечах гигантов». Такие умные ребята, как Исаак, знают, что мы многому можем научиться у тех, кто был до нас. Будь таким же.

Действуй!

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

Найди группу единомышленников для ежемесячных встреч. На каждой встрече один из членов группы должен предлагать для разбора код длиной от 2 до 200 строк. Группа должна проанализировать и обсудить его. Подумайте, какие решения принимались при его написании и что можно было бы добавить.

Совет 18
Автоматизация задач

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

К сожалению, меня часто прерывали на полуслове. И проблема была вовсе не в моей неправоте (это очевидно!). Но простого способа доказать мою правоту не существует. А с точки зрения затрат единственные имеющиеся у нас объективные данные заставляли сделать вывод о выгоде найма сотрудников с более низкой почасовой оплатой.

Представь себе гипотетический проект по созданию программного обеспечения для какой-либо сферы по твоему выбору. Сколько программистов потребуется, чтобы написать такую программу за три месяца? Говоришь, пять? Шесть? (Потерпи минутку.) Хорошо. А как насчет выполнения этого проекта за два месяца? Как ты уберешь целый месяц?

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

Но достичь поставленной цели можно несколькими способами. Для увеличения объемов производства программного обеспечения можно:

♦ нанять тех, кто будет работать быстрее;

♦ нанять дополнительных работников;

♦ автоматизировать работу.

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

Это дает простую формулу, привязанную к фиксированному периоду времени:

Продуктивность = Количество проектов / (Количество программистов * Почасовая оплата)

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

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

Я помню сенсационную безработицу в США в 1980-х. В то время мы возлагали вину не только на другие страны, но и на машины, а особенно на компьютеры. На предприятиях стали появляться гигантские роботы-манипуляторы. Эти роботы настолько превосходили людей в производительности и точности, что состязаться с ними не было никакой возможности. Расстроены такой ситуацией были все, кроме создателей этих роботов.

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

Введя в формулу нашего финансового директора некоторые (вымышленные) цифры, мы получим показанное ниже уравнение.

Сравнение производительности

Быстрые программисты: 5 / (З * $80) = 0,02.

Дешевые программисты: 5 / (20 * $12) = 0,02.

Один программист + робот: 5 / (1 * $80) = 0,06

Автоматизация является неотъемлемой частью нашей отрасли. Но по каким-то причинам мы пока не хотим автоматизировать наш труд разработчиков программного обеспечения. Как гарантированно создавать программы быстрее и дешевле зарубежных конкурентов? Нужно сделать роботов. Автоматизируй свою работу!

От консультанта по вопросам информатизации до генерального директора

Вик Чадха, генеральный директор Enterprise Corp.

Путь от консультанта по информационным технологиям в General Electric до должности entrepreneur-in-residence [12]12
  Должность в фирмах из сферы венчурного капитала, юридических фирмах, бизнес-школах, которую занимает опытный предприниматель, назначенный компанией с венчурным капиталом, университетом или другой организацией. Человек, отвечающий за запуск новых компаний, помощь в оценке потенциальных инвестиций и функциональную экспертизу для помощи с текущим инвестированием. – Примеч. пер.


[Закрыть] в bCatalyst (бизнес-акселератор с фондом в 5 миллионов долларов) – вовсе не та карьера, о которой я мечтал.

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

Вскоре после получения степени магистра в области электроники и вычислительной техники в Политехническом университете Виргинии я устроился консультантом в General Electric. Набирало обороты использование интернета в коммерческих целях, и я работал над несколькими проектами, предназначенными для извлечения максимальной выгоды из этой невероятно мощной платформы и лежащих в ее основе технологий. Произошел стремительный переход из IT-отдела финансового департамента в группу технологий и сервисного обслуживания, затем – в группу отдела продаж, занимающуюся автоматизацией, и наконец – в группу складского учета. В каждой группе я занимался разработкой новых программ. Я обожал исследование и последующее внедрение, изучение новых сетевых технологий и их применение к решению сложных коммерческих задач.

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

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

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

Вместе с моим предприимчивым бывшим соседом, а ныне близким другом (Раджем Хаджелой) и моей женой (Видаей) я занялся мозговым штурмом, направленным на выявление неудовлетворенных потребностей на рынке. Нас привлекала электронная коммерция, но заниматься продажей товаров широкого потребления мы не хотели. Мы интересовались искусством и имели соответствующий опыт. Плюс ко всему привлекал тот факт, что каждое произведение искусства уникально по своей природе. Мой дядя-художник всю свою жизнь испытывал трудности с заработком. Исследования показали, что с этой проблемой сталкивается большинство художников. Появилась идея платформы, позволяющей художникам публиковать и рекламировать свои работы, поддерживая связь с постоянными покупателями. В результате появился сайт Passion4Art.com, а мы занялись сложным делом поиска художников, которые согласились бы там зарегистрироваться и предоставить цифровые копии своих картин. После регистрации первой тысячи пользователей, открывших у нас собственные страницы, выгода нашего предложения стала очевидной, поэтому мы занялись поисками внешнего финансирования.

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

После рассказа о поиске субсидий для развития инфраструктуры он любезно порекомендовал отправить наш бизнес-план в недавно появившийся в городе бизнес-акселератор bCatalyst.

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

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

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

Тогда я попросил еще об одной встрече с Китом и сказал, что собираюсь уйти из General Electric, чтобы на следующие несколько месяцев посвятить себя работе в его команде и совместному исследованию возможностей для открытия бизнеса. Я объяснил, что они ничем не рискуют, ведь я не прошу никаких долговременных гарантий (по аналогии с условно-бесплатным программным обеспечением). В итоге меня взяли на работу, потому что я смог убедить в своем желании поставить на карту все, уйдя из General Electric даже при отсутствии четких гарантий на будущее.

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

Я составил список и предлагаю вам с ним ознакомиться на случай, если вам когда-нибудь потребуется получить деньги от венчурной компании http://www.enterprisecorp.com/resources/assessment.htm.

Навыки, полученные за год работы в компании bCatalyst, привели меня на должность генерального директора Enterprise Corp. За семь прошедших лет мне довелось работать с более чем ста компаниями, которым я помог получить около 75 миллионов долларов. Я испытываю глубокое удовлетворение от своей работы, которую никогда бы не получил, не рискни я попробовать себя в совершенно новой области. Подобный процесс невозможен без крутых поворотов. Надеюсь, что вы, читатель, сможете использовать мою историю как источник вдохновения для поиска собственного уникального пути, который позволит в полной мере задействовать ваши способности.

Действуй!

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

2. Исследуй архитектуру, управляемую моделями (Model-Driven Architecture, MDA). Попробуй поработать с доступными инструментами. Посмотри, где в твоей работе можно применить если не весь инструментарий, то хотя бы некоторые концепции MDA. Подумай о применении этих концепций к ежедневно используемым тобой инструментам.

Часть III
Исполнение

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

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

Подобно парню, желающему «стать J2ЕЕ-разработчиком», о котором шла речь в совете № 9, большинство из нас не отождествляет себя с фирмами, дающими нам работу. Я имею в виду, что я прежде всего программист и только потом человек, помогающий компании Fortune 500 продавать посудомоечные машины. Я разработчик архитектуры приложений, а не служащий энергетической компании. Это неудивительно, если смотреть на создание программного обеспечения как на ремесло. Выбранное нами ремесло обычно никак не связано с отраслью, в которой мы его применяем. Архитектор, проектирующий офис для военного ведомства, остается архитектором, а не превращается в военного подрядчика.

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

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

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