Тот факт, что в вашем коде заведомо будут присутствовать ошибки, не означает, что вы не несете за них ответственность. Написать идеальную программу практически невозможно, но за все недочеты несете ответственность именно вы, и никто другой.
За свою карьеру отвечаете вы сами. Ваш работодатель не обязан заботиться о вашей востребованности на рынке труда. Он не обязан обучать вас, отправлять вас на конференции или покупать книги. Всем этим должны заниматься вы сами.
В неделе 168 часов. 40 достается вашему работодателю, еще 20 – вашей карьере. Остается 108. 56 тратится на сон, на все остальное остается 52. Возможно, вы не хотите брать на себя подобные обязательства. И это вполне нормально, но тогда не считайте себя профессионалом.
я часто применяю метод повторения простых упражнений вроде «игры в боулинг» или «разложения на простые множители». Я называю эти упражнения ката. Существует много разных ката, из которых можно выбрать то, что лучше подойдет вам.
Ката обычно имеет вид простой задачи по программированию – например, написать функцию, которая раскладывает целое число на простые множители. Целью выполнения ката является не поиск решения; вы уже знаете, как решается задача. Ката тренируют ваши пальцы и ваш мозг.
Я ежедневно выполняю одну-две ката, часто в процессе погружения в работу.
Относитесь к ката как к 10-минутной разминке по утрам и 10-минутной релаксации по вечерам.
Профессионалы берут на себя персональную ответственность за обучение новичков. Они не бросают новичков, предоставляя им самим решать свои проблемы.
профессионал также знает, что в отдельных случаях он потерпит неудачу, его оценки риска окажутся неверными, а его способности – недостаточными; он посмотрит в зеркало и увидит, что оттуда ему улыбается самонадеянный болван.
Итак, оказавшись мишенью для насмешки, профессионал смеется первым. Он сам никогда не высмеивает других, но принимает заслуженные насмешки и легко отмахивается от незаслуженных. Он не издевается над коллегами, допустившими ошибку, потому что знает – следующим может быть он сам.
Рабам запрещается говорить «нет». Наемные работники неохотно говорят «нет». Но профессионалу положено говорить «нет». Более того, хорошим руководителям очень нужны люди, у которых хватает смелости сказать «нет». Только так можно действительно чего-то добиться.
Когда ваш руководитель говорит вам, что страница входа в систему должна быть готова к завтрашнему дню, он преследует и защищает одну из своих целей. Он выполняет свою работу. Если вы хорошо знаете, что сделать страницу к завтрашнему дню невозможно, то отвечая: «Хорошо, я попытаюсь», вы не выполняете свою работу. Выполнить ее в этот момент можно только одним способом: сказать: «Нет, это невозможно».
Но разве вы не должны выполнять распоряжения начальства? Нет, ваш начальник рассчитывает на то, что вы будете защищать свои цели так же жестко, как он защищает свои. Таким образом вы вдвоем приходите к оптимальному результату.
Майк: «Да ладно, Пола, можно хотя бы попытаться?»
Пола: «Майк, я могу попытаться летать по воздуху. Могу попытаться превратить свинец в золото. Могу попытаться переплыть Атлантический океан. Как ты думаешь, у меня получится?»
Майк: «Послушай, я же не требую невозможного».
Пола: «Нет, Майк, именно требуешь».
Искушение «быть героем» и «решать проблемы» велико. Однако все мы должны понять, что отказ от профессиональных принципов не решает проблемы, а создает
Обещайте только то, что находится под вашим полным контролем.
Если конечная цель зависит от кого-то другого, обещайте только конкретные действия, которые способствуют достижению конечной цели.
Если вы не можете выполнить свое обещание, очень важно как можно быстрее сообщить об этом тому, кому вы обещали.
Если вы не можете в достаточной степени сосредоточиться на своей работе, у вас получится плохой код. В нем будет много ошибок. Он будет иметь неверную структуру. Он получится запутанным и непрозрачным. Он не будет соответствовать истинным потребностям заказчика. Короче говоря, код придется перерабатывать или писать заново. Работа без сосредоточенности – напрасная трата времени.
Если вы устали или не можете сосредоточиться – не пишите код.
вам не удастся полностью избежать помех, которые неизбежно будут отвлекать вас и приводить к потерям времени. Вспомните, что в следующий раз помощь может понадобиться вам. Таким образом, профессионализм проявляется в вежливой готовности прийти на помощь.
Не можете уйти домой, пока не решили свою задачу? Уйти не только можно, но и нужно! Творческое мышление и интеллектуальная деятельность – недолговечные состояния нашего разума. Когда мы устаем, они исчезают.
Вы будете отставать от графика. Это происходит с самыми лучшими из нас. Это происходит с самыми прилежными. Оценки срываются, а результат запаздывает.
Чтобы свести к минимуму проблемы, связанные с отставанием, помните о двух важнейших аспектах: раннем обнаружении и прозрачности. Хуже всего, когда вы до последнего момента уверяете окружающих, что работа будет завершена вовремя, а потом подводите всех. Не делайте этого.
Регулярно проверяйте ход проекта по отношению к конечной цели и представьте три[16] обоснованные конечные даты: лучшую, номинальную и худшую.
Надежда убивает проекты. Надежда срывает графики и рушит репутации. Надежда навлечет на вас большие неприятности. Если выставка начнется через 10 дней, а номинальная оценка составляет 12 дней, вы не успеете к сроку. Убедитесь в том, что группа и ключевые участники проекта понимают ситуацию, и не успокаивайтесь до тех пор, пока не будет сформулирован альтернативный план. И не позволяйте надеяться другим.
А если начальник приглашает вас на беседу и настоятельно просит успеть к сроку? Если он настаивает, что вы должны сделать «все возможное»? Не отступайте от своих оценок! Исходные оценки всегда точнее любых изменений, вносимых под давлением. Скажите начальнику, что вы уже рассмотрели все варианты (потому что вы их действительно рассмотрели) и что ускорить работу можно только одним способом – усечением части функциональности. Не поддавайтесь искушению ускорить темп.
соглашаться только при выполнении некоторых условий: 1 – лично вы можете ее себе позволить; 2 – аврал будет продолжаться недолго, не более двух недель, и 3 – у руководства имеется резервный план на случай, если ваши усилия завершатся неудачей.
Последний критерий имеет решающее значение. Если ваш начальник не может объяснить, что он собирается делать в случае неудачного исхода, не соглашайтесь на сверхурочную работу.
Проблема ложной готовности решается созданием независимого определения «готовности». Для этого следует поручить бизнес-аналитикам и специалистам по тестированию создать автоматизированные приемочные тесты,[17] без прохождения которых продукт не может считаться готовым.
Честь профессионала обязывает предложить ближним помощь тогда, когда это потребуется.
Научитесь просить о помощи. Когда вы зашли в тупик или не можете разобраться в задаче, попросите других помочь вам.
хирургам уже не нужно доказывать полезность мытья рук. И я не думаю, что программистам нужно защищать TDD.
Добавляем небольшой фрагмент в тестовый код. Добавляем небольшой фрагмент в рабочий код. Два кодовых потока растут одновременно, превращаясь во взаимодополняющие компоненты.
одно из величайших преимуществ TDD. Если у вас имеется пакет тестов, которому можно доверять, вы перестаете бояться вносить изменения. Видя плохой код, вы просто чистите его «на месте». Код становится глиной, из которой лепятся простые, эстетичные структуры.
Когда программист перестает бояться чистить код, он чистит его!
Три закона TDD
1. Новый рабочий код пишется только после того, как будет написан модульный тест, который не проходит.
2. Вы пишете ровно такой объем кода модульного теста, какой необходим для того, чтобы этот тест не проходил (если код теста не компилируется, считается, что он не проходит).
3. Вы пишете ровно такой объем рабочего кода, какой необходим для прохождения модульного теста, который в данный момент не проходит.
Программные ката представляют собой строго определенный набор отрепетированных нажатий клавиш и перемещений мыши, имитирующих решение некоторой программной задачи. Вы не решаете задачу, потому что уже знаете решение. Вместо этого вы тренируетесь в выполнении действий и принятии решений, необходимых для решения задачи.
Отработка нескольких ката помогает запомнить «горячие клавиши» и идиомы навигации. Она также хорошо работает при изучении таких дисциплин, как разработка через тестирование (TDD) и непрерывная интеграция (CI, Continuous Integration). Но самое важное – ката помогают закрепить в подсознании пары «задача/решение»; столкнувшись с этими задачами в реальном программировании, вы попросту будете знать, как они решаются.
Один из способов «держаться на переднем крае» позаимствован из практики адвокатов и врачей: выполняйте общественно-полезную работу, участвуя в проекте с открытым кодом. Таких проектов очень много; пожалуй, нет лучшего способа пополнить ваш творческий арсенал, чем поработать над проектом, который принесет пользу другим.
Профессиональные программисты тренируются в личное время. Ваш работодатель не обязан заботиться о поддержании вашей квалификации или расширении вашего резюме. Пациенты не платят врачам, тренирующимся в наложении швов.
Профессиональные разработчики понимают, что оценки могут (и должны) базироваться на требованиях с низкой точностью. Они понимают, что оценка – это именно оценка. Они всегда включают в свои оценки диапазоны погрешности, чтобы бизнес-участники понимали наличие неопределенности
«неоднозначность в документе с требованиями появляется из-за разногласий между участниками[34]».
Профессиональные разработчики (и менеджеры) должны следить за тем, чтобы из требований была исключена всякая неоднозначность.
Профессиональные разработчики расширяют определение требований до автоматизированных приемочных тестов. Они общаются с ключевыми участниками и специалистами по контролю качества, стремясь к тому, чтобы автоматизированные тесты полностью отражали определение «выполнения».
Приемочные тесты всегда должны быть автоматизированными. В других моментах жизненного цикла программных продуктов находится место для ручного тестирования, но такие тесты никогда не должны выполняться вручную. Причина проста: затраты.
Бизнес-аналитики обычно пишут «оптимистичные» версии тестов, потому что эти тесты описывают аспекты, обладающие коммерческой ценностью. Служба контроля качества обычно пишет «пессимистичные» тесты с проверкой всевозможных граничных условий, исключений и аномальных случаев.
Согласно принципу «поздней точности» приемочные тесты следует писать как можно позднее, обычно за несколько дней до реализации. В проектах на базе гибких методологий тесты пишутся после выбора функций для следующей итерации или спринта.
Первые приемочные тесты должны быть готовы к первому дню итерации. Новые тесты должны появляться ежедневно вплоть до середины итерации, когда готовы должны быть все тесты.
Не путайте приемочные тесты с модульными (unit tests). Модульные тесты пишутся программистами для программистов. Они представляют собой формальные архитектурные документы с описанием нижнего уровня структуры и поведения кода. Их читателями являются не бизнесмены, а программисты.
Приемочные тесты создаются бизнесменами для бизнесменов (даже если в конечном итоге их пишете вы, разработчик). Они представляют собой формальные описания требований, определяющие поведение системы с точки зрения бизнеса. Их читателями являются бизнесмены и программисты.
Модульные и приемочные тесты прежде всего являются документами и лишь потом – тестами. Их главная цель – формальное документирование архитектуры, структуры и поведения системы. Автоматическая проверка архитектуры, структуры и поведения чрезвычайно полезна, но истинной целью является именно документирование.
пишите тесты бизнес-логики так, чтобы они проходили через API, находящийся за графическим интерфейсом.
Проследите за тем, чтобы все модульные и приемочные тесты запускались несколько раз в день в механизме непрерывной интеграции. Этот механизм должен инициироваться вашей системой управления исходным кодом. Каждый раз, когда кто-то вносит в базу новый модуль, механизм непрерывной интеграции должен инициировать сборку с последующим запуском всех тестов в системе. Результаты запуска должны рассылаться всем участникам группы.
Очень важно, чтобы тесты непрерывной интеграции все время проходили успешно. Они никогда не должны завершаться отказом. В случае отказа вся группа прекращает заниматься текущими делами и направляет все усилия на то, чтобы обеспечить успешное прохождение всех тестов. Сборка в системе с непрерывной интеграцией должна рассматриваться как экстренное событие, своего рода «стоп-сигнал».
Слишком часто стороны соглашаются с тем, что они поняли друг друга, и расходятся с совершенно разными убеждениями.
Мне известен только один способ эффективного исключения коммуникационных ошибок в общении программистов с ключевыми участниками проектов – написание автоматизированных приемочных тестов. Эти тесты формализованы, полностью однозначны и всегда остаются синхронизированными с приложением. Они являются идеальным документом, определяющим требования к проекту.
тестирование не сводится к написанию нескольких модульных или приемочных тестов. Написание этих тестов – дело полезное, но отнюдь не достаточное. Любой группе профессиональных разработчиков нужна хорошая стратегия тестирования.
группа разработки должна стремиться к тому, чтобы контроль качества не выявлял никаких дефектов.
оптимальная роль для специалистов по контролю качества должна заключаться в создании спецификаций и описании характеристик системы.
Служба контроля качества должна работать совместно с бизнес-стороной для создания автоматизированных приемочных тестов, которые представляют собой истинную спецификацию и документированные требования к системе. Последовательно, от итерации к итерации, они получают информацию о требованиях со стороны бизнеса и преобразуют их в тесты, которые описывают желаемое поведение системы для разработчиков (см. главу 7, «Приемочное тестирование»). Как правило, бизнес-сторона создает «оптимистичные» тесты, а служба контроля качества – «пессимистичные» тесты с проверкой всевозможных граничных условий, исключений и аномальных случаев.
Встречи обходятся примерно в $200 в час на каждого участника. Здесь учитываются зарплаты, премии, затраты на использование помещения и т. д. Когда вы в следующий раз будете проводить рабочую встречу, посчитайте затраты на нее.
Человек, приглашающий вас на встречу, не отвечает за управление вашим временем – за него отвечаете только вы.
Одна из самых важных обязанностей вашего руководителя – удерживать вас от участия в лишних встречах. Хороший руководитель более чем охотно защитит ваш отказ от участия, потому что ваше время представляет для него такую же ценность, как и для вас.
оставаться на встрече, расходующей ваше время, в ход которой вы не можете внести сколько-нибудь значительного вклада, было бы непрофессионально. Вы обязаны разумно тратить время и деньги своего работодателя, поэтому в выборе подходящего момента для обсуждения вашего ухода нет ничего зазорного.
Если вас просят прийти на встречу, убедитесь в том, что вы знаете, какие темы будут обсуждаться, сколько времени на них выделено и какая цель должна быть достигнута. Если вам не удается получить четкие ответы на эти вопросы, вежливо откажитесь от участия.
На встречах планирования итераций из списка реализации должны выбираться те элементы, которые должны быть выполнены в ходе следующей итерации. Оценки и прогнозы коммерческой ценности выполняются заранее. При действительно хорошей организации работ приемочные/компонентные тесты должны быть уже написаны или хотя бы определены в черновом варианте.
есть простое эмпирическое правило: встреча не должна занимать более 5 % общего времени итерации. Таким образом, для недельной итерации (40 часов) встреча должна завершаться в пределах двух часов.
Профессионал оценивает приоритет каждой задачи независимо от своих личных страхов и предпочтений и решает эти задачи в порядке приоритетов.
Опыт и благоразумие помогут избежать некоторых тупиков, но обойти их все не удастся. Так что в действительности вы должны быстро понять, что ваш путь завел в тупик, и иметь смелость для отступления. Иногда это называется «правилом ямы»: если вы оказались в яме, прежде всего перестаньте копать.
Опыт и благоразумие помогут избежать некоторых тупиков, но обойти их все не удастся. Так что в действительности вы должны быстро понять, что ваш путь завел в тупик, и иметь смелость для отступления. Иногда это называется «правилом ямы»: если вы оказались в яме, прежде всего перестаньте копать.
Ничто не оказывает более основательного и долгосрочного отрицательного эффекта на производительность группы программистов, чем грязь в программном коде.
Движение вперед по грязи (когда вы знаете, что это грязь) является худшей из разновидностей инверсии приоритетов. Двигаясь вперед, вы обманываете себя, обманываете вашу группу, обманываете свою компанию и заказчиков. Вы говорите им, что все будет хорошо, хотя на самом деле вы ведете их к общей катастрофе.
Оценка – это первый клин, вбиваемый между бизнесменами и разработчиками. Это источник почти всего недоверия, связанного с этими отношениями.
Проблема в том, что оценки можно рассматривать по-разному. Бизнес любит рассматривать их как обязательства. Разработчики предпочитают рассматривать оценки как предположения. Между этими точками зрения существуют принципиальные различия.
Схема PERT предоставляет очень простой, но исключительно эффективный способ преобразования оценок в вероятностные распределения, подходящие для начальства.
При оценке задачи предоставляются три числа (так называемый анализ по трем переменным):
• О: оптимистическая оценка. Это значение выбирается предельно оптимистичено. Задача может быть выполнена за это время только в том случае, если все без исключения пройдет гладко. Более того, чтобы математическая теория сработала, вероятность такого исхода должна быть менее 1%1. Как видно из рис. 10.1, в ситуации Питера это один день;
• N: номинальная оценка (наиболее вероятная). На гистограмме она будет представлена самым высоким столбцом. На рис. 10.1 номинальная оценка составляет 3 дня;
• P: пессимистическая оценка. Эта оценка также должна быть крайне предельно пессимистической. В ней следует учесть все возможные неприятности, кроме ураганов, ядерной войны, блуждающих «черных дыр» и других катастроф. Математическая база также работает только в том случае, если вероятность этого исхода много меньше 1 %. В ситуации Питера пессимистическая оценка представлена крайним правым столбцом (12 дней).
По этим трем оценкам вероятностное распределение описывается следующей формулой: (O+4N+N)/6
σ – среднеквадратическое отклонение распределения времени выполнения задачи.
=(P-O) /6
Для любой последовательности задач предполагаемая продолжительность выполнения вычисляется простым суммированием продолжительностей всех задач последовательности.
Среднеквадратическое отклонение последовательности равно квадратному корню из суммы квадратов среднеквадратичных отклонений задач.
Простая схема PERT – один из разумных способов предотвращения подобных излишне оптимистических ожиданий. Профессионалы очень тщательно относятся к выбору разумных сроков, несмотря на давление и уговоры.
Метод быстрого голосования
Все участники сидят за столом. Задачи рассматриваются последовательно. Для каждой задачи проводится краткое обсуждение, описываются возможные усложняющие факторы и возможная реализация. Затем участники опускают руку под стол и поднимают от 0 до 5 пальцев в зависимости от того, сколько, по их мнению, займет решение задачи. Модератор считает до трех, после чего все участники одновременно показывают руки.
Если оценки согласуются, участники переходят к следующей задаче. В противном случае они продолжают обсуждение, чтобы определить причины расхождений. Цикл повторяется до тех пор, пока их оценки не будут согласованы. Согласие не обязано быть абсолютным – если оценки достаточно близки друг к другу, это тоже хорошо.
Одновременность предъявления пальцев очень важна. Участники не должны изменять свои оценки на основании оценок, которые они видят у других.
В оценке заложена ошибка. Собственно, поэтому они и называются оценками. Один из способов контроля ошибок основан на законе больших чисел.[48] В частности, из этого закона следует, что при разбиении большой задачи на несколько меньших и независимой их оценке сумма оценок меньших задач будет более точной, чем одна оценка большей задачи. Возрастание точности объясняется тем, что погрешности оценки меньших задач взаимно компенсируются.
Профессионал спокоен и решителен, даже когда он находится под давлением. Даже с ростом давления он не забывает полученные знания и методы, зная, что это лучший путь к выполнению установленных сроков и обязательств.
Профессионал всегда помогает бизнесу найти способ достижения его целей, но он не всегда принимает на себя обязательства, принятые за него. В конечном итоге, если нам не удастся выполнить обязательства, принятые за нас, то ответственность за это должен нести тот, кто эти обязательства принял.
Не изменяйте свое поведение в напряженной ситуации. Если ваши методы действительно оптимальны, то они должны соблюдаться даже в самые тяжелые времена.
Уведомите свою группу и начальство о неприятностях. Изложите свой план по выходу из кризиса. Обратитесь к ним за информацией и советом. Избегайте сюрпризов. Ничто не сердит людей и не делает их менее рациональными так, как сюрпризы. Сюрпризы повышают уровень стресса десятикратно.
Чтобы избежать проблемной ситуации, контролируйте свои обязательства, соблюдайте правила методологий и поддерживайте чистоту в коде.
Первая обязанность профессионального программиста – заботиться об интересах своих работодателей. Это означает, что вы должны общаться со своими начальниками, бизнес-аналитиками, тестерами и другими участниками группы, чтобы глубоко понимать коммерческие цели проекта. Никто не заставляет вас становиться экспертом в области бизнеса. Просто нужно понимать, зачем вы пишете свой код и какую пользу
Профессиональные разработчики не запрещают коллегам работать со своим кодом. Они не возводят вокруг своего кода стены принадлежности. Напротив, они стараются работать друг с другом над как можно большей частью кода. И работая над другими частями системы, они учатся друг у друга.
Профессионалы также объединяются в пары, потому что это лучший способ обмена знаниями.
Профессионалы объединяются в пары, потому что это лучший способ рецензирования кода.
Возможно, вам кажется, что в одиночку вы будете работать эффективнее. Даже если это и так, отсюда вовсе не следует, что группа будет работать эффективнее.
программирование не для того, чтобы работать с людьми. Ему не повезло: все программирование неразрывно связано с работой с людьми. Мы должны общаться со стороной бизнеса, и мы должны общаться друг с другом.
Бессмысленно приказывать программисту посвятить половину времени проекту A, а другую половину – проекту B, особенно если в двух проектах участвуют разные руководители, бизнес-аналитики, программисты и тестеры.
Группы формируются не сразу. Между участниками постепенно налаживаются отношения. Они учатся работать друг с другом, узнают странности, сильные и слабые стороны своих коллег. Со временем участники «притираются» друг к другу.
В «притертой» группе есть что-то волшебное: она способна творить чудеса. Участники понимают друг друга, поддерживают и требуют максимальной отдачи. Благодаря их взаимодействию достигаются результаты.
Аналитики разрабатывают требования и пишут для них автоматизированные приемочные тесты. Тестеры тоже пишут автоматизированные приемочные тесты, но отличаются от аналитиков направленностью. И те и другие пишут тесты, но аналитики ориентируются на коммерческую ценность, а тестеры – на правильность работы кода. Аналитики пишут «оптимистичные» тесты, а тестеры беспокоятся о том, что может пойти не так, и пишут тесты для выявления сбоев и граничных случаев.
Создать хорошую группу сложнее, чем создать проект. Соответственно лучше формировать группы с постоянным составом, которые переходят от одного проекта к другому и могут заниматься несколькими проектами одновременно. При формировании группы следует дать ей достаточно времени для того, чтобы она сработалась, а затем использовать ее как инструмент для успешного выполнения многих проектов.
Различия между сегодняшним положением дел и моей идеализированной программой заключается в ориентированности последней на техническое обучение, опеку и контроль. Оно проявляется в самом представлении о том, что профессиональные ценности и техническую сметку нужно объяснять, культивировать и взращивать. В нашем современном стерильном подходе отсутствует ответственность старших за обучение молодежи.
Профессионализм – стиль жизни с определенными представлениями о ценностях, методологиях, приемах, подходе и ответах на вопросы.
Нельзя убедить людей быть профессионалами. Нельзя убедить их принять профессиональное отношение к делу. Аргументы неэффективны. Данные непоследовательны. Ситуационные исследования не значат ничего. Принятие профессионального отношения является не столько рациональным, сколько эмоциональным решением. Это очень человеческое решение.
Как же подвести людей к переходу на профессиональное отношение? Да, оно заразительно, но только в том случае, если вы можете наблюдать за его проявлением. Следовательно, вы должны демонстрировать его. Станьте образцом для подражания. Вы становитесь профессионалом сами и показываете свой профессионализм другим. А затем пусть концепция сама сделает всю работу.