Ми не знаємо, як працюють програми. Доведено на практиці

TelegramУсі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт друзі! Я — Олексій Остапов, 15 років як QA-інженер, автор блогу QA Mania та один з ведучих подкасту «Питання Якості». І сьогодня я збираюсь вчити програмістів програмувати.

Ця стаття — розширена версія мого виступу на олімпіаді з програмування KPI Open 2023.

Ви зараз можете подумати «що цей тестер собі дозволяє? Що він в біса знає про розробку ПЗ, чого не знаємо ми? Кого він тут вчити зібрався?» Давайте спробую дати вичерпну відповідь:

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

Математика, алгоритми і патерни

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


Проти

  • Математика не потрібна, щоб зробити черговий інтернет-магазин.
  • Існує безліч фреймворків та бібліотек, розроблених розумними людьми, навіть розумнішими за мене, що вже мають вирішення більшості математичних проблем, тож не треба винаходити велосипед.
  • У випадку якоїсь складної задачі завжди можна пошукати відповідь на Stackoverflow чи спитати в ChatGPT.
  • Я ж розумний, я завжди можу вивчити, коли треба буде (ха-ха).

За

  • Математика дає нам необхідну термінологію, щоб я мав змогу описати проблему, яку намагаюсь вирішити.
  • Я можу знати більше ніж один спосіб вирішити одну і ту ж проблему, розуміючи переваги і недоліки кожного підходу.
  • Мій улюблений аргумент, який я почув від Ніла Деграсса Тайсона: ми вчимо математику не для того, щоб все життя потім розв’язувати квадратні рівняння чи ошелешити всіх знанням теореми Піфагора — ми вчимось вирішувати проблеми. Наш мозок будує важливі нейронні зв’язки, які допоможуть нам і далі вирішувати різні проблеми і задачі. Важливо, не що ми вчимо, а як!

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

Якщо подумати над прикладами, то я одразу згадую, як я був молодший і ще тільки вчився в університеті. Ми вивчали і програмували на лабораторних роботах алгоритми сортування (бульбашкою, перестановками, вставками і т.д.). Для кожного з них була визначена складність, яку описують як, наприклад, O(n log n). Тоді я не дуже розумів, навіщо стільки алгоритмів, якщо результат ми маємо один! Чом би не взяти найшвидший і насолоджуватись життям? Але реальність завжди складніша і відповідь на моє питання досить очевидна: на швидкість кожного алгоритму напряму впливають якість вхідних даних, їх кількість, потужність заліза, на якому ми виконуємо алгоритм. І кожен раз, виграючи в швидкості, ми точно втрачаємо щось. І найгірше, що часто ми не можемо зрозуміти, що ми втратили аж до моменту, поки фінальні користувачі не знайдуть баг. Деякі алгоритми вимагають багато оперативної пам’яті для роботи, деякі — стають повільними на великих вибірках, деякі погано сортують вибірки з повторами.

Стандарт якості ПЗ

Я помітив, що дуже часто розробники, пишучи код, фокусуються саме на вирішенні задачі. Програма має робити певну функцію — програма робить функцію. Що ж тут поганого? Ми, тестери, знаємо про стандарт якості ПЗ ISO 25010, що допомагає нам дизайнити гарні тести. Цей стандарт визначає 8 характеристик якісного ПЗ. За стандартом функції — це лише 1 характеристика з 8. Хороші досвідчені програмісти часто беруть до уваги ще 2-3 характеристики, такі як вже згадана вище ефективність і надійність. Але ж навіть в такому випадку залишається ще цілих 5!

Ми з Михайлом Чубом записали низку відео про стандарт якості для навчання тестерів, але я рекомендую до ознайомлення всім. Ось їх повний список зі спрощеними описом:

  1. Функціональна відповідність — міра, в якій програма виконує очікувані функції.
  2. Ефективність — міра, в якій програма використовує ресурси протягом певного часу.
  3. Сумісність — міра, в якій програма може працювати разом з іншими програмами.
  4. Зручність користування — міра, в якій програмою можуть користуватись окремі користувачі.
  5. Надійність — міра, в якій програма може виконувати свої функції, незважаючи на помилки.
  6. Безпека — міра, в якій програма захищає інформацію.
  7. Підтримуваність — міра, в якій програма може бути оновлена чи виправлена.
  8. Портативність — міра, в якій програма може бути використана в різних середовищах.

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

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

Теорія змови розробників фреймворків

На початку я вже написав, що існує безліч фреймворків та бібліотек, що дійсно можуть в 2 рядки коду вирішити багато крутих і дійсно складних задач (існує навіть жарт, що якщо взяти будь-яке слово англійської мови, додати до нього .js — майже гарантовано існує бібліотека з такою назвою 😂). Ніхто в здоровому глузді не буде для повсякденних задач писати велосипед. Але за зручність розробки ми платимо досить велику ціну — ми втрачаємо контекст! Багато налаштувань в сучасних фреймворках — неявні (implicit). Деякі версії одних фреймворків можуть бути не сумісні з іншими фреймворками.

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

Тобто, розробляючи застосунок, кожен з нас має пам’ятати:

  • Що ми використовуємо?
  • На якому залізі це буде працювати?
  • На якій ОС?
  • Яке буде типове мережеве підключення?
  • Яке ПЗ вже буде встановлено там, де буде працювати застосунок?
  • Які є явні і неявні налаштування наших бібліотек?
  • Які версії фреймворків точно протестовані і сумісні з іншими версіями фреймворків?

Я маю дуже круту байку про контекст. 14 грудня 1966 року, на тестовому запуску ракета з безпілотним кораблем «Союз» не змогла взлетіти зі стартового майданчика — один з двигунів не загорівся. Автоматика зупинила запуск. Персонал космодрому пішов перевіряти стан ракети. І в цей час не заплановано спрацювала система аварійного спасіння (САС) «Союзу» (у випадку аварії корабель з екіпажем має вистрілити від ракети та посадити на парашутах на безпечній відстані). Двигуни САС підпалили горючу рідину, що була розлита на землі, сталася пожежа, одна людина загинула.

Розслідування причин аварії встановило, що ракету обладнано інерційною системою відліку, і комп’ютери порівнюють положення ракети за даними системи та згідно із запланованою траєкторією. Якщо є різниця — вистрілює САС. Під час розробки системи було закладено, що Земля — нерухома (і ракета на землі теж). В той же час Земля рухається і за приблизно півгодини після невдалого старту ракета разом з усією планетою (чималу змінну не врахували) відхилилась від запланованої траєкторії на 8 градусів, що і викликало запуск САС.

Зважайте, що контекст завжди більший ніж ви можете уявити.

Ніхто не знає, як працюють програми

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

До чого цей приклад? Навіть знаючи теоретичні можливості фреймворків та інструментів, самі розробники не знають, як це буде працювати на практиці, поки не спробують на практиці. Тож немає нічого постидного розробникам визнавати, що вони не знають, як і що працює на 100%, і це ок — кооперуватись з тестерами, щоб краще зрозуміти те, що ми пишемо!

Підсумки

Спробую дуже коротко сформулювати підсумки своєї статті:

  • Краще знати математику, ніж не знати (дякую, Кеп😂).
  • Програмуючи, майте на увазі стандарт якості ПЗ, це допоможе написати кращий код.
  • Ретельно вивчайте фреймворки, які використовуєте, щоб не мати помилок через нерозуміння контексту.
  • Завжди тестуйте власний код, щоб на практиці переконатись, що він працює так, як задумано.
  • Експериментуйте! Створюйте MVP та порівнюйте ваші рішення, щоб знайти найкраще. І пам’ятайте, що різниця між готовим продуктом і MVP — це якість!

Дякую, що дочитали. Го в коменти доводити, що ви точно знаєте, як і що працює, не те, що цей от тестер. 😀

👍ПодобаєтьсяСподобалось16
До обраногоВ обраному3
LinkedIn

Найкращі коментарі пропустити

Порівнюючи IT з інженерією, це справді так.

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

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

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

Естімейти і можливість принципової реалізації ідеї робляться буквально за години, і від кінцевого результату відрізняються менш ніж на порядок. Більш детальна розробка і досвід попередніх реалізацій — результат вже менш ніж в 2 рази гірший за ідеал, ретельні комп’ютерні симуляції, гарний контроль якості матеріалів для безпечної роботи на межі міцності — і ідеал вже досягнутий.

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

ІТ ж виглядає як радше юриспруденція, чи інша суто гуманітарна сфера. Можна знати теоретичний CS, але воно не дасть ніяких здогадок без документації або тривалого реверс-інжинірінгу, що там конкретний підвантажений твіттером або фейсбуком .js збирається робити у браузері, або які API стирчать з libgmp.so.10.4.1, бо вони є результатом домовленостей і інтуїції розробників і узгодженості з іншими компонентами, а не прямих розрахунків з перших принципів.
У деяких сферах, типу карти пам’яті архітектури х64, легасі просто кричуще нелогічне і неактуальне, але на відміну від інженерії, де неефективні стандарти зазвичай відмирають по мірі фізичного застарівання систем, в ІТ вони можуть бути безсмертними.
Значна, якщо не переважна частина роботи — це читання документації, аналіз вже існуючого, мітинги з людьми, що є протилежним до інженерної розробки, де навпаки, переважає власне робота над хоч загальним дизайном, хоч типова розробка.

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

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

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

Ця стаття заряджена на якісний код, прикладайте її до своїх PR і буде вам менше багів ;)

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

І ані слова про те як програмувати краще... чат GPT писав чи що?

я навіть висновок написав, в якому виділив прописні істини, як то

Завжди тестуйте власний код

Чи скористайтесь порадою іншого коментатора

Ця стаття заряджена на якісний код, прикладайте її до своїх PR і буде вам менше багів ;)

😁

О, друга порада вже непогана, проте... Ви вже протестували такий підхід, це дійсно працює? :)

як раз тестуємо. робіть і пишіть відгук 😁

Ха-ха! Тестування кінцевим споживачем.

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

Усміхнуло :) Це не хибна, а вірна думка. Це лише в допотопні часи розробник був і експертом та адміністратором БД, сисадміном, математиком, алгоритмістом, тестувальником та всім іншим, бо ніякого CI/CD не існувало, а файлики закидувались по FTP. Технології розвиваються та ускладнюються і вже давним давно все вилилось в купу різних посад і ролей.
Є вузькоспеціалізовані ніші, де специфічна математика йде по замовчуванню, як геймдев — там ок.

Коли на проекті потрібна математика, наймають математика, що пише формули (інколи примітивне POC на мові програмування проекту), розжовує та дає розробникам з конкретними прикладами вхідних та вихідних даних для розробки дерева калькуляції (або простішими словами — написати нормальний ООП код, котрий робить те саме). Ніхто просто так з якимось інтегруванням чи диференціальними рівняннями розбиратись не буде. Звісно, є люди котрі знають (або можуть пригадати) математику, але їхня зарплата від цього не факт, що збільшиться, а якщо ще й людина прогинається, то хитрий менеджер поставить йому це як «ціль» на півроку для +150 до зп, а його колезі без цих знань, котрий прийшов з офером від сусідньої компанії, одразу докине +500 (чи скільки треба) ;)

Також, коли потрібні специфічні алгоритми, наймають алгоритмістів, так як в аутсорсі розробники таким не займаються, хоча такі «математики-алгоритмісти-розробники» трапляються, переважно в R&D, FAANG або стартапах на цікавих зарплатах.

Якщо ви прийдете на співбесіду до звичайного сіньор-помідора з 5+ років досвіду та декількома успішними проектами за плечима, котрий в душі не бачив ту вашу математику, крім базових речей, та, можливо, BFS/DFS і почнете йому говорити про інтеграли (а у вакансії цього не було), то може моментально дропнутись з цієї співбесіди, щоб не тратити свій час на нісенітниці, і буде правий :)

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

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

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

Ці два питання взагалі до Product Manager + UI/UX Designer.
А далі, що продакт та архітект з техлідом надумали, то і розробник буде робити згідно функціональних та інших вимог, котрі йому надали.

Деякі алгоритми вимагають багато оперативної пам’яті для роботи, деякі — стають повільними на великих вибірках, деякі погано сортують вибірки з повторами.

Дата- чи бігдата-інженер вам в допомогу, їх для цього придумали :)

Коли на проекті потрібна математика, наймають математика

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

Ви взагалі бачили як пишуть код в стартапах

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

бігдата-інженер вам в допомогу

якщо код написано погано, біг-дата не допоможе. Ось приклад згадав: dou.ua/forums/topic/43364

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

інтерпретації автора сильно затиснуті в контекст українського аутсорсу — фреймоврки, платформи

ооо, а можете пояснити, що це означає?
Чи за межами українського аутсорсу не використовують докер? Чи джаву зі спрингом? Не пишуть на реакті? В такому випадку я дуже пишаюсь українським аутсорсом! 😁

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

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

Понабирают по объявлению программистов, а потом удивляются что они не знают, как работают программы. Вода водная

Хаха. Оце самовпевненість. Такі потім особливо голосно репетують, що вінда глючна, і на їх компі локально точно усе працює 😄

Да, я офигенный программист.

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

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

Вашого власного коду хватає на розбір польотів :)

github.com/...​nce_operations.py#L75-L78

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

Оце ви дійсно офігенний програміст 😂
Ну відкопайте десь мої шкільні лаби по Паскалю для розбору, якщо вам «хватає»

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

Аргумент про 6 років доволі цікавий, я б сказав не зрілий, бо воно рахується по іншому — остання дата активності в репозиторії — Updated on Nov 2, 2022. В розробників, по замовчуванню, це означає, що також ведеться рефакторінг (причісування) старого коду, особливо коли він з часів «я вчився програмувати на пайтоні» і в публічному репозиторії. А ви цього не знаєте, але вчите розробників як програмувати. Класика дебатів «теоретиків» проти «практиків».

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

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

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

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

А ви цього не знаєте, але вчите розробників як програмувати

Підіб’ємо підсумки:
1) Заявляєте всім, що є «офігенним програмістом». Хто не згоден, чи хоче пруфів — хам і неймовірно токсичний айтішник
2) Маєте унікальний скіл оцінювати код на умовній джаві, дивлячись код на пайтоні іншої людини, написаний for fun багато років тому — і не розумієте, що в цій концепції не так
3) Робите проєкцію своїх химерних очікувань на інших а потім звинувачуєте, що хтось їх не знає

Класика дебатів «теоретиків» проти «практиків»

Це вже офтоп, але прям наболіло. Спостереження: всі люди, які мені заявляли «я не теоретик, я практик», не тільки не знали теорії, а ще й на практиці мало чого могли зробити

За пункт #1 підсумків приношу вибачення. Не догледів, що автор того коменту — інший 😱

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

Ну... зазвичай термінологія йде збоку клієнта.

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

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

Мій улюблений аргумент, який я почув від Ніла Деграсса Тайсона: ми вчимо математику не для того, щоб все життя потім розв’язувати квадратні рівняння чи ошелешити всіх знанням теореми Піфагора — ми вчимось вирішувати проблеми. Наш мозок будує важливі нейронні зв’язки, які допоможуть нам і далі вирішувати різні проблеми і задачі. Важливо, не що ми вчимо, а як!

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

зазвичай термінологія йде збоку клієнта

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

щоб добре знати засоби вирішення проблеми нам треба знати предметну область

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

не про необхідність, а про кориснісь

true. Корисніше знати ніж не знати. Уявіть, в команді 2 програміста, один вчить математику, грає в го і катає на велосипеді, щоб тренувати тіло і розум, а інший... і так розумний.
Потім вони роблять естімейт одної і тої ж задачі, і один може її зробити за 4 години, а інший за 20, бо там ще розбиратись треба чи інші відмазки

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

По-перше, наскільки часто виникають такі задачі?

По-друге, це не проблема програміста. Зазвичай треба відповісти, що тут треба дослідження, яке можуть зробити на мехматі КГУ: нехай вони запропонують варіанти на ваших даних, а ви вже виберете найкраще. Тому, шановний клієнте, нам не треба «чесний рейтинг», це дуже суб’єктивно, тут можна сперечатися до нових віників. Дайте нам формулу, які б ви хотіли бачити.

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

В-четверте, якщо брати особисто мене, то мені це нагадує MCTS, тому дуже перспективно буде буде виглядати формула:

  m[i]             ln N
  ---- + c * sqrt ------
  N[i]             N[i]
де теоретичне значення c це sqrt 2 але ми можемо його змінювати віддаючи більше переваги або середній оцінці (границя c = 0), або віддаючи перевагу перевіреності (границя c = ∞). Але знову, я просто це знаю, бо подібна задача у вже виникала. Якщо попросити мене самому вивести цю формулу, то я не впораюся. Думаю, що 90% розробників також.

А як ви вирішили цю ситуацію?

тут треба дослідження... А як ви вирішили цю ситуацію?

На жаль, я б теж проводив дослідження ¯\_(ツ)_/¯ Але тим і круті експерти — їм треба менше часу на дослідження, чи вони знають приблизну відповідь одразу. Тому я і пропагую ідею гарно і постійно вчитись, щоб експертів у нас в ком’юніті було більше 😀

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

Потім вони роблять естімейт одної і тої ж задачі, і один може її зробити за 4 години, а інший за 20, бо там ще розбиратись треба чи інші відмазки

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

більша задача — більша похибка 😁

Порівнюючи IT з інженерією, це справді так.

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

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

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

Естімейти і можливість принципової реалізації ідеї робляться буквально за години, і від кінцевого результату відрізняються менш ніж на порядок. Більш детальна розробка і досвід попередніх реалізацій — результат вже менш ніж в 2 рази гірший за ідеал, ретельні комп’ютерні симуляції, гарний контроль якості матеріалів для безпечної роботи на межі міцності — і ідеал вже досягнутий.

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

ІТ ж виглядає як радше юриспруденція, чи інша суто гуманітарна сфера. Можна знати теоретичний CS, але воно не дасть ніяких здогадок без документації або тривалого реверс-інжинірінгу, що там конкретний підвантажений твіттером або фейсбуком .js збирається робити у браузері, або які API стирчать з libgmp.so.10.4.1, бо вони є результатом домовленостей і інтуїції розробників і узгодженості з іншими компонентами, а не прямих розрахунків з перших принципів.
У деяких сферах, типу карти пам’яті архітектури х64, легасі просто кричуще нелогічне і неактуальне, але на відміну від інженерії, де неефективні стандарти зазвичай відмирають по мірі фізичного застарівання систем, в ІТ вони можуть бути безсмертними.
Значна, якщо не переважна частина роботи — це читання документації, аналіз вже існуючого, мітинги з людьми, що є протилежним до інженерної розробки, де навпаки, переважає власне робота над хоч загальним дизайном, хоч типова розробка.

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

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

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

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

Ні, ви не праві. Тестер має знати і вміти більше за юзера — теорію, тест дизайн, відповідні інструменти. Чим більше, тим краще.
В іншому випадку тестерів би не було, все б тестили юзери 😄

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

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

не зрозуміли — не переймайтесь — не беріть дурного в голову, а тяжкого у руки! :))) не всім дано творити фирмварь для станків з числовим керуванням, частотним перетворювачам та іншим системам, котрі повинні працювати на 100% та 24/7/365. Хтось повинен і сайти програмувати, та ті сайти тестувати — це теж дуже потрібна справа ;))) Але коли в мого знайомого років 10-ть тому не спрацювала на Gelly MK китайський ABS та подушка — він дуже спітнів... :))) Слава Богу обійшлося!

здається одне місто на Кіпрі назвали в вашу честь

та я не про себе — я про того в честь кого названа ОС :)

Хахахахахаха 😂, тобто, замість того, щоб чітко і ясно сформулювати свої думки, ви одразу виріши піськами мірятись? Оце дійсно Senior embeded developer рівень 💪
Перепрошую, свою п’ятиметрову рулетку я вже задонатив на ЗСУ, але чесно і відкрито заявляю, що в мене більше 😁

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

дівчину виписати з села, але село з дівчини

ох, просиш-просиш, щоб люди чітко формулювали думки по темі, але, я занадто оптиміст 🙃

Приклад BIOS вашого пк — як часто глючить і як давно ви його відновлювали

Ха! Пів року тому. Бо виробник ASUS розпаяв на платі мікросехму MUX, яка викликали безбожні глюки, і лише 2 хотфікси біоса пофіксили проблему.
Всі помиляються. А самовпевнені люди помиляються в рази частіше 😉

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

Та яка там елітність... тут вже не про ембед — тут про «як ввійти в іт» 😁 казки «як писати прямий код» від "я сам був програмістів"😂

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

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

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

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

які образи — що за дітячи слогани? І при чому тут помилки?
А про що «думав» автор коли писав цей твит? Та хто ж його зна — може в нього нежить, а він думав про «витік мізків з України».
Повторюю: помилки це нормально, але не знати я к працює твій софт — це дикунство та/або пофігізм. Я часто зустрічаю наприклад таке: for( int i = 0; i < IMAX; i++ ){...} - зараз норма не аналізувати задачу, а писати а-ля «я художник — я так бачу», но не розуміти, що кожна така «i» буде розміщена в стеку і може визвати переповнення стеку — це профанація та профнепридатність. А всіляки парсери! Программист повинен розуміти що на вхід парсера може прийти «любе лайно», причому «лайно» пливе на вхід як цілим куском, так і якими завгодно нерівними долями і це не повинно крашити або підвішувати прилож.

Ця стаття заряджена на якісний код, прикладайте її до своїх PR і буде вам менше багів ;)

Якщо прибрати якусь негативну оцінку «ви програмісти тупі, не розумієте як працює ваш код», то взагалі так воно і є, через що взагалі зʼявився Agile, та ідея fast feedback loop. Тобто код треба якомога частіше запускати, тестити та деплоїти. Це найкращий спосіб дізнатися його цінність та стан, через перевірку реальністю, а не довгі обговорювання чи обмислення.

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

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

то пишу юніт тести

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

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

Всі тести важливі, але в правильній піраміді — юніт найбільше, потім менше інтеграційних, потім ще менше системних і зовсім трози приймальних

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

Та насправді можна зовсім не писати юніт тестів і усе працюватиме. Покажи мені де модульні тести до ядра Linux ? Інша справа, що для самих розробників суттєво краще їх писати. До тестування це взагалі не має особливого відношення, більшість виявлених дефектів зазвичай стосується випадків не передбачуваних вимогами. Наприклад є поле вводу, в яке користувач може вводити якись номер квитанції. У цього номеру є чіткий формат — 9 символів, перші три літери латинського алфавіту — а далі 6 цифр. У вимогах не описали, що користувач не повинен мати можливості вводити в поле значення в невірному форматі, програміст використав стандартний елемент і не додав валідацію. От тут QA має усі змоги виявити цей дефект на етапі експеременту, а програміст додати ту валідацію формату. Після чого користування програмною системою суттєво покращиться. Як це можуть виявити модульні тести які створив сам програміст ? Цю перевірку вже можна додати в модульні тести вже постфактум. Більше за те, у програмістів із досвідом таких багів буде знайдено значно меньше. Та всеодно QA щось таке знаходитимуть, про що і не подумаєш коли писатимеш першу реалізацію.

«діду, пий таблетки, а то отримаєш по жопі» — вибачте, не втримався 😀

Якщо люди менше будуть витрачати час на юніт тести

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

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

Пхахахаха 😂

але в правильній піраміді — юніт найбільше, потім менше інтеграційних, потім ще менше системних

Зупиніть цей bullshit, будь ласка ) У кожного виду тестів є свої особиливості. Наприклад, юніт тести — гарно підходять для тестування алгоритмів, проте вони фіксують імплементацію (хороший тест «переживе» код що він тестує, тобто дозволить виконати своє призначення — при внесені нефункціональних змін (рефакторинг) у код, впевненитись що існуючий функціонал не зламаний, з юніт тестами це дуже важко зробити, адже при зміні коду в 99% випадків доводиться змінювати багато тестів). Фіксація імплементації — це теж може бути ок, насправді, особливо коли проект дуже великий.

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

при внесені нефункціональних змін (рефакторинг) у код, впевненитись що існуючий функціонал не зламаний, з юніт тестами це дуже важко зробити, адже при зміні коду в 99% випадків доводиться змінювати багато тестів

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

Піраміда — це надмірне спрощення такого рішення

sarcasm on «Дизайн паттерни — це надмірне спрощеня, щщо веде лише до неадекватних підходів. Нафігачити спагетті коду — вибір справжніх мужиків 💪» sarcasm off

покриття юніт тестами не меньше 90%

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

якщо після рефакторингу у вас юніт тести не проходять

Проблема не в проходять — не проходять, проблема в тому, що юніт тести привʼязані до коду, тому банально великий клас розділити на 2-3, або просто перенести якийсь функціонал — частіше за все юніт тести летять в мусорку. Юніт тести рідко дозволяють вийти за рамки звичайного перейменування змінних. Наприклад e2e як протилежність — дозволяють хоч повністю з нуля все написати й не змінювати тести — вони будуть нам допомагати. А це може бути корисно для стартапа наприклад, особливо коли немає впевненості в тому як правильно все задизайнити.

Дизайн паттерни — це надмірне спрощеня

без сарказму: «<будь яке правило> — це тру, треба робити тільки так, все інакше не тру» — шкідлива позиція. З дизайн патернами такаж хрінь — про спагетті-код ви чули, а про лазанья-код, який виникає при зловживанні патернами?

Ви буквально стверджуєте, «якщо каміння тверде, а значить небо зелене»

Ні, ви кажете що, ось правильно, коли «піраміда», я кажу що ні, це лише один з можливих варіантів. Про покриття 90% відсотків — це лише приклад; люди які думають «це тру, а це не тру» схильні проявляти цей підхід усюди.

П.с. я не кажу що сами ви мислите «тру — не тру», це так, до теми.

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

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

Далі, завжди буде певний баланс між якістю коду та швидкістю розробки. З одного боку можна взяти Agda або Idris, починати зі специфікації поведінки, а вже потім писати 100% верифікований код, а можна взагалі забити. З цієї точки зору, якщо 90% відсотків робочого часу витрачається на фікс поламаних тестів, то у мене б виникало питання більш ефективного підходу.

юніт тести — гарно підходять для тестування алгоритмів

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

Але у разі алгоритмів та bzip2 дуже добре заходять функціональні тести: id = zip * unzip.

Unit тести можуть заходити для ООП бізнес-архітектури, яку легко робити на незалежні класи, ...

алгоритму дуже важко зробити декомпозицію на незалежні частини

Значить

bzip2

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

функціональні тести

Це ортогональна/віддільна класифікація:
— функціональні тести — тестують поведінку(функціональні вимоги)
— нефункціональні тести — тестують час виконання, використання памяті, наявність і коректність документації ітд (нефункціональні вимоги)

Модульне тестування потрібно не для того щоб «ловити баги» тобто виявляти в системі логічні помилки се не доопрацювання які були виявлені в ході її тестової або безпосередньої експлуатації. Назва баг — тобто жучок, походить від того, що одну зі схем ENIAC замкнув метелик. Модульне тестування це один з методів методології Extreme Programming XP яке дозволяє виявляти внесення регресії рефакиорнгом. Тобто виявляти на ранніх стадіях, що рефакиоринг — процесс структурної зміни програмного коду з метою полегшення його подальшої модифікації і підтримки, не змінює логіки яка була в нього закладена. Виявити баги та дефекти модульне тестування не здатне взагалі, це взагалі доки, що може робити лише людина. Можливо щось можна автоматизувати з допомогою ШІ. Останні 10 років при розробці систем для електронної комерції (Enterprise) бачу чітку тенденцію, що тестування займає принаймні в двічі довше за розробку.

Тільки я не зрозумів звідки екіпаж на безпілотному кораблі?

На Прогресс-ах теж є САС, крім останніх модифікацій (бо дуже дорого возити із собою). Для випадків аварійного порятунку самого корабля та наукового обладнання. Ще з подачи Сергія Королева САС встановлюється майже на усі цивільні ракети з 1966 року, загалом це твердопаливні ракетні двигуни загальною вагою 800кг. В атомних ракетах, є система самознищення.

екіпажу не було, наскільки я зрозумів, але ж не знімати через це САС з корабля

Було б напевно прикольно, якби QA спочатку писали тестовий код, а вже далі ми, розробники, писали код, який не впаде на їхніх тестах. Оті всі 8 стадій. Але то тільки мрії. Як правило сам написав, сам покрив тестами.
Дякую за цікаву статтю.

так є ж таке, TDD називається. Можна впроваджувати хоч в кожному першому проєкті

Якщо часу не шкода.

Витратили час на ТДД, зекономили час на інтеграційному та системному тестуванні

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

От тільки тести заставляють писати саме розробників, тому так собі воно те TDD

заставляють

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

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

кожна задача займає в 3 рази більше часу, зате економить час на дебаг, багфікс, регресійне тестування і «та якого ж біса воно не працює?!» 😁

В тебе якісь перевернуті орієнтири.
Працездатність програми на 95% залежить від якості коду.
І на 5% від тестів. Як код лайно — покривай його тестами, не покривай. Там завждм будуть баги, іноді такі, що виправити неможливо. Іноді такі, що репродюсяться тільки час від часу.

Гарний приклад гарно спроектованої програми — SQL запити. Люди придумали декларативну мову і тепер жодному інженеру не приходить на ум там щось покривати тестами. Воно працює завжди. С першого разу.

Тож підсумки дуже прості. Якщо в вас дуже багато тестів — ви намагаєтесь відкачати пацієнта який опинився в дуже поганому стані.

Ключове слово більш менш.

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

Ах, TDD — єдиноріг, про який всі говорять, проте ніхто вживу не бачив.

Чудова гуманітарна стаття.

гг, це моя гуманітарна допомога тим розробникам, які, не зважаючи ні на що, продовжують писати херовий код ¯\_(ツ)_/¯

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

Пробачте за дотошність, але гляньте правила щодо ком перед «ніж»

дякую, пофіксив одну кому. інші, наче, на своєму місці

Краще знати математику(,) ніж не знати

Гарна стаття Олексій. дякую, хоч і не програміст

Підписатись на коментарі