Чед Фаулер - Программист-фанатик
1. TopCoder. TopCoder.com — это сайт корпорации, проводящей соревнования по спортивному программированию. Ты можешь зарегистрироваться там и участвовать в соревнованиях с призами. Для тех, кто не любит соревноваться с другими, на сайте есть раздел с набором задач, которые послужат прекрасной основой для отработки практических навыков. Регистрируйся и начинай заниматься.
2. Code Kata. Один из самых прагматичных программистов, наш любимый издатель Дэйв Томас (Dave Thomas), превратил идею наработки программистских навыков в… кое-что прагматичное. Его кодовая ката (code kata) — набор небольших, но провокационных упражнений. Программисты могут выполнять их на любом языке. Каждая ката делает упор на определенную технику или мыслительный процесс, нагружая один из твоих ментальных мускулов.
На момент написания этой книги Дэйвом была создана двадцать одна ката. Все они доступны в его блоге (http://codekata.pragprog.com/). Там же можно найти список рассылки и чужие решения этих упражнений, а также обсуждения способов решения.
Твоя задача — выполнить всё. Записывай результаты в дневник или веди блог. Закончив дело, напиши собственную кату и поделись ею с широкой публикой
Совет 16
Подход к работе
«Разработка программного обеспечения» — это не некая вещь, а процесс создания некой вещи. При написании кода важно сосредоточиться не только на разрабатываемом продукте, но и на самом процессе разработки. Отвлекаясь от процесса, мы рискуем опоздать со сроками выполнения задания, получить некачественный продукт или не получить вообще ничего. Ни один из этих вариантов заказчика не обрадует.
К счастью, процесс создания хорошего программного обеспечения (и в целом продукции) давно как следует обдуман. И изрядная часть этой информации легла в основу целой группы методик. Они описаны в книгах, доступных как в Сети, так и в обычном книжном магазине.
К сожалению, зачастую разработчики не пользуется преимуществами, которые дает данная информация. В большинстве команд процесс является делом второстепенным или даже навязываемым сверху. Слово методика с их точки зрения является синонимом бумажной работы и долгих бессмысленных собраний. И слишком часто методика превращается в нечто, навязываемое им руководством.
Интуитивно руководство понимает необходимость следования определенному процессу, но зачастую понятия не имеет о доступных в настоящее время вариантах. В результате начальник отряхивает пыль с процедур, которым его научили в 1980-е, пересказывает их с использованием модных словечек и учит всему этому подчиненных. И пока кто-нибудь не прервет порочный круг, исследовав, что работает, а что не очень, ситуация повторяется, как только очередной разработчик дорастает до руководящей должности.
Очевидно, должен существовать лучший способ разработки программного обеспечения. И у большинства групп он есть.
Как программист, тестировщик или дизайнер ПО ты можешь считать, что сам по себе процесс разработки не входит в сферу твоей ответственности. Возможно, это правильно, так как ты всего лишь наемный работник. Но, к сожалению, обычно эта ответственность повисает в воздухе. И даже если ее на кого-то возлагают, она передается «группе организации процесса» или другому отдельному подразделению. Но дело в том, что для успешного внедрения метода разработки программного обеспечения его должны принять те, кто будет им пользоваться, — такие, как ты.
Лучшим способом ощутить ответственность за подход к работе является участие в его внедрении. Если в фирме, где ты работаешь, производственный процесс отсутствует, изучи методики, которые могут тебе помочь. Во время обеденных перерывов обсуждай с другими членами группы проблемы текущего процесса разработки и варианты смягчения этих проблем путем перехода к некоему стандарту. Составь план внедрения выбранного тобою рабочего процесса и получи всеобщее одобрение. Затем приступай к реализации этого плана.
Чтобы почувствовать причастность к процессу разработки, помоги с его внедрением.
Возможен и вариант, когда ты работаешь в фирме, где производственный процесс спускается сверху. Здесь зачастую, когда инструкция добирается до группы разработчиков, к описанию технологических приемов добавляют столько лишних слов и интерпретируют их столь вольно, что они теряют свой первоначальный смысл. Инструкцию постигает судьба фразы в игре Испорченный телефон.[9] Тут ты снова можешь взять на себя инициативу. Изучи спущенную сверху методику и помоги своей группе и руководству корректно интерпретировать описание рабочего процесса. Если ты не собираешься бороться против спускаемых сверху инструкций, по крайней мере обеспечь корректность их практической реализации.
Мир методик быстро начинает напоминать наполненную трескучими словами полую раковину. Но если привыкнуть к подобной манере изложения, рассматривая процесс разработки программного обеспечения, всегда можно найти какую-то полезную информацию — даже если это информация о том, как не нужно делать. Человек, хорошо разбирающийся в способах организации рабочих процессов, более убедительно обосновывает принципы, в соответствии с которыми работает его группа.
Методики: Не только для зануд
Управление проектами далеко не всегда имеет отношение к методам разработки программного обеспечения, но ты можешь оказаться первым в своей компании, кто решил изучить данную тему. Многочисленные методики управления проектами широко используются во всей отрасли. Вероятно, самым известным является Свод знаний по управлению проектами (Project Management Book of Knowledge)[10] от Института управления проектами (с его общепризнанной программой сертификации).
Шесть сигм (Six Sigma)[11] — еще одна качественная методология, не связанная, впрочем, напрямую с программным обеспечением. Подход, продвигаемый такими монстрами, как General Electric и Motorola, придает особое значение измерению и анализу процессов и продукции для улучшения качества обслуживания клиентов и роста эффективности. Этот не имеющий отношения к разработке программного обеспечения, строгий и методичный подход предлагает данные, непосредственно применимые к работе программиста.
Несмотря на обилие нормативных методик, вряд ли ты когда-нибудь попадешь в компанию, полностью внедрившую какую-нибудь из них. И это нормально. Самым лучшим рабочим процессом считается тот, который обеспечивает наибольшую продуктивность группы и выпуск самой лучшей продукции.
Единственным способом создания подобного гибрида (ну, кроме божественного откровения) является изучение доступных вариантов и выбор оттуда фрагментов, приемлемых для тебя и твоей команды, которые будут постоянно совершенствоваться на основе реального опыта.
В конечном счете, если ты не в состоянии организовать рабочий процесс, ты не сможешь производить продукцию. Найти человека, который сможет писать программы, куда проще, чем человека, умеющего организовать процесс написания программ. Поэтому имеющиеся в твоем арсенале сведения о принципах организации процесса разработки ПО будут тебе только в плюс.
Действуй!1. Выбери методику разработки программного обеспечения и найди посвященные ей ресурсы. Начни читать книги и сайты, присоединись к списку рассылки. Посмотри на эту методику критически. Выдели с твоей точки зрения сильные и слабые стороны. Что мешает внедрить ее на твоем рабочем месте? Изучи аналогичным способом еще одну методику. Сравни достоинства и недостатки обеих методик. Можешь ли ты скомбинировать предлагаемые подходы?
Совет 17
На плечах гигантов
Будучи джазовым музыкантом, я часто слушаю музыку. И это не фоновая музыка, звучащая, когда я читаю или веду машину. Я в нее вслушиваюсь. Ведь джазовая импровизация представляет собой воспроизведение того, что ты слышишь кроме аккордов песни, и поэтому вдумчивое слушание является важным источником вдохновения и сведений о том, что работает, а что не очень. Что звучит здорово, а что всего лишь приемлемо.
Огромное количество записей, сделанных за историю существования джаза, представляет собой невероятный комплекс знаний, которым может воспользоваться любой, обладающий умением слушать. А значит, прослушивание музыки для джазового музыканта — не пассивная деятельность. Это обучение. Более того, умение понимать, что именно ты слышишь, — это навык, развивающийся со временем. Мои друзья-музыканты для этого устраивают специальные встречи. Мы сидим и слушаем джаз, а потом обсуждаем услышанное. Иногда мы играем в игру, в которой один из нас исполняет импровизированное соло, а остальные должны по стилю понять, какая запись послужила основой импровизации.
