-
Досить важко знайти помилку у своєму коді, коли ви її шукаєте; це ще складніше, коли ви вважаєте, що ваш код безпомилковий.
-
Робота середньостатистичного менеджера вимагає перемикання уваги кожні кілька хвилин. Робота середньостатистичного розробника програмного забезпечення вимагає, щоб Розробник перемикав увагу не частіше, ніж кожні кілька годин.
-
Хороший код сам по собі є найкращою документацією. Коли ви збираєтеся Додати коментар, запитайте себе: "як я можу вдосконалити код, щоб цей коментар не був необхідним?"Вдосконаліть код, а потім задокументуйте його, щоб зробити його ще більш зрозумілим.
-
Проекти з розробки програмного забезпечення зазнають невдачі з однієї з двох основних причин: команді проекту не вистачає знань для успішного ведення проекту з розробки програмного забезпечення або команді проекту не вистачає рішучості для ефективного ведення проекту.
-
У програмному забезпеченні ланцюжок не такий міцний, як його найслабша ланка; він такий же слабкий, як і всі слабкі ланки, помножені разом.
-
За замовчуванням у програмному проекті рух повинен бути спрямований на видалення елементів програмного забезпечення, щоб зробити його простішим, а не на додавання елементів, щоб зробити його більш складним.
-
Краще почекати, поки з'явиться продуктивний програміст, ніж чекати, поки перший доступний програміст стане продуктивним.
-
В успішному програмному проекті немає секретів. Як хороші, так і погані новини повинні мати можливість переміщатися вгору і вниз по ієрархії ptoject без обмежень.
-
... програмування вимагає більшої концентрації, ніж інші види діяльності. Саме з цієї причини програмісти засмучуються через "швидкі перерви"-такі перерви рівнозначні проханню жонглера одночасно тримати три кулі в повітрі та продукти.
-
Розгадувати таємниці вбивств - це нормально, але вам не обов'язково розбиратися в коді. Ви повинні вміти його читати.
-
Проблема з quick and dirty полягає в тому, що брудне залишається надовго після того, як quick було забуто.
-
Тестування саме по собі не покращує якість програмного забезпечення. Результати тестування є показником якості, але самі по собі вони його не покращують. Спроба покращити якість програмного забезпечення за рахунок збільшення тестування-це все одно, що намагатися схуднути, частіше зважуючись. Те, що ви з'їсте перед тим, як встати на ваги, визначає, скільки ви будете важити, а методи розробки програмного забезпечення, які ви використовуєте, визначають, скільки помилок буде виявлено при тестуванні. Якщо ви хочете схуднути, не купуйте нові ваги; змініть свій раціон харчування. Якщо ви хочете вдосконалити своє програмне забезпечення, не тестуйте більше, а розробляйте краще.
-
Хороший код сам по собі є найкращою документацією.
-
Створення програмного забезпечення передбачає різні етапи планування, підготовки та виконання, які відрізняються за характером та ступенем залежно від того, що будується. [...] Для зведення чотирифутової вежі потрібні тверда рука, рівна поверхня та 10 непошкоджених пивних банок. Для будівництва вежі в 100 разів більшого розміру потрібно не тільки в 100 разів більше пивних банок.
-
Хороший візуальний макет показує логічну структуру програми.
-
Рішення грубої сили, яке працює, краще, ніж елегантне рішення, яке не працює.
-
Навіть якщо у вас є кваліфіковані, мотивовані та працьовиті працівники, неправильна структура команди може звести нанівець їхні зусилля, а не призвести до успіху. Погана структура команди може збільшити час розробки, знизити якість, підірвати моральний дух, збільшити плинність кадрів і в кінцевому підсумку призвести до скасування проекту.
-
Інженерія-це застосування наукових принципів у практичних цілях. Якщо інженерія не практична, це погана інженерія.
-
Спроба застосувати офіційні методи до всіх програмних проектів настільки ж погана, як спроба застосувати розробку коду та виправлення до всіх проектів.
-
Евристика-це алгоритм у костюмі клоуна. Вона менш передбачувана, більш захоплююча і надається без 30-денної гарантії повернення грошей.
-
Загальна Спроба уникнути помилок-це найбільша помилка з усіх можливих.
-
Консультанти з програмного забезпечення іноді радять дотримуватися певних методів розробки програмного забезпечення, виключаючи інші методи. Це сумно, тому що, якщо ви на 100% дотримуєтеся будь-якої однієї методології, ви побачите весь світ з точки зору цієї методології. У деяких випадках ви втратите можливість використовувати інші методи, більш відповідні для вирішення вашої поточної проблеми.
-
95% вмісту та комп'ютерної мови залишаються незмінними.
