1) Тестовый сервер
Очень часто бывают ситуации, когда разработчик(в частности фрилансер) находится не за своим любимым рабочим местом, а где-то в гостях, в отъезде и т.д.
Когда появляется необходимость исправить баг или внести какие-либо изменения — разворачивать за чьим-то ноутбуком/стационарником все инструменты, ставить денвер, качать все целиком, разворачивать базу. Значительно проще поставить winscp¬epad++ и внести правки на продакшн. С увеличением частоты таких «правок» код превращается в то, что описано выше.
Для решения таких проблем в первую очередь введен регламент — запрета вносить правки на продакшн, но! одновременно с этим допускается работа на тестовом сервере! Все правки, мелкие большие с сервера коммитятся в свн(изучить консольные команды svn для разработчика не составляет проблемы… их нужно 2-3 в такой ситуации) и уже только после этого апдейт на продакшене. Для апдейта на продакшене даже сделан www-скрипт, который позволяет делать апдейт без подключения к ssh и т.д.
Изменения в БД все только через миграции!
Так что делайте тестовый сервер обязательно! ИМХО необходимая вещь любому проекту.
2) Трекер! Писать и общаться через трекер воспитывает и клиента и заказчика.
Мы на томже тестовом развернули редмайн. Позже добавили к нему tikiwiki, в которую пишутся полезные няшечки для других разработчиков и клиента. Трекер также отображает активность разработчиков для клиента. Клиенту приятно посмотреть, что вот была такая ошибка и по её исправлению был сделан такой-то коммит и вон чето поменяли.
3) Проведение рефакторинга. Очень сложно клиенту объяснить, что это такое и зачем он нужен. Почему он должен платить за «переписывание» кода? Пишите сразу правильно, скажет он. Практика показывает, что всетаки можно доказать клиенту необходимость этого действия.
4) Автоматические тесты.
На тестовом сервере далеко не всегда можно увидеть все проблемы- не поломался ли чужой код.
Использование фреймворков позволяют не разводить тотальную быдлятину и обложить код тестами.
