Например, сейчас мне нужно внести изменения в самописный сайт. На сайте осуществляется регистрация бизнес-партнеров из разных стран. Попросили добавить еще одну страну (в выпадающий список). Казалось бы, добавляешь в select еще один option – и задача выполнена. При выборе списка меняется подчиненный div. Вроде тоже понятно. В общем, работы на полчаса, как показалось с первого взгляда. Оказалось всё не так просто. На серверной стороне пришлось переписывать много кода, связанного с этими изменениями.
Выходя из таких ситуаций, я понимаю, что должен быть алгоритм по разрешению такой и таких задач. Ведь заказчику не скажешь что работы на полчаса (добавить «пунктик»), а потом сидишь целый день и берешь денег соответственно больше.
И я понимаю, что говорить и обещать наперед – значит наступать на одни и те же грабли.
Вторая проблема в том, что кажущееся просто задание может закончиться внесением изменений в структуру БД, java-скрипты, в серверный скрипт. И от этого у самого и волосы поднимаются и руки опускаются по простой причине: работы видно сразу много, а вот что и куда делать – не всегда ясно. Столкнулся я например со случаем когда система перевода диалогов была основана на БД, где каждое переведенное слово находилось в колонке со своим языком. Что делать сначала – ясно: добавить колонку. А что еще дальше – вот это вызывало уйму вопросов…
Спустя время, алгоритм работы с изменениями оказывается классическим. В чем-то обидно, что долго придумывал велосипед. С другой стороны есть ощущение того, что нашел свою истину.
Процесс изменений я разбиваю на простые этапы.
1. Что хочет увидеть заказчик.
2. Анализ: как работает программа сейчас. Какие общие функции используются и на что повлияет их изменение – что придется переписывать дополнительно.
3. Какие изменения нужно сделать, сколько их. Именно на этом этапе можно называть цену.
4. Собственно сам процесс изменений
Естественно, что в каждом этапе скрыто много подпунктов, если программирование на коленках превращается в большой проект. Но как ни странно, этапы реализации проекта и мини-проекта оказываются одинаковыми.
В бОльших проектах всё должно документироваться и описываться максимально подробно. Я бы сказал, что наиболее видным отличием будет наличие документов, зафиксированных критериев цели, и конкретности описанных изменений.
В общем, эта схемка мне в последнее время довольно неплохо помогает копаться в «грязном белье». Если она кому-то будет полезна или есть другие мнения: буду рад услышать.