Чед Фаулер - Программист-фанатик
- Название:Программист-фанатик
- Автор:
- Жанр:
- Издательство:Питер
- Год:2015
- Город:СПб.
- ISBN:978-5-496-01062-7
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Чед Фаулер - Программист-фанатик краткое содержание
В этой книге вы не найдете описания конкретных технологий, алгоритмов и языков программирования — ценность ее не в этом. Она представляет собой сборник практических советов и рекомендаций, касающихся ситуаций, с которыми порой сталкивается любой разработчик: отсутствие мотивации, выбор приоритетов, психология программирования, отношения с руководством и коллегами и многие другие. Подобные знания обычно приходят лишь в результате многолетнего опыта реальной работы. По большому счету перед вами — ярко и увлекательно написанное руководство, которое поможет быстро сделать карьеру в индустрии разработки ПО любому, кто поставил себе такую цель. Конечно, опытные программисты могут найти некоторые идеи автора достаточно очевидными, но и для таких найдутся темы, которые позволят пересмотреть устоявшиеся взгляды и выйти на новый уровень мастерства. Для тех же, кто только в самом начале своего пути как разработчика, чтение данной книги, несомненно, откроет широчайшие перспективы. Издательство выражает благодарность Шувалову А. В. и Курышеву А. И. за помощь в работе над книгой.
Программист-фанатик - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Придумай простой проект и попробуй создать прекрасное приложение в рамках ненавидимой тобой технологии. Если ты пишешь на языке Java, покажи этим фанатам .NET, как настоящий разработчик использует их платформу! В лучшем случае ты поймешь, что столь ненавидимая тобой технология на самом деле не так уж плоха и на ее основе можно создавать приличный код. Кроме того, у тебя появится (разумеется, пока не развитый) новый навык, из которого в будущем ты, возможно, сумеешь извлечь выгоду. В худшем случае ты выполнишь практическое упражнение, получив дополнительную базу для своих аргументов.
Совет 51
Избегай каскадного планирования карьеры
В начале этого тысячелетия один небольшой протест сильно изменил всю индустрию разработки программного обеспечения. Группа экспертов-разработчиков в какой-то момент поняла, что существующие методы ведения проектов могут привести как к успеху, так и к неудаче. В промышленных условиях, где большинство проектов оканчивается неудачей, они, как им казалось, нашли способ, ведущий к успеху. Эта группа называла себя альянсом специалистов по быстрой разработке ПО (Agile Alliance).
В индустрии в те времена считалось, что единственным способом разработки проектов является спуск сверху вниз по цепочке серьезно распланированных, жестко регламентированных процессов. Аналитики формировали список требований, передавали документацию архитекторам, которые создавали архитектуру и передавали ее дизайнерам, которые, в свою очередь, работали над детализированным дизайном. Затем все это отдавалось разработчикам, перед которыми стояла задача написать код дизайна на каком-нибудь языке программирования. Наконец, спустя месяцы, а иногда и годы усилий код собирался и отдавался группе тестировщиков, которые утверждали его развертывание.
Иногда вариации на тему такого процесса давали неплохие результаты. Когда в начале проекта все в деталях знают, что им предстоит делать, столь строгий подход к планированию позволяет получить хорошо продуманное и качественное программное обеспечение. Но в большинстве случаев исполнители не знали всех деталей реализации будущего проекта. Чем больше и сложнее проект, тем менее вероятно, что кто-то сможет вообразить все его особенности в мельчайших подробностях и написать спецификацию. Такой процесс называют каскадным, и в наши дни это слово почти всегда воспринимается как синоним плохого процесса.
В итоге члены альянса специалистов по быстрой разработке поняли, что следование жестко регламентированному процессу хотя и порождает хорошо протестированное и тщательно документированное программное обеспечение, но совсем не отвечает пожеланиям пользователей. Их бунт выразился в создании гибких методик. Это были процессы разработки приложений, в которые легко вносились изменения. На планирование и дизайн отводилось меньше времени. Если программы гибкие, значит, их модификация может обходиться дешево. Гибкие методики рассматривают изменения как неотъемлемую часть процесса разработки и упрощаются, чтобы сделать этот процесс по возможности дешевым и простым.
Сейчас все это звучит тривиально. Но изначально гибкие процессы стали источником конфликтов и дискуссий. В теории идея детального планирования и жесткости выглядела без сомнений верной. Просто на практике она работала далеко не всегда.
На ранних стадиях моего перехода к гибким подходам (особенно это касается экстремального программирования) я начал рассматривать все через призму гибкой разработки. Появлялись силы и мотивации, выходящие за рамки написания программ. Как только я сталкивался со сложной проблемой, то понимал, что постепенный подход к решению, допускающий изменения, в моем случае всегда является менее сложным и более эффективным.
Но почему-то на осознание того факта, что самым сложным проектом, которым я когда-либо занимался, — самый напряженным и важным — была моя карьера, потребовалось немало времени. Я запланировал свою карьеру сверху вниз, как проект программы, созданный в рамках каскадного процесса. В итоге со мной и с моей карьерой начинали происходить те же вещи, которые возникают в программных проектах.
Я успешно продвигался к должности вице-президента корпорации и директора по информационным технологиям. От зеленого программиста я быстро шагнул к архитектору программного обеспечения, руководителю и директору и мог легко представить, чем завершится моя цепочка. Но при всех моих успехах я начал ощущать, что занимаюсь не тем, что мне нравится. Более того, чем успешнее я становился, тем меньше получал удовольствия от работы.
Я делал для себя ровно то же самое, что строго регламентированные процессы делают для заказчиков. Я отлично справлялся с созданием для себя карьеры, которая была мне не нужна.
Сначала я не мог осознать, что подобная проблема решается просто. Достаточно поменять свою карьеру. Это может означать что угодно. Для меня это было возвращение к серьезным технологиям, которые изначально так восхищали меня в этой отрасли. Для моих знакомых это был переход от системного администрирования к разработке программного обеспечения, от работы, не связанной с компьютерами, — к программированию или вообще уход из профессии и посвящение себя любимому делу.
Как и в ситуации с разработкой программного обеспечения, стоимость изменений не должна быть слишком высокой. Разумеется, превратиться из тестировщика в адвоката вряд ли будет легко. Но в трансформации из управленца в программиста и обратно нет ничего сложного. Несложно найти и новую фирму. Или переехать в другой город.
Карьерные изменения — это не строительство небоскреба, они не потребуют выкинуть на помойку весь наработанный ранее опыт. В настоящий момент я целыми днями пишу программы на Ruby, но мой опыт руководителя, занимавшегося переводом операций в офшоры, остается актуальным и помогает в моих трудах. Работодатели и клиенты это понимают и используют данное преимущество.
Важно понимать, что подобные изменения не только возможны, но и необходимы. Как разработчик ты никогда не позволишь вовлечь себя в ненужный заказчику проект. Гибкие методики просто не дадут тебе этого сделать. О твоей карьере можно сказать то же самое. Ставь большие цели, но по пути постоянно вноси коррективы. Учись на собственном опыте и меняй цели при необходимости. В конечном счете нам всем нужен довольный заказчик (а в деле планирования карьеры ты сам являешься собственным заказчиком), а не выполнение требований.
Совет 52
Лучше, чем вчера
Исправить ошибку легко (в общем случае). Что-то идет не так? Тебе об этом кто-то сообщил? Если ты можешь воспроизвести ошибку, то для исправления достаточно устранить вызывающие ее факторы и удостовериться, что проблем больше не возникнет. Если бы все трудности исчезали так просто!
Читать дальшеИнтервал:
Закладка: