Ти пишеш поганий код, коли тиснеш? [зачинено]

Коли ти відчуваєш тиск, наближається термін, і менеджер дихає вам за шию, чи не починаєте ви писати поганий код? Чи TDD та найкращі практики просуваються убік, щоб встигнути зробити це? Що ти робиш у таких ситуаціях? Якими були ваші переживання?

Одним словом, так. Той, хто говорить вам інакше, мабуть, у кращому випадку помиляється.

Однак ключовим є те, щоб спиратися на ваш досвід написання коду, який є менш поганим. Втримайтеся від спокуси вкласти щось, щоб змусити його "просто працювати", якщо це взагалі можливо, тому що це не буде. Вам все одно потрібно дотримуватися певного процесу (будь то ваш, чи вашої компанії, чи якоїсь суміші).

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

Якщо команда перебуває у крихті, то щось було зроблено не так.

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

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

50-відсоткове хороше рішення, яке у людей насправді вирішує більше проблем і виживає довше, ніж 99% рішення, якого ніхто не має, тому що це у вашій лабораторії, де ви нескінченно шліфуєте прокляту річ. Доставка - особливість .

^{Від Джоела на програмі Програміст стрічки Duct .}

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

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

Деякі люди скажуть "Ну, це життя, ти повинен корабель", але я дійсно не згоден з таким ставленням.

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

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

Так. Але це завжди повертається, щоб переслідувати мене пізніше.

Коли я перебуваю в стресовій ситуації, мій код має на меті виконати роботу. Це воно. Я не концентруюся на ефективності та інших питаннях, що погано, на мій погляд.

Я над цим працюю.

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

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

Вихідний код, який ви пишете під час хрускоту, може бути високої якості, але він майже напевно буде поставлений як частина недбалого продукту.

Залежить.

Чи є тиск через те, що немає можливості зробити все, і тому, що основні нові функції додаються за години до виходу?

Поганий код з'являється!

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

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

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