Разработка программного обеспечения - это всегда компромисс между тем, что делает само программное обеспечение, и тем, чтобы проект был завершен. Вас могут попросить пожертвовать качеством разработки, чтобы ускорить запуск проекта. Причем жертва может оказаться такой, что это серьезно заденет вашу инженерную или бизнес-ответственность. Например, вас могут попросить применить слабое или неоправданное техническое решение, которое в дальнейшем приведет к множеству проблем.
В таком случае ваша первая обязанность сообщить о таком требовании своей команде и четко объяснить, чем обернется снижение качества. В конце концов, ваше техническое понимание проекта должно быть гораздо лучше понимания вашего босса. Подчеркните, что теряет проект, что приобретает, и какой ценой потери на текущем этапе придется восполнять на следующем цикле разработки. Здесь очень пригодится общее понимание, которое дает хороший проектный план. Если жертвование качеством влияет на усилия по обеспечению качества, укажите на это боссу и команде по качеству. Если жертвование качеством приведет к увеличению найденных багов после тестирования, укажите и на это.
Если жертвы неизбежны, вам стоит попытаться отделить некачественный в результате такого решения код в отдельные компоненты, чтобы в дальнейшем вернуться к нему и переписать. Разъясните это своей команде, чтобы они могли запланировать такой подход.
NinjaProgrammer на Slashdot прислал на эту тему такой шедевр:
Помните, что хорошая архитектура устойчива к плохой реализации к коде. Если в коде присутствуют правильные интерфейсы и абстракции, тогда последующий рефакторинг будет менее болезненным. Если вам сложно написать чистый код, который легко поправить, подумайте, в чем проблема архитектуры, из-за которой возникает эта сложность.
Следующее: Как управлять зависимостями