РАЗВЕНЧИВАЕМ СТЕРЕОТИПЫ О ДИЗАЙНЕ КОДА И ДЕЛИМСЯ ЛАЙФХАКАМИ,КАК СДЕЛАТЬ КОД ПОНЯТНЫМ И НЕ УБИВАТЬСЯ НА ПРОЕКТЕ.

Коллеги из IT-среды уделяют много внимания качеству кода.

Код тщательно выписывают и переписывают, о его красоте заботятся, его дизайн обсуждают.

Тем не менее, скажем страшную вещь.

О красоте кода можно и нужно заботиться, только если это требования работодателя или у вас большая команда.

Если вы пишете аналитический код для расчетов своих продуктов - пишите так, чтобы лично вам было (а) удобно, (б) понятно, (в) быстро.

В школе все писали шпаргалки. Мелким почерком на крохотном листе бумаги могли уместить сразу многое. И всё было сразу понятно. Это работает и для кода в production.

Например, мы в Raisk не используем autopep8 и в целом PEP8, потому что нам не нравятся переносы строки. Наш код бывает грязен и отвратителен. Он нарушает примерно все принципы и паттерны проектирования: как писать интерфейсы, классы, модели, как они должны соотноситься друг с другом на Python и других языках программирования.

Если посмотреть наш код на Python, то каждая строка насыщена смыслом. Там и трансформации, и преобразования данных, и многое другое. Хотя на проектах C# у нас реализованы и интерфейсы, и настоящее OOP - для нас время разработки приоритетнее, чем то, как код устроен изнутри.

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

Такой подход позволяет нам вести десяток проектов и не тратить огромные (клиентские) средства на то, что прямо не приносит прибыль.

Самое интересное, что на github мы видим десятки (сотни?) очень красивых, “вылизанных” проектов, перспективных с точки зрения бизнеса, но просто заброшенных. Почему? Красоту сложно поддерживать, а костыль работает всегда!

Часто нам говорят, что красивый код пишут, чтобы обеспечить более быстрое внедрение изменений - когда что-то ломается (меняется), то код правится в одном месте, а не в десяти. Честно говоря, это довод из книг. Как правило, с красивым кодом менять надо как раз в десяти местах, а не в одном.

Мы стараемся добиваться гибкости за счет несколько других принципов. Например, в основном продукте - Yes Systems - у нас активно используются конвенции и рефлексия и не используется Entity Framework. Код довольно гибкий, его удобно сопровождать, если знаешь принципы, на которых он был построен.

Десять лайфхаков, чтобы ваш код был понятен и вам, и коллегам:

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

2.Используйте системы версионирования кода (очевидно) и версионирования данных (нигде кроме как у нас не видели).

3. Мы также используем видео- и аудиокомментарии. Такого расширения для Visual Studio и Visual Code нет, но после записи мы вставляем ссылки комментарием туда, где они хранятся.

4.Не гонитесь за новыми технологиями. Если говорить о среде .Net, то смена фреймворка (например на .Core) часто означает иной способ работы кода или вовсе прекращение его работы))

5. Используйте протяжку кода в Excel. Например, на некоторых проектах мы не пользуемся Entity Framework и нам нужно довольно много кода с проверками данных, присвоением переменных, значений и проч. Мы делаем это в Excel, протягиваем код, копируем в Studio - и у нас получается та самая шпаргалка мелким почерком. Особенно это хороший совет для SQL-кода, но DBA со стажем, думаем, о нем знают.

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

7. Не сносите старые комментарии. Увы и ах, в наших решениях несколько страниц закомментированного кода, который работает, если его раскомментировать. Очень часто случается так, что он становится снова актуален, а искать его в ветках в гите довольно долго.

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

9. Избавьте клиента от лишних программерских вопросов. Большинство ответов на технические вопросы звучит так: "Мне все равно". Но для приличия клиент вникает и пытается дать лучший ответ. На самом деле лучший ответ - это то, что работает у вас, а время покажет, насколько вы были правы.

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

Да, можно сказать, что все это походит на костыльное программирование, описанное в интервью Завински, либо, как мы бы предпочли это назвать, “прыжок в продукт”.

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