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

Нещодавно я відвідав лекцію Грега Вілсона (головного вченого програмного забезпечення столярної справи). З реферату:

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

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

Відверто кажучи, я був довірливим .

Ось приклад, взятий з лекції:

"Якщо більше 25% коду потребує рефакторингу, швидше переписати його".

Звучить правдоподібно, але це правда? Де це підтвердження? Це правда для всіх мов? І так далі.

Гаразд, цілком можливо це довести до кінця і нікому нічого не вірити, якщо ви самі не отримали це з перших принципів. Таким чином лежить божевілля (а може, математика ;-)). Але, якщо хтось до вас звернеться із заявою «Ей, роблячи це в [виберіть мову моменту], ми зможемо підвищити продуктивність на [вибрати кратне 10]%», ви схильні просто прийміть це, чи збираєтесь просити підтверджені докази?

Якщо це останнє (і я сподіваюся, що так), то

1. куди б ви пішли, щоб знайти ці докази?
2. наскільки суворими ви були б?

Коротше кажучи, якщо хтось запропонує вам неперевірене твердження, ви відповісте "цитуванням потрібне"?

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

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

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

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

Якщо хтось сказав вам: "Якщо більше 2% коду потребує рефакторингу, швидше його переписати", ви знаєте, що це неправда так само, як якщо б хтось сказав вам "Тільки якщо більше 98% коду потребує рефакторингу, це швидше переписати його ". Де фактичне число залежить від того, що ви робите, і наскільки далеко від ідеального поточного коду.

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

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

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

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

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

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

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

Зрештою, твердження типу "Якщо більше 25% коду потребує рефакторингу, швидше його переписати" не може бути доведено, що воно працює за будь-яких обставин, тому твердження [потрібне цитування] - це справді спосіб інформування догматичного програміста, який прагне змусити свої погляди на інших, що це не завжди "Його Шлях або Шлях".

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

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

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

Це означає, що вони без вартості? Я б не сказав цього взагалі.

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

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

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

З іншого боку, коли продавець заявляє, що нова IDE на 50% більш продуктивна, моя перша реакція - бик $% ^ &!

Хіба це не те, що залежить від цілого ряду нематеріальних змінних (змінних, що не можуть бути науково виміряні)?

На мою думку, вони говорять про емпіричний метод вимірювання емоцій. Щось, що навіть Спок не міг досягти. =)