Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО
- Название:Идеальный программист. Как стать профессионалом разработки ПО
- Автор:
- Жанр:
- Издательство:Издательство «Питер»046ebc0b-b024-102a-94d5-07de47c81719
- Год:2012
- Город:Санкт-Петербург
- ISBN:978-5-459-01044-2
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО краткое содержание
Всех программистов, которые добиваются успеха в мире разработки ПО, отличает один общий признак: они больше всего заботятся о качестве создаваемого программного обеспечения. Это – основа для них. Потому что они являются профессионалами своего дела.
В этой книге легендарный эксперт Роберт Мартин (более известный в сообществе как «Дядюшка Боб»), автор бестселлера «Чистый код», рассказывает о том, что значит «быть профессиональным программистом», описывая методы, инструменты и подходы для разработки «идеального ПО». Книга насыщена практическими советами в отношении всех аспектов программирования: от оценки проекта и написания кода до рефакторинга и тестирования. Эта книга – больше, чем описание методов, она о профессиональном подходе к процессу разработки.
Идеальный программист. Как стать профессионалом разработки ПО - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Переход на язык обязательств поможет вам пройти следующие две фазы: ответственного отношения к словам и выполнения обещанного.
Есть несколько причин, из-за которых говорящий может не относиться ответственно к своим обещаниям (или препятствующих их выполнению).
Выполнение обещания зависит от другого человека X
Обещайте только то, что находится под вашим полным контролем. Например, если вашей целью является завершение модуля, в работе над которым также участвует другая группа, вы не можете обещать завершить модуль с полной интеграцией. Однако вы можете обещать выполнить конкретные действия, которые приблизят поставленную цель. Вы можете:
• пообщаться часок-другой с Гарри из инфраструктурной группы, чтобы понять зависимости;
• создать интерфейс, абстрагирующий зависимости модуля от инфраструктуры другой группы;
• встречаться не менее трех раз в неделю с ответственным за сборку, чтобы обеспечить работоспособность ваших изменений в системе сборки, используемой в компании;
• создать собственную процедуру сборки, в ходе которой выполняются интеграционные тесты.
Видите разницу?
Если конечная цель зависит от кого-то другого, обещайте только конкретные действия, которые способствуют достижению конечной цели.
Вы не уверены в том, что обещание можно выполнить
Даже если конечная цель невозможна, вы можете взять на себя обязательства по выполнению действий, приближающих ее достижение. Более того, проверка достижимости цели может быть одним из таких действий!
Вместо того чтобы обещать исправить все 25 оставшихся ошибок до выхода финальной версии (что может быть невозможно), вы обещаете выполнить конкретные действия, приближающие вас к этой цели.
• Перебрать все 25 ошибок и попытаться воспроизвести их.
• Пообщаться с автором каждого сообщения об ошибке и увидеть ее воспроизведение.
• Потратить все оставшееся время на исправление ошибок.
Вы не справились
Что ж, бывает. Могло произойти что-то непредвиденное – жизнь есть жизнь. Однако вы не должны подводить тех, кто от вас чего-то ожидает. В такой ситуации лучше как можно скорее изменить ожидания.
Если вы не можете выполнить свое обещание, очень важно как можно быстрее сообщить об этом тому, кому вы обещали.
Чем быстрее вы оповестите о неудаче все заинтересованные стороны, тем больше вероятность того, что у группы будет время остановиться, переоценить текущую обстановку и решить, можно ли что-то сделать или изменить (например, приоритеты). Возможно, это позволит выполнить исходные обязательства или изменить их.
Пара примеров.
• Вы назначили встречу в кафе с коллегой, но застряли в транспортной пробке. Вы сомневаетесь в том, что вам удастся сдержать свое обещание вовремя быть на месте. Как только вы поймете, что можете опоздать, позвоните коллеге и сообщите ему об этом. Возможно, вы найдете другое место или отложите встречу.
• Вы пообещали исправить ошибку, которая на первый взгляд казалась вполне рядовой. В какой-то момент вы понимаете, что ошибка оказалась намного коварнее ваших представлений о ней, и поднимаете белый флаг. Далее группа может выбрать программу действий для выполнения этого обязательства (парная работа, проработка потенциальных решений, мозговая атака) или же изменить приоритеты и перевести вас на более простую ошибку.
Если вы никому не сообщите о потенциальной проблеме как можно быстрее, то никто не сможет вам помочь в выполнении ваших обязательств.
Резюме
Сама идея особого «языка обещаний» выглядит немного пугающе, но она поможет решить многие проблемы общения, с которыми программисты сталкиваются в своей повседневной работе: прогнозы, сроки, недоразумения при личном общении. Вас будут считать серьезным разработчиком, который держит свое слово, – а это, возможно, одна из самых высоких репутаций в нашей отрасли.
Учимся говорить «да»
Я попросил Роя разрешение на публикацию этой статьи, потому что она задела меня за живое. Я долго объяснял, как научиться говорить «нет». Однако не менее важно научиться говорить «да».
Обратная сторона «попытки»
Представьте, что Питеру поручено внести изменения в систему оценок. По его собственной оценке, работа займет пять-шесть дней. Он также полагает, что подготовка документации по изменениям займет несколько часов. В понедельник утром Мардж, его начальник, интересуется у него текущим состоянием дел.
Мардж: «Питер, изменения в системе оценок будут готовы к пятнице?»
Питер: «Я думаю, это возможно».
Мардж: «Вместе с документацией?»
Питер: «Попытаюсь сделать и ее».
Возможно, Мардж не слышит нерешительности в заявлениях Питера – на самом деле он ничего не обещает. Мардж задает вопросы, на которые нужно ответить «да» или «нет», а Питер дает неопределенные ответы.
Обратите внимание на слово «попытаюсь». В предыдущей главе мы определили его как «приложить дополнительные усилия», но здесь Питер использует определение «может, получится, а может, нет». Ему следовало бы отвечать иначе.
Мардж: «Питер, изменения в системе оценок будут готовы к пятнице?»
Питер: «Не исключено, но это может быть и понедельник».
Мардж: «Вместе с документацией?»
Питер: «На документацию уйдет еще несколько часов. Теоретически могу успеть к понедельнику, но возможно, документация будет готова только во вторник».
В данном случае Питер говорит более честно – он описывает существующую неопределенность. Возможно, Мардж удастся что-то сделать с этой неопределенностью. А может, и не удастся.
Дисциплинированное принятие обязательств
Мардж: «Питер, мне нужно четкое „да“ или „нет“. Система оценок вместе с документацией будет готова к пятнице?»
Мардж задает абсолютно правильный вопрос. Ей нужно обеспечить соблюдение графика, и ей нужен однозначный ответ насчет пятницы. Как должен ответить Питер?
Питер: «В таком случае я должен сказать „нет“. Самая ранняя дата, когда изменения и документация будут точно готовы, – это вторник».
Мардж: «Ты обещаешь сделать ко вторнику?»
Питер: «Да, ко вторнику все будет готово».
А если для Мардж очень важно, чтобы изменения и документация были готовы именно к пятнице?
Мардж: «Питер, со вторником у нас будут большие проблемы. Вилли, наш штатный технический писатель, освободится в понедельник. У него будет всего пять дней на подготовку руководства пользователя. Если документация по системе оценок не будет готова в понедельник утром, то он не уложится в срок. Ты не можешь сначала написать документацию?»
Читать дальшеИнтервал:
Закладка: