Недостаточно создавать просто работающий софт

Позвольте мне побыть самокритичным на минутку. Присоединяйтесь.

Ложь

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

Уже в течение многих лет я не работаю ни над чем другим кроме новых проектов (чистые заготовки, новые свежие репозитории). Это действительно помогло мне испробовать много новых техник и реализовать новые идеи. За 2 самых продуктивных года я создал около 40 веб-приложений разных размеров с моим хорошим другом и коллегой Джастином Сейтером. Это был замечательный опыт для меня, и я этому рад.

Я верил в то, что был «на гребне волны».

Правда

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

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

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

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

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

Попытка искупления

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

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

В течение всего этого времени я никогда не задавался вопросом: «Что делают другие люди?» Я никогда не считал необходимым учиться у авторитетных людей. Я не хотел читать старые пыльные тома о PHP и HTTP. Я знал, что мне надо улучшить, но не знал как. У меня была идея, что возможно я много выиграю от изучения других языков программирования, но я не видел никаких особых причин заниматься этим вместо работы над своим бизнесом и заказами клиентов, поэтому ничего не менялось.

Реализация

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

Пока я не начал вплотную заниматься автоматическим тестированием, я не осознавал, что я на самом деле не понимаю объектно-ориентированное программирование. Я знал, как использовать части, классы и объекты, инкапсуляцию, всё такое… Я только не понимал, как это всё сочетается.

Когда ко мне пришло осознание, передо мной открылся новый мир. Я наткнулся на видео Дяди Боба и начал зарываться в такие изобилующие ресурсы, как Шаблоны архитектуры промышленных приложений, Рефакторинг, и чудесно названный POODR. Внезапно я понял, что проблемы, которые я решаю, не новы, и что мои решения ужасно устарели.

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

В этот момент я совершенно ясно осознал, что просто делать так, чтобы что-то работало, совершенно недостаточно. У меня было слишком много власти над результатами проектов. У меня было слишком много ответственности. Часто надо мной не было абсолютно никакого контроля. Рядом не было никого, кто знал бы, что я могу сделать лучше.

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

У меня была другая ситуация.

Ответственность

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

«Кто караулит Караульного?»

Если никто кроме вас не оценивает вашу работу с критической точки зрения, то на вас лежит двойная ответственность, чтобы это делать.

Несколько примеров того, как я не брал на себя ответственность в течение своей карьеры:

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

Есть ещё очень много примеров. (Пожалуйста, поделитесь со мной своими, если они напомнят мне о моих, то я добавлю их в список)

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

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

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

Долгосрочность

Стоимость сопровождения — стоимость работы над кодовой базой после запуска. Сюда входят исправления ошибок, копирование изменений, новые функции и т.д. Это значит — всё.

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

Следовательно, важна оптимизация для снижения затрат на сопровождение. Но как часто мы на самом деле это делаем? Знаем ли мы, как сократить затраты?

Я знаю, это моё мнение, что два лучших способа сократить расходы это:

1. нанимать очень хороших инженеров
2. доверять им

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

Парадокс квалифицированных инженеров

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

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

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

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

Что для этого нужно?

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

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

Разработчик ПО, который сопротивляется изменениям, находится в весьма невыгодном положении.

Вместо фокусирования внутрь нам надо фокусироваться наружу. Что делают другие? Как другие люди решают эти проблемы?

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

Так как же мы можем решить проблему слишком глубокого погружения в «кроличью нору», когда у нас больше нет бюджета на то, чтобы из неё выбраться?

Строгое и постоянное обучение

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

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

Опыт важен.

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

Мартин Фаулер, Кент Бек, Дядя Боб, Эрик Эванс, Санди Мец и многие другие постоянно влияли на меня. Я не могу представить, как бы я стал собой без них. Сложно сказать. Знаю ли я всё? Совсем нет. Но благодаря этим людям у меня есть то, что необходимо для движения вперёд. Моё видение.

Я настоятельно рекомендую следить за работой этих людей. Читать их книги в туалете, если придётся. Смотреть видеоролики Clean Coders за обедом. Всегда, всегда, всегда заставлять себя поглощать новую информацию.

На нас лежит серьёзная ответственность. Мы значительно влияем на жизни других людей. Мы в состоянии навредить бизнесу. Давайте признаем это и будем действовать соответственно.

Мне нравится моя работа и проекты, которые я завершил. Я просто хочу быть честным.

Откровенный разговор

Не тратьте своё время, изучая какой-либо фреймворк. Конечно, вы должны изучить, как работать с ним. Но фреймворк должен быть чем-то большим, чем деталь вашего приложения, которая должна быть изолирована от остальных насколько это возможно. Изучайте что-то НАСТОЯЩЕЕ. Учитесь проектированию приложений (для меня это объектно-ориентированное проектирование). Объектно-ориентированное проектирование намного больше, чем Ruby, Java, PHP, или любой язык ООП. Это способ мышления. Это больше, чем язык. Это важнее.

По этой теме я рекомендую книгу The Clean Coder. Я считаю, что для программиста прочитать эту книгу важнее, чем любую книгу по программированию.

Я оставляю за собой право обновлять/улучшать эту статью на неограниченный срок.

Медиа

Вы можете наблюдать начало формирования многих этих идей в этом докладе, который я сделал в феврале 2013. Я расширил и обновил доклад для конференции Groningen PHP.