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


336

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

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

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

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

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

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

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


154
Обов’язкове посилання (колись не xkcd): osnews.com/images/comics/wtfm.jpg
Джеррі

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

6
"Звичайно, з точки зору вашого коду, читається" - не так очевидно!
UncleZeiv

24
Я б сказав, що ти знаєш це, коли бачиш це через кілька місяців після того, як ти його написав.
JeffO

2
@asfallows: Я показав дружині якийсь код, і вона подумала, що це дійсно поганий код, тому що вона може його прочитати! (У ній занадто багато англійських шукаючих слів, а недостатньо символів @ [! ^ $ & *) ...)
gnasher729

Відповіді:


370

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

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


6
Ніщо не перемагає емпіричного тестування.
Світовий інженер

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

69
На мій досвід, це працює лише тоді, коли ваш колега знає, що добре, а що погано. Інакше це буде звучати так: "Ви повинні записати цей код тим же методом, що простіше знайти код"
Рангі Лін

12
@RangiLin, ну, може, твій колега мав рацію.

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

220

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

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


28
Так, це звучить добре (і це правда), але це не дуже вдалий підхід для вирішення того, що / як робити сьогодні ...
Michael Durrant

10
Розсічення підказує, що це займе певний час, і ви повинні зробити це обережно ...
deworde

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

1
@MichaelDurrant Кожен раз, коли ви переглядаєте старий код, ви знайдете фрагменти, які повинні були бути написані по-іншому, і тоді ви врахуєте код, який ви пишете "сьогодні". Так, потрібен час, щоб навчитися писати хороший код.
dj18

1
@MichaelDurrant це все-таки є тим, що ви можете дізнатися, які незрозумілі речі ви робили півроку тому, а не робити це сьогодні.
djechlin

94

Це є:

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

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

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

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


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

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

30

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

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


8
... і після того, як ви його прочитали, передайте його комусь іншому, щоб спробувати прочитати.
jcmeloni

19
Це не особливо вдале випробування. Багато застосувань цих правил є суб'єктивними, і ви майже завжди можете прочитати власний код відразу після його написання.
DeadMG

1
"Якщо відповідь" так ", код читається" ... ви . Щоб побачити, чи читається вона для інших, інші повинні спробувати її прочитати.

2
ІМО, СОЛІД завищений. Особливо "S." Той чи всі його неправильно читають.
Ерік Реппен

Я безліч разів наштовхувався на код, який був ДУХОГО і ТОЛОГО і все ж жахливим. Дотримуючись принципів, можна створити помилкове враження, що те, що ви пишете, не є лайно.
Якуб Арнольд

24

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

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

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

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

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


Дивіться також водоспад2006.com/ gorman.html Реффукторинг - це процес прийняття добре розробленого фрагмента коду і через низку невеликих, оборотних змін, що робить його абсолютно незбагненним для всіх, окрім вас самих.
Шьорд

22

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

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


4
+1 для поступового навчання та не намагаючись стати ідеальною протягом ночі
dj18

19

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

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


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

1
@HermannIngjaldsson - Досить справедливо. Звичайно, якщо вони не компетентні і щось зламається, ви почуєте про це досить скоро. "Допоможи !!!!"
MathAttack

це, здається, просто повторює те, що було сказано у верхній відповіді
gnat

17

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

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

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

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

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


2
Це має бути відповіддю. Виміряйте. Інші відповіді - це більше думка, ніж факт, якщо я можу це зрозуміти, він повинен бути хорошим? Спочатку вимірюйте, використовуючи аналіз складності, потім рефактор людини, щоб шукати дублювання тощо
Джон Рейнор

1
Ваш останній абзац, в якому згадуються недоліки балів McCabe, розділених на LOC, швидше за все скасовує всю ідею. Якщо вам потрібно 300 шляхів через ваш код, чому, на вашу думку, це зробить код більш доцільним для використання більше рядків? Це як би сказати, що якщо книга представляє хитромудрі ідеї, це повинна бути справді велика книга, а не спроба спілкуватися лаконічно. -1.
Wildcard

8

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

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

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


8

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

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

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

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

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

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


3
Читання коду без IDE здається бездоганним, особливо як міру читабельності. Цей тип метрики призводить до "рішень" угорського стилю позначень, які зрештою підривають читабельність.
rubenvb

8

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

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

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

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

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

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

1
@ Рой, так, досить справедливо. Можливо, я ніколи не повинен був додавати цей зразок коду. Зрозуміло, це було майже 3 роки тому, але навіть тоді я, мабуть, не повинен був використовувати PHP (я вже зараз переглядаю це), і я не повинен був використовувати регулярний вираз, оскільки це одна з тих речей, яку деякі люди Ви можете подивитися і негайно отримати його, але для інших, як би не були лаконічні, регулярні виразки - це негайне вимкнення. Я збираюся відредагувати відповідь і відкинути зразок коду. Дякуємо за коментар
Віл Мур III

Як об’єкт може зробити одне?
Корай Тугай

@KorayTugay Подумайте про це так. Якщо об’єкт описує більше, ніж єдину згуртовану концепцію, у вас запах.
Віл Мур III

6

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

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

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

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


3

Не будучи пуританською: віддайте перевагу функціональному стилю. Більшість мов у наші дні (.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);

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


2

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

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

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

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

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

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


це, мабуть, не додає нічого суттєвого щодо питань, викладених та пояснених у попередніх відповідях
gnat

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

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

2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


1

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


1

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

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

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


Якщо припустити, що одноранговий програміст є принаймні однаково досвідченим та читається мовою програмування та її ідіомами. Часто подібні методи можуть призвести до того, що люди пишуть код у підмножині виразності мови в помилковій спробі зробити інт зрозумілим навіть наймолодшому члену команди. Результатом є більший фрагмент коду в скиданому підмножині мови. І незалежно від того, скільки ви притупите мовний підмножина, 500KLOC коду підмножини невеликої мови завжди буде працювати більше, ніж підтримувати код 200KLOC, який використовує більш виразне підмножина.
user1703394

це, здається, просто повторює те, що було сказано у верхній відповіді
gnat

-1

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

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

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

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

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

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

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

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

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

Я


1
це , здається, не пропонує нічого істотного над точкою зроблена і пояснена в попередньому рівні 25 відповідей
комар

@gnat, я сподівався додати "нюанс" багатьом (потенційно шкідливим) спрощенням в інших відповідях. Особливо з пунктом 3.
user1703394

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

-2

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

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

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

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

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

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

Домовились !! але якщо ми дотримуємось вищезазначених принципів, то якість коду легко виміряти, читати, зрозуміти і, очевидно, досяжно. Виправте мене, якщо я помиляюся.
Narender Parmar

Я не знаю, чому моя відповідь заперечує, навіть я вже висвітлюю основні моменти
Narender Parmar
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.