English

Никогда! На этом, в общем можно было бы и закончить, но я все же напишу больше.

Мне довелось однажды оказаться в ситуации, когда мне поручили сдать проект, притом, что отгрузка (он же дедлайн) была очень близка. В проекте участвовало несколько человек: программист прикладной части ПО (он же менеджер проекта) и программист программы контроллера, и программист контроллера в части системы сигнализации и связи с АСУ ТП (моя часть). Проект уже был в стадии, когда самый главный начальник несколько раз в неделю приходил в кабинет и настойчиво спрашивал о сроках завершения проекта. Моя часть была завершена, и я был спокоен. Обещали сдать до нового года, но, увы и ах как-то не выходило. Основная часть программы контроллера была не готова. Результаты тестирования содержали более 20 страниц формата А4 с описанием, в основном, критических багов.

После нового года ко мне подходит менеджер проекта и говорит о том, что программист контроллера уезжает на обучение, а после этого будет переведен на другой проект и поэтому мне придется заняться основной частью программы. Исправить баги и сдать ее как можно быстрее. Мой непосредственный начальник не сказал мне поэтому поводу ни слова. Сейчас я вспоминаю те дни и корю себя за то, что не пошел к нему, и не начал разбираться как же так получилось. Возможно, стоило вообще отказаться от выполнения поставленной задачи, ну или предложить условия, на которых это будет сделано. Но тогда случилось так, что я согласился на то, чего пока еще мало понимал. Тогда я постеснялся выразить свое недовольство и, молча, принялся доделывать и справлять чужую программу. Сейчас я вспоминаю это и в целом даже рад, что так получилось, ведь опыт, как говорится, не пропьешь.

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

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

Малой кровью это не обошлось: пришлось задерживаться, пришлось много раз прочитать документы, которые были написаны (хорошо, что они были), пришлось много раз прочитать чужой код и процентов на 80 в нем разобраться, пришлось разбираться с аппаратурой и ее особенностями (тем, кто работал с DC time и модулями Ethercat меня поймет).

Вот с чем мне пришлось иметь дело:

После того, как с горем пополам проект был доделан и прошел тестирование (я иногда удивляюсь как это так получилось) встала необходимость распространить ПО на устройства другого типа. И тут началась жесть... Мало того, что текущий код был плохим (очень хочется написать другое слово), так теперь его предстояло распространить на устройства другого типа. Это было сделано. Теперь программ с плохим кодом стало две, а позже 3. Они работали и все прошли выходное тестирование, но сопровождать это ПО и тем более отвечать на вопросы связанные с потенциальными багами было очень затруднительно.

Порядка 20 устройств уехало с данным ПО в разные места. Я и сам участвовал в наладке и запуске на нескольких объектах. На наладке были выявлены еще ряд моментов, которые требовалось обсудить и, возможно, на их основании внести изменения в ПО. Плюс наклевывался еще один заказчик, который хотел дополнительный выходной дискретный сигнал и дополнительный функционал. Эти изменения касались все трех видов ПО и в тот момент я подумал, что это шанс упускать нельзя. И тут я принялся за разработку новой архитектуры с учетом прошлых недочетов. Требования были простыми:

На текущий момент новое ПО находится в фазе окончательного тестирования. Баги, конечно были найдены, но их идентификация и исправление было намного проще, чем ранее. Полностью универсальное ПО получить не удастся, по крайней мере на текущий момент, но уже есть планы как это можно исправить. Потребление энергонезависимой памяти сокращено в 2 раза. Процентов на 80 повторяющийся код заменен на функции или функциональные блоки. Могу сказать, что теперь я доволен тем, что сделано.

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

В завершении хотелось бы отметить, что, возможно, я слишком драматизировал и зря переживал насчет старого программного обеспечения. Оно работало и прошло все выходные тесты. И, возможно, даже следовало бы вспомнить правило "Работает - не трогай!", но тут я был твердо уверен в том, что я хочу сделать. Как показал опыт, обслуживать три версии ПО, достаточно трудоемко. Мое мнение было и остается таким, что уж лучше потратить время на переработку и переписывание программы и сделать ее более понятной, менее избыточной в части повторения кода и, главное, в единственном экземпляре, нежели с ужасом вспоминать и разбираться в трех плохих программах при появлении вопросов или претензий от заказчика.

Закрывать глаза на плохой код нельзя, но можно призакрыть глаза на некоторое время, если этот плохой код является рабочим и программа выполняет все выходные тесты. Такую программу можно и нужно отправить заказчику, чтобы не затягивать сроки и она, скорее всего, даже может работать в течении длительного времени, но, при любом удобном случае, следует выделить время и учесть все недочеты, которые были выявлены и эффективно устранить их. Сделать программу понятной, универсальной, более простой это те принципы, которых я старался придерживаться при внесении изменений и думаю, что работу, которая я выполнил еще принесет свои плоды. Я также уверен в том, что практика написания плохого кода, с учетом его дальнейшего исправления - плохая практика, но, иногда, в силу определенных причин, так происходит.

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

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