Писать хороший код я умею. Обычно это предполагает, что нужно потратить немного больше времени здесь и сейчас во имя некоего более совершенного миропорядка в будущем. Но здесь мы исходим из предпосылки, что нам известно, чего ждать от будущего. А в разработке будущее обычно прогнозируется с трудом.
Неопределенность может порождаться тем, что нам не всё известно о технологии, о бизнесе, о пользователе, объеме данных в системе, продолжительности жизни кода, а также другими неизвестностями, о которых мы даже не подозреваем (за расширенным списком примеров обратитесь к 2020 году).
В ситуации, когда будущее неопределенно, продолжительность цикла выходит на первый план. Скорость позволяет мне извлекать ценность из собственного кода: я быстрее осваиваю новые навыки, вред от плохого кода или отдельных ошибок в неплохом коде сводится к минимуму и продукт быстрее выходит на рынок.
Любые препятствия плохо влияют на продолжительность цикла. Они лишают меня возможности превращать неопределенность в определенность – а в этом и состоит суть обучения. Быстрое обучение формирует наиболее устойчивую ценность, оно выступает своего рода коэффициентом, на который умножается качество кода и архитектуры впоследствии. Есть такая поговорка «Писать значит переписывать», перелагая ее на код, можно сказать: «Писать код – значит проводить рефакторинг».
Исходя из этого, вот несколько причин, почему не нужно бояться писать паршивый код. Точнее сказать, почему не нужно бояться писать больше паршивого кода.
Если вы хотите научиться программировать, лучший способ для этого – практика. Как я для себя установил, читать можно сколько угодно, но пока не наберешь код своими собственными пальцами, информация не будет удерживаться. Написание кода – не то, чему можно научиться за день, это определенный способ мышления и подход к решению проблем, а также набор сведений об инструментах и вычислительных средах. Единственный способ углубить необходимые знания – работать с этими инструментами и средами. Каждый раз, как я что-то пишу, я подготавливаю почву для того, чтобы следующий раз прошел проще и результат получился лучше.
Когда пишешь паршивый код, основная цель – как можно быстрее получить что-либо на выходе. А это означает прямой путь к тому удовлетворению и ощущению успеха, которое возникает, когда что-то – что угодно – начинает работать. Я написал первую строку кода тридцать лет назад, и, тем не менее, меня по-прежнему охватывает восторг каждый раз, когда удастся привести очередной кусок кода в рабочее состояние.
Иногда в системах что-то не работает. Как я мог убедиться, именно это дает богатые возможности чему-то научиться. Самые ценные уроки я вынес не из какого-нибудь заранее просчитанного компромиссного решения о качестве кода, а из тех случаев, когда поведение системы совершенно не укладывалось в мои ожидания.
К тому же, когда выкладываешься, стараясь написать безупречный код, появляется эмоциональная вовлеченность в его корректную работу. Если по завершению возникают какие-то ошибки, первым делом начинаешь искать внешнюю причину. Ну а о функционировании паршивого кода душа не болит. Если что-то идет не так, то просто исходишь из того, что код и есть «самое слабое звено», и сразу начинаешь разбирать его и систему по косточкам, попутно узнавая много нового. Такой подход стимулирует любознательность и не портит настроение.
Код никогда не бывает замкнут сам в себе. Любой неожиданный сбой по умолчанию предполагает, что в работе системы есть что-то, чего я не понимаю. А значит, любая ошибка – идеально сконструированный индивидуальный урок, адаптированный для максимальной отдачи от обучения.
Когда я пишу код, у меня имеется несколько стандартных каналов обратной связи. Когда я пишу паршивый код, эти каналы начинают работать на более высокой частоте. Естественно, передо мной встает острая необходимость разобраться в том, на что и как смотреть, чтобы оценить функционирование кода. Каждая попытка писать код приводит к более глубокому пониманию инструментов – иногда осваиваешь какие-нибудь горячие клавиши для редактора, иногда пишешь скрипт, чтобы автоматизировать тот этап тестирования, который до этого проводил вручную. Суть в том, при написании кода совершенствуются и сами инструменты, и мое умение с ними работать.
Когда я пишу код, реализующий какие-то незнакомые мне функции (то есть практически всегда, иначе это уже рефакторинг), у меня нет представления о проектном поле. Я не знаю, что в принципе возможно, из-за недостатка сведений.
Тем, кто учится рисовать, иногда дают такое задание: нужно сделать 5-10 черновых набросков на заданную тему, а затем выполнить по 5-10 вариантов для каждого наброска. Это и есть исследование проектного поля. Иногда я ловлю себя на том, что сравниваю два возможных варианта архитектуры, а ведь это сильно сужает рамки того, что возможно на самом деле – гипотетических вариантов архитектуры, скорее всего, десятки. Когда пишешь много паршивого кода, получаешь доступ к большему количеству вариантов. Он приводит в определенную точку, с которой открывается новый, более полный обзор возможностей.
Знаю, что уже говорил об этом в предыдущих пунктах, но изменения в душевном состоянии, когда я глушу самолюбивое стремление, чтобы в коде было «всё правильно», колоссальны. Вместо досады и раздражения и испытываю любопытство, радость открытия и удовлетворение от достигнутого результата. Даже если все прочие доводы были бы ошибочны, паршивый код следовало бы писать почаще просто ради собственного психологического здоровья.
Опытные разработчики-сениоры любят поговорить о том, каким «должен быть» код. Часто это описания какой-то недосягаемой земли обетованной, где они и сами никогда не бывали. Некоторые из этих «должны» складываются во фреймворки, которые помогают расставить приоритеты при проектировании систем. Самые лучшие прямым текстом указывают на необходимость понимать, когда правило применять не следует. Но в конечном счете, все они приносят пользу, пока направляют вас, и перестают приносить пользу, если начинают вас тормозить.
Иными словами: не теряйте направления, но со спокойной душой позвольте себе писать паршивый код здесь и сейчас.
Неопределенность может порождаться тем, что нам не всё известно о технологии, о бизнесе, о пользователе, объеме данных в системе, продолжительности жизни кода, а также другими неизвестностями, о которых мы даже не подозреваем (за расширенным списком примеров обратитесь к 2020 году).
В ситуации, когда будущее неопределенно, продолжительность цикла выходит на первый план. Скорость позволяет мне извлекать ценность из собственного кода: я быстрее осваиваю новые навыки, вред от плохого кода или отдельных ошибок в неплохом коде сводится к минимуму и продукт быстрее выходит на рынок.
Любые препятствия плохо влияют на продолжительность цикла. Они лишают меня возможности превращать неопределенность в определенность – а в этом и состоит суть обучения. Быстрое обучение формирует наиболее устойчивую ценность, оно выступает своего рода коэффициентом, на который умножается качество кода и архитектуры впоследствии. Есть такая поговорка «Писать значит переписывать», перелагая ее на код, можно сказать: «Писать код – значит проводить рефакторинг».
Исходя из этого, вот несколько причин, почему не нужно бояться писать паршивый код. Точнее сказать, почему не нужно бояться писать больше паршивого кода.
Это улучшает навыки написания кода
Если вы хотите научиться программировать, лучший способ для этого – практика. Как я для себя установил, читать можно сколько угодно, но пока не наберешь код своими собственными пальцами, информация не будет удерживаться. Написание кода – не то, чему можно научиться за день, это определенный способ мышления и подход к решению проблем, а также набор сведений об инструментах и вычислительных средах. Единственный способ углубить необходимые знания – работать с этими инструментами и средами. Каждый раз, как я что-то пишу, я подготавливаю почву для того, чтобы следующий раз прошел проще и результат получился лучше.
Это помогает снова испытать радость от созидания
Когда пишешь паршивый код, основная цель – как можно быстрее получить что-либо на выходе. А это означает прямой путь к тому удовлетворению и ощущению успеха, которое возникает, когда что-то – что угодно – начинает работать. Я написал первую строку кода тридцать лет назад, и, тем не менее, меня по-прежнему охватывает восторг каждый раз, когда удастся привести очередной кусок кода в рабочее состояние.
Это позволяет изучить нерабочий код или нерабочую систему
Иногда в системах что-то не работает. Как я мог убедиться, именно это дает богатые возможности чему-то научиться. Самые ценные уроки я вынес не из какого-нибудь заранее просчитанного компромиссного решения о качестве кода, а из тех случаев, когда поведение системы совершенно не укладывалось в мои ожидания.
К тому же, когда выкладываешься, стараясь написать безупречный код, появляется эмоциональная вовлеченность в его корректную работу. Если по завершению возникают какие-то ошибки, первым делом начинаешь искать внешнюю причину. Ну а о функционировании паршивого кода душа не болит. Если что-то идет не так, то просто исходишь из того, что код и есть «самое слабое звено», и сразу начинаешь разбирать его и систему по косточкам, попутно узнавая много нового. Такой подход стимулирует любознательность и не портит настроение.
Код никогда не бывает замкнут сам в себе. Любой неожиданный сбой по умолчанию предполагает, что в работе системы есть что-то, чего я не понимаю. А значит, любая ошибка – идеально сконструированный индивидуальный урок, адаптированный для максимальной отдачи от обучения.
Это учит устранять баги
Когда я пишу код, у меня имеется несколько стандартных каналов обратной связи. Когда я пишу паршивый код, эти каналы начинают работать на более высокой частоте. Естественно, передо мной встает острая необходимость разобраться в том, на что и как смотреть, чтобы оценить функционирование кода. Каждая попытка писать код приводит к более глубокому пониманию инструментов – иногда осваиваешь какие-нибудь горячие клавиши для редактора, иногда пишешь скрипт, чтобы автоматизировать тот этап тестирования, который до этого проводил вручную. Суть в том, при написании кода совершенствуются и сами инструменты, и мое умение с ними работать.
Это помогает исследовать проектное поле
Когда я пишу код, реализующий какие-то незнакомые мне функции (то есть практически всегда, иначе это уже рефакторинг), у меня нет представления о проектном поле. Я не знаю, что в принципе возможно, из-за недостатка сведений.
Тем, кто учится рисовать, иногда дают такое задание: нужно сделать 5-10 черновых набросков на заданную тему, а затем выполнить по 5-10 вариантов для каждого наброска. Это и есть исследование проектного поля. Иногда я ловлю себя на том, что сравниваю два возможных варианта архитектуры, а ведь это сильно сужает рамки того, что возможно на самом деле – гипотетических вариантов архитектуры, скорее всего, десятки. Когда пишешь много паршивого кода, получаешь доступ к большему количеству вариантов. Он приводит в определенную точку, с которой открывается новый, более полный обзор возможностей.
Сниженные ожидания освобождают мысль и развязывают руки
Знаю, что уже говорил об этом в предыдущих пунктах, но изменения в душевном состоянии, когда я глушу самолюбивое стремление, чтобы в коде было «всё правильно», колоссальны. Вместо досады и раздражения и испытываю любопытство, радость открытия и удовлетворение от достигнутого результата. Даже если все прочие доводы были бы ошибочны, паршивый код следовало бы писать почаще просто ради собственного психологического здоровья.
В заключение
Опытные разработчики-сениоры любят поговорить о том, каким «должен быть» код. Часто это описания какой-то недосягаемой земли обетованной, где они и сами никогда не бывали. Некоторые из этих «должны» складываются во фреймворки, которые помогают расставить приоритеты при проектировании систем. Самые лучшие прямым текстом указывают на необходимость понимать, когда правило применять не следует. Но в конечном счете, все они приносят пользу, пока направляют вас, и перестают приносить пользу, если начинают вас тормозить.
Иными словами: не теряйте направления, но со спокойной душой позвольте себе писать паршивый код здесь и сейчас.
