Test Engineering Notes — Vol. 15. Про flaky-тести в Uber, “хаос” в serverless та інтернет в Антарктиці

#testing #engineering #digest

Підбірка статей за червень вже готова.

TLDR, або Що у випуску

- як Uber бореться з flaky-тестами та як в Zalando тестують на мобілках;
- наскільки успішно великі компанії застосовують ШІ в роботі інженерів;
- новий інструмент для тестування мобільних девайсів від Google;
- як зробити chaos engineering для ваших serverless-систем;
- зрозуміле пояснення контрактних тестів;
- як працюють токени, cookie та черги в сучасних системах;
- багато іншого...

Engineering Principles for Building Financial Systems

#engineering

Хороші поради для тих, хто створює (й тестує) фінансові системи. Базові штуки, та речі, на які варто звернути увагу.

🛠 Про інженерну роботу в часи розквіту AI 🦾

#engineering

Глобальний ІТ ринок змінився.

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

AI прискорює та полегшує роботу кваліфікованих інженерів. Разом із тим - AI робить неефективних інженерів дуже вразливими до звільнень.

Кент Бек у своєму твіті минулого року підкреслив цей факт. Він заявив, що ChatGPT зробив 90% наших навичок вартими 0$, але збільшив цінність інших 10%. (Але яких саме - Кент не розголошує).

В світі AI виживуть інженери - професіонали, які прагнуть розвиватись, адаптуватись та рости.
Успіху досягнуть навіть вже не T-shape, а M-shape спеціалісти - ті, що можуть швидко вчитись та розбиратись навіть в тих дисциплінах "які поза межами зони відповідальності".

Будьте готовими до нового порядку речей.
Вчіться. Вже. Зараз. 🧑‍🎓

How SQL Query works? SQL Query Execution Order for Tech Interview

#engineering #howitworks #interview

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

По-перше - це цікаво.
По-друге - дехто може задати щось подібне на співбесіді - то ж ви зможете відповісти на базовому рівні на таке питання.

Як пишуть код в NASA

#engineering

Знайшов коротенький документ, що описує вимоги до написання коду в NASA. Тобто це "код для rocket science 🚀".

10 правил для safety-critical коду (на мові С):

1. Користуйтеся тільки простими конструкціями управління
2. Усі цикли повинні мати фіксований ліміт
3. Не користуйтесь динамічною памʼяттю після ініціалізації (привіт, Javascript!)
4. Функції не повинні перевищувати 60 строк (як максимум)
5. Не більше двох ассертів на функцію
6. Обʼєкти даних повинні створюватись на мінімально можливому рівні видимості
7. Результат non-void функцій перевіряє фукнція, що їх викликає; валідність вхідних параметрів перевіряється всередині кожної функції
8. Користування пре-процессорами та макросами повинно бути вкрай обмеженим
9. Посилання (pointers) повинні бути обмежені також
10. Весь код повинен бути компільованим, з першого дня розробки з усіма можливими перевірками на рівні компілятора. Усі помилки компіляції (навіть типу "warning") повинні бути виправлені одразу. Код повинен бути протестований як мінімум раз на день (більше - краще) з усіми можливими аналізаторами та із нульовою кількістю помилок.

Кожен може розробити калькулятор! (та де калькулятор краще - Android чи IOS)

#engineering

Цікавезна історія, в якій Hans-J. Boehm, що працював над власними версіями garbage collector та деякими частинами стандарту С++, отримав задачу написати ... калькулятор.
Здається, задача вкрай проста. Але це не так.

P.S. Hans навіть написав дослідницьку роботу про цей досвід - Towards an API for the Real Numbers

What would happen if we didn't use TCP or UDP?

#engineering #rust

Невеличкий експеримент щодо використання кастомних протоколів (відмінних від TCP та UDP).

Чи будуть такий протокол обробляти провайдери - такі як Digital Ocean чи AWS?

Чи правда шаурма стає гіршою чим ближче до станції метро ...

#engineering #python

Цієї пʼятниці хочу поділитись дуже цікавою історією про те, як одна фраза на Reddit може привести до повноцінного проєкту з аналізу даних.

А точніше - приклад того, як можна інженерно підходити до перевірки гіпотез.

Integrated Tests Are Scam

#testing #engineering #automation

Хороша доповідь про те, чому писати end-to-end UI та інтеграційні тести - це шлях у нікуди (за думкою доповідача).

По факту, він розповідає, що юніт + контрактні тести зможуть майже на 100% замінити оці нестабільні високорівневі перевірки.

Про контрактні тести говорили ще 9 років тому!

Vibe coding та реальність

#engineering #llm

Починаємо тиждень з трендів. Останнім часом чув багато хайпу щодо такого поняття як vibe coding. Це коли люди пропагують забити на складне навчання, а всю роботу віддати LLM. Штучний інтелект сам все зробить, а людині треба буде тільки "якось інтегрувати чи просто запустити згенероване".

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

P.S. Наші досвід та вміння ШІ поки не замінить. Поки ...

🚀Хто такі Expert Generalists та чому варто ставити такими?

#engineering #career

Як завжди, Мартін Фаулер задає тренди (як було з мікросервісами) та пише цікаві речі. В свіжій статті він пише про те, куди буде розвиватися інженерна індустрія.

🕶Хто такі Експерти Універсали?

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

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

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

💫Характеристики експертів-універсалів

👉 ФУНДАМЕНТАЛЬНІ ЗНАННЯ. Самі ці знання допомагають швидше переходити між доменами, швидше розбиратись в технологіях. Самі ці знання старішають повільніше.

👉 Допитливість. Базова реакція на новий інструмент та технологію в такого інженера - розібратися ЯК ВОНО ПРАЦЮЄ та як цим користуватись ефективно.

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

👉 Скромність. Вміння прийняти той факт, що кожен новий домен має відмінності та свої "цікавинки". Та те, що контекст має значення.

👉 Фокус на користувачеві. Кожен новий домен чи технологія оцінюються через призму користі для продукту та користувача. А для цього - треба вивчати своїх користувачів

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

💼 Для менеджерів

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

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

🪄Висновок

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

Але думка в цілому мені подобається. Вона до того ж переклікається з підходом Modern Testing від Alan Page.

А що думаєте ви? Чи варто ставати експертом - універсалом? Чи, може, треба розслабитись - бо нас усіх захопить ШІ?

Augmented Coding: Beyond the Vibes

#ai #engineering

Kent Beck написав статтю про свій досвід використання AI агентів для написання коду. Якщо більш точно, то він вирішив написати свою версію B+ Tree на Rust 🦀 та на Python🐍. Й порівняти їх потім з нативними реалізаціями.

Цікаві результати:

👉 Kent називає свій відхід augmented (змінений) coding на противагу відомому vibe coding. В чому різниця? З vibe кодінгом розробнику важливий тільки результат, а не код. То ж такий розробник просто кидає помилки знову в LLM й сподівається на коректні фікси. З augmented coding розробнику важливий результат та код як такий (його якість, покриття, читабельність). То ж він постійно контролює процес написання коду.

👉 LLM спочатку заплуталася та не змогла реалізувати алгоритм на Rust. Чому? Бо мова програмування непроста та компілятор вельми прискіпливий. Тоді Kent зробив наступне - він виконав задачу на Python, а потім ... попросив LLM транслювати код з Python в Rust. Тоді LLM справився із задачею краще.

👉 LLM також зміг згенерувати порівняльні тести для написаного коду та нативної структури даних.

Висновок. Програмування з LLM - все ще програмування. Навички та знання все ще мають цінність. Особливо, коли ви працюєте з нетривіальними проєктами чи мовами програмування.

Practical advice for engineers in these troubled times

#engineering #career

Невеликий пост з порадами про те, як виживати інженерам в сучасному світі.

1. "Забий на роботу, туси на мітингах, качай тільки софт-скілли, харди нікому не потрібні!". Так працювало в 2010х. Але зараз таких людей звільняють дуже швидко

2. Краще працювати над тими компонентами та продуктами, що реально приносять компанії гроші

3. Вчіть фундаментальну базу - вона залишиться з вами надовше. Бо компанії можуть змінити правила найму дуже швидко. Наприклад - перейти від задачок на LeetCode до розглядання ваших власних проєктів чи open-source активності

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

The Problem with Time & Timezones

#engineering

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

Наче задача виглядає просто. Чи не так?

У цьому короткому відео дуже гарно пояснюють, чому програмувати (та й тестувати) задачі звʼязані із часом та часовими зонами - то вельми складна задача.