Пришел, значит я на новое место работы Руководителем проекта внутренней автоматизации предприятия.
Мой предшественник уволился за день до этого по неизвестным мне причинам.
Стал я значит зазбираться с наследством........
Описание системы нет в принципе(ни ТЗ, ни описания БД, ни прочей проектной документации).
Мало того в БД вообще царит хаус. Есть таблицы, которые вообще не используються, есть которые дублирують, есть таблицы без первичных ключей. Такое чувство, что понятие внешних ключей вообще не в природе. В таблицах есть Код клиента(ссылка на клиентов), а внешнего ключа нет и т.п. Про индексы я и говорить не хочу.
Клиент это отдельная история до него еще руки не дошли(Что там классов нет я это сразу понял).
Мой предшественник работал в этой фирме на данной позии лет 5-8, соответственно он очень нравиться боссу, да и система каким то образом работает с минимальными ошибками.
Как мне сказать начальству, что это в принципе не работоспособная система и требует разработки ее заново, а не залатывание ошибок старой системы. К слову сказать можно и приобрести уже имеющиеся системы.
Тут еще мне кажется, что своими силами(помимо меня еще два человека на проете) врятли обойтись и надо брать хотя бы одного.
Как мне довести до босса(не специалист в ИТ), что это все необходимо, когда босс высоко убежден в компетентности моего предшественника.
Переписывать с нуля большой работающий (!) проект — гнилое дело. Ни к чему хорошему это не приведёт. Тем более тяжело будет объяснить боссу, что он должен платить тебе за то, чтобы ты сделал из работающей системы другую точно такую же по функциям работающую систему. Конечно, первая мысль "переписать всё на ...", но в таком случае лучше прикинуть сроки и успокоиться
Я в аналогичных ситуациях стараюсь хотя бы рефакторить систему маленькими кусочками (в которых приходится добавлять/менять функциональность) и писать доки по тому, до чего руки доходят. Но — не забывая о том, что вылизывание архитектуры/кода и прочие внутренние усовершенствования вряд ли увеличат доходы от проекта.
Здравствуйте, banderlog, Вы писали:
B>Мой предшественник работал в этой фирме на данной позии лет 5-8, соответственно он очень нравиться боссу, да и система каким то образом работает с минимальными ошибками. B>Как мне сказать начальству, что это в принципе не работоспособная система и требует разработки ее заново, а не залатывание ошибок старой системы.
Лучше такого не говорить, постольку система все-таки работает. То, что каждый новый работник считает себя умнее предшественника, и так всем известно. Лучше выбрать другой подход — сказать, что система разрабатывалась давно, число доработок/изменений системы достигло критического уровня, и сейчас, с приходом нового руководителя, настал хороший момент для редизайна всей системы. При этом скорее всего придется некоторое время наряду с разработкой новой системы латать старую.
B>К слову сказать можно и приобрести уже имеющиеся системы.
Тут потребуется экономическое обоснование. Также встанет вопрос о необходимости имеющихся специалистов.
B>Тут еще мне кажется, что своими силами(помимо меня еще два человека на проете) врятли обойтись и надо брать хотя бы одного. B>Как мне довести до босса(не специалист в ИТ), что это все необходимо, когда босс высоко убежден в компетентности моего предшественника.
Для босса это будет выглядеть так, что он потерял очень ценного сотрудника, вместо которого приходится брать двух новых (и один из них явно тупее ушедшего работника).
Здравствуйте, banderlog, Вы писали:
B>Как мне довести до босса(не специалист в ИТ), что это все необходимо, когда босс высоко убежден в компетентности моего предшественника.
А с чего ты взял, что он не был компетентным?
Вполне возможно, он смог сделать лучшее, что было возможно на том фундаменте, что достался ему.
тем более, что работает все с минимальными ошибками.
Посему если пойдешь к боссу разговаривать, ни в коем случае не ругай предшественника, лучше, наоборот, похвали за то, что он был способен так долго поддерживать эту систему в рабочем состоянии.
А дальше потихоньку перейди на тему того, что сейчас в этой системы есть проблемы, не позволяющие ее быстро расширять, если изменятся требования, и т.п., т.е. то, что значимо для босса.
И лучше это делать не в один прием, а исподволь, встречаясь в коридорах/за обедом, а финальный разговор отложить на момент, когда босс будет готов вынести положительное решение
Возможно стоит постепенно внушать боссу идею о новой версии (2.0) !!
Но только постепенно и сформулировав как миниму 10 аргументов на "nonIT-Languge".
Типа "сроки внесения изменения функциональности" в версии 2.0 будут в 4 раза меньше.
"Скорость работы приложения" — возростёт в 2 раза.
"Ипользование новых версий средств разработки" сократит срок разработки и последующей модификации приложения.
"Интеграция с такими-то системами и импорт туда-то туда-то в такой-то формат" — в данной версии приложения не возможен или такая модернизация займёт время сопоставимое со сроком разработки 2.0
В принципе, то что код и база — помойка только наша (разработчиков) проблема. Для начальства это проблема подобна тому, что у разработчика неудобный стул или медленый старый компьютер.
While (!Life.EOF){
You.Money ++;
You.Girls.Add(new Girl(90,60,90));
BeHappy();
}
Была подобная ситуация, правда там было чуть попроще, потому что старая система была в принципе несовместима с новыми задачами. По архитектуре.
А идти к боссу и говорить о том, что систему нужно переписывать — рано. Вначале нужно сделать рефакторинг того что есть с малыми добавлениями нужной функциональности. Скоро (довольно быстро) из системы можно будет выкидывать старые куски по причине их дублирования новой логикой. На этом этапе я подошел к своему заказчику и предложил кое что добавить в выходных результатах (ему то до фонаря, что там внутри, ему отчеты важны). А спустя неделю где-то для ускорения процесса было предложено переписать ядро системы. В общем то шефа надо любить и не заставлять его думать над предметами, лежащими ниже его уровня компетентности. Так и в этом случае. Он видит что система работает и будет работать. А через два месяца он получил нормальную функциональность. И все довольны. Веключая старого разработчика.
- Простите, профессор, не пса, а когда он уже был человеком.
— То-есть он говорил? Это еще не значит быть человеком. (с) Булгаков
Хехе, поздравляю ! Я был в похожей ситуации. Только в роли того кто только что ущел Ж) Но я конечно не так сволочно поступил, а нашел последователя и обрисовал ему в общих чертах. А начальству сказал что система хоть и рабочая, но требует "доработок", которые я не успел сделать (когда я ее делал я не знал что такое транзакция !).
А вообще, я не советую хаять систему. А просто доделывать все к ней молча что потребуют. Спросят почему долго так — скажешь что дело не быстрое, это не было запланировано в системе.
А если ничего не потребуют НИЧЕГО НЕ ДЕЛАЙ. Придумывать себе работу ты не обязан.
B>Описание системы нет в принципе(ни ТЗ, ни описания БД, ни прочей проектной документации).
Если это не контора, занимающася разработкой ПО, то такое просходит в 99% случаев, если автоматизацию писали местные программисты.
Ведь разве кто-то любит писать документацию? -))
B>Мало того в БД вообще царит хаус. B>система каким то образом работает с минимальными ошибками.
т.е. система все-таки рабочая...
B>Как мне сказать начальству, что это в принципе не работоспособная система и требует разработки ее заново, а не залатывание ошибок старой системы. B>К слову сказать можно и приобрести уже имеющиеся системы.
Нужно представить план, что лучше переписать заново, чем поддерживать существующую:
1.Укажи время, которое требуется для поддержки существующей программы.
2.Оцени время реализации в ней добавляемого функционала.
3.Укажи время + деньги, которые будут затрачены на разработку нового софта.
4.Опиши подробно достоинства и недостатки каждого(!) подхода. Ведь и у разработки с нуля есть свои минусы (мы ведь не обманываем работодателя? )
B>Тут еще мне кажется, что своими силами(помимо меня еще два человека на проете) врятли обойтись и надо брать хотя бы одного.
Здравствуйте, banderlog, Вы писали:
Ха, это ещё что. Я поддерживаю подобную систему, только её разработчик никуда не уволился, спокойно работает и является моим начальником.
Держись, мы вместе!
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, banderlog, Вы писали: B>Ха, это ещё что. Я поддерживаю подобную систему, только её разработчик никуда не уволился, спокойно работает и является моим начальником.
В аналогичной ситуации нахожусь сейчас и я. При этом начальник отлично разбирается в том, что нужно делать, по каким технологиям, умеет вести переговоры с заказчиком, выяснить, чего хочет заказчик на самом деле и т. д. Но иногда он садится это реализовывать сам. Тогда у команды начинаются сложности. Правда, сейчас все реже и реже. В старом коде еще много мест, в которые мне просто страшно залезать. А еще бывает, что он поправит что-нибудь где-то в моей функции, а я потом долго ищу, почему она портит лишнюю пару глобальных переменных.
Здравствуйте, Privalov, Вы писали: >> А еще бывает, что он поправит что-нибудь где-то в моей функции, а я потом долго ищу, почему она портит лишнюю пару глобальных переменных. http://subversion.tigris.org/
Если бы жизь не менялась постоянно, а изменения одной части программы не касались всего остального (а раз тут нет декомпозиции вообще, то такое более чем реально), то это правило верно только до поры до времени...а именно до того момента как надо будет внести дополнение в функционал..и тут-то можно будет получить весь букет...с одного конца потянул вылезло еще в трех...и на стабилизацию угробишь кучу времени.
Более того, тот факт что все работает скорее всего определен пользователями по основным функциям и совсем не означает что система работает по всему заявленному функциналу как надо.
Если при разработке системы автор не знал о необходимости первычных ключей в базе, то с какой стати он реализовал правильно все алгоритмы? Если конечно это не самородок какой, которого просто забыли научить и он всему учился сам, но скорее всего это человек, который просто нахватался верхов и попал в нужное время в поле зрения руководства.
Привет, banderlog.
Вспомнилась мне народная мудрость: "лучшее — враг хорошего".
B> система каким то образом работает с минимальными ошибками.
Вот это и есть самое ценное. Для любого человека не-разработчика система есть чёрный ящик, который делает что-то полезное. И если работа делается хорошо, то проблем нет. Если же есть грабли вроде того, что "производительность не устраивает", то самым правильным/дешёвым решением будет докупить железа, а софт оставить старым. Хуже если от тебя требуют расширять функциональность системы. Взамен кусочного рефакторинга (или параллельно ему) могу посоветовать "обернуть" то что есть в код с удобоваримым API и дальше развивать софт уже по новым правилам.
Почему добро всегда побеждает зло? Потому что историю пишут победители.
Здравствуйте, valmond, Вы писали:
RST>> работает — не трогай!
V>Если бы жизь не менялась постоянно, а изменения одной части программы не касались всего остального (а раз тут нет декомпозиции вообще, то такое более чем реально), то это правило верно только до поры до времени...а именно до того момента как надо будет внести дополнение в функционал..и тут-то можно будет получить весь букет...с одного конца потянул вылезло еще в трех...и на стабилизацию угробишь кучу времени.
V>Более того, тот факт что все работает скорее всего определен пользователями по основным функциям и совсем не означает что система работает по всему заявленному функциналу как надо.
V>Если при разработке системы автор не знал о необходимости первычных ключей в базе, то с какой стати он реализовал правильно все алгоритмы? Если конечно это не самородок какой, которого просто забыли научить и он всему учился сам, но скорее всего это человек, который просто нахватался верхов и попал в нужное время в поле зрения руководства.
Один из моих клиентов (а точнее админ его) предложил мой софт реализации алгоритма RSA переделать в библиотеку и подключить к PHP или перлу уже не помню. До этого он был просто standalone executable. Хотел, чтоб был красивый код, и все выглядело solid и было быстро.
Аргументация с моей стороны была следующая :
1) Время на реализацию задачи.
2) Время на тестирование (мой код успешно и без модификаций работает уже больше двух лет).
В результате оба сошлись на мнении, что намного дешевле при проблемах с перформансом просто арендовать ещё один сервер. Учитывая, что это компонент mission-critical системы — это наиболее грамотный выход из задачи — пол дня простоя сервера из-за кривого RSA обойдутся дороже, чем арендовать ещё один сервер на год.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, RST_Angellab, Вы писали:
RST>>http://subversion.tigris.org/
P>И что дальше? Знает он о таких вещах.
Я к тому, что subversion помогает быстро определить кто-где напакостил. не зря же я квотировал вот этот кусок :
">> А еще бывает, что он поправит что-нибудь где-то в моей функции, а я потом долго ищу, почему она портит лишнюю пару глобальных переменных. "
RST>Хотел, чтоб был красивый код, и все выглядело solid и было быстро.
Я о чем говорил? О том, что делать если надо вносить изменения/дополнения.
Вопрос о быстродействии другой совсем.
Все работает правильно и ничего менятьне надо это одно, а если что-то рабботает правильно, а что-то непонятно рабтает или нет это другое...да еще и "вдруг" надо будет прикрутить еще чего-то, совсем не решается вторым-десятым сервером.
