Сердце машины сообщает,Участники: Лю Сяокунь, Ван Шутин, Ли Цзэнань.
«Однажды я принял код с десятками модулей if else…» Для программистов должно быть неприятно столкнуться с таким явлением — многие считают такой способ написания очень уродливым и имеющим множество ответвлений, подверженных ошибкам. Недавно пользователи сети нашли такой фрагмент кода на GitHub платформы управления контейнерами Kubernetes, 1700 строк операторов if else поразительны.
Дабы не дать "головным железным" массам реально его рефакторить, в начале этого кода есть такой комментарий:
Не пытайтесь упростить этот код.
Пожалуйста, смотрите, как он взлетает.
Этот контроллер намеренно написан очень подробно. Ты заметишь:
1. Каждому оператору «if» соответствует «else» (за исключением простой проверки ошибок вызовов клиентского API).
2. Здесь мы хотим объяснить понятно
Мы называем этот код «стилем космического челнока». Стиль космического челнока заключается в том, чтобы гарантировать рассмотрение каждой ветви и условия — так же, как при написании кода приложения космического корабля для космического челнока в НАСА.
Изначально работа этого контроллера была разделена на три контроллера. Этот контроллер является результатом огромных усилий по упрощению фотоэлектрической подсистемы. В ходе этих усилий стало ясно, что нам нужно гарантировать, что каждое условие обрабатывается и оценивается в коде, даже если оно приводит к неработающей ветке кода.
В результате код контроллера может показаться слишком многословным, со слишком большим количеством комментариев и «разветвлений». Тем не менее, здесь задокументировано большое количество бизнес-знаний и контента, чтобы будущие сопровождающие могли правильно рассуждать о сложностях поведения привязки. Поэтому изменения в этом файле должны оставаться в стиле космических челноков.
Адрес GitHub для файла:GitHub.com/Это так особенно/…
Будучи популярной системой с открытым исходным кодом, Kubernetes часто используется для автоматизации развертывания и управления контейнерными приложениями. Его разработчики говорят, что Kubernetes имеет 15-летний опыт работы с рабочими нагрузками Google. Для разработчиков в области искусственного интеллекта Kubernetes может помочь нам развернуть модели глубокого обучения (см.:Как легко развернуть модели глубокого обучения с помощью Kubernetes).
стиль космического корабля
Слышали, это кодовый стиль НАСА? На Hackernews многие пользователи сети единодушно похвалили код после прочтения полного текста.
@Клэтмон сказал:
Мне это нравится! Это буквально «джаз» в разработке программного обеспечения. Он нарушает все неотъемлемые «правила», но имеет четкую цель и гораздо лучшие результаты, чем следование «правилам».
На первый взгляд вы почувствуете, что этот файл слишком велик, наполнен множеством ветвей и вложенных операторов if, а также множеством «бессмысленных комментариев», описывающих только то, что делают окружающие строки или строки кода. В комментариях также много логики, которая быстро устаревает или содержит ошибки по сравнению с реальным кодом.
Но в то же время это значительно упрощает поддержку и управление кодом, поскольку вам не нужно разбивать логику на десятки или даже сотни файлов. Он содержит много изначально сложной работы, которую необходимо выполнить над этим файлом, и его аннотации хорошо сделаны, и любые изменения могут быть легко обновлены с помощью аннотаций.
@munchbunny сказал:
Не могу не согласиться. Код, с которым я ежедневно сталкиваюсь, находится не на этом уровне, но также имеет низкоуровневые функции, а также ближе к металлу, чем типичный внутренний код, называемый большим количеством внешнего и внутреннего кода. Если есть что-то «еще больше бэкенд-кода», это хороший пример. Если проигнорировать нюанс, к вам на стол при деплое кода бросится куча разгневанных разработчиков, а если не исправить быстро, будет куча разгневанных заказчиков.
Для кода во внутренних циклах критически важного кода основные временные затраты связаны не с написанием кода или его пониманием, а с оптимизацией с учетом нюансов обслуживаемых сценариев, проверкой непосредственного влияния изменения кода и последующей проверкой изменений. Эффекты третьего порядка.
Тщательно аннотированный код легче поддерживать, когда ваш код настолько детализирован, что каждое вносимое вами изменение имеет эффект третьего порядка. Потому что, если вы собрали вместе десять разных файлов и вам нужно потратить много усилий, чтобы выяснить правильный путь, вы, скорее всего, упустите нюансы.
Об аннотациях
Многие пользователи сети отмечают, что код с большим количеством комментариев очень полезен и не вызывает отвращения, а код без комментариев принесет много хлопот.
@EB66 сказал:
Я абсолютно согласен. Мне также нравится этот стиль для неизбежно сложного кода.
Мне очень нравится лаконичный код и выразительные операторы/имена, но иногда необходимы комментарии, чтобы четко сформулировать логику или вариант использования. Выразительный код может напрямую передавать только ограниченное количество значений. Хорошо продуманные комментарии могут значительно сократить время, которое другие разработчики тратят на работу с незнакомыми кодовыми базами.
Суть в том, чтобы обновить комментарии. Нет ничего более отвратительного, чем неточные аннотации. При просмотре кода обязательно проверяйте наличие комментариев к измененным строкам кода.
@ascar сказал:
Устаревшие комментарии, объясняющие вариант использования или цель, все же лучше, чем отсутствие комментариев. Он может дать вам справочную информацию, такую как эволюция кода и его назначение.
Комментарии только для чтения могут быть хуже, чем чтение некомментированного кода, поэтому некоторые разработчики возмущаются устаревшими комментариями и, таким образом, имеют обобщенные (слишком сокращенные) комментарии.
Комментарии — это дополнительная информация о коде, здесь нет источника правды, поэтому читайте и код, и комментарии.
@nicharr сказал:
У меня более 25 лет опыта написания, просмотра, комментирования и проверки кода на нескольких языках, так что я бы сказал, что это действительно хорошо — независимо от «стиля» программирования (или языка в целом).
Хорошие комментарии к коду могут оказать огромное влияние на производительность — будь то отдельный человек, команда или бизнес. Это помогает хранить знания (информация легко теряется между текущей и предыдущей командами/индивидуалами).
Лично я трачу слишком много времени на реверс-инжиниринг кода, который не закомментирован. Иногда опытные программисты или разработчики идут по короткому пути: сжимают программы и функции, которые основаны на языке и/или предметной области, которые они явно знают, но не аннотируют их...
На фундаментальном уровне комментарии должны информировать, обучать, обрисовывать в общих чертах и помогать другим понять иногда сложные пути и функции, которые мы создаем при написании кода.
Некоторые люди думают, что хороший код не нуждается в комментариях, и в какой-то степени это правда, но это не относится к каждой кодовой базе. Некоторый код сложный, неуклюжий, похожий на спагетти, а иногда и непонятный.
Я всегда пытался научить менее опытных разработчиков делать хорошие комментарии эффективно и с долей юмора (когда это возможно), что позволяет нам быстро понимать код, ценить усилия тех, кто был раньше, и смеяться над сложными задачами.
Меня лично не волнует соотношение кода и комментариев. Иногда комментарии к коду могут быть более ценными, чем сам код. А иногда они просто помогают вам выполнить работу; пока это быстро, эффективно и без ошибок, это хороший код.
Размер файла
@Клэтмон сказал:
Я занимаюсь разработкой интерфейсных веб-приложений, и самая сложная проблема заключается в том, как добиться быстрой итерации кодовой базы, что в большинстве случаев не является реальной бизнес-проблемой. Но как бы хорошо не звучало «глубокая функциональность и небольшие интерфейсы», в большинстве случаев большие файлы, которые экспортируют только несколько функций, нелегко поддерживать. Помещение всего кода в один и тот же файл требует, чтобы вы полностью его поняли, прежде чем вносить какие-либо изменения.
@taneq сказал:
Они делают это специально, чтобы убедиться, что разработчик понимает весь файл перед его изменением, так как его функциональность настолько критична, что его легко спутать. Кроме того, разделение логически плотного файла на более мелкие файлы (вместо перезаписи их на более мелкие логические модули) приведет только к ненужным проблемам с управлением файлами.
Поклонение новичка
@ jml7c5 сказал:
Как начинающий программист, я шокирован тем, что это не стандартная практика в программировании. Общая исходная документация должна содержать контекст, предысторию предмета, руководства по ссылкам/блогам/книгам, объясняющие концепции, информацию о том, как код вписывается в программу в целом, и (что наиболее важно) мыслительный процесс, воплощенный в документации (т. е. почему это практикуется и а не другие, проблемы, компромиссы и т. д.).
Я до сих пор не могу понять, каждый программист должен научиться использовать кодовую базу с нуля. Невозможно улучшить нетривиальную программу, если вы не готовы часами тестировать ее. Разработчикам с открытым исходным кодом: эти типы комментариев довольно просты, если вы хотите, чтобы люди внесли свой вклад в ваш проект, не говоря уже о том, что они могут сэкономить много времени.
@qlk1123 сказал:
«Как начинающий программист, я шокирован тем, что это не является стандартной практикой для программирования.» Я согласен с этим, и, конечно, многие люди выиграют, если это станет стандартом сообщества. Но разве вы не думаете, что хорошая культура сообщества может удерживать людей в хороших привычках для этого?
Моя основная работа — разработчик ядра Linux. Я обнаружил, что исходный код - это только часть "Что", часть "Как/Почему" должна быть указана в комментариях. И если это не заставит меня понять исходный код, я напишу автору напрямую по электронной почте для более глубокой части «Почему». Информации достаточно в большинстве случаев.
Будьте осторожны с подражанием
Помимо Kubernetes, еще одной программой, которая в последнее время горячо обсуждается из-за ее кода, может стать ставшая популярной в Steam независимая отечественная игра «Taiwu Picture Scroll». По словам любопытных программистов, ранние версии содержали тысячи операторов if. Поскольку главный создатель игры родился в китайском отделе, а затем присоединился к строительной отрасли, код игры он писал на полпути монахом — в конце концов, с игрой не возникло серьезных проблем.
Эти знаменитые кейсы работают, но в них нельзя играть без сильной логики (удачи). Программисты с профессиональным прошлым обычно не подражают.