А потім дивуємося чого така низька якість стала всього на світі. Що робиться, коли тест рандомно фейлить? Звісно ж, збирається консиліум синьор девів, які шукають race condition, проблеми з локами, read after write проблему, деградацію перформансу або проблему з об’ємом (volume) даних, 99 перцентиль, баг в бібліотеці, або ще якусь еболу. Жартую, звісно. Він просто ретраїться (інколи й не 1 раз) і все зашибісь. От би була б людина, яка могла б цілий день займатися тим, що аналізувати тести і шукати баги цілий день, не відволікаючись на нові фічі. Звісно, 90% тестувальників не запарювалися б теж, але мати можливість отримати степи, які відтворюють всратий баг хоча б кожен другий чи третій раз — це може бути різниця між просто продуктом і хорошим продуктом.
І так, деви зазвичай пишуть погані тести, і ші тут не дуже допомагає. Більш того, я коли перейшов в деви, теж з часом почав писати погані тести, хоча мав достатньо попереднього досвіду в автоматизації і думав, що мені таке не загрожує.

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

ви бачили, що то був за компілятор?) Очевидно, що далі заголовків ніхто не читає

Бо якщо тобі треба оптимізувати SQL з low-code системи, значить в тебе щось пішло не так

Дуже схоже колись казали про орм, але, як бачимо, потреба в написанні sql руками нікуди не зникла

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

Це ж буквально про лоу код

Що стосується SDLC:
— деградація зазвичай повільна і видима (інциденти, velocity drop)
— маємо технічні метрики
— є CI/CD, rollback, observability etc.

З цього всього валідний лише перший пункт. Метрики і observability вам нічого не покажуть. Вони покажуть, що в рамках цієї задачі цикломатична складність/дублікати/код смели/споживання ресурсів збільшилися на 1%. І от тут хз, чи це в рамках поточної архітектури це необхідне зло, і краще ви вже не напрограмуєте цю фічу без значного рефакторингу, чи ллм погано нагенерувала. Тому ви вважаєте, що хай буде. І потім у вас кожна задача додає ще по 1%. І ви візьмете аналітику за останні півроку і побачите, що починаєте тонути в поганому коді, що ви будете ролбечити? Останню задачу? Так вона додала всього 1% поганого коду. Чи відкотите усі задачі за півроку?

Дослідження: розробники, що використовували ші сповільнилися на 19%, хоча суб’єктивно відчували пришвидшення на 24%.
Ші оптимісти в цьому топіку: ці дослідження фігня, там рівняють мух з котлетами, я бачу пришвидшення своєї роботи мінімум на 43%.

Діло Хуанг каже, дата-центри ж, як відомо, будуються десятиліттями і попит на них не падає ніколи. А якщо набридне, то можна свічнутися на будівництво будинків, які тепер зможе собі дозволити кожна родина завдяки тому, що їх замін... Oh, wait

А, і тепер ще й кичаться тим, що не читають. Це прям пік ллм культури

Сиджу на доу з 18 року, за цей час лайкнув може 3-5 статей, бо кнопка лайку крихітна і занадто близько до секції жирнючих коментарів

Як іронічно, що активний користувач ші не читав статтю. Попросіть ші скласти вам короткий її переказ

Ого, кого я бачу. Дякую за статтю, сподіваюся це лише початок, було б цікаво почитати більше

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

чи зарплатня то лише вираження скілів, а інших факторів немає?

Зарплатня, як і будь-яка ціна — це баланс попиту і пропозиції. Дістатися стелі скілів можна за 2 роки? Пропозиція росте бо кожен другий може це робити. Ніхто не хоче цим займатися? Пропозиція падає і зарплата росте.
Але наша розмова була геть не про те. Розмова була про те, що ми типу порівнюємо «синьорів водіїв» і джунів програмістів. Я вказую на те, що якщо водія взяли на роботу, значить він уже достатньо кваліфікований для роботи, на відміну від джуна, де різниця продуктивності може бути колосальна, складність навчання в порівнянні також набагато вища. А тепер повернемося до балансу попиту і пропозиції. Багато людей хочуть з хворою спиною в 50 їздити по 12 годин? Ні. Але чи багато людей хочуть сушити собі мізки дебагами, книжками і новими фреймворками по 8 годин щодня? Теж ні.

А водій, який має 2 роки досвіду, і водій, який має 40 років досвіду якось радикально відрізняються по скілах? Прям, як джун і синьор?

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

Так можна сказати про будь-яку не rnd роботу. Оператори АЕС просто користуються посадовими інструкціями і ± розуміють, чому вони саме такі. Лікарі теж користуються протоколами лікування. Навіть архітектори, навіть тих же АЕС користуються таблицями матеріалів і просто збирають те, шо треба з доволі стандартизованих блоків. Інженери (звичайні, не комп‘ютерні) теж мають купу готових модулів і характерних прийомів для побудови мостів чи телевізорів.
Коротше, до паттернів можна звести будь-що.
Ну і на останок, юристи, фінансисти теж переживали наплив всіх, кому не лінь. Це більше питання зарплати і розміру ринку. Ніхто не йде в ядерну фізику не тому, що це неймовірно складно, а тому що в тебе на вибір 2-3 роботодавця в кращому випадку і фоновий стрес.

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

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

Зазвичай більшість багів за статистикою пов’язані із невірним використанням API та інтерфейсів.

Еее, ну це, якщо чесно, вже якийсь дитячий садок або лютий ковбой кодинг. Щоб таке вилізло, треба провтикати валідацію, тести, тестування самими QA/AQA (куди вони взагалі дивляться, якщо не ганяють такі кейси). І взагалі, якщо у нас шось кудись стирчить, то Господь дав нам контрактне тестування.
Тому тут явно або щось зі статистикою або я недооцінив кількість гівняних проектів.

Але ніхто не запитує: «Чому розробник допустив баг?»

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