У програміста широкий перелік правил, яких він повинен дотримуватися в роботі. Це і правила хорошого синтаксису, і загальні стандарти коду в компанії.

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

Принцип роздування

«Кожна програма розвивається до тих пір, поки не зможе читати пошту. Програми, які не можуть так розвинутися, витісняються тими, що змогли».

Це правило має безліч варіацій, але офіційною прийнято вважати Закон про програмне забезпечення, або Закон Завінського. Вперше він був згаданий в книзі «Мистецтво програмування для Unix» (The Art of UNIX Programming). Мова йде про тенденції програм збільшувати функціональність з плином часу і, як наслідок, ускладнюватися. Цей принцип закладений також в функцію повзучості, в якій йдеться:

«ПЗ розширює функціональність до тих пір, поки не задіє всі надані ресурси».

Принцип має негативне забарвлення і протиставляється основним цілям програмування.

Принцип «Чим гірше - тим краще»

«ПЗ, яке має обмеження, але просте у використанні, більш затребуване користувачем і ринком, ніж те. що не має обмежень, але складне для розуміння» .

Річард П. Габріель вперше згадав це правило в есе, написане ним про якість програмного забезпечення, в кінці 1980-х років. У розвитку цієї ідеї він пише, що розумно розібратися в одній проблемі, яку ваше ПО прагне вирішити і довести функцію до досконалості. Треба бути простіше. Чим більше ви розпливається в ідеях, тим більше некерованим стане проект і тим більше незатребуваним він буде.

У разі ігнорування ви стикаєтеся з принципом Пітера:

«Кожен комплексний проект неминуче стає складним для розуміння навіть для власних розробників».

Він виходить з ширшого Принципа Пітера про просування по кар'єрних сходах співробітників з обмеженою компетентністю. Результат - всі співробітники компанії виявляються некомпетентними. Цей же принцип легко спроектувати на ПО, і він теж буде вірним.

Закон Іглсона

«Ваш код, який ви не переглядали 6 або більше місяців, виглядає так, ніби його написав хтось інший».

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

Іншими словами, якщо ви не побачите в старому проекті нічого, що можна поліпшити - це вірна ознака стагнації або деградування.

Правило найменшого подиву

«Якщо необхідна доробка має високий коефіцієнт подиву, можливо, її варто переробити».

Правило вперше з'явилося в IBM Systems Journal в 1984 році, а широкого розголосу отримало завдяки книзі «Мистецтво програмування для Unix». Воно стосується тонкого балансу між інноваціями і знайомством з ними: якщо ПО занадто відрізняється від інших подібних і не відповідає очікуванням користувачів, то вони ймовірно його не приймуть. Краще прагнути до додаткових поліпшень, які досить маштабні, щоб вразити, але всеодно мають здаватися знайомими.

Закон кібернетичної ентомології

«Завжди є ще один баг».

У ЗМІ це правило часто носить назву закону Кібернетичної ентомології Любарського. Його принцип справедливий для всіх програмістів: незалежно від того, наскільки ви чітко пишете код, ретельно тестуєте модулі, і як часто ви реорганізуете класи, завжди знайдеться якась помилка.

Закон Кернігана

«Налагодження коду вдвічі складніше, ніж його написання. Тому, якщо ви пишете настільки розумний код, наскільки це можливо, ви за замовчуванням недостатньо розумні, щоб його налагодити».

Брайан Керніган - один з авторів фундаментальної книги «The C Programming Language». Суть закону: напишіть хороший код, який читабельний, простий, але тільки не занадто розумний. Інакше, ви створите повну протилежність тому, що прийнято вважати найкращим кодом.

Закон Брука

«Додавання робочої сили на пізніх стадіях розробки ПЗ затягує його випуск».

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

Налагодження гумової качки

Тут обійдемося без цитати, так як це швидше корисна техніка. Мова йде про публікацію The Pragmatic Programmer, що розповідає про метод налагодження, коли ви пояснюєте свій код неживому об'єкту, наприклад, гумовії качці. Це задіює різні області вашого мозку, і ви швидше знаходите помилки.