Реинжиниринг чужого кода и временные решения

Как известно, постоянный фактор нашей жизни - временные трудности.

Бывает такое, что весьма способные и инициативные сотрудники из благих побуждений сделали много полезных программок с помощью MS Excel & MS Access (или даже MS SQL и других корпоративных инструментов).

Сделали, а потом нашли лучшее применение своим талантам, и ушли из компании. А их полезные программы, порой даже относящиеся к классу Mission Critical System, остались без присмотра. А это риски для компании… Что же делать?

Что делать, если ушёл программист

А еще бывает такое. Взялась какая-то крупная ИТ компания за большой проект. Обещала сделать промышленно, непротиворечиво, так, чтобы все департаменты были довольны, а генеральный директор – счастлив. Но, как это обычно бывает, гладко было на бумаге, да забыли про овраги, а по ним – ходить. Сроки переносятся, и идеальное решение по-прежнему обещает быть на горизонте. А надо делать что-то сейчас, потому что низы не могут работать с такими объемами исключительно руками. И если автоматизироваться хотя бы на 20% от задач идеального продукта, что так и пока и не внедрен, то, согласно принципу Парето, будет решено 80% проблем. Только вот подрядчик не может внедрить только 20% своего монолитного решения. Он может внедрить сразу 100% (так он, во всяком случае, говорит на данном этапе внедрения). И нужно обращаться к кому-то еще, тому, кто не строит монолиты, но может автоматизировать пресловутые 20% задач за вполне приемлемое время. К кому же обратиться?

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

Как я разбираюсь в чужом коде?

Давайте возьмем гипотетический пример. Есть программа, программист, ее написавший и поддерживавший, куда-то свалил (например, в США, чтобы было понятно, что он уже не поможет за российский прайс). Но программа работает, выполняет те задачи, что на нее возложены.

И нужно сделать какую-то новую фичу, ради которой Вы обратились ко мне. Как я построю свою работу, чтобы все прошло хорошо?

Стандартно. Если место ответственное, то для начала необходимо избавиться от артефактов разгильдяйства. Сложный участок должен быть документирован, как минимум, в терминологиях черной коробки: что на входе, что на выходе, и полный перечень тест кейсов (сценариев тестирования), как As Is (как это работает сейчас), так и To Be (после внедрения фичи). И эта задача, задача описания работающей программы (или ее части) в терминах черного ящика находится на стороне заказчика. Совместно мы можем подготовить полный набор тест кейсов.

Помимо тест кейсов должно быть частное техническое задание на фичу. Дальше: разработка, тестирование, акт сдачи-приемки - все как обычно.