Иногда речь идет не о том, кто прав, а кто виноват, а скорее о наилучшем подходе к достижению цели. То, как вы определяете успех, зависит от того, что вы и ваша команда цените.
В кодировании есть много способов добиться одного и того же результата. Одни подходы хороши, другие лучше. Например, можно реализовать умное решение с минимальными изменениями строк, а другое может изменить много строк, но более понятно.
Лично я считаю, что читаемый код более ценен, чем умный код. Это потому, что мы, люди, тратим больше времени на чтение кода, чем на его написание. В результате сосредоточение внимания на читабельности позволяет упростить обслуживание, улучшить улучшения и уменьшить количество ошибок и регрессии. Улучшение ментальных моделей кода — благо для разработчиков.
Когда-то на работе я писал умный код. Я чертовски гордился тем, насколько он умен, и даже продемонстрировал его своим коллегам. Я не прикасался к коду в течение 6 месяцев, и когда я вернулся к нему, я понятия не имел, что он делает. По иронии судьбы, я спросил себя: Кто написал этот дерьмовый код? и был смущен, узнав, что это был я после того, как сделал мерзкую вину. Я усвоил очень важный урок: хотя код выполняется машинами, он пишется людьми. С этого дня я стал больше времени уделять написанию читабельного и хорошо документированного кода.
Но вы можете пошутить: Не пожертвуете ли вы «оптимизацией?» В большинстве случаев сохраненные строки и оптимизация не стоят жертвы читабельностью — особенно если это преждевременно. Основываясь на правиле 80/20 или принципе Парето, в вашей кодовой базе есть другие места, которые могут дать вам больший выигрыш, чем преждевременная оптимизация некоторых частей вашего кода. Бенчмарк, чтобы узнать, где они находятся, и оптимизировать их там, где это необходимо.
Эта статья была изначально опубликована на сайте замечательной марки.org 16 января 2022 г.
