Вы пишете плохой код под давлением? [закрыто]

Когда вы находитесь под давлением, приближается крайний срок, и менеджер дышит вам в голову, вы начинаете писать плохой код? TDD и лучшие практики уходят на второй план, чтобы добиться цели? Что вы делаете в подобных ситуациях? Каковы были ваши переживания?

Одним словом да. Любой, кто говорит вам иначе, возможно, в лучшем случае ошибается.

Тем не менее, ключ заключается в том, чтобы опираться на свой опыт написания кода, который не так плох. Не поддавайтесь искушению вставить что-то, чтобы это «просто работало», если это вообще возможно, потому что это не сработает. Вам все еще нужно следовать некоторому процессу (будь то ваш собственный, или ваша компания, или какое-то их сочетание).

Опыт подсказывает мне, что гораздо лучше ( задыхаться ) проскользнуть график на пару дней, чтобы избежать недельных исправлений, особенно когда «под давлением» означает ускоренный выпуск в производство. Если вы спешите выпустить код, тестеры, вероятно, тоже будут спешить с его штамповкой.

Если команда находится в затруднительном положении, то что-то было сделано неправильно.

Пропуск сроков является признаком плохого планирования и оценки. Признать, что крайний срок будет пропущен, и решить проблему. Иногда вы не можете контролировать планирование или оценку. Определите, кто это делает, и убедитесь, что они знают, что это было сделано по ошибке.

В ситуации, когда крайний срок не может быть перенесен, вы отказываетесь от напитков с высоким содержанием кофеина и спешите с этим. Определите все, что вы можете пожертвовать и вырезать это. Бери то, что осталось, и реализуй это как можно быстрее. Это приведет к таким проблемам, как нестабильность, странные ошибки, неэффективные методы кодирования, исправления ошибок и другие виды ужасов. Это не обязательно плохой код, но он не идеален .

50% -ное хорошее решение, которое на самом деле есть у людей, решает больше проблем и выживает дольше, чем решение на 99%, которого никто не имеет, потому что это в вашей лаборатории, где вы бесконечно совершенствуете эту чертову штуку. Доставка это особенность .

^{От Джоэла по программному обеспечению The Duct Tape Programmer .}

С неидеальным кодом можно разобраться, если с ним разобраться . Код, который не был обработан, будет накапливаться и вносить дополнительные изменения сложнее, если не невозможно. Это может привести к тому, что приложение будет настолько взаимосвязано, что дополнения могут быть сделаны только самыми осторожными программистами с непомерными затратами времени. Хотя доставка это особенность, так что это ремонтопригодность.

Я большой поклонник мастерства программного обеспечения - пишу чистый код как можно лучше и т. Д., Но иногда мне приходилось торопиться в моменты, когда времени мало и приближается крайний срок. Я действительно стараюсь не делать этого как можно лучше, но иногда от этого не уйти.

Некоторые люди скажут: «Ну, это жизнь, ты должен быть на корабле», но я действительно не согласен с таким отношением.

При написании ускоренного кода вы можете в конечном итоге получить программное обеспечение вовремя, но что произойдет, если в течение следующих нескольких дней вы получите звонки в службу поддержки, относящиеся к ошибкам в программном обеспечении (эти ошибки живут в одной части). кода вы бросились, чтобы закончить). Или вы получаете злой клиент, который звонит вам и спрашивает, почему его модуль отчетности больше не работает, даже если вы обещали, что все будет хорошо в день релиза?

Все очень хорошо говорят: «Ты должен отправиться» , но есть разница между тем, чтобы выглядеть эффектно и выглядеть неаккуратным рабочим.

Да. Но это всегда возвращается, чтобы преследовать меня позже.

Когда я нахожусь в стрессовой ситуации, мой код предназначен для выполнения работы. Это оно. Я не концентрируюсь на эффективности и других проблемах, что плохо, по моему мнению.

Я буду работать над этим, хотя.

Я не верю, что лично я пишу значительно худший код, но я поставляю худший продукт.

Столкнувшись с произвольным и невозможным сроком, мы экономим на процессе разработки. Мы делаем более поверхностные обзоры кода (или вообще их пропускаем). Мы проводим меньшее тестирование, минуем подробное модульное тестирование для интеграционных тестов типа выборочной проверки, а затем пытаемся считать интеграционный тест формальной квалификацией. Мы склонны упускать из виду аномалии во время тестирования, если они не связаны напрямую с критериями прохождения и отказа. Мы пропускаем обновления документации, не перепроверяем заметки о выпуске, забываем чистить список результатов для файлов, которые больше не нужны.

Исходный код, который вы пишете во время кризиса, может быть высокого качества, но он почти наверняка будет поставляться как часть некачественного продукта.

Зависит.

Это давление, потому что не существует способа, которым можно все сделать, и потому что новые важные функции добавляются за несколько часов до релиза?

Плохой код!

Но если это потому, что график просто действительно очень плотный, но общий план тверд, и мне просто нужно работать намного усерднее, чем обычно, и постоянно фокусироваться, настраивая некоторые функции, которые можно услышать и там ... Тогда я создаю гораздо лучший код, чем если график позволяет тонны времени. Даже если это означает, что я пишу не все модульные тесты, а покрываю основные части кода.

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

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