Сегодня поговорим о том, как писать код, чтобы он не злил окружающих и не раздражал вас спустя годы работы, когда вы снова попытаетесь его прочесть.
Я расскажу о подходах, которые мы используем в Яндекс.Такси для написания читаемого кода на C++, Python, JavaScript и других языках.
Читать полностью »
Бывает, что посмотрев на старый код, мы говорим: «Его проще переписать, чем поменять». Печально, если речь идет о нашем собственном коде, с такой любовь написанном несколько лет назад. Head of Developer Relations в Evrone Григорий Петров в своем докладе на TechLead Conf 2020 разобрал проблемы, которые приводят к такой ситуации, и рассказал, как бороться с Software complexity problem.
В этой статье пересекаются, казалось бы, непересекаемые вещи: нейрофизиология, проклятие нулевой цены копирования, когнитивная и социальная интуиция. И, конечно же, в ней поднимается тема сложности кода. Вы узнаете о том, откуда она берется, почему ее нельзя убрать и как с ней жить.
Как разработчик, вы услышите много сумасшедших, невероятных теорий о значении «строк кода». Не верьте ни одной. Строки кода — нелепая метрика. В очень редких случаях она что-то говорит, обычно — ничего. Использование строк кода для принятия решений похоже на оценку качества книги по количеству страниц.
Некоторые могут сказать, что чем меньше строк кода в приложении, тем легче его читать. Это только частично верно. Вот мои метрики для читаемого кода:
Если уменьшение количества строк кода противоречит любой из этих метрик, это становится проблемой. На практике оно почти всегда будет мешать и, следовательно, почти всегда является проблемой. Но вот в чём дело, если вы стремитесь соответствовать вышеуказанным критериям, то у вашего кода будет идеальное количество строк — и не нужно их подсчитывать.
Читать полностью »
