Повідомлення telegram каналу - @from_a_to_qa

Логотип телеграм спільноти - From A to QA | Все про тестування 2024-07-14

From A to QA | Все про тестування

Кількість підписників:
4101
Фото:
76 
Відео:
40 
Посилання:
234 
Категорія:
Технології
Опис:
Привіт. Я Артур — Director of Engineering, Head of QA, кандидат наук та викладач в універі. Пишу про тестування, програмування, автоматизацію та айтішку. По питанням пишіть @ar2r_s

Канал From A to QA | Все про тестування - @from_a_to_qa - №407

Закони в розробці ПЗ які повинні знати всі:
💡 Brooks’s Law
Adding [human resources] to a late software project makes it later.
Додавання нових учасників до проєкту який не втискується у дедлайни може ще більше затримати його через зростання витрат на координацію.
💡 Goodhart’s Law
When a measure becomes a target, it ceases to be a good measure.
Якщо націлитися на певний показник, поведінка людей почне змінюватися для його досягнення, навіть якщо це не допомагає досягти справжньої мети. Приклад, коли ви починаєте міряти ефективність тестувальника по кількості створених багів або ефективність розробника ко кількості рядків коду. Перший починає на кожний піксель створювати баг, а другий писати спагетті код.
💡 Hyrum’s Law
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
Користувачі починають залежати від навіть неочікуваних поведінкових аспектів системи, що ускладнює зміни.
💡 Conway’s Law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Архітектура програмного забезпечення часто відповідає структурі організації, яка його створила.
💡 Linus’s Law
Given enough eyeballs, all bugs are shallow.
Чим більше людей перевіряє код, тим легше знайти помилки.
💡 Hofstadter’s Law
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
Реальність майже завжди перевищує очікувані терміни виконання завдань.
💡 Kernighan’s Law
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
Якщо ви пишете занадто складний код, його буде важче виправити.
Надмірно складний код ускладнює відлагодження і підтримку.
💡 Peter Principle
People in a hierarchy tend to rise to ‘a level of respective incompetence.
Людей часто просувають по кар’єрних сходах до тих пір, поки вони не досягнуть позиції, на якій не зможуть ефективно працювати.
💡 Pareto Principle
For many outcomes, roughly 80% of consequences come from 20% of causes.
Більшість результатів досягаються від невеликої частини причин, тому важливо фокусувати зусилля на найважливіших аспектах.
2500
24-10-02 08:44