Чи слід шукати код брехні?

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

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

Словами мирянина:

Так , вам слід шукати неправдивий код і змушувати його говорити правду. Але не шляхом порівняння його з документацією. Це був би метод виявлення неправдивої документації.

Код може лежати декількома способами, з яких я зазначу лише кілька:

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

Чим коротше, тим менше лежить. Це очевидно.

Чим менш складний код, тим він прозоріший. Так лежить менше.

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

Хороший інструмент аналізу статичного коду допоможе вам знайти неправдивий код.

Також хороший автоматизований тестовий акумулятор змушує код говорити правду.

Код не може брехати.

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

Код, безумовно, може бути неправильним . Це, безумовно, може ввести в оману в своїй назві чи організації. Це, безумовно, може бути нечитабельним.

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

Ви ставите кілька запитань.

Чи варто нам оглядати брехливий код?

Звичайно!

Чи слід порівнювати [код] з будь-якою наявною документацією?

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

Або зазвичай [код] найкраще джерело для того, що він повинен робити?

Це завжди краще джерело для того, що він буде робити. Найкращим джерелом для того, який код слід робити, можуть бути (комбінація) різних речей, хоча основні з них:

• Сам код;
• Код виклику;
• Коментарі в цьому коді;
• Документація;
• Одиничні випробування;
• Інтеграційні та регресійні тести;
• Програміст;
• Кінцевий користувач;

Яке "найкраще" джерело (або їх комбінація) залежить від вашої ситуації.

Якщо він є спритним кодом, чи менше шансів брехати, чи цей код не може лежати зовсім?

Я не впевнений, що ви маєте на увазі під "спритним кодом", AFAIK "agile" зазвичай стосується процесу кодування. Припустимо, ви маєте на увазі "код, створений у процесі спритного програмування", тоді я думаю, що можна впевнено сказати, що він все ще може брехати. Наскільки це брехня, порівняно з кодом, створеним, наприклад, у проектах у стилі водоспад - суб'єктивна справа (особисто я не думаю, що це великий зв’язок).

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

public int DivideByTwo(int input) 
{
    return input / 3;
}

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

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

if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

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

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

doSomething()

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

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