Как поддерживаются огромные библиотеки с открытым исходным кодом, в то время как код далек от практики «чистого кода»?

Я все еще неопытен для написания высококачественного кода, поэтому я читаю книги, посвященные такой проблеме, как « Чистый код » Роберта С. Мартина, и продолжаю проверять код известных библиотек, чтобы улучшить свои навыки.

Хотя многие библиотеки с открытым исходным кодом поддерживаются годами, а это означает, что маловероятно, что они не на правильном пути, я обнаружил, что код во многих из них далек от принципов, нацеленных на написание чистого кода - например, методов, сотни строк кода.

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

Я буду признателен за любые краткие разъяснения. Я извиняюсь, если вопрос кажется глупым от новичка.

РЕДАКТИРОВАТЬ

Проверьте этот пример в библиотеке Butterknife - одной из самых известных библиотек в сообществе Android.

Хороший ответ уже здесь, но позвольте мне сказать несколько слов о вашем примере с ножом-головкой : хотя я понятия не имею, что делает код, на первый взгляд, он не выглядит для меня по-настоящему неприемлемым. Кажется, что переменные и имена методов выбираются намеренно, код имеет правильные отступы и форматирование, в нем есть некоторые комментарии, а длинные методы, по крайней мере, показывают некоторую блочную структуру.

Да, он никоим образом не следует правилам «чистого кода» дяди Боба, и некоторые методы слишком длинны (вероятно, весь класс). Но, глядя на код, я все еще вижу достаточно структуры, чтобы их можно было легко «очистить», извлекая эти блоки в методы самостоятельно (с низким риском появления ошибок при использовании инструментов рефакторинга).

Реальная проблема с таким кодом состоит в том, что добавление одного блока и другого блока и другого блока работает до некоторой степени, иногда в течение многих лет. Но с каждым днем ​​код становится все сложнее развиваться, и требуется чуть больше времени для его модификации и тестирования. И когда вам действительно нужно изменить что-то, что не может быть решено путем «добавления другого блока», но требует реструктуризации, тогда вам захочется, чтобы кто-то начал очищать код раньше.

Принципы, изложенные в «Чистом кодексе», не всегда в целом согласованы. В основном это здравый смысл, но некоторые мнения автора довольно противоречивы и разделяются не всеми.

В частности, предпочтение коротких методов не согласовано всеми. Если код в более длинном методе не повторяется в другом месте, его извлечение в отдельный метод (таким образом, вы получаете несколько более коротких методов) увеличивает общую сложность, поскольку эти методы теперь видны для других методов, которые не должны заботиться о них. Так что это компромисс, а не объективное улучшение.

Рекомендации в книге также (как и все советы) направлены на определенный тип программного обеспечения: корпоративные приложения. Другие виды программного обеспечения, такие как игры или операционные системы, имеют другие ограничения, нежели корпоративное программное обеспечение, поэтому в игру вступают другие шаблоны и принципы проектирования.

Язык также является фактором: чистый код предполагает Java или подобный язык - если вы используете C или Lisp, многие советы не применимы.

Короче говоря, книга представляет собой отдельные лица мнения о конкретном классе программного обеспечения. Это не будет применяться везде.

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

Резюме

Как пишет JacquesB, не все согласны с «Чистым кодом» Роберта Мартина.

Проекты с открытым исходным кодом, которые, как вы обнаружили, «нарушают» принципы, которые вы ожидали, скорее всего, просто будут иметь другие принципы.

Моя перспектива

Мне довелось наблюдать за несколькими основами кода, которые в значительной степени придерживаются принципов Роберта Мартина. Тем не менее, я на самом деле не утверждаю, что они правы , я могу только сказать, что они хорошо работают для нас - и что «мы» на самом деле является комбинацией по крайней мере

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

По сути, это сводится к следующему: каждая команда (будь то компания, отдел или проект с открытым исходным кодом) уникальна. У них будут разные приоритеты и разные точки зрения, и, конечно, они будут делать разные компромиссы. Эти компромиссы и стиль кода, к которому они приводят, во многом являются вкусом и не могут быть доказаны как «неправильные» или «правильные». Команды могут только сказать «мы делаем это, потому что это работает для нас» или «мы должны изменить это, потому что это не работает для нас».

Тем не менее, я считаю, что, чтобы иметь возможность успешно поддерживать большие кодовые базы в течение многих лет, каждая команда должна согласовать набор соглашений по кодам, которые, по их мнению, подходят для указанных выше аспектов. Это может означать принятие практики Робертом К. Мартином другим автором или изобретение собственной; это может означать запись их формально или документирование их «примером». Но они должны существовать.

пример

Рассмотрим практику «разделения кода длинного метода на несколько частных методов».

Роберт C. Мартин говорит , что этот стиль позволяет для ограничения содержимого каждого метода на один уровень абстракции - как упрощенный пример, открытый метод, вероятно , состоит только из звонков частных методов , таких как verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)и , наконец sendJsonToClient(...), и эти методы будут иметь детали реализации.

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

Урок: все они правы, потому что имеют право иметь мнение.

Многие библиотеки с открытым исходным кодом на самом деле страдают от объективно плохой практики кодирования и с трудом поддерживаются небольшой группой долгосрочных участников, которые могут справиться с плохой читабельностью, потому что они очень хорошо знакомы с частями кода, которые они чаще всего поддерживают , Рефакторинг кода для улучшения читабельности после факта часто является серьезной задачей, потому что все должны быть на одной странице, это не весело и не окупается, потому что новые функции не реализованы.

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

Лично я избегаю создания именованных функций, если у меня нет хорошего имени для них. И хорошее имя должно быть коротким и точно описывать, что функция делает с внешним миром. Это также связано с попыткой иметь как можно меньше аргументов функции и не иметь глобально доступных для записи данных. Попытка разрезать очень сложную функцию на более мелкие функции часто приводит к очень длинным спискам аргументов, когда функция была действительно сложной. Создание и поддержание читаемого кода - это упражнение в равновесии между взаимно противоречащими правилами здравого смысла. Чтение книг - это хорошо, но только опыт научит вас, как находить ложную сложность , и именно здесь достигается реальное улучшение читабельности.

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

Это не критика всех владельцев / менеджеров проектов, чьи проекты я имею в виду, это просто вопрос времени. У этих людей есть дела поважнее, например, оплачиваемая работа.

В начале код - работа одного человека и, вероятно, маленький. И маленький код не должен быть чистым. Или, скорее, усилия, необходимые для очистки кода, больше, чем выгода.

Со временем код становится кучей патчей для множества разных людей. Авторы патчей не чувствуют себя владельцем кода, они просто хотят добавить эту функцию или исправить эту ошибку самым простым способом.

У владельца нет времени на то, чтобы навести порядок, и больше никому нет дела.

И код становится большим. И некрасиво.

По мере того, как становится все труднее находить путь к коду, люди начинают добавлять функции не в том месте. И вместо того, чтобы исправлять ошибки, они добавляют обходные пути в других местах кода.

На данный момент людям не все равно, они больше не смеют убирать, так как боятся что-то сломать.

У меня были люди, которые описывали основы кода как «жестокое и необычное наказание».

Мой личный опыт не так уж и плох, но я видел несколько очень странных вещей.

Мне кажется, вы спрашиваете, как этот материал вообще работает, если никто не делает то, что должен делать. И если это работает, то почему мы должны делать эти вещи ?

Ответ, ИМХО, заключается в том, что он работает «достаточно хорошо» , также известной как философия «чем хуже , тем лучше » . По сути, несмотря на сложную историю между открытым исходным кодом и Биллом Гейтсом, они оба де-факто приняли ту же идею, что большинство людей заботятся о функциях, а не об ошибках .

Это, конечно , приводит нас к « нормализации девиантности » , что приводит к ситуациям , как Heartbleed , где, точно , как если бы , чтобы ответить на ваш вопрос, массивная, заросшие спагетти груду из открытого исходного кода под названием OpenSSL пошел « неочищенный » что - то вроде десяти лет с огромным недостатком безопасности, затрагивающим тысячи миллионов людей .

Решение было изобрести целую новую систему под названием LibreSSL , который собирается использовать чистый иш код , и, конечно , почти никто не пользуется .

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

Так почему вы должны беспокоиться о том, чтобы делать что-то « в правильном направлении », если никто не делает этого ?

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

То, что составляет хороший код, зависит от контекста, и классические книги, которыми вы руководствуетесь, если не слишком стары для обсуждения открытого исходного кода, по крайней мере, являются частью традиции ведения бесконечной войны против плохих внутренних кодовых баз. Поэтому легко упустить из виду тот факт, что библиотеки имеют совершенно разные цели, и они написаны соответственно. Рассмотрим следующие вопросы в произвольном порядке:

• Когда я импортирую библиотеку или из библиотеки, мне, вероятно, не хватает специалиста по ее внутренней структуре, чтобы точно знать, какая крошечная часть ее набора инструментов мне нужна для всего, над чем я работаю, если только я не копирую какую-либо Stack Exchange ответ велел мне сделать. Поэтому я начинаю печатать from A import(скажем, на Python) и смотрю, что из этого выйдет. Но это означает, что то, что я вижу в списке, должно отражать логические задачи, которые мне нужно будет позаимствовать, и это должно быть в кодовой базе. Бесчисленные вспомогательные методы, которые делают его короче, просто смущают меня.
• Библиотеки существуют для самого неопытного программиста, пытающегося использовать какой-то алгоритм, о котором большинство людей слышали лишь смутно. Им нужна внешняя документация, и для этого нужно точно отразить код, чего не может быть, если мы продолжаем рефакторинг всего, чтобы порадовать приверженцев коротких методов и единомышленников.
• Каждый библиотечный метод, который заимствуют люди, может разрушить код во всем мире с катастрофическими последствиями, если он будет удален или даже переименован. Конечно, я бы хотел, чтобы sklearn исправил опечатку в Calinski-Harabasz , но это может привести к еще одному инциденту на левой панели . На самом деле, по моему опыту, самая большая проблема эволюции библиотек - это когда они слишком усердно пытаются внедрить какое-то хорошее «новое» усовершенствование того, как они структурируют все.
• Внутренние комментарии - это в значительной степени необходимое зло в лучшем случае, по разным причинам, которые мне не нужно извергать (хотя эти моменты несколько преувеличивают). Хороший комментарий говорит, почему код работает, а не как. Но библиотеки знают, что их читатели - компетентные программисты, которые не могут, скажем, написать линейную алгебру, выходя из бумажного пакета. Другими словами, все нужно комментировать: почему это работает! (ОК, это еще одно преувеличение.) Вот почему вы видите строку подписи, 100-строчный блок комментариев, 1 строку кода, которая буквально могла бы попасть в строку подписи (конечно, с учетом языка).
• Допустим, вы что-то обновляете на Github и ждете, будет ли принят ваш код. Должно быть понятно, почему смена кода работает. По своему опыту я знаю, что рефакторинг для обеспечения чистоты места для лагеря как части функционального коммита часто приводит к значительному сохранению строк, перестановке и переименованию, что усложняет работу рецензента без зарплаты и вызывает другие вышеупомянутые проблемы.

Я уверен, что люди с большим опытом, чем я, могут упомянуть другие моменты.

Уже есть много хороших ответов - я хочу дать представление о разработчике открытого кода.

Моя перспектива

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

Это усложняет поддержание - как основной член Node.js, я боюсь коснуться частей кода, но есть много работы, которую нужно выполнить независимо, и люди успешно используют платформу и наслаждаются ею. Самое главное, что это работает.

На читаемый код

Когда ты сказал:

Я обнаружил, что код во многих из них далек от принципов написания чистого кода - например, методов, содержащих сотни строк кода.

Строки кода не являются хорошим показателем того, насколько он читаем. В исследовании, которое я связал с ядром linux, был проанализирован, и опрос программистов обнаружил, что «обычный» код (код, который люди ожидают в основном) и согласованный код лучше, чем «чистый» код в понятности. Это также соответствует моему личному опыту.

Некоторые проекты с открытым исходным кодом не слишком приветливы

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

Лично я абсолютно не согласен с его позицией там - но это также то, что люди делают.

Программное обеспечение с открытым исходным кодом не обязательно означает участие нескольких авторов. Когда программное обеспечение (или единица программного обеспечения) написано одним автором, часто появляются длинные функции.

Это происходит от характера процесса разработки. Простой метод расширяется с течением времени, добавляются новые функции и исправляется ошибка.

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

Вы не показали никаких примеров, но, насколько я понимаю, это также часто связано с языком разработки. Некоторые языки применяют строгие правила линтинга с самого начала и тяжелые юнит-тесты (или даже TDD). Как линтинговые, так и модульные тесты обычно предотвращают эту проблему (сложно тестировать комплексные / длинные методы).

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