Якщо неприємність може трапитись, вона трапиться — універсальний закон Мерфі ви, напевно, знаєте. У програмуванні є теж чимало таких тверджень: частина з них просто дотепи, але є і чіткі принципи, безпосередньо пов'язані з розробкою. Ми зібрали ці закони програмування докупи, щоб абревіатури типу KISS або WYSIAYG на форумах більше нікого не лякали.
Ми не хотіли під кожним абзацом писати, що завжди є винятки й нюанси, тому напишемо тут. Про всяк випадок: усі ці закони не є універсальними й не варто застосовувати їх наосліп.
Про час і релізи
Почнемо з Закону Брукса: якщо додати робочу силу на пізній стадії розробки, це ще більше відтягне випуск проєкту. Тож якщо ви вирішили збільшити команду, аби прискорити вихід майже готового релізу — подумайте ще раз.
Звісно, є різні випадки: Брукс радить звертати увагу на тип завдання — чи його можна взагалі розділяти. Умовно, 9 двірників зберуть листя скоріше, ніж 1 (якщо не заважатимуть один одному), але 9 жінок не народять дитину за місяць.
Розробку ПЗ розділити зазвичай можна. Втім, нова людина не буде продуктивною одразу: cтарі учасники витрачатимуть час на навчання нових, ті будуть робити помилки — тож процес триватиме довше.
Ще один момент — це правило стосується лише тих проєктів, випуск яких дійсно затримується. Якщо ж справа у надто оптимістичних прогнозах і графіках, то проблема, вочевидь, не в команді й продуктивності, а в неправильному плануванні.
Якраз плануванню присвячене правило дев'яносто на дев'яносто: перші 90% коду виконуються за перші 90% часу, а написання інших 10% коду займає ще 90% часу. Правило іронічне, але вдало ілюструє дві істини: люди схильні відкладати найскладніші етапи на потім + завжди можуть виникати непередбачувані обставини.
Схожий сенс має ще іронічний закон Гофстедтера:
Будь-яка справа завжди триває довше, ніж очікується, навіть якщо врахувати закон Гофстедтера.
Подібна ідея вдало сформульована й у сатиричному законі Паркінсона: будь-яка робота завжди забирає весь відведений на неї час.
Це твердження в оригіналі стосувалось передовсім британської бюрократії та роботи державних установ. Його перетворили у математичну формулу, в якої з'явилось багато похідних трактувань та інтерпретацій. Наприклад, одне з них для комп'ютерної галузі звучить так: дані розширюються рівно настільки, щоб заповнити увесь доступний для зберігання простір.
Якщо говорити про розробку і час, доречно згадати ще закон Іґлсона. Якщо не переглядати свій код пів року чи більше, здаватиметься, що його написав хтось інший. Буває.
Про якість
Певно, найвідомішим правилом про якість коду і помилки є закон Лінуса, або правило достатньої кількості очей: якщо буде достатньо спостерігачів, усі баги стануть помітними (в оригіналі «given enough eyeballs, all bugs are shallow»). Це була одна з причин, чому виникла галузь open-source: адже чим більше розробників побачать код, тим ймовірніше, що вони знайдуть помилки.
Стосовно цього закону є один приклад, який гарно ілюструє, що не всі правила спрацьовують вчасно. Мова, звісно, про баг Heartbleed у коді OpenSSL, проєкту з відкритим вихідним кодом, від якого залежали дві третини сайтів у світі.
Баг дозволяв перехоплювати інформацію, що передавалась на будь-який сайт під захистом OpenSSL. Помилка була нескладна, але побачили й виправили її лише через два з половиною роки. Вона встигла перейти на тисячі пристроїв, звідки навряд колись зникне. Детальніше про цю історію та її вплив на галузь розробки ми розповідали у статті про економіку open-source ось тут.
Ще одне цікаве твердження — Закон Голла, що стосується проєктування систем:
Складна система, яка правильно працює, не виникає сама по собі, вона завжди бере початок з простої та робочої системи. Складні ж системи, створені з нуля, не працюватимуть і виправити їх неможливо.
Закон Гатбера, або покращення означає погіршення. Патрік Гарбер вважав, що заявлене поліпшення системи насправді або приховує певні недоліки, або негативно впливає на інші складники — і цю закономірність можна застосувати як для бізнесу, так і для розробки.
Розбиті вікна і борг коду. Теорію розбитих вікон сформулювали політолог Джеймс Вілсон та кримінолог Джордж Келлінг. Ідея в тому, що як одне вікно в будинку розбили і ніхто не поставив нове — скоро всі вікна в будинку будуть знищені. Цю тезу часто цитують на підтвердження своїх (будь-яких) ідей, та не менш часто її і заперечують.
У програмуванні є схожа концепція технічного боргу, або боргу коду. Якщо код не оптимізувати одразу (а для цього потрібні час, ресурси тощо), то байдужість зростатиме, перевагу віддаватимуть найпростішим рішенням, і як наслідок виникає код із запашком, якому конче необхідний рефакторинг.
При цьому треба пам'ятати про закон Кернігана: налагоджування коду вдвічі складніше, ніж його написання. Тому, якщо ви написали максимально складний код, який тільки могли, це означає, що самі ви налагодити його не зможете. А за законом кібернетичної ентомології Любарського — завжди є ще один баг.
Емпіричні
Закон Теслера про збереження складності, присвячений взаємодії людини з комп'ютерами, програмами та інтерфейсами. Річ у тому, що в кожної системи є певний рівень складності, який неможливо зменшити чи приховати. Він в кожному разі перейде або в код (тоді користувачу буде простіше), або в інтерфейс (тоді код стане елегантнішим). Теслер при цьому вважав, що краще зусиль докладе розробник, аніж потенційні мільйони користувачів, хоча з цим погоджуються не всі.
Модель Spotify — підхід до структури команди і організації, який започаткувала компанія Spotify. За цією моделлю, команди організовуються навколо функцій програм і гнучкої моделі розробки — а не навколо технологій чи виняткового використання певних скрам-методів.
Тема структури компаній також згадується у законі Конвея. Він стверджує, що технічні обмеження та інтерфейс системи будуть відповідати структурі компанії, яка ці системи створила.
Принцип Парето, або правило 80/20: часто 80% наслідків певного явища спричинені 20% причин. Наприклад, 20% розробників створюють 80% програм, а 20% програм вирішують 80% задач (звісно, це умовне твердження, але суть, думаємо, зрозуміла).
Закон Мура. Ґордон Мур, співзасновник Intel, свого часу помітив, що кількість транзисторів у мікросхемах регулярно подвоюється. Тож він передбачив, що так відбуватиметься і далі, кожні 2 роки, а потужність обчислювальних пристроїв зростатиме експоненційно, допоки це буде можливо.
На це правило довго орієнтувались виробники пристроїв, і тому можна було передбачити, як зросте потужність процесорів через кілька років. Мур також прогнозував, що закон припинить діяти через обмеження швидкості світла та атомну природу речей.
Зараз існує думка, що ми вже досягли межі й закон Мура або вже не діє, або скоро припинить, зокрема й тому, що сучасні системи дуже потужні й швидкі, а подвоювати ці характеристики складно і дорого. До того ж розвиваються квантові комп'ютери, які принципово відрізняються від традиційних пристроїв (оскільки обробляють дані в кубітах, тобто 0 і 1 одночасно), тож закон Мура застосувати до них не можна.
Існує також жартівливе твердження, відоме як закон Вірта:
Програми стають повільнішим значно швидше, ніж комп\'ютери прискорюються
Воно сформульоване ще в 1995 році, тож різниця потужностей між програмним і апаратним забезпеченням стала очевидною досить давно.
Завершимо цей розділ ще одним іронічним правилом, законом Каннінгема. Якщо потрібно знайти щось в інтернеті — краще не запитувати про це, а просто опублікувати неправильну відповідь. Згадуйте про нього, коли підете на Stack Overflow.
Абревіатурні
WYSIAYG («What You See Is All You Get»), автором якого є згаданий вище Браян Керніган. Цей вираз — іронічний перифраз класичного «What You See Is What You Get» (WYSIWYG). Варіант Кернігана описує гарненькі користувацькі інтерфейси, яким бракує глибини та функціоналу для масштабних застосунків. Такі інтерфейси часто розчаровують просунутих користувачів, які шукають більше фіч, ніж видно на екрані, це явище ще називають проблемою WYSIAYG.
Принцип DRY, або «Не Повторюйся» («Don't Repeat Yourself»). Фундаментальне правило і популярна мантра серед розробників, котра звучить так: кожна частина інформації повинна мати єдине, однозначне, авторитетне представлення в межах системи. Та хоча чистий код і уникнення суцільної копіпасти — це добре, але розуміти й враховувати контекст теж важливо. На цю тему можете почитати гарні статті на Medium.
Порушення принципу DRY жартома називають WET — «Write Everything Twice» («пишемо все двічі») та «We Enjoy Typing» («ми обожнюємо друкувати»). Додати нічого.
Від того ж правила DRY напряму залежать принципи SOLID, зокрема відкритості/закритості — програмні сутності мають бути відкриті для розширення та закриті для модифікацій — та принцип єдиного обов'язку (SRP) — може бути лише одна причина, щоб змінювати клас («A class should have only one reason to change»). Тобто кожен об'єкт має лише одну відповідальність та причину існування і вони мають бути інкапсульовані в клас.
Принцип KISS, або «Не ускладнюй, дурко» («Keep it simple, stupid», є ще варіант без коми). Для кінцевого користувача не важливо, наскільки вигадливим може бути розробник, головне — щоб усе було зрозуміло. Чим простіше працюватиме продукт, тим більше людей ним скористаються, а отже — тим він буде корисніший.
Зараз цей принцип стосується найбільше розробки й дизайну, але його авторство належить авіаконструктору Келлі Джонсону. Він створював літаки такими, щоб їх могли полагодити в польових умовах механіки з мінімальною підготовкою і набором інструментів.
POLA, або правило найменшого здивування: якщо у функції високий коефіцієнт здивування, можливо, її потрібно переробити. Тобто поведінка елементів має бути очікуваною і не надто дивувати користувача. Це актуально і для розробки ПЗ і для проєктування інтерфейсів. Сумно чи ні, але надто інноваційні речі здатні відлякувати людей (взяти б половину ранніх розробок Apple або серіальний Pied Piper з «Кремнієвої долини»).
Принцип YAGNI. Розшифровується як «You Ain't Gonna Need It», або «Вам це не знадобиться». Якщо в системі не передбачений певний функціонал, не потрібно його прописувати в коді (навіть якщо дуже хочеться). На певному етапі розробки може здаватися, що додаткові фічі не завадять, знадобляться в майбутньому і взагалі зайвими не будуть. Але час на тестування цих функцій, документування, реалізацію втрачається, а одна надлишкова конструкція може потягнути за собою ще дванадцять — і продукт зрештою стає надто складним, ресурсно невигідним і роздутим.
З приводу розширення функціоналу свого час міркував Джеймі Завінські. Він стверджував, що кожна програма розвивається доти, доки не зможе читати пошту. Програми, які пошту не вміють читати, замінять ті, як можуть. Сформулював він його ще у минулому столітті, а досконалого поштового клієнта і досі немає, тож закон вважатимемо актуальним.
Ще немає коментарів