20 законів розробки софта

#engineering

Приніс немаленьку статтю про 20 різних правил та законів, за якими працює розробка та ІТ в цілому.

💡 Gall's Law. Складна система, що працює завжди була побудована з більше простої систем, яка працювала

💡 KISS. Keep It Simple/ Спрощуйте там де можливо.

💡 Conway's Law. Організації створюю системи, що відображають їх організаційну структуру

💡 CAP Theorem. Розподілена система може гарантувати лише дві з трьох властивостей одночасно: узгодженість, доступність чи толерантність до розділення

💡 Hyrum's Law. Маючи достатню кількість користувачів, кожна поведінка вашого API стає чиєюсь залежністю.

💡 Zawlinski Law. Кожна програма розшируюється, поки не зможе читати пошту. Ті, хто не може читати - змінюються тими, хто може.

💡 Brook's Law. Додавання людей на піздньому етапі розробки ще більше віддаляє реліз.

💡 Ringelmann Effect. Індивідуальна продуктивність падає зі збільшенням розміру команди.

💡 Ефект Даннінга - Крюгера. Чим менше ви знаєте про щось, тим впевненіше ви з цієї теми.

💡 Hofstadter's Law. Це займе більше часу, ніж ви очікуєте.

💡 Price's Law. Половина роботи виконується квадратним коренем із кількості людей.

💡 Parkinson's Law. Робота розширюється, щоб заповнити весь відведений на неї час.

💡 Goodhart's Law. Коли метрика стає ціллю, вона перестає бути хорошою метрикою.

💡 Gilb's Law. Все, що потрібні виміряти кількісно, можна виміряти іншим чином, що буде краще, ніж кількісно.

💡 Knuth's Optimization Principle. Передчасна оптимізація - корінь усього зла.

💡 Amdahl's Law. Прискорення від паралелізму обмежене частиною, що працює послідовно.

💡 Murphy's Law. Все, що може піти не так, піде не так.

💡 Postel's Law. Будьте консервативними в тому, що надсилаєте, та ліберальними в тому, що приймаєте (наприклад для API).

💡 Sturgeon's Law. 90% усього - повна фігня.

💡 Cunningham's Law. Найшвидший спосіб отримати правильну відповідь онлайн - це опублікувати неправильну.

А ви які закони знаєте?