[Разработка веб-сайтов, Программирование, IT-стандарты] Радикальный перфекционизм в коде
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Идея взята с постов telegram-канала Cross Join
Представьте себе, что какой-то программист придет на работу в одних трусах. Или вообще голышом. Работа встала, все обсуждают происходящее, смеются или кривят лицо, никто не работает. Приходит руководитель и пытается что-то сделать.
Плохое решение: ввести дресс-код на всю организацию. Костюм, галстук, белый верх, черный низ, начищенная обувь, никакого пирсинга, вот это всё.
Бред, правда? Ну да, слишком радикально. Пусть в целом люди ходят как хотят, и чувствуют себя хорошо. Исключительные ситуации нужно решать частным порядком (уволить хулигана?), ну в крайнем случае ввести правило, что кроме белья должно быть что-то еще.
И правда, бред. Ну а зачем тогда мы сами себе вводим бешеный фашизм в коде?
Слишком жесткие правила
Посмотрите правила code style. Стандарт PSR-12, например.
Вот несколько пунктов:
1) В конце каждого файла должен быть перевод строки. А если не будет, то кто умрёт?
2) Нельзя делать несколько statements на одной строке. Если я напишу $x = 1; $y = 1; $z = 1;, то читабельность ухудшится на 0.00001% и можно закрывать техотдел?
3) Declare statements MUST contain no spaces and MUST be exactly declare(strict_types=1). Ох, как всё серьёзно. Ни одного пробела, причем слово MUST капсом, чтобы все понимали степень ответственности. Если вставить где-нибудь пробел, то на код ревью никто код же прочесть не сможет!
Но блин, если один чудак однажды написал под воздействием каких-то веществ
declare( strict_types =1 )
то это еще не значит, что надо ВСЕХ бить плёткой ругать линтером за каждый пробел. Нужно просто вправить мозг ОДНОМУ чудаку. Готов поспорить, что именно он тогда пришел на работу без трусов.
Понятно, что в стандарте есть и нужные правила, но по моим наблюдениям почти в любой команде есть какие-то законы, которые придуманы фиг пойми для чего, никто уже не помнит, или не задумывался глубоко, насколько это всё важно или не важно.
Правила надо вводить, когда явно видно, что ухудшается читабельность. Это индивидуально для языка, проекта, команды.
Почему это важно
Дома, когда ты пилишь свой pet-проект, ты используешь язык тот, какой хочешь, форматируешь код, как хочешь, структурируешь код, как хочешь. Точно не будешь надевать галстук.
И перформишь при этом как бог! Совершенно спокойно можно все выходные провести за кодингом и особо не устать.
Короче. От программирования мы получаем фан, от внешних навязанных ограничений мы получаем раздражение. От навязанных необоснованных ограничений мы получаем выгорание.
Раньше мне казалось, что начальство перегибает палку ради дисциплины в вакууме, и меня от этого бомбило. Я это запомнил, и, став тимлидом, в своих командах стал применять демократию. Не навязывал от себя практически никаких правил. Тем не менее странные правила всё равно появлялись.
К примеру, в Go есть goimports, который форматирует код по стандарту, вшитому в стандартный тулинг. Казалось бы, о чем тут теперь спорить. Но все равно внезапно обнаруживаешь себя, переименовывающим getJson в getJSON и getById в getByID, иначе правило линтера N100500 скажет айайай. При этом читабельность если и меняется, то незначительно, и даже не ясно, в какую сторону.
Куча такого. Ладно код стайл, бог с ним. Но ведь тысячи других радикальных шутк. Договорились, что контроллеры тонкие, не содержат никакой логики — и всё, даже убогий код в контроллере из пары строк где-то в богом забытой части системы порождает споры на код ревью — является ли это логикой или нет.
Дофаминовый цикл "сделал задачу — получил удовлетворение" нарушен. Сделал задачу — получи звиздюлей от линтера и коллег на код ревью.
Дофамин еще полбеды. Возведение принципов программирования (тех же DRY или SOLID) в радикальный абсолют может привести к таким абстракциям, что код превращается в нечитабельное месиво. Увидел пару switch case — сразу городи иерархию классов. Так ведь в книжке написано.
Мы ругаем бешеный принтер, ограничивающий свободу, но сами часто действуем по принципу "запретить и не пущать".
Вообще, иногда хочется пересмотреть вообще всё. Например, однажды мы думали, как назвать по-английски переменную для ЦФО (центр финансовой ответственности). Словарь говорит, что это будет financial responsibility center. Если назвать переменную "FRC", то новичку будет непонятно, что это за хрень. В документации по продукту термин везде по русски, ЦФО. Если назвать financialResponsibilityCenter, то можно догадаться, о чем речь, но слишком длинно как-то.
Понятно, что никто не рискнет так делать, но идеально было бы так и назвать переменную русскими буквами — ЦФО. Если проект сугубо для русскоязычных людей и русскоязычных программистов, то почему нет? Просто потому что не принято, вот и всё. Рациональных причин мало, и с ними можно поспорить, как минимум в каком-то конкретном случае.
Вывод
Я считаю, что:
Придумывая универсальное правило, нужно убедиться, что оно точно капец необходимо.
Применяя универсальное правило, нужно смотреть на контекст, и уметь делать исключения. Потому что совсем универсальных правил не существует.
Очень надеюсь на дискуссию в комментариях.
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Венчурные инвестиции, Развитие стартапа, Карьера в IT-индустрии] Пол Грэм: Над чем я работал (перевод)
- [Высокая производительность, Разработка веб-сайтов, Клиентская оптимизация, Браузеры] Максимально оптимизированная веб-загрузка изображений в 2021 году (перевод)
- [Программирование, .NET, ASP, C#] Реализуем глобальную обработку исключений в ASP.NET Core приложении (перевод)
- [Программирование, Разработка под Android, GitHub, Социальные сети и сообщества] Российский разработчик написал клиент Clubhouse для Android после реверс-инжиниринга API
- [JavaScript, Программирование] Поддержка JavaScript-приложений в долгосрочной перспективе (перевод)
- [Программирование, DevOps, Микросервисы] Feature Flags и фабрика ПО
- [Веб-дизайн, Разработка веб-сайтов, ReactJS, Интервью] Юзкейс нечаянно нагрянет, когда его совсем не ждешь
- [Программирование, Интервью, IT-компании] Один день из жизни разработчика VMware
- [Python, Программирование, Алгоритмы] Как же писать эти грёбаные циклы?
- [Python, Программирование] Ускоряем код на Python с помощью Nim (перевод)
Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_programmirovanie (Программирование), #_itstandarty (IT-стандарты), #_refaktoring (рефакторинг), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_programmirovanie (
Программирование
), #_itstandarty (
IT-стандарты
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 13:29
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Идея взята с постов telegram-канала Cross Join Представьте себе, что какой-то программист придет на работу в одних трусах. Или вообще голышом. Работа встала, все обсуждают происходящее, смеются или кривят лицо, никто не работает. Приходит руководитель и пытается что-то сделать.
Плохое решение: ввести дресс-код на всю организацию. Костюм, галстук, белый верх, черный низ, начищенная обувь, никакого пирсинга, вот это всё. И правда, бред. Ну а зачем тогда мы сами себе вводим бешеный фашизм в коде? Слишком жесткие правила Посмотрите правила code style. Стандарт PSR-12, например. Вот несколько пунктов: 1) В конце каждого файла должен быть перевод строки. А если не будет, то кто умрёт? 2) Нельзя делать несколько statements на одной строке. Если я напишу $x = 1; $y = 1; $z = 1;, то читабельность ухудшится на 0.00001% и можно закрывать техотдел? 3) Declare statements MUST contain no spaces and MUST be exactly declare(strict_types=1). Ох, как всё серьёзно. Ни одного пробела, причем слово MUST капсом, чтобы все понимали степень ответственности. Если вставить где-нибудь пробел, то на код ревью никто код же прочесть не сможет! Но блин, если один чудак однажды написал под воздействием каких-то веществ declare( strict_types =1 )
то это еще не значит, что надо ВСЕХ бить плёткой ругать линтером за каждый пробел. Нужно просто вправить мозг ОДНОМУ чудаку. Готов поспорить, что именно он тогда пришел на работу без трусов. Понятно, что в стандарте есть и нужные правила, но по моим наблюдениям почти в любой команде есть какие-то законы, которые придуманы фиг пойми для чего, никто уже не помнит, или не задумывался глубоко, насколько это всё важно или не важно. Правила надо вводить, когда явно видно, что ухудшается читабельность. Это индивидуально для языка, проекта, команды. Почему это важно Дома, когда ты пилишь свой pet-проект, ты используешь язык тот, какой хочешь, форматируешь код, как хочешь, структурируешь код, как хочешь. Точно не будешь надевать галстук. И перформишь при этом как бог! Совершенно спокойно можно все выходные провести за кодингом и особо не устать. Короче. От программирования мы получаем фан, от внешних навязанных ограничений мы получаем раздражение. От навязанных необоснованных ограничений мы получаем выгорание. Раньше мне казалось, что начальство перегибает палку ради дисциплины в вакууме, и меня от этого бомбило. Я это запомнил, и, став тимлидом, в своих командах стал применять демократию. Не навязывал от себя практически никаких правил. Тем не менее странные правила всё равно появлялись. К примеру, в Go есть goimports, который форматирует код по стандарту, вшитому в стандартный тулинг. Казалось бы, о чем тут теперь спорить. Но все равно внезапно обнаруживаешь себя, переименовывающим getJson в getJSON и getById в getByID, иначе правило линтера N100500 скажет айайай. При этом читабельность если и меняется, то незначительно, и даже не ясно, в какую сторону. Куча такого. Ладно код стайл, бог с ним. Но ведь тысячи других радикальных шутк. Договорились, что контроллеры тонкие, не содержат никакой логики — и всё, даже убогий код в контроллере из пары строк где-то в богом забытой части системы порождает споры на код ревью — является ли это логикой или нет. Дофаминовый цикл "сделал задачу — получил удовлетворение" нарушен. Сделал задачу — получи звиздюлей от линтера и коллег на код ревью. Дофамин еще полбеды. Возведение принципов программирования (тех же DRY или SOLID) в радикальный абсолют может привести к таким абстракциям, что код превращается в нечитабельное месиво. Увидел пару switch case — сразу городи иерархию классов. Так ведь в книжке написано. Мы ругаем бешеный принтер, ограничивающий свободу, но сами часто действуем по принципу "запретить и не пущать". Вообще, иногда хочется пересмотреть вообще всё. Например, однажды мы думали, как назвать по-английски переменную для ЦФО (центр финансовой ответственности). Словарь говорит, что это будет financial responsibility center. Если назвать переменную "FRC", то новичку будет непонятно, что это за хрень. В документации по продукту термин везде по русски, ЦФО. Если назвать financialResponsibilityCenter, то можно догадаться, о чем речь, но слишком длинно как-то. Понятно, что никто не рискнет так делать, но идеально было бы так и назвать переменную русскими буквами — ЦФО. Если проект сугубо для русскоязычных людей и русскоязычных программистов, то почему нет? Просто потому что не принято, вот и всё. Рациональных причин мало, и с ними можно поспорить, как минимум в каком-то конкретном случае. Вывод Я считаю, что: Придумывая универсальное правило, нужно убедиться, что оно точно капец необходимо.
Применяя универсальное правило, нужно смотреть на контекст, и уметь делать исключения. Потому что совсем универсальных правил не существует. =========== Источник: habr.com =========== Похожие новости:
Разработка веб-сайтов ), #_programmirovanie ( Программирование ), #_itstandarty ( IT-стандарты ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 13:29
Часовой пояс: UTC + 5