Когда я начинал младшим разработчиком в своей первой компании, я придумал блестящий однострочный код на питоне с побитовыми операторами вместо четырехстрочного блока if-else. Я объяснял эту строчку кода всем и гордился собой.

Мой технический директор сказал: «Если этот код когда-нибудь войдет в SVN (да, это было давно), вы мертвы». Я был разочарован и попытался спорить с ним. Он хотел, чтобы кодовая база была чистой и понятной, и путь, по которому он дошел до сути, заключался в преодолении трудностей. Он предложил мне показать его любому программисту в офисе, и если они смогут понять, что он делает без моих объяснений, он разрешит это.

Как и предполагалось, я не справился с задачей, и мне пришлось переписать ее.

Читабельность, а не производительность — это функция

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

Я бы сказал, что не только производительность, но и читаемость кода — важная функция вашей кодовой базы/продукта. Вы можете писать на каком-то малоизвестном языке со всевозможными оптимизациями компилятора и встроенным кодом сборки, чтобы получить эти дополнительные 3 миллисекунды от вашего вызова API. Но стоит ли?

Программы пишутся в первую очередь для людей

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

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

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

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

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

Код-ревью спешит на помощь

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

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

Помните, что лучший показатель качества кода — это не наименьшее количество строк кода, а наибольшее количество разработчиков, понимающих ваш код.

Первоначально опубликовано в Srinivasan Rangarajan.