ворення резервних копій. Коли щось не так, головне - це знати, як відкотити систему в нормальний стан, в якому вона була якийсь час назад. Інкрементное резервування з гнучкою стратегією відстеження змін дерева каталогів може зменшити довіру до того, що все працює нормально, навіть коли це так. Або, скоріше, зменшить. Команда, що перейшла до простого тексту, що записує все на стрічку і змінює стрічку щоночі, знає, де все це знаходиться, і на цьому надійному фундаменті здатна досягати прогресу у виконанні цієї роботи, дійсно розумніший, ніж любляча складності команда, яка проводить місяць тільки в спробах організувати роботу.
Роби простіше. Ніколи не латай нічого - ти ніколи не знаєш, чи знайшов ти всі проблеми. Зітри і завантаж заново. Завжди будь здатний переформатувати свій диск, переінсталювати свої інструменти, відновити тексти з репозитарія, переконфігурувати і перекомпілювати. Це дає повну безпеку і зберігає весь той час, який пішов би на суєту з приводу вірусів. Кого це хвилює?
Один з найважливіших питань, яке потрібно задати про нову систему, або навіть про старій системі, з якою довелося зіткнутися, - якого виду ця система? Ніхто не стане навіть намагатися розташувати колонію хіпі навколо плацу або військовий табір у вигляді хаотично розташованих вігвамів, з'єднаних стежками! Будь-яка система може володіти більш ніж одним ознакою з перерахованих нижче, хоча деякі взаємно виключають одне одного. Ці, ймовірно корисні, ознаки - грубі категорії, що зустрічаються на практиці. Вони не виведені з якоїсь лежить в основі теорії. Існують наступні типи систем:
Монолітна;
Клієнт-Сервер;
Інтерактивна;
Пакетна;
Керована подіями;
Керована даними;
Опортуністична;
Штурманська (Dead reckoning);
Збіжна в одну точку (Convergent);
На гребені хвилі (Wavefront);
Ретроспективна (Retrospective).
Концептуальна цілісність вимагає, щоб ви визначили загальний підхід до обробки помилок, що використовується по всьому проекту. Як ви будете повідомляти про помилки? Які ідіоми будуть застосовувати програмісти для елегантної перевірки помилок без порушення головного потоку управління? Зовсім необов'язково робити другий виклик, щоб перевірити, чи виникла помилка або що там було - інакше код буде розпухати. В ідеалі помилки повинні перевірятися при виході з функції, щоб використовувати короткі ідіоми, що призводить до отримання зрозумілого коду.
З деяких причин існує думка, що для того, щоб системи були робастний (стійкими до помилок), їм потрібні нормальні режими, режими збою, в які вони потрапляють при збої, і режими відновлення, в які вони переходять після потрапляння в режим збою для повернення у нормальний режим. Частково це провокується Втративши орієнтування користувачами, які намагаються описати мети у разі збою, але роблять це розмірковуючи про «режимах» системи. Це делікатна область, оскільки при обговоренні збою користувачі повинні думати про складові реальної системи, які можуть давати збій, і вони повинні обговорювати збої заздалегідь, раз вони змушенийи підписувати Вимоги Користувача, які потім можуть бути використані як палиця, якою їх будуть бити. Це означає, що вони повинні намагатися вивчити фінальну реалізацію краще, ніж її знають самі розробники, щоб зуміти описати, що потрібно робити при збої компонентів.
Наявність безлічі режимів для обробки збоїв насправді набагато менш потрібно, ніж думає більшість людей, а позбавлення від них дуже сильно поліпшує керованість складністю. Якщо ми бажаємо зберегти контроль і розуміння наших проектних рішень, ми повинні мінімізувати складність всього, що ми можемо. На боці переможця в цьому рівнянні знаходиться плато якості. На боці переможеного - взаємодія однієї складності з іншого складністю, що дає неймовірний ріст простору станів системи, званий «комбінаторним вибухом».
Кожен проектувальник баз даних знає про нормальних формах. Справа стає дуже складним, якщо намагатися проводити повний аналіз предмета в умовах реального світу, але базова ідея дуже проста. Уникайте надмірності в поданні. Якщо вам знадобилася запис замовлення і запис рахунки, кожна з яких вимагає назви замовника, зберігайте запис про замовника в одній таблиці, і використовуйте унікальну посилання на таблицю замовників у запису замовлення. Потім вставте посилання на таблицю замовлень в запису рахунку. Тоді речі ніколи не встануть наперекосяк, коли вам доведеться не забувати упевнитися у завантаженні різних дрібниць кожен раз, коли ви хочете змінити дані.
Точно також як важливо уникати надмірності представлення даних в конт...
