Переписать бы тут всё!

Опубликовано: 2015-10-09 13:07:32

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

А сейчас я считаю, что это не профессионально. Взять и переписать все не получится. Есть пользователи, есть менеджмент, есть другие задачи.

Для себя я отметил следующие пункты. Можно попробовать переписать часть кода для собственного удобства. Чтобы это прошло безболезненно нужно знать следующее:

1) Процесс;

2) Права пользователей;

3) Критичность в случае простоя, либо ошибок после переписывания;

4) Оценку времени на переписывание.

Бывает так, что бизнес готов платить за переписывание кода. Да, так бывает, но это бывает уже задолго после того, как программисты 100500 раз скажут "Переписать все", но это не плохо. Скорее это даже хорошо, потому что тогда для вас зеленый свет и вы можете спланировать переписывание, запросить время и уведомить менеджмент о будущих проблемах, которые могут возникнуть после переписывания.

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

Есть вариант когда бизнес не готов и все еще не так плохо. Это трясина и тут надо смотреть вперед, так как со временем, скорее всего, будет только хуже. Можно в фоновом режиме взять какую-то часть проекта, например, отчет какой-нибудь и перенести его на новые версии ПО, переписать (если необходимо) убедиться, что все работает и продолжить. В конечном счете отчеты должны быть оформлены как отдельная подсистема и далее нужно перейти к другим частям системы и в идеале разделить систему на модули, организовать между модулям api и стараться изолировать каждый модуль настолько, насколько это возможно.

Прошлые записи

  1. Отпуск в Калининграде
  2. Подарок из Грузии
  3. Уборка придомовой территории
  4. Терпеть нельзя, действовать
  5. Курс 'Upgrade руководителя' от Rubius Academy
  6. Мечты об идеальном Томске. Общественный транспорт и проблема пробок
  7. Arch Linux вместо Linux Mint
  8. Highload 2017 vs Codefest 2018
  9. Детализация по звонкам Теле2, совершенным более полугода назад
  10. Побыть туристом в своем городе
  11. Космология, Байкал, Математика, Минимализм