Як величезні бібліотеки з відкритим кодом підтримуються, маючи код, далекий від практики "чистого коду"?

Я все ще недосвідчений писати високоякісний код, тому я читаю книги, що стосуються такої проблеми, як « Чистий код » Роберта К. Мартіна, і постійно перевіряю код відомих бібліотек, щоб покращити свою майстерність.

Хоча багато бібліотек з відкритим кодом підтримуються роками, а це означає, що малоймовірно, що вони не на правильному шляху, я знайшов код у багатьох з них далеким від принципів, призначених для написання чистого коду - наприклад, методів, що містять сотні рядків коду.

Отже, моє запитання: чи принципи чистого коду занадто обмежені, і ми можемо обійтися без них у багатьох подібних бібліотеках? Якщо ні, то як підтримуються величезні бібліотеки без урахування багатьох із цих принципів?

Буду вдячний за будь-яке коротке уточнення. Прошу вибачення, якщо це питання здається дурним у новачка.

EDIT

Перевірте цей приклад у бібліотеці Butterknife - одній із найвідоміших бібліотек спільноти Android.

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

Так, це ніяк не дотримується правил "чистого коду" дядька Боба, і деякі методи впевнені занадто довго (напевно, весь клас). Але дивлячись на код, я все ще бачу достатню структуру, щоб їх можна було легко «очистити» шляхом вилучення цих блоків методами самостійно (з низьким ризиком введення помилок при використанні інструментів рефакторингу).

Справжня проблема такого коду полягає в тому, що додавання одного і іншого блоку, а інший блок працює певною мірою, іноді протягом багатьох років. Але з кожним днем ​​код стає дедалі складнішим, і його модифікація та тестування потребує трохи більше часу. І коли вам дійсно доведеться змінити щось, що неможливо вирішити "додаванням іншого блоку", але вимагає реструктуризації, тоді ви побажаєте, щоб хтось почав очищати код раніше.

Принципи, викладені в "Чистому кодексі", не завжди є загальним. Більшість це здоровий глузд, але деякі думки автора досить суперечливі і не всі поділяються.

Зокрема, перевагу коротких методів не погоджують усі. Якщо код у більш тривалому методі не повторюється в іншому місці, витягнення частини його в окремий метод (так ви отримуєте кілька коротших методів) збільшує загальну складність, оскільки ці методи тепер видимі для інших методів, які не повинні їх хвилювати. Тож це компроміс, а не об'єктивне поліпшення.

Поради в книзі також (як і всі поради) орієнтовані на певний тип програмного забезпечення: Програми для підприємств. Інші типи програмного забезпечення, такі як ігри або операційні системи, мають інші обмеження, ніж програмне забезпечення для підприємств, тому в грі є різні шаблони та принципи дизайну.

Мова також є фактором: Clean Code передбачає Java або подібну мову - якщо ви використовуєте C або Lisp, багато порад не застосовуються.

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

Що стосується проектів з відкритим кодом, якість коду коливається від безглуздого до блискучого. Адже кожен може опублікувати свій код як відкритий код. Але якщо ви подивитеся на зрілий та успішний проект з відкритим кодом з кількома учасниками, ви можете бути впевнені, що вони свідомо влаштували стиль, який їм підходить. Якщо цей стиль суперечить певній думці чи настанові, то (простіше кажучи) саме керівництво є помилковим чи неактуальним, оскільки робочий код перетворює думки.

Підсумок

Як пише ЖакБ, не всі згодні з "Чистим кодексом" Роберта К. Мартіна.

Проекти з відкритим кодом, які ви виявили, що "порушують" принципи, які ви очікували, швидше за все, мають інші принципи.

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

Мені здається, я наглядаю за кількома кодовими базами, які дуже дотримуються принципів Роберта К. Мартіна. Однак я не дуже стверджую, що вони мають рацію , можу лише сказати, що вони добре працюють на нас - і що "нас" насправді є комбінацією принаймні

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

В основному, це зводиться до: кожна команда (будь то компанія, відділ або проект з відкритим кодом) є унікальною. У них будуть різні пріоритети та різні точки зору, і, звичайно, вони будуть робити різні компроміси. Ці компроміси та стиль коду, до яких вони призводять, значною мірою є предметом смаку і не можуть бути доведені "неправильними" чи "правильними". Команди можуть сказати лише "ми робимо це, тому що це працює для нас" або "ми повинні це змінити, тому що це не працює для нас".

Зважаючи на це, я вважаю, що для успішного підтримання великих кодових баз протягом багатьох років кожна команда повинна погодитись набір конвенційних кодів, які, на їхню думку, підходять для вищезазначених аспектів. Це може означати прийняття практики Робертом К. Мартіном, іншим автором, або винайдення їх власних; це може означати їх формальне записування або документування "на прикладі". Але вони повинні існувати.

Приклад

Розглянемо практику "розщеплення коду від довгого методу на кілька приватних методів".

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

• Деяким це подобається, тому що читачі можуть отримати короткий огляд кроків на високому рівні та можуть вибрати, які деталі вони хочуть прочитати.
• Деяким людям це не подобається, тому що, коли ви хочете дізнатися всі деталі, вам доведеться стрибати в класі, щоб слідкувати за потоком виконання (саме це, напевно, звертається до JacquesB, коли він пише про додавання складності).

Урок такий: всі вони мають рацію, оскільки мають право на думку.

Багато бібліотек з відкритим кодом насправді страждають від об'єктивно поганих методів кодування і з труднощами їх підтримує невелика група довгострокових дописувачів, які можуть впоратися з поганою читабельністю, оскільки вони дуже добре знайомі з частинами коду, які вони найчастіше підтримують . Код рефакторингу для поліпшення читабельності після факту часто є геркулесовим зусиллям, тому що всі повинні бути на одній сторінці, це не весело і не платить, оскільки нові функції не впроваджені.

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

Особисто я уникаю створювати названі функції, якщо я не маю гарного імені для них. І гарне ім’я повинно бути коротким і правдиво описувати, яку функцію виконує зовнішній світ. Це також пов’язано із намаганням мати якомога менше аргументів функції та відсутність глобально записуваних даних. Спроба скоротити дуже складну функцію на менші функції часто призводить до дуже довгих списків аргументів, коли функція була справді складною. Створення та підтримання читабельного коду - це вправа рівноваги між взаємно суперечливими нормами здорового глузду. Читання книг - це добре, але лише досвід навчить вас знаходити помилкову складність , саме там і робляться реальні переваги читабельності.

Більшість проектів з відкритим кодом керуються погано. Очевидно, є винятки з цього, але ви знайдете багато сміття у світі з відкритим кодом.

Це не критика всіх власників / менеджерів проектів, про проекти яких я говорю, це просто питання часу, що використовується. Ці люди мають кращі речі, пов'язані зі своїм часом, як, наприклад, їхня фактична оплачувана робота.

На початку код є роботою однієї людини і, ймовірно, невеликий. І невеликий код не повинен бути чистим. А точніше, зусилля, необхідні для очищення коду, більше, ніж користі.

З часом, код - це більше купу патчів багатьох різних людей. Автори патчів не володіють кодом, вони просто хочуть, щоб ця функція була додана або ця помилка була виправлена ​​найпростішим способом.

У власника немає часу на прибирання речей і ніхто більше не дбає.

А код стає більшим. І некрасиві.

Оскільки стає все складніше і складніше знайти свій шлях навколо коду, люди починають додавати функції в неправильному місці. І замість виправлення помилок вони додають обхідні місця в іншому коді.

На сьогоднішній день справа не лише в тому, що людей не хвилює, вони вже не наважуються прибирати, бо бояться зламати речі.

У мене були люди, які описували кодові бази як "жорстоке і незвичне покарання".

Мої особисті переживання не такі вже й погані, але я побачив кілька дуже дивних речей.

Мені здається, ви запитуєте, як працює цей матеріал, якщо ніхто не робить те, що він повинен робити. І якщо це справді працює, то чому ми повинні робити це ?

Відповідь, ІМХО, полягає в тому, що вона працює «досить добре» , також відома як філософія « гірше - краще » . В основному, незважаючи на кам’янисту історію між відкритим кодом та Біллом Гейтсом, вони обоє де-факто прийняли одну і ту ж ідею, що більшість людей дбають про функції, а не про помилки .

Це, звичайно, також призводить до " нормалізації девіантності ", що призводить до таких ситуацій, як Heartbleed , де, точно так, якби відповісти на ваше запитання, масивна, заросла купа спагетті з відкритим вихідним кодом під назвою OpenSSL пішла "не очищеною " десь на кшталт десяти років , що закінчилося величезним недоліком безпеки, що зачіпає тисячі мільйонів людей .

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

То як підтримуються величезні погано кодовані проекти з відкритим кодом? Відповідь - у питанні. Багато з них не підтримуються в чистому стані. Вони пропатчений випадково на тисячі різних людей , щоб охопити випадки використання на різних дивних машинах і ситуаціях розробники ніколи і не мають доступу для тестування на. Код працює "досить добре", поки не стане, коли всі панікують і вирішують кинути гроші на проблему .

То чому б вам турбуватися робити щось " правильне ", якщо ніхто інший?

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

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

• Коли я імпортую бібліотеку чи з бібліотеки, я, мабуть, недостатньо експерта з її внутрішньої структури, щоб точно знати, яка крихітна частина її інструментарію мені потрібна для того, над чим я працюю, якщо тільки я не копіюю те, що Відповідь обміну стека сказала мені зробити. Тож я починаю набирати текст from A import(якщо він є в Python, скажімо) і дивлюся, що з’являється. Але це означає, що те, що я бачу, перераховане, щоб відображати логічні завдання, які мені потрібно запозичити, і це те, що повинно бути в кодовій базі. Незліченна кількість помічників, які скорочують її, просто збентежить мене.
• Бібліотеки існують для найдосвідченішого програміста, який намагається використовувати якийсь алгоритм, про який більшість людей лише невиразно чує. Їм потрібна зовнішня документація, і для цього потрібно точно відображати код, який він не може зробити, якщо ми продовжуватимемо рефакторинг для того, щоб зробити прихильників короткого методу та дій одного.
• Кожен бібліотечний метод, який люди запозичують, може зламати код світу з катастрофічними наслідками, якщо його зняти або навіть перейменувати. Звичайно, я б хотів, щоб склеарн виправив друкарську помилку в Калінській-Харабаші , але це може спричинити ще один інцидент з лівою панеллю . Насправді, на мій досвід, найбільша проблема еволюції бібліотек полягає в тому, що вони надто намагаються прийняти якесь нове «вдосконалення» для того, як вони все структурують.
• Внутрішні коментарі в основному є необхідним злом в кращому випадку, з усіх причин мені не потрібно повторюватися (хоча ці пункти дещо перебільшують). Хороший коментар говорить про те, чому код працює, а не як. Але бібліотеки знають, що їхні читачі - це грамотні програмісти, які не могли, скажімо, записати лінійну алгебру з вихідного паперу. Іншими словами, все потребує коментарів щодо: чому це працює! (Гаразд, це ще одне перебільшення.) Тож саме тому ви бачите рядок підпису, 100-рядковий блок коментарів, 1 рядок коду, який міг буквально перейти на рядок підпису (звичайно, це дозволяє мова).
• Скажімо, ви щось оновлюєте на Github і чекаєте, чи буде прийнятий ваш код. Повинно бути зрозуміло, чому працює зміна вашого коду. Я знаю з досвіду, що рефакторинг, щоб зробити кемпінг чистішим у складі функціональних зобов’язань, часто означає багато економії, перестановки та перейменування ліній, що робить роботу вашої оглядової особи без заробітних плат більш важкою, а також викликає інші вищезгадані проблеми.

Я впевнений, що люди з більшим досвідом, ніж я, можуть згадати інші моменти.

Вже є багато хороших відповідей - я хочу дати перспективу підтримці з відкритим кодом.

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

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

Це суттєво підтримує підтримку - як основний член Node.js є частини коду, яких я боюся торкнутися, але потрібно зробити багато роботи незалежно, і люди користуються платформою успішно і насолоджуються нею. Найголовніше - це працює.

На читабельному коді

Коли ви говорите:

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

Рядки коду не є великим показником того, наскільки він читається. У дослідженні, яке я пов’язаний з ядром Linux, було проаналізовано, і опитування програмістів виявило "звичайний" код (код, який люди в основному очікують) і послідовний код буде кращим, ніж "чистий" код у зрозумілому стані. Це також відповідає моєму особистому досвіду.

Деякі проекти з відкритим кодом не надто вітають

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

Я особисто не згоден з його позицією там - але це теж щось, що роблять люди.

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

Це випливає з характеру процесу розвитку. Простий метод з часом розширюється, додаються нові функції та виправляються помилки.

Тривалі методи сильно знижують розуміння функціональності для нових авторів. Однак з одним автором це рідко є проблемою, і проблема, як правило, не помічається. Іншою природою відкритого коду є той факт, що багато програмного забезпечення активно не розробляється, тому не існує рефакторингу, яка б, наприклад, розділила складні методи на кілька простих методів.

Ви не показали жодних прикладів, але, на моє розуміння, це також часто пов'язане з мовою розробки. Деякі мови застосовують суворі правила зв’язування від початку та важкого тестування модулів (або навіть TDD). І тестові зв'язки, і одиничні тести зазвичай запобігають цю проблему (важко розділити складні / довгі методи тестування).

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