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

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

Ці цілі досягаються, коли з кодом можна виконати наступне без консультації експерта оригіналу автора:

• Можна прочитати код і зрозуміти на базовому рівні потік логіки.

• На більш глибокому рівні можна зрозуміти, що робить код, включаючи входи, виходи та алгоритми.

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

• Можна написати новий код, наприклад клас або модуль, який використовує оригінальний код.

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

Ваш переглядач повідомляє вам, переглянувши код.

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

Іноді найкращий спосіб знати - це повернутися до коду, який ви написали півроку тому, і спробувати зрозуміти, що це було написано.

Якщо ви це швидко зрозумієте - це читабельно.

Це є:

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

Справжнє випробування для 1. - це (як говорять Алекс в Парижі та Quant_dev ), що ви можете забрати його за кілька місяців, роблячи щось інше.

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

Є правила великого пальця, принципи (тобто правила великого пальця, які хтось добре написав і дав ім’я), і всілякі пропозиції, які можуть привести вас у правильному напрямку або від загальних підводних каменів. Однак жоден з них не гарантує якості, про яку ви просите.

Якщо ваш код відповідає принципам SOLID і DRY і має хороший набір одиничних тестів, він, ймовірно, є реконструкційним.

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

Читання, як написати незрозумілий код - Забезпечте роботу на життя Роді Гріном, сміючись та навчаючись.

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

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

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

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

Незважаючи на те, як це здається, ви можете розглянути деякі досить об’єктивні заходи. У таких книгах, як C ++ Стандарти кодування , Refactoring та Clean Code є довгий перелік критеріїв, за якими можна судити про ваш код, переглядаючи такі речі, як значущі назви, розміри функцій, принципи, як з'єднання та згуртованість, дизайн об'єктів, тестування блоків, послідовне вдосконалення тощо.

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

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

Це був ранній урок моєї кар’єри. Наставник сказав: "Документуйте все, щоб потім піти від програми. Якщо ви не очікуєте питань, коли відповіді свіжі у вас на думці, вам доведеться розібратися в них, коли їх немає".

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

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

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

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

Де Маккей впаде, однак, є в цьому останньому прикладі. Якщо у мене 300 рядків коду без будь-яких умов, є справді хороший шанс, що я зробив "копіювати / вставляти повторне використання", і очевидно, що це теж не дуже добре. Тож існують загальносистемні показники, які ви застосовуєте на додаток до McCabe - як виявлення дублікату або майже дублювання коду.

Я поділяюсь одним із пунктів, якщо код вбудований у "модулі", і коли я кажу, що я маю на увазі, що ви можете змінити одну річ у модулі та легко працювати з цілим. Це усуває наслідки між непов'язаними речами. Також:

• Код легко використовувати повторно
• Ваш код є гнучким (це пов'язано зі створенням модулів)
• СУХО - не повторюйте себе

Я настійно рекомендую прочитати, Прагматичний програміст.

Деякі тести / показники:

• Вимкніть IDE. Ви ще можете прочитати власний код? Коли є помилка, чи досить легко простежити її вручну і зрозуміти, для якого класу вам знадобиться точка перелому, щоб з'ясувати, в чому тут проблема? Або коли ви використовуєте IDE, ви просто не турбуєтесь і просто переступаєте з самого початку?

• Чи налагодження часто стає грою wack-a-mol, де виправлення однієї помилки створює ще 2+.

• Від натискання тригера до чогось корисного, що насправді відбувається, скільки викликів методів потрібно? Скільки методів передають однакові або більшість однакових точних параметрів на інший виклик методу?

• Скільки файлів потрібно відкрити, щоб просто додати простий новий метод до класу?

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

Звідки можна дізнатися, чи створений ним код легко легко читати та читати?

Ви можете помітити простий у обслуговуванні та читанні код, шукаючи ці властивості:

1. Об'єкти, методи та / або функції завжди роблять одне.
2. Методи та / або функції стислі (як у "короткій, але всебічній").
3. Об'єкти, методи та / або функції по суті роблять те, що ви вважаєте, що вони повинні робити, виходячи з їх імен.
4. Код, призначений для повторного використання, насправді може бути повторно використаний.
5. І останнє, але не менш важливе значення, якщо ви зможете одразу перевірити код, ви, ймовірно, написали модульний код з одноосібною відповідальністю.

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

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

Одним словом, досвід .

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

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

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

Не будучи пуританською: віддайте перевагу функціональному стилю. Більшість мов у наші дні (.NET, Ruby, Python, Javascript тощо) підтримують та просувають її (наприклад, LINQ, підкреслення).

Це надзвичайно легко читати.

var recentTopCustomers = OrderList
    .Where(o => o.Date >= DateTime.Now.AddDays(-5))
    .Where(o => o.Amount > 1000)
    .OrderBy(o => -o.Amount)
    .Take(10)
    .Select(o => o.Customer);

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

Зрозумілий і доступний код: Код, який, на перший погляд, програміст може зрозуміти досить добре, щоб легко:

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

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

Книга «Код завершена, Стівом МакКоннеллом» детально розглядає це питання.

Він проходить різні показники, за допомогою яких можна визначити, чи хороший код.

Дивіться приклад тут: http://books.google.co.uk/books?id=3JfE7TGUwvgC&lpg=PT376&pg=PT389#v=onepage&q&f=false

Мінімізувати побічні ефекти (в ідеалі їх немає)

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

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

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

Уникайте зайвих зовнішніх залежностей

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

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

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

Перевірте лайно з цього

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

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

Документація на інтерфейс

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

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

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

Читабельність

Ця частина дуже суб'єктивна. Мені не дуже цікаво читабельність такого роду, близького людським мисленнєвим процесам. Найбільш добре задокументований код, що описує речі на найвищому рівні, мені все ще важко дотримуватися, якщо автор використовує химерні та згорнуті думки, щоб вирішити проблему. Тим часом лаконічний код, що використовує 2 або 3 імена символів, часто може бути простішим для мене, якщо зрозуміти, чи логіка дуже проста. Я думаю, ви могли б оглянути рецензію та побачити, що віддають перевагу інші.

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

Я б сказав, що один із способів знати, якщо нові члени команди зможуть забрати код, зрозуміти його та змінити, щоб виправити дефекти / відповідати новим вимогам відносно легко.

Ось метод, який я люблю використовувати:

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

1) Якщо вони не можуть легко пояснити мету блоку рефактора коду, це.
2) Якщо їм доведеться перейти до іншого розділу коду, щоб зрозуміти поточний розділ, перефактуруйте його.
4) Коли ви відчуваєте бажання говорити під час процесу, цей розділ коду потребує рефакторингу. (Код не говорить сам за себе).

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

• максимально сухий

По-друге, немає нічого гіршого в технічному обслуговуванні, ніж приховані залежності. Отже, для правила №2:

• Зробіть усі свої залежності явними.

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

Бібліотеки крос-проекту: старші розробники, повний підказки код / ​​ідіома / методи Проектування конкретних бібліотек та системного бекенду: середні розробники, уникайте найсучасніших і важких для пояснення матеріалів. Старші люди перейдуть цей код, шукаючи можливості для покращення DRY.

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

Отже, для правила №3:

• Розкладіть свій код за рівнем майстерності розробника і запишіть відповідний код.

Я

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

OOAD - це чотири букви, але його важко зрозуміти за один раз - слідуйте об'єктно-орієнтованому аналізу та дизайну

1. Завжди почніть з хорошого збору вимог та точної постановки проблеми

   • почніть з кількох випадків використання, тобто; Взаємодія між системою і користувачем

2. Ви повинні тримати ваші об'єкти вільно з’єднані та переконайтесь, що ваш код не повториться - дотримуйтесь DRY [Не повторюйте себе]

   • в будь-який час ви бачите дублікат, шукайте місце для інкапсуляції
3. ваш код відкритий для розширення та закритий для модифікації - OCP [принцип відкритого закриття]
4. Коли ви змінюєте код, завжди пам’ятайте - не створюйте проблем для вирішення проблем, ІТ просто заявляє, що не змінюють існуючі функції
5. Тестуйте свій код
   • завжди перевіряйте свій код, коли справи йдуть не так
6. Працюючи над функціоналом, завжди пам’ятайте, що слід дотримуватися основних OOP (об'єктно-орієнтованих принципів) та прийомів, щоб переконатися, що ваша програма добре розроблена з самого початку
   • Об'єкти повинні робити те, що вказує їх назва
   • Кожен об’єкт повинен представляти єдине поняття
7. Завжди пам'ятайте про проблему системи та в якому контексті / доменному програмному забезпеченні
8. Займіться певною роботою на папері - так, це працює для мене
   • мати деякі роздруківки матеріалів, що стосуються інтерфейсу, та діаграм UML завжди працює
   • Ви навіть можете мати знімки екрана сеансу мозкового штурму з Білої дошки
9. Макети архітектури
10. За можливості застосуйте принципи дизайну
11. Документація
    • завжди документуйте свій код
    • встановіть відступи в IDE і документуйте також