Я отличный инженер?

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

Я дошел до того момента, когда начал чувствовать себя вполне уверенно в своей работе. Я чувствовал, что твердо владею большей частью нашей кодовой базы Ruby on Rails, TypeScript, React. Для большинства задач меньшего размера я мог без особых проблем справиться с ними. Я начал спрашивать себя: «Как мне сохранить интерес к разработке и продолжить обучение, когда у меня есть задача, которую я по большей части уже знаю, как ее реализовать?»

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

ШОКЕР: Я был неправ

К этому моменту я подумал, что имею довольно твердое представление о том, что влечет за собой «хороший» код. Один из ключевых моментов: хорошо продуманные, описательные комментарии.

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

Хорошая идея, правда? Я так и думал. Чем больше комментариев, тем лучше!

А потом я прочитал эту цитату.

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

ЧЕРТ.

Переосмысление моего фокуса

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

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

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

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

Это не рецензия на книгу

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

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

Возможность и риск: с нетерпением жду

Каждая написанная строчка кода, даже если предположить, что она отлично работает после реализации, является одновременно возможностью и риском.

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

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

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

а) постепенно улучшать уже существующий код,

б) написать новый код, который использует возможности, описанные выше, или в идеале

c) как a, так и b

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