×Закрыть

Старый ящик — новый ящик, белый ящик — черный ящик. Теорвер или эзотерика?

Условия задачи:
Есть программная система разработанная в течении многих лет разными разработчиками. Несколько месяцев назад она была развернута и как-то работала на серверах (по крайней мере это утверждает клиент). После этого была продана клиенту, который пришел с ней к украинским мастерам для того, что бы они ее наладили и «допилили».

Результаты анализа:
Документация — отсутствует. Люди, обладающие знанием о системе — недоступны. Клиент систему в работе видел только несколько раз и понимания как она работала не имеет (вместо этого у него есть представление что в ней уже есть все готовое что бы воплотить его самые безумные фантазии). Единственный источник данных о системе — это исходный код. Для некоторых модулей неизвестного происхождения исходный код отсутствует и они подключаются в виде скомпилированных библиотек. Количество модулей велико, их интерфейсы и взаимодействие нигде не описаны.

Исходный код написан разными людьми в разное время. Общей архитектуры, практик и соглашений по дизайну, именованию, оформлению кода не прослеживается. Часть кода содержит явные ошибки и очевидно является «мертвой», либо ошибки не влияли на конечный результат. Распространенной практикой является подавление любых ошибок внутри метода без логирования и возврат результата «по умолчанию» (NULL, 0, −1). Часть кода закомментирована, во многих местах присутствуют комментарии из которых можно понять что это «заплатка», временное решение либо девелопер не мог понять что делает код написанный другим (и написал что-то вроде «не знаю зачем Вася это здесь вызывает но оставлю на всякий случай»). В коде очень большая косвенность (классы вызывают друг-друга по многу раз даже для выполнения простых задач), много «предположений» построенных на совпадении имен или идентификаторов, активно используется динамическое связывание и «рефлексия». Так же присутствуют меж-потоковые и меж-процессные вызовы разного вида (как по сети так и «локальные») что усложняет дебагинг.

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

Это было описание «старого ящика», который нам отдал клиент.

Цель: клиент хочет от нас починить и развернуть систему в рабочем состоянии. После этого «сконфигурировать» ее что бы она реализовала видение клиента. У клиента есть мнение что это не сложная задача (ведь система «рабочая»), с которой профессионалы могут справится очень быстро.

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

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

Сейчас стоит проблема выбора стратегии поисков. Все возможные стратегии делятся на метод «черного ящика» — когда мы не смотрим в код, и метод «белого ящика» — когда смотрим.

А) Черный ящик

А.1) Слепой перебор. Пробуем развернуть на «голом» сервере «как есть», запускаем тесты, если не сработало то что-то меняем.
Плюсы:
— Если составить все возможные значения настроек и перебирать все комбинации без пропуска то риск пропустить правильную довольно низкий.
— Время проверки известно как известно и число комбинаций поэтому можно оценить общее время и прогресс задачи.
— Не требует больших знаний от исполнителей — можно посадить много людей перебирать свой набор настроек.
Минусы:
— Время перебора всех комбинаций огромно (десятки тысяч часов).
— Вероятность угадать правильную комбинацию не зависит от времени (она может оказаться последней).

А.2) Направленный перебор. Делаем предположение о наиболее разумном наборе настроек, проверяем, анализируем ошибки, меняем предположение, проверяем опять.
Плюсы:
— Поскольку первыми пробуем наиболее логичные комбинации, то вероятность угадать раньше повышается.
Минусы:
— Зависит от знаний и интуиции исполнителей.
— Сложно распаралелить работу и непонятно насколько это ускорит процесс.
— Невозможно заранее предсказать сроки получения результата и невозможно отслеживать прогресс.
— Есть риск пропустить правильную комбинацию разминувшись с ней всего в одной настройке.

Б) Белый ящик

Б.1) Полный анализ кода. Изучить весь код, разобраться как он работает, пройти дебагом все основные маршруты, нарисовать схемы, все документировать и т.д.
Плюсы:
— Гарантированное получение результата и возможности исправлять проблемы.
Минусы:
— Исключает вероятность случайной удачи.
— Время изучения кода велико (тысячи часов). Превосходит время разработки подобной системы «с нуля».
— Процесс изучения нелинейный и тяжело отслеживать прогресс.
— Зависит от квалификации девелоперов.
— При уходе девелопера часть знаний будет неизбежно потерянна.
— Сложно распаралелить работу и непонятно насколько это ускорит процесс.

Б.2) Частичный анализ кода. Изучение кода, построение гипотезы как он работает, проведение экспериментов, корректировка гипотезы.
Плюсы:
— Совмещает накопление знаний о системе с вероятностью случайной удачи.
— Есть вероятность что потребует меньше времени, чем изучение всего кода и чем перебор вариантов.
Минусы:
— Гипотезы могут быть ложными а понимание кода — неполным.
— Процесс изучения нелинейный и тяжело отслеживать прогресс.
— Зависит от квалификации девелоперов.
— Сложно распаралелить работу и непонятно насколько это ускорит процесс.

В) Новый ящик
Как особую стратегию необходимо так же учесть вариант «нового ящика». Вместо работы со старой системой начать строительство новой «с нуля» и постепенно реализовать в ней все ожидания клиента.
Плюсы:
— Полный контроль над ходом проекта и результатами.
— Возможность быстро находить и исправлять проблемы а так же вносить изменения.
— Использование современных библиотек и компонентов ускоряет разработку.
— Можно распаралелить работу.
— Промежуточные результаты видны клиенту.
— Можно добавить функциональность, которая отсутсвовала в старой системе.
Минусы:
— Исключает вероятность случайной удачи. Новая система не заработает пока не будет готова.
— Единственным источником информации о том, что должна делать система является клиент.
— Время разработки системы «с нуля» значительное (около тысячи часов). Оно зависит от изменений требований.

Очевидно, что в последнее время клиенты не рискуют отдавать на разработку в Украину новые масштабные проекты. Поэтому «лидеры рынка» все чаще с радостью берут старые, гнилые проекты на «бесконечный ремонт и перекраску». Или продают своих сотрудников в международные команды таких проектов. Куда набирают команду из принципа: не прибыльный проект, но закрывать жалко — наберем со всего мира кого подешевле: авось что-то сделают. В наших условиях вариант «не соглашаться с клиентом» и менеджеры даже не рассматривают — ведь местных менеджеров в европах никто не ждет, в отличии от девелоперов.

Вопросы к тем, кто сталкивался с подобным «старым ящиком»:
— Какую стратегию выбирали?
— Чье это было решение: команды, менеджера, клиента?
— Делали ли ставку на удачу: поковыряем — и вдруг сразу заведется?
— Или ныряли в пучины спагетти-кода?
— А может втихаря делали новую версию «с нуля» что бы потом удивить клиента?
— Какая текучка кадров при разной стратегии: сколько спивается от бесполезных попыток или сходит с ума от дебага кода?

И, наконец, самый главный вопрос — вопрос Веры! Можно верить в науку и теорию вероятности. Но после многих дней бесплодных попыток днем и ночью (каждая попытка занимает время и надо ждать), после крушения сотен логичных предположений, после неоднократных блужданий в коде, который на проверку оказывался мертвым, моя вера в науку и здравый смысл начинает истончаться. В конце-концов та же наука не исключает возможность удачи или даже чуда при самой низкой вероятности события. Может есть возможность как-то повлиять: найти удачливого девелопера, положить подкову на сервер, пригласить гадалку, экстрасенса или батюшку? Что если математическое ожидание количества попыток давно пройдено — а результата все нет? Может это «бес водит» или кто-то сглазил? Что делать?

Я знаю что на ДОУ есть верующие девелоперы: скажите, есть примеры когда искренняя молитва помогала запустить приложение? Практикуете ли вы иконы, свечи, часовню, церковные службы в офисе?

Или может есть увлекающиеся эзотерикой: помогают ли гороскопы, имеет ли смысл переставить сервера по фен-шую, можно ли сделать «снимок ауры» и отследить потоки негативной энергии или геопатогенные зоны в офисе?

Ну и напоследок: есть ли у вас в компании штатный психолог, который помогает тем, у кого уже начинает съезжать крыша от такой работы?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Это все проекты на .NET нынче такие?

Это было в 2015...
Нынче ситуация с .Net намного лучше. Наконец-то «выстрелил» новый .Net Core. И, учитывая какой-то застой в Java, он набирает обороты.
А вот с проектами проблема все та же. Новый модный проект на передовых технологиях — это обычно стартап. Ну или что-то небольшое для бизнеса. Т.е. это проекты априори не дорогие и не слишком масштабные — поэтому за них много не платят.
Много платят за большой старый энтерпрайз. ASP.Net веб-формы, XML, WCF — сервисы, огромные реляционные базы с проками — все как было модно 5 — 10 лет назад, когда это писали.
Поэтому для новых проектов синьоры не нужны — слишком дорого они стоят, а серьезных проблем-то на новом проекте еще нет (кроме налабать побыстрее). Синьоров охотно берут на проблемные проекты — там где надо разгребать мутный говнокод, где скомпилить проект — это уже члендж на полдня, где джуны просто не понимают что делать. Потому что джунов учат модному MVC, а не интеграции дотнета с COM+, не AJAX путем вcтавления IFRAME и не табличной верстке.

То есть два мира вырисовывается:

Первый — старые, неповоротливые проекты со спагетти-кодом, несовременными технологиями и унынием

Второй — новые и свежие проекты, не такие длительные и стабильные, но работать на них хорошо, если чайка-менеджеры не испоганят.

Переход из первого мира во второй нелегко осуществить, из второго в первый — запросто, достаточно отключить бдительность или торопиться с выбором проекта.

Где сосредоточен второй мир, что это за компании и как туда попасть?

Немного перепутал: переход из старого мира в новый осуществить легко!
Я для разминки бывало прикидывал как можно переписать какой-нибудь старый кусок на новых технологиях. Получается очень быстро и красиво! Интерфейсы и IOC контейнеры решают массу проблем (например с тестами), многие костыли, которые лепили, например, для динамического обновления теперь решаются «из коробки» через микросервисы, биндинг и SygnalR...
Т.е. написать такой-же проект «с нуля» на .Net Core было бы быстрее раз в 5. НО — для этого нужно точно знать как работает старый! И вот тут самая главная проблема любого гнилого энтерпрайза — он «работает как работает». Т.е. никто не знает как правильно! Но при любых изменениях все должно работать как раньше.
Поэтому перейти из «нового мира» в старый — очень сложно! Молодежь, которая имела опыт делать новые проекты, зачастую отсеивается на банальном: у них не получается старый проект скомпилировать и развернуть локально!
Потому что новый стянул из репы, открыл у Студии — и все сбилдилось и запустилось. А в старом все билдится кучерявыми скриптами, везде прописаны абсолютные пути и т.д. А когда сбилдил — нужно понимать как настроить MSSQL, IIS, пермишены в AD и еще 100500 мелочей и нюансов.
Опытный синьор, который в этой жизни хлебнул говнеца, уже только по виду ошибки может понять куда копать: то ли в реестре чего не хватает, то ли ком не зареган, то ли пермишины нужны. Но молодые-то ошибки видеть не привыкли! На новых проектах тяп-ляп и в продакшин — глубоко дебажить некогда.
Поэтому и платят синьорам большие деньги: потому что найти таких динозавров с 10+ летним опытом разгребания проблем — непросто. Еще и платить им нужно намного больше, чем на новых проектах — в говно нырять за мелкий прайс никто не хочет!
23х летние синьоры может и хотели бы за большую зарплату грести говна — но они просто не разберутся. Все-таки опыт в книжках не вычитать.

Потому что джунов учат модному MVC

MVC уже давно не модный, модно уже миркосевисы, причем не так недавно уже.

интеграции дотнета с COM+, не AJAX путем вcтавления IFRAME и не табличной верстке

Таким молодых уже не запугать, тупо не знают. Ты бы стэк обновил толе?

Я кстати не понимаю, почему он не обновил.
На этих же технологиях можно превратиться в gamepedia.cursecdn.com/...​x-Moss_Elemental_full.jpg
У Бобра нет своры детей, которые требуют внимания так, что не выделишь время на самообучение, нет бестолковой пилючей жены (хотя в восточной Украине женщины ещё в целом нормальные, и какие-то лёгкие).
Сиди себе хочешь пень пинай, хочешь — некоммерческий проект делай.

Может Харьков настолько затхлый и убивает душу в людях?

Я кстати не понимаю, почему он не обновил.

Вы про список технологий в профиле на ДОУ? Так я новую работу не ищу — зачем обновлять? Какой был когда регался — такой и остался. У меня даже линкедын когда-то был — но теперь даже пароль не помню.

Сиди себе хочешь пень пинай, хочешь — некоммерческий проект делай.

Если кому интересно — то да, для себя смотрю .Net Core, щупаю Blazor, надеюсь что в будущем можно будет все (фронт, бэк, мобаил) писать на C# и не вспоминать про JavaScript.

Может Харьков настолько затхлый и убивает душу в людях?

Есть такое. А работа крепко убивает желание вообще что-то педалить дома. Так что самообучение на выходных, а будние дни — считай вычеркнуты их жизни. Работа — дом, тупо что-то посмотреть/почитать развлекательное — сон и опять работа.

Дядя, вот объясни, ты мазохист? Не устраивает тебя работа- поменяй. Зачем терпеть то?

Не опоздал. Такие персонажи с таких работ не вылезают. Так что до сих пор актуально.

До сих пор актуально. Но не только потому, что я не вылезаю с «таких» работ.
А скорее потому что именно на «такие» работы и берут синьоров вроде меня!
Так что тут нет выбора: писать новый проект с нуля на передовых технологиях или сапортить легаси энтерпрайз.
Это просто вопрос масштаба и рисков: что бы написать новый сайтец или аппликушечку за год — не нужен синьор! Тут негде и некогда вникать в предметную область, проектировать архитектуру, продумывать масштабируемость, писать код, который потом легко развивать много лет. Это все не нужно! Нужно «тяп-ляп и в продакшин».
А вот большие проекты «с нуля» объемом в несколько лет и сроком жизни хотя бы десять лет — никто в Украину не отдаст! Да и никакая украинская ИТ компания не возьмет на себя ответственность написать такое. На таком проекте только фаза планирования и проектирования будет идти несколько месяцев — а как дойдет до реализации уже может все поменяться. Слишком большой риск для серьезных проектов.
Другое дело — отдать в Украину «старую лошадь» в виде прогнившего энтрепрайза, который еще жалко выкинуть но и тянуть уже тяжело. Таких монстров, написанных в эпоху рассвета доткомов и автоматизации документооборота осталось полно. А для наших «галер», которые не хотят делать проекты (это ответственность за результат!), а хотят только перепродавать рабов — это «золотое дно». Продал команду — и она сидит и что-то ковыряет много лет. А денежки капают.
Не понравился проект — менять компанию? А если в новой то же окажется не лучше? Так придется 10 раз уволиться пока найдешь хороший проект. А через два года он успешно закончится. Потому что хорошие проекты раньше или позже заканчиваются (в отличии от «бесконечных» сапортных). И что — опять бегать по компаниям и выбирать? Как-то возраст уже не тот что бы так часто работу менять.

Так что тут нет выбора: писать новый проект с нуля на передовых технологиях или сапортить легаси энтерпрайз.
Это просто вопрос масштаба и рисков: что бы написать новый сайтец или аппликушечку за год — не нужен синьор! Тут негде и некогда вникать в предметную область, проектировать архитектуру, продумывать масштабируемость, писать код, который потом легко развивать много лет. Это все не нужно! Нужно «тяп-ляп и в продакшин».
это очень субъективное мнение, на самом деле все не так плохо, проекты не делятся на клевые веселые для новичков и унылое говно для старичков
Как-то возраст уже не тот что бы так часто работу менять.
что-то мне подсказывает что когда возраст был тот, то ты тоже не бегал, а теперь оправдание это клевое придумал
Не понравился проект — менять компанию?
Да
А если в новой то же окажется не лучше? Так придется 10 раз уволиться пока найдешь хороший проект.
Можно спрашивать. Говорить, если заявленное не соответствует реальному — уволюсь.
Как-то возраст уже не тот что бы так часто работу менять.
Мыши плакали, кололись но продолжали жрать кактус©. Дядя, чего ты боишься? Что тебя перестанут брать на работу в говнопроекты? Или что денег не будет? Так ты вроде сам сказал, что денег у тебя накоплено лет на 10 жизни?

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

история чем-то закончилась?

Уже год прошел — как быстро время бежит!
Ничем хорошим, естественно, этот проект не закончился. За несколько месяцев удалось что-то поднять ценой очередного увеличения количества седых волос на моей голове.
Естественно, этот зомби оказался совсем не тем, о чем мечтал клиент. В итоге еще с полгода мы подпирали мертвую лошадь что бы стояла как живая и красили что бы выглядела как новая. Все это было медленно, печально и очень криво. Клиент, естественно был не в восторге.
За это время успела частично поменяться команда, поменялся менеджер, поменялись люди на стороне клиента...
Насколько я понял в итоге пошли какие-то политические игры: то ли клиент кому-то продался, то ли у него поменялись начальники, то ли ему окончательно надоел наш «сервис» (по галерным рейтам), то ли галера рассчитывала развести клиента на большее, а когда не вышло — потеряла интерес.
Как бы то ни было пару месяцев назад проект окончательно сдох. Часть людей разбежалась, другую распихали на другие проекты.
Новых проектов на Дотнет сейчас нет совсем. Хрен его знает, почему. Может новые проекты принципиально не отдают в Украину (а тем более в прифронтовой Харьков), может галере интереснее брать большие старые проекты, чем небольшие новые, может дотнет сейчас не в моде а все хотят жабаскрипт.
Как бы то ни было меня перепродали в аутстаф другому заморскому клиенту. С одной стороны — компания с именем из топ 10 в Долине. Но с другой — проект все такой же старый легаси-энтерпрайз. Не такое ужасное говнище, как было — но и до правильных практик далеко.
Одно радует — нормальный менеджер. Который трезво оценивает уровень говености проекта и не ожидает что девелоперы в овертайм слепят из него конфетку.

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

И вообще, вы рассказываете невероятно интересно. Вы блог не ведёте? Где вас вообще можно почитать, кроме как в комментариях на DOU?

Я теперь как-то чаще пишу на «уютненьком ит» — там не ущемляют анонимов
dou.ua/forums/topic/16653
Зачем мне блог?
Делиться техническими знаниями? Так тут я ничего нового не придумаю — все правильные методики, практики, алгоритмы уже 100500 раз описаны, разжеваны и переложены на видео и подкасты. Кто ищет как сделать правильно — найдет в момент. Жаль что мало кому это сейчас надо.
Делиться опытом? Ну так опыт словами не передать. Кому надо — тот подходит на работе и спрашивает — я и расскажу и покажу. Иногда просят совета бывшие коллеги — тут уже немного сложнее. Что бы подсказать по делу — надо вникнуть в ситуацию: мудрые советы «с высоты моего опыта» (читай — с потолка) пользы не принесут.
Ну а если писать «за жизнь» — то это будет не блог, а какая-то tlenta.ru . Депрессия мой спутник на протяжении многих лет — с тех самых пор, как я понял что «девчонки полюбили не меня ...». Собственно «погружение ИТ» — это и была моя альтернатива суициду от несчастной любви в подростковом возрасте. Этакое «медленное самоубийство» длинной в жизнь.

Я теперь как-то чаще пишу на «уютненьком ит» — там не ущемляют анонимов
Замена ваших комментариев на комментарии спамеров с подтверждёнными аккаунтами — неравноценна. И объяснение администрации, что кому-то может быть необходимо знать реальное имя собеседника в интернете, чтобы определить достоин ли он общения, довольно странное, как по мне.
Зачем мне блог?
Вы хорошо пишете, вот я и подумала, что такой талант должен где-то реализовываться. Но если не чувствуете необходимости в блоге, то вести его действительно незачем.

Мне кажется тут основная проблема это заказчик, считающий задачу простой и подгоняющий процесс и тем самым нагнетающий стресс. Советую вам как-то помягше обьяснить ему, что исходя из вашей профессиональной оценки задача пока крайне сложна и труднопрогнозируема. Что нужно больше времени. Что спешка в этом деле — зло. А потом советовал бы смешать способы черного и белого ящиков, разделить задачи на мелкие этапы и делать, сообщая заказчику о каждом выполненном этапе.
Был сам в еще худшем положении — не было даже тестов, предыдущие разработчики, коих было как я понял более десятка на протяжении нескольких лет испарились. Меня поставили ОДНОГО разбираться со всем этим. Единственное что — система запустилась довольно легко. Но имела кучу багов и такого же нетерпеливого клиента (то что любому программисту нужно время на осваивание в коде ему было непонятно). Вообщем я пофиксил там с десяток багов подгоняемый обвинениями в медлительности и некомпетентности и нашел другую работу.
Были и еще случаи... Сейчас опять работаю над легаси проектом без тестов, документации и связи с предыдущим разработчиком (это видно карма). Но в этот раз все гораздо проще, проект не слишком объемный, написан приемлемо только одним разработчиком, клиент (тьху-тьху) пока не сильно торопит. Да и получается реализовывать новые фичи относительно быстро, не смотря на то, что многое приходится рефакторить/переписывать.

Советую вам как-то помягше обьяснить ему, что исходя из вашей профессиональной оценки задача пока крайне сложна и труднопрогнозируема. Что нужно больше времени.
Это язык девелоперов — не бизнеса. Сказать такое заказчику никто не позволит — а если и позволят, то он не поймет.
Представьте что Вы купили подержанную машину. Через пару дней она не заводится. Привезли на техсервис и говорите «почините». А мастер начинает рассказывать что «это сложная и труднопрогнозируемая задача», «даже не знаю сколько это времени займет», «вы пока заплатите за первый месяц — мы поковыряем, но гарантии что поедет не даем». Вы лично готовы несколько месяцев платить за «может быть сделаем»?
Вот и бизнесмен никогда не будет платить за «кота в мешке». Менеджер должен назвать сроки и цену — хотя бы с потолка для начала. Потом уже будет торговля за «нужно больше времени», «вы не сделали — не буду платить», «доделывайте бесплатно», «платите неустойку» и т.д.
Таким образом любой ИТ проект, который доходит до девелопера уже имеет какие-то обещания заказчику. Эти обещания давят на менеджера — а он, соответственно, давит девелоперов. Если не успевают — втык то же идет «сверху-вниз»: заказчик отказывается платить, топ-менеджмент ругает или выгоняет ПМа, девелоперов наклоняют «доделывать» бесплатно в овертайм. Девелоперов выгонять жалко — но для примера могут найти «крайнего» и показательно «опустить».
Огромная беда бодишопов — это модель когда клиент платит за девелоперов. Т.е. не только сроки проекта фиксированы (сайлз уже наобещал клиенту все «на вчера»), но и ресурсы фиксированы (команду нельзя увеличить). Вот и получается что вытаскивают прежде всего за счет экономии на качестве и «добровольно — принудительных» овертаймах. Ну и аджайл помогает хотя-бы немного пожертвовать фичерами (скопом).
ru.wikipedia.org/...ойственная_ограниченность
Выходит клиент платит не за результат — а за работу. Ну и получает в итоге вместо конфетки большую кучу «отработанного материала».

Вы не дочитали —

А потом советовал бы смешать способы черного и белого ящиков, разделить задачи на мелкие этапы и делать, сообщая заказчику о каждом выполненном этапе.
. Наверно мне следовало написать несколько иначе: Сначала оценить и разбить на мелкие этапы, а потом говорить заказчику что исходя из вашей профессиональной оценки нужно больше времени, сначала нужно поднять тесты, а потом уже заниматься функционалом.
Если брать аналогию, то это как если бы клиент привез свою машину залитую в глыбе бетона и говорит, что она почти рабочая, в ней только что-то сломалось... Ну и еще этот бетон... Вы же должны обьяснить ему, что прежде чем оценивать величину поломки, нужно ювелирно, не поцарапав машину снять весь этот бетон. Вы готовы сообщать заказчику о каждом освобожденном участке машины, и по мере ее освобождения оценивать новые участки и, наконец, собственно неисправность.
Обещания сейлзов «все на вчера» можно смело игнорировать — на то они и сейлзы, чтоб продавать. Оценку делают только эксперты — тоесть вы. А овертаймы ИМХО вредят не меньше чем помогают.

Логичный подход. Только заказчику его объяснять бесполезно: он человек не технический и ему пофиг где бетон, а где металл — ему надо что бы ездило. А промежуточные результаты — не интересуют.
Поэтому с ним работает опытный менеджер: он умеет наплести лапши, а если вдруг что-то удалось оживить — преподнести как грандиозный прорыв и пообещать что уже «вот-вот», только дай еще немного времени (а значит — заплати бабла).
На оценки девелоперов менеджеру плевать — ему платят не за то, что бы все заработало, а что бы клиент платил подольше. В целом это типичный бодишоповский сценарий «грандиозные похороны мертвой лошади». Примерно как спасение безнадежно больного: пока есть деньги ему не дадут умереть.

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

Есть очень хреновый кейс как для команды(в плане мотивации) так и для компании(в плане потери репутации и клиента). Если после всех попыток оживить хоть что то, оживить не удастся ничего. И клиент начнет наезжать уже на вас мол вы некомпетентные а как вы уже писали заказчик не особо то и разберается в технических вопросах и плюс искрене верит что у него «полностью рабочая» система которой требуется «небольшая» корректировка.
Вам опреленно нужно пообщшаться со всей тимой что они думают по этому поводу.
И конечно же как то решить это с вашим менеджером.
В любом случае, удачи вам и да поможет вам Бог, и все вселенские силы!

Создайте 2 команды. Одна — создает новое, вторая — исследует старое. Та, которая исследует старое может помочь новой какими-то идеями. Что то же может работать в старом проекте

Создайте 2 команды. Одна — создает новое, вторая — исследует старое.
И получите конфликт на пустом месте. Одна команда будет делать что-то новое, другая разребать говны мамонтов. Закончится тем, что одна ничего не создаст, другая вся убежит, ибо в говне копаться никому не нравиться.

Ну делать же что то надо :) Автору и нужно придумать, как эти 2 команды сплотить ради единого результата. Команда старого направления по логике будет в более нормальном положении, т. к. они могут: 1) сделать сами результат 2) помочь коллегам нового направления. Но, скорее всего, 1 они не сделают. Тут нужно не упустить момент, когда переключить всех сотрудников на новое направление :)) Достигнет ли команда нового направления результата зависит от команды, от сложности задач. В любом случае обе команды будут работать над одной общей задачей, т.е. переключение старых на новую задачу — это не взять человека с улицы

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

Да, если предполагается, что на этот проект заказчик предполагает затратить года 2-3 и не будет сильно выпендриваться, то пути решения известны. Проект режется на части и заказчик определяет приоритеты по запуску этих частей. Дальше в соответсвие с определенными приоритетами части запускаются и собираются воедино. Это всё делается с минимальным рефакторингом кода. Всё это рефакторинг и понимание архитектуры, четкое понимание, что именно делает каждая часть и зачем. Всё это оборачивается различными тестами (полным комплектом). После того, как большая часть проекта заработала на старом коде, но с новой архитектурой начинается рефакторинг кода и доделывания оставшейся части проекта.

Может эту «вторую команду», которая делает новое, уже и создали!
Например, клиент оказался достаточно умным что бы стартовать новый проект где-нибудь в европах, а пока его будут несколько лет делать, отдать старье на ремонт в Украину — авось починят и еще поработает.
А может даже наша компания уже создала вторую команду где-нибудь в Кракове и там будут пилить новое. А в Харькове сразу создают команду для бесконечного сапорта и разгребания проблем сначала в старой версии — а потом и в новой.
Но, как правильно написали, лучше команде «могильщиков» не знать о том, что интересную работу отдали другим — иначе им станет еще тоскливее. А тем более глупо ожидать что «неудачники» буду с радостью помогать «везунчикам».
Я все больше начинаю понимать что все мои проблемы как раз в том, что я считаю достоинствами.
Например что работу надо делать какую скажут. Вместо того, что бы посылать начальников (или даже бить, как советует один местный спортсмен) и требовать за такую работу +500 к зарплате и секретаршу с 5 размером. Или что работать на одном заводе бодишопе много лет — это заслуженный почет и уважение. Вместо того, что бы «прыгать» каждый год на +500 и новое звание «супер-синьора» в очередную «компанию мечты». Или что «на свете много улиц разных — но не сменяю адрес я». Вместо того, что бы согласиться быть перевезенным в штаты или европу на все готовое.
Вообщем то, что в совке считалось быть примерным гражданином: ударником труда, «стахановцем», «не отрываться от коллектива» и т.д. в капиталистическом мире называется «быть лохом и терпилой», которого хозяин с радостью наклонит, «вытрясет» и потом выбросит.

что в совке считалось быть примерным гражданином: ударником труда, «стахановцем», «не отрываться от коллектива» и т.д. в
Чувак, забудь ты о совке: самый дикий капитализм гораздо человечнее даже самого гуманного совка. Просто потому, что капитализм работает, а совок — нет.
в капиталистическом мире называется «быть лохом и терпилой», которого хозяин с радостью наклонит, «вытрясет» и потом выбросит.
В твоём совке именно так и делали. Не веришь — посмотри на нынешних пенсионеров собирающих бутылки по мусоркам. Именно их пенсии забрал совок на поддержку всяких там гондурасов и на бессмысленные повороты рек вспять. В нормальных, капиталистических странах, где человек человеку волк за каждую штуку отвечает конкретный человек. И именно его можно порезать на ленточки с помощью суда, если не делает что должен. А где всё вокруг колхозное — сам понимаешь
Я все больше начинаю понимать что все мои проблемы как раз в том, что я считаю достоинствами.
А какими это достоинствами считает начальство м.... Лоха и вдруг найти!
Я все больше начинаю понимать что все мои проблемы как раз в том, что я считаю достоинствами.
Это достоинства, но нынешний мир требует правильной их продажи. Т.е. продавать их надо тем людям, которые смогут их оценить. Аутсорс подобные достоинства не может и не будет оценивать по определению. Задача владельца аутсорсинговой конторы продавать подороже тушки, которых он кормит поменьше. Точно как в поговорке, чтобы корова давала больше молока её надо меньше кормить и больше доить.
бы согласиться быть перевезенным в штаты или европу на все готовое.
Насмешил.
Обрадовались тогда буржуины, записали поскорее Мальчиша-Плохиша в своё буржуинство и дали ему целую бочку варенья да целую корзину печенья.
На самом деле эмиграция — это серьезный стресс даже и для людей помоложе. Типа как черепаху пересадить в другой пруд с иным составом воды, флорой, фауной и пр.

Да уж, нерадостный проект... пару замечаний:
1. Это не продолжение истории про заказчика, который заплатил 2к за 3 месяца работы и теперь думает что делать дальше? А то неясно, откуда может взяться «почти рабочий проект», сделанный полгода назад, никогда не работавший, без документации, и без контактов предыдущего исполнителя.
2. А почему вы считаете, что все тесты рабочие? Я в гораздо более благополучных проектах видел кучу падающих тестов, а тут бы ожидал худшего.
3. Если хотите заниматься перебором, то автоматизируйте это дело. Во-первых интереснее, во-вторых сможете оценить прогресс и требуемое время.
4.

В наших условиях вариант «не соглашаться с клиентом» и менеджеры даже не рассматривают — ведь местных менеджеров в европах никто не ждет, в отличии от девелоперов.
вот именно! Это важно. Не бойтесь менеджера, он от вас сейчас зависит очень сильно — где ему найти другого такого? А клиент в итоге с него спросит. Потому я бы прямо сказал ему, что всё плохо, риски огромны, может получиться провал. Естественно, с настроем что Вы всецело на его стороне и хотите чтобы всё вышло как лучше, но хотите заранее показать проблему. А нездоровый оптимизм проявить можно, но только может оказаться что это не поможет. Потому лучше сразу начать обсуждать с клиентом другое варианты — например, переписать с нуля, или заплатить предыдущему исполнителю за хоть какую-то документацию.
вот именно! Это важно. Не бойтесь менеджера, он от вас сейчас зависит очень сильно — где ему найти другого такого? А клиент в итоге с него спросит. Потому я бы прямо сказал ему, что всё плохо, риски огромны, может получиться провал. Естественно, с настроем что Вы всецело на его стороне и хотите чтобы всё вышло как лучше, но хотите заранее показать проблему. А нездоровый оптимизм проявить можно, но только может оказаться что это не поможет. Потому лучше сразу начать обсуждать с клиентом другое варианты — например, переписать с нуля, или заплатить предыдущему исполнителю за хоть какую-то документацию.
Оное сильно зависит от личных отношений Бобра и его менеджера.

Жаль, что не написано, что собственно должно делать приложение. По описанию могу предположить, что это ERP-подобная система. Если так, то нужно честно признать, что с точки зрения разработки данный проект провальный. Клиенту нужно у конторы в своей стране заказать внедрение типового ERP-продукта.

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

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

В том и вторая часть прикола, столько лет трындежа о совокупной стоимости владения, а бизнес, в разы, если не на порядки, переплачивает нам, программистам :)

Про 8ку, как вона, на стене висит сертификат и доныне, полученный в 3ем учебном центре (г Москва) не хочу. ИМХО, её не за то ругают, и, не за то превозносят. И с провалом, тоже самое :)
Стоит у меня на полке, переведённая книга, О бух учёте, даденная когда и 7ку в проекте франчи ещё не слышали...
А воз и ныне там — снговское представление даже о бух учёте, левое.

Из «левого» представления о бухучёте «у нас», думаю, только жёсткая завязка официального учёта на юридические лица. А что касается плана счетов и регистра бухгалтерии — то это довольно-таки универсальные вещи. Работаю в конторе, где пользуются основной учётной системой Oracle E-Business Suite, версии где-то середины нулевых годов. Так там план счетов реализован как плоская таблица записей, т.е. вместо планов видов характеристик на субконто реализованы все возможные комбинации этих субконто на 1-м счёте как записи в таблице. Регистр бухгалтерии — general ledger, т.е. главная книга. Как оно там детально работает и пользуются ли им — не в курсе.

История частая.

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

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

Переписать — не получится. Влом писать агроменный пост почему, даже на основе имеющейся информации. А уж если добавить от себя.... Кстати, у меня сейчас подобный :) но, ситуация в компании много лучше чем у вас, судя по вашему рассказу. И то,
Вобщем — о переписать забудьте.

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

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

Как съезжать с разговора о них, другой отдельный вопрос. С вашим психотерапевтом :)

Был у меня опыт подобного. Советую пойти от противного, сесть с клиентом и попытаться доказать что это никогда не работало и надо все переписать. Тогда есть шанс что всплывут новые нюансы. По своему опыту скажу что шансы оживить невелики. У нас «оживление» свелось к реализации по кусочкам с нуля. Т.е. выделялся какой то модуль и заменялся на свой код. Благо исходная система была все таки структурированна(т.е. были крупные модули с интерфейсами обмена данными между ними). Итого за приемлемое время из мертвого уродца без документации получился живой уродец с документацией.

Чем вообще ограничен объем работ? Есть что-то типа приемочных тестов? Как заказчик будет принимать работу, если вы прямо сейчас скажете «можно забирать, все готово»?

От этого и плясать.

Попробую дать пару советов:
1). Объедини пути 1 и 2. То есть, пытаемся угадать — наталкиваемся на ошибку — лезем в код, дебажим — локализуем ошибку — меняем конфигурацию так, чтобы ошибку пофиксить. Повторить со следующей ошибкой.
Плюсы: изменение конфигурации делается обдуманно, без угадайчика.
Минусы: требует больше времени, чем перебор.
2). Гарантии того, что это угрёбище работало, по сути нет никакой. Клиент утверждал, что он видел работающую систему? Отлично. А что именно он видел? В какие модули тыкал? На заборе тоже много чего написано ;)
3). Гарантии того, что интеграционные тесты работали — нет никакой. Совсем не факт, что зелёные тесты будут означать работающую систему и наоборот, красные тесты означают, что система не работает. Поэтому ИМХО больше внимания на код, меньше на тесты.
4). Нахуй такие проекты. Меняй работу на нормальную продуктовую (если за бугром) контору, которая заинтересована в качестве своего продукта.

4). Нахуй такие проекты. Меняй работу на нормальную продуктовую (если за бугром) контору, которая заинтересована в качестве своего продукта.
Он в Харькове вообще-то и в обычном бодишопе работает.

Кто мешает сменить работу? Полно в Харькове продуктовых

Тю... Тогда тем более. В Украине и в Харькове в том числе полно нормальных аутсорсинговых (если не искать продуктовые) контор с проектами получше, чем «возьмите дерьмо, написанное неведомыми индусами 20 лет назад и сделайте из него конфетку».

Это Вы из Харькова или все-таки из Киева пишите?

Считаю, что здесь стоит вопрос веры в себя:
Верите ли вы, что найдете решение?
Если да, то переживать нечего — нужно принять ответственность за свое решение и вперед, как бы трудно ни было.
Человек не попадает в такие ситуации, которые он не может решить.
У высших сил стоит просить не исправление ситуации, а силы/подсказки, чтобы самому преодолеть трудности.
www.youtube.com/watch?v=M_CZTi8L29c

P.S. Я в вас верю.

Верите ли вы, что найдете решение?
Зачем ему это? Денег больше ведь не дадут

Если бы это не было нужно, на форуме петицию бы не писал, а слил все спокойно.
Его отношение к деньгам он написал.

Человек не попадает в такие ситуации, которые он не может решить.
Французский, российский и др. монархи так же думали. А как известно они были наместниками бога на земле.
Верите ли вы, что найдете решение?
Конечно найду. Вопрос только — сколько времени на это уйдет. И сколько раз мне скажут о некомпетентности.
И самое обидное: время уйдет впустую! Человек, который уже знает этот проект справился бы за день там, где я потрачу несколько месяцев. Несколько месяцев не делая ничего нового, ничего не исправляя, а только наощуп повторяя уже сделанное кем-то. И, естественно, меня за это никто не похвалит — любой начальник будет считать что другой бы сделал, например, за полмесяца.
И, естественно, меня за это никто не похвалит
Ты на работу ходишь за похвалой?

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

Брось свою фирму и иди на нормальную работу

а никогда не задумывался что ты эту потребность пытаешься закрывать тем что ты лид и социализация да призвание с уважением достались тебе в придачу, только потому что тебя поставили начальником? и ведь тут не надо ничего добиваться, просто факт — что ты решаешь в конце как будет, ведь спрос с тебя, и на самом деле все ложное, просто ты получил это право

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

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

а вот в случае с деньгами иллюзий и обмана не получится, платят мало денег — не уважают, считают хуже среднего, платят средне денег — обычный сотрудник, такой же как все ни хуже, ни лучше, платят много — уважают, ценят
Как-то вы странно представляете себе «социализацию». Т.е. выходит что если человек сидит дома и работает на фрилансе, но ему платят много — то это значит его уважают, ценят и он чувствует признание. А вот если он в каком-нибудь ВУЗе преподает и ему платят мало — то значит никакого реального уважения и признания у него нет, даже если его лекции и книги очень популярны?

с фрилансом невдалый пример — это не зп, так что много мало тут нет, платят ровно столько на сколько договорились и уважения да признания тут никакого нет, кастомер пришел за услугой, получил ее и ушел, вот и весь фриланс

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

классика теории 80/20
усилия 20 дают срубить 80 бабла, если правильно впихнуть клиенту...
клиент хочет получить рабочий продукт и готов платить 20, чтобы сделали 80 (но он то думает, что сделано минимум 80, а то и 99,99999)

Вопросы к тем, кто сталкивался с подобным «старым ящиком»:
такие «сталкивания» всегда приводили конфликту между руководителем/ми проекта и всеми остальными участниками и в результате созданию нового продукта процентов на 80 минмум
классика теории 80/20
Ага — менеджер и клиент думают что это можно сделать за 20% времени. А я трачу 80% — и все равно нихрена не работает.
Просто пока еще не привык работать «по новому»: не стремится к результату, а 20% времени создавать видимость работы, а 80% — забивать. Все-таки для меня девелопмент — это призвание, а не «отсидка за бабки». Но видимо пришло время нашему ИТ ориентироваться на Индию и брать количеством: джунов ломятся толпы, синьоры сваливают. Один я тут завис «между раем и адом» — возможно меня и засунули на этот проект потому что отказался переезжать «from Kharkiv to Кrakov».
возможно меня и засунули на этот проект потому что отказался переезжать
Просто других нет. И у них выбор или тебя на этот проект или уволить. Пока решили не увольнять. Вот у тебя где-то и есть полгода на поиск другой работы.

Или потому, что он безотказный будет работать, мало того овертаймить.

Проверить легко, попроситься на другой проект.
Вероятный ответ: «Другого нет».

Ну так это зависит от личности. Судя по постам Бобёр известен как безотказный мул, который на своих плечах вытащит что угодно. Зачем такому идти навстречу?

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

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

И какого хрена ты вместо того, чтобы ставить условия ноешь?

ну я в Ай-Ти еще не работаю :)
эта практика работает везде, например заказчик «нанял» московский институт для решения одного вопроса и «потратил» на это 3 млн. рос рублей... вопрос был «почти решен» осталось «всего ничего» что и было поручено нам... и на ЗП в 10к грн в месяц... все это переделывалось
вот и думал пойти в Ай-Ти, типа по другому тут...

а тут не берут типа ты ж Тим Лид, на прошлом месте, а к нам Джуном идешь, нах ты тут нужен
ну да и хер с ним

вот и думал пойти в Ай-Ти, типа по другому тут...
Нет, тут в 95% случаев всё также. Для другого желательно работать в западной продуктовой конторе.

Зато розовые очки у тебя спали с носа.

хз, хз...
если в 37 пытаться устроиться джуном-тестером, когда до этого немного кодил на С++, на РНР, и знаю еще пару языков....
и продолжать туда ломиться...
хз, может еще не спали

Налицо несколько заблуждений и предположений, которые воспринимаются как истина
1) Система рабочая. Ее нужно только правильно сконфигурировать. — не более, чем предположение. Заказчик хочет, чтобы так было.
2)

Когда девелопера продают клиенту предполагается что он уже все знает и будет сразу начинать работу.
— заблуждение. Когда разработчик сможет эффективно начать работать зависит от входных данных: если есть документация, требования, диздоки, тренинг по проекту, тогда это время меньше, иначе оно сильно возрастает, стремясь к бесконечности (для руководства/заказчика это может быть, например, 1, 3 или 6 месяцев).
3)
проблема не в коде, а в отсутствии понимания системы
Это точно. А самое печальное — что это проблема девелоперов!
— заблуждение. Это проблема для всех участников.
4)
А вот синьор уже должен все знать и уметь. И логика менеджера простая: ты C# и .Net знаешь? Сам такую систему написать смог бы? Ну значит и с готовой системой должен быстро разобраться!
— чистой воды манипуляция, то есть действия с целью заставить человека сделать что-то вопреки его желанию, пониманию и оценке ситуации, здравому смыслу.
5)
И, естественно, делать это придется в овертайм
 — заблуждение. Желание заказчика/руководства разгребать ... чужими руками и бесплатно. Если заказчик дал плохой код, то он должен быть предупрежден и готов, что работа с ним будет продвигаться медленнее, чем с хорошим кодом. Аналогично руководитель.

Поэтому, если решил остаться:
0) Беречь нервы и здоровье
1) Пишешь план того, что ты будешь делать. Именно что делать, а не сколько это займет времени. Обязательно с рисками. Утверждаешь с руководством/заказчиком. Все это письменно
2) Начинаешь работать по плану. Отчеты каждый день. Главное, чтобы отчет создавал иллюзию движения в правильном направлении. Если что-то сделать нельзя (не получается), сразу предлагай, что еще можно попробовать.
3) Как уже писали, показывать, что разделяешь озабоченность заказчика/руководителя

1) Пишешь план того, что ты будешь делать. Именно что делать, а не сколько это займет времени. Обязательно с рисками. Утверждаешь с руководством/заказчиком. Все это письменно
И начальники и заказчик будут Бобру выкручивать руки, чтобы он проставил сроки в плане. И в начале заебут его до той стадии, когда он поставит сроки (понятно, что случайные), а затем заебут тем, что сроки не выдерживает.
Мой совет, ни в коем случае такую хрень, как план в данной ситуации не делать. Выкручиваться всеми силами. Если выкрутиться не получится, то в план исключительно то, что сказало начальство.
В общем максимально сваливать все обещанки, планы и сроки на начальников. Если они сами определят план и сроки, то Бобру на это пофиг (ну не шмогла я, но очень старалась).

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

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

В целом план понятен:
1) Признать что работа в этой компании больше не может приносить девелоперу никакого удовольствия а нужна только ради бабла.
2) Забыть про результат и создавать видимость работы.
3) Вместо овертаймов на работе косить и экономить время для себя.
4) Делать пет-проект что бы все-таки был какой-то результат и не чувствовать бессмысленность жизни.
5) Перестать говорить менеджеру правду.

И ты забыл священную вещь. Твои отчеты должны быть хороши с точки зрения твоего менеджера.

В приведенном объеме с таким не приходилось сталкиваться, но если частично, то случалось наверное с каждым, кто работает достаточно долго. Как и было сказано, можно пытаться танцевать от тестов, хотя и не факт, что если заработают тесты, то заработает и вся система. Если тестов много, они наверное как-то структурированы, и можно поискать там ниточку, за которую тянуть. В каждом отдельном тесте хорошо то, что если он валится, это обычно указывает на какое-то противоречие — остается лишь понять, как его устранить. Концептуально это похоже на tdd. Конечно, следуя за ниточкой, глупо игнорировать исходный текст и как источник информации, и как средство модификации системы, хотя и пытаться читать его весь сверху вниз тоже глупо. По ходу дела станет понятно, с чем можно справиться, меняя конфигурационные установки, а с чем проще совладать, меняя код. Заодно могут возникнуть идеи модернизации отдельных блоков. Важно как-то продраться к конечному результату, не углубляясь в боковые ветви этого лабиринта. И уж глупее всего, как мне кажется, «втихаря делать новую версию», ибо проблема не в коде, а в отсутствии понимания системы, без которого новый код рискует стать таким же монстром, как и старый, если не хуже того. Что до свечей, гороскопов и прочей эзотерики, мне кажется, надежды мало. В крайнем случае, можно пригласить попа, чтоб окропил сервер святой водой и выгнал из офиса пару бесов.

проблема не в коде, а в отсутствии понимания системы
Это точно. А самое печальное — что это проблема девелоперов!
Когда девелопера продают клиенту предполагается что он уже все знает и будет сразу начинать работу. Если он чего-то не знает — то за обучение клиент платить не должен. А компания тем более не будет — учись в овертайм. Этот подход вполне логичный и все джуны растут именно так: самообучаясь на проекте.
А вот синьор уже должен все знать и уметь. И логика менеджера простая: ты C# и .Net знаешь? Сам такую систему написать смог бы? Ну значит и с готовой системой должен быстро разобраться!
И как можно объяснить что в «готовой» системе используются 100500 разных надерганных со всего инета фреймвоков и библиотек для которых вообще не существует документации. Здесь 80% моих правильных знаний почерпнутых из умных книг и опыт успешных проектов — все бесполезно.
Вместо этого мне нужно, как джуну, забыть все чему учили в институте и пытаться вникнуть в безумную логику этой «картины Пикассо». И, естественно, делать это придется в овертайм (ведь синьор уже все знает). Т.е. тратить свое свободное время не на изучение нового и полезного, а на изучение анти-паттернов и самописных «велосипедов». Именно это меня раздражает больше всего!
Т.е. выбор между «черным ящиком» и «белым ящиков» это выбор между: попробовать разгрести Г снаружи лопатой или нырнуть туда с головой.
И, естественно, делать это придется в овертайм (ведь синьор уже все знает). Т.е. тратить свое свободное время не на изучение нового и полезного, а на изучение анти-паттернов и самописных «велосипедов». Именно это меня раздражает больше всего!
А ты просто не вникай особо, просто тупо что-то делай. Ты же не Бог. Главное отчеты красивые пиши.

Плюсую. Кто как вообще разруливает в подобных ситуациях, при этом не теряя в деньгах и личном времени?

А что тут разруливать? Есть 2 пути по сути:
1. Положить свое здоровье, впахать и в итоге починить этого угребка. Плюсы обычная зарплата, разрушение нервной системы и здоровья.
2. Забить на этого угрёбка. Часа 3 в день тратить на него, особо не напрягаясь и писать красивые отчеты. Плюсы обычная зарплата, здоровая нервная система и не угробленое здоровье. Плюс возможный левый доход с остальных 5 рабочих часов.

Понял. Спасибо. Я делаю все как во втором варианте, кроме подрабатывания остальные 5 часов.

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

З.Ы. Да, это я сейчас понимаю, а раньше был типичным лохом-ботаном, в итоге расплатился здоровьем.

поовертаймить, но только тогда, когда начальство это видит. Овертаймить вместе с начальником. Иначе начнет тебя попрекать, что ты не разделяешь его озабоченности.
Толково. Кстати после того как начал так делать стала повышаться зарплата.

Конечно. Но не забывай про стекляный потолок. После какого-то момента зарплата будет расти только на уровень инфляции известной валюты. А потом после определенной возрастной планки уже по чуть-чуть падать (в пост-совке это 35-40 лет), пока тебя не спишут, как дедушку (дедушка в постсовке это 50, а не 70, как в нормальных странах).
После 50 для тебя останется 3 варианта:
1. Или ты топ в каком бодишопе.
2. Или твои заказчики только западные люди.
3. Еще можно начать пить и ускорить отплытие на лодке лет на 10.

З.Ы. В Украине еще есть нюанс. Вайти-вайти. Посмотри какая толпа народа у вас ломанулась в IT. Так или иначе многие из них войдут и запустят волну конкуренции, которая через несколько лет распространиться на мидлов, а еще через несколько и на сеньоров.

раньше был типичным лохом-ботаном, в итоге расплатился здоровьем.
Можно подробнее, пожалуйста?

Уже много рассказывал здесь. Вкратце, без паксила и ноотропов периодически уже никак.

Если он чего-то не знает — то за обучение клиент платить не должен. А компания тем более не будет — учись в овертайм. Этот подход вполне логичный
Нихрена не логичный. Это перекладывание риска ведения бизнеса на работников. Лучшее решение, который может принять работник в такой ситуации — не идти у бизнеса на поводу.
Нужно объяснить, что нет разработчиков, которые знают всё. Взять любой фреймворк или cms: невозможно в разумные сроки приобрести опыт работы со всеми подключаемыми модулями. Изучение нужных модулей для конкретного проекта — это работа программиста. За работу нужно платить. Тем более невозможно знать как работает эксклюзивный код, который писали до тебя под конкретную задачу и не составили к нему документации. Если бизнес не хочет этого понимать — пусть сам менеджер/директор/владелец садится за комп (программировать — это же легко) и удовлетворяет нужды клиента.

Ну ты и сказочник. Ты не хочешь, найдем другого.

Ну и замечательно. Работать несколько лет на костылях вредно для разработчика. Потому что потом опыт у тебя как бы и есть, и на джуновскую зарплату не хочется, а скилов фактически нет.

Вот тут ( dou.ua/forums/topic/15530 ) написали что синьор — это не тот, у кого скилы, а как раз тот, у кого опыт «работать на костылях». Без костылей-то любой побежит.

А на работу по скилам принимают.

так можно выделываться, если выше рынка зп платишь, в противном случае фирму ждут темные времена, т.к. есть более адекватные фирмы на среднюю зп (читай такую же) и такие же неадекватные на повышенную

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

Ну хорошо — берут девелопера на Java, он говорит «я вот с этим фреймвоком не работал и учить в свое время не буду». Но проект-то стоять не будет пока он учится — выходит нужно срочно искать другого а этого — выгнать.
Сильно будет рад человек, которого только взяли — и сразу уволили? Или может он все-таки решит что придя на новую работу нужно быть готовым подтянуть свои знания?

берут девелопера на Java, он говорит «я вот с этим фреймвоком не работал и учить в свое время не буду»
И ему выделяют рабочее время на обучение. Делов то
Сильно будет рад человек, которого только взяли — и сразу уволили?
Я думаю, оказали разработчику услугу — с м_удаками работать вредно для здоровья

да, если бы 90%+ людей не были бы брехунами, то так бы и было, на самом деле ответ будет такой «я не работал с этим фреймворком, но я читал про него, у него хорший потенциал, я сча на него смотрю, у меня не очень много знаний по нему, т.к. я недавно приступил, но я определенно хочу его выучить», после чего человек получит таски связанные с этим фреймворком и будет его учить в рабочее время, вот и все

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

и самое забавное что человек такой плюс в карму получит :) т.к. задачу сделал, мотивированный, самообучается, следит за модными веяньями

p.s.: в нормальной фирме раз уж человека взяли работать и он что-то не знает, то его не будут заставлять учить что-то в свободное время, ему создадут условия для того чтобы он выполнил задачу — покажут кто может проконсультировать и выделят больше времени на задачу чтобы человек мог разобраться, в итоге все в плюсе

Твое раздражение можно понять и посочувствовать, и все же, как мне кажется, оно не продуктивно. В реальном мире никто никому ничего не должен, зато от каждого свинства можно отрезать кусочек ветчины. Наивно ждать от потерпевшего указаний, где искать преступника, хотя это сильно облегчило бы работу дознавателей. А так одни юристы защищают диссертации, совершенствуя методологические patterns, а другие следаки ищут настоящих фриков в реальных обстоятельствах, и именно к их услугам приходится прибегать в сложных случаях. Аналогично больной не всегда скажет врачу, где у него недуг, а медицинские карты пациентов полны пропусков, ошибок и прямого вранья, в чем пришлось убедиться разработчикам систем медицинской диагностики, основанных на этих данных. У тебя тут все перемешано — технические аспекты проблемы, человеческий фактор — отношения разработчик — менеджер — клиент, эмоциональный фактор — волна раздражения, которую у тебя вызывает эта ситуация. Но нас же учили декомпозиции задачи, то есть выделять отдельные подзадачи, а не смешивать все в один ком. А в психическом плане нас разрушает как раз само это раздражение, а совсем не левые фреймворки, анти-паттерны и несовершенство каких-то неизвестных нам программистов. По твоему описанию это типичный исследовательский проект, что на мой взгляд интереснее, чем клепать стандартные страницы по рекомендованной методике. Всякое исследование в числе прочих характеризуют следующие черты:

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

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

1). Открыто признать, что ты не так крут, заявив, что по твоим профессиональным оценкам задача потребует существенно больше времени и / либо иных ресурсов. Я сам прибегал к такому не один раз и как правило получал желаемое время либо иную помощь, например в форме усилий других разработчиков по параллельному ведению всяких периферийных работ, типа создания виртуальных машин для необходимого тестового окружения и иной тому подобной лабуды.

2). Спокойно исследовать в свое удовольствие, никак себя не перегружая, и пусть оно займет то время, которого потребует, либо какая-то из заинтересованных сторон ни сделает свой ход для изменения ситуации. Нередко пункт 2 оказывается на практике эквивалентен пункту 1 за исключением тонны словоблудия на тему того, как что «должно быть» по представлениям разных сторон. :)

Получается, дело не в самой задаче, а в том, что тебя принуждают ее решать в некомфортных стрессовых условиях, спекулируя на том, что иначе ты не так крут, как полагается быть украинскому синьору по представлениям невежд.
Ну сама задача то же не доставит мне удовольствия. Тут проблема больше в моем отношении к ней. Если я считаю что это вызов, который нужно принять и быстрее сделать — то этим обрекаю себя на овертаймы и потерю месяцев жизни на ненавистную работу. А если считаю что это мне не надо и нужно поработать «на отвали» — все равно ничего не получится, то значит я халтурю, а не работаю. В обоих случаях обеспеченны «некомфортные условия».
Если я считаю что это вызов, то этим обрекаю себя на овертаймы ... А если считаю что это мне не надо и нужно поработать «на отвали» ... то значит я халтурю
Ну, мне вообще-то не слишком импонируют оба эти подхода. Тебе же требуется оживить систему. Допустим, по аналогии, что ты дежурный врач, и к тебе в реанимацию поступил очередной пациент. Это что, «вызов», или это «тебе не надо»?

В данном случае привезли труп и всё что ты можешь константировать смерть и отправить труп в морг, что врач и сделает.

В руках у программистов такие средства реанимации, какие медикам и не снились. Хотя не думаю, что информации достаточно для заключения о смерти. Конечно, в истории про клиента, единожды узревшего, как что-то как-то работает, концы с концами не сходятся. Но покопаться в этом спокойно, на трезвую голову, без эмоций, которые зашкаливают сразу в обе стороны — то ли это «гуано», то ли «вызов», не помешало бы. Сам я к такой работе отношусь нормально, но наверное кому-то она может быть сильно не по кайфу. Ну, не сделает один, может, сделает кто-то другой.

1. ход конем: насколько система _по описанию_ вообще отвечает потребностям клиента? может, надо ставить вопрос «переделка всего этого дерьма или покупка вон того + написания таких-то модулей за 4 месяца ± месяц»?
2. насколько оно сильно связанно? возможно вообще по частям рефакторить или там ад начинается?
3. насколько клиенту нужна рабочая система «прям сейчас»? может быть, вообще будет выигрышным вариант «реанимируем зомби, а пока он хоть как-то работает — пилим свежую систему».
4. собрать чуть больше требований к доработкам. че-то мне подсказывает, что будет аргумент «нет смысла оживлять, все равно даже на зомби это платье не налезет» — в то время как разработка с нуля дает такую возможность.
5. подавать новую систему не просто как облегчение разработчикам(сорри, если вам это очевидно), а как:
а) возможность планировать и гарантированный результат(не про то речь, что через N месяц гарантировано рабочий полноценный клон, а про то, что в процессе разработки можно контроллировать ситуацию, получая частично-функционирующую систему — с реанимацией ж вполне может быть полгода колупания без результата вообще)
б) документация с возможностью легкого дальнейшего расширения
в) полноценное тестирование фич, а не «та оно ж работало»
г) если среди хотелок есть фичи, которые на дохлую систему очевидно не ложатся(скорость, функционал, UI — да мало ли), тоже отдельно осветить

это не советы как жить. скорее, brainstorming.
вообще, сочувствую :(

Я думаю что про будущее проекта пока думать не приходится. Если бы у клиенты были деньги на это будущее — он бы не выбирал самый дешевый вариант типа «мертвая лошадь» + аутсорс. Думаю его потолок — это полгода. Если за полгода мы ему не поднимем хотя-бы полудохлого «зомби» — то он просто «хлопнет дверью». А вот если поднимем и пойдет хоть какой-то доход то тогда ему нужно будет постоянно этого «зомби» поддерживать — на это и расчет менеджмента. У нас в бодишопе очень любят «стабильные» проекты которые можно делать годами.
А вот если сделать новую, стабильную версию — то клиент уйдет довольный. Так уже было: сделали все замечательно — клиент ушел, а команду спецов, которые его сделали, распихали по «бесконечным» проектам вроде этого. Видимо не умеют наши сейлзы находить новые проекты каждые полгода. А учитывая что сейлзы не в Украине то при упоминании оной они морщатся.

Вот щас занимаемся похожим (правда не все так грусно). За 2 года разгребли но сил много потратили и вы будьте готовы.

Рецепт:

Cначала узнайте а как заказчик будет проверять что система поднятая? И делает то что ему нужно?

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

Не бойтесь что-то упустить. Активно выкидывайте и переписывайте это так как вы считаете правильным, а заказчик пусть вас поправляет если что упустили из того что ему нужно было.

Через 1-2 года когда вы будет уже понимать что и как начнете задумываться об архитектуре и предлагать бизнесу свои решения.

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

В основном C#, хотя есть куски на VB.Net, F# и С++. Но там еще зачем-то прикрутили NodeJS и кучу джавасткриптовой фигни как на клиенте так и на сервере.
Насколько я понял подход: там каждый педалил как хотел и на чем хотел.

Поскольку система работала
 — не факт.
Мой совет — возьми отпуск на полгода год.

Мне и до «ИТ пенсии» уже недалеко. Когда там писали перестают брать на работу и пора «сплавляться»? В 50 лет?

так если вам 48 можно брать)

Отпуск на полгода в таком возрасте это гарантия отпуска уже до конца жизни.

Только в случае, если решил уйти в свободное плавание на фриланс и сил и энергии для этого хватает.

Постоянно подумываю об уходе во фриланс. Но отдаю себе отчет что уйти из бодишопа будет легко — а вот потом прийти во фриланс может настойчивости не хватить. Тем более что бабки уже как бы не нужны — пассивных доходов хватает на скромную жизнь. Поэтому есть большой риск вместо фриланса перейти к домашнему алкоголизму в одиночестве. Лучше уже какая-то работа.

Займись спортом. Начнёшь и через месяц желания выпить не останется

С твоим настроением там будет очень сложно. Тебе нужно будет быть активным, шуршать по биржам, договариваться с различными идиотами (там на одного нормального заказчика сотня дебилов, что хотят Гугл за 3 копейки). Фактически тебе придется делать то, что сейчас у тебя делают селлеры, манагеры и это дополнительно к программированию.
Риск перехода к пьянству (алкоголизм это другое и шансов у тебя уже не много) у тебя очень высок. Но алкоголь — это депрессант и сильный. Кроме того ухудшает и сильно работу мозга, в отличие от тех же канабиоидов и никотина. Так что если начинать пить, то так, чтобы за полгода сдохнуть (а это непросто, у славян организм к алкоголю устойчивый), иначе еще хуже будет.
По большому счету, я решения не знаю. От пьянства удержался только потому, что ребенок еще вырос. Но пил уже прилично, был период, что каждый день по 2-3 литра пива плюс чего-нибудь 40-градусного. Ну и сейчас на антидепрессантах плюс никотин и ноотропы, они реально действуют, только это всё сильнодействующие препараты и только по рецепту.

Если

пассивных доходов хватает на скромную жизнь.
то может свободное творчество?

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

может свободное творчество?
Это то же красивая мечта. Многие думают «вот выйду на пенсию — будет полно свободного времени вот тогда и буду делать то, о чем всегда мечтал!» (мемуары писать или орхидеи разводить). Но на практике все чаще спиваются, чем становятся творческими людьми. А все потому, что когда человек что-то делает в одиночку то это обычно никто не оценит!
Даже известнейшие художники, писатели, поэты при жизни часто были никому не нужными «чудиками», их творчество никого не интересовало и они от этого так и умерли несчастными так и не узнав что создали что-то великое.
Я уверен что каждый, кто закомитил что-то в опенсорс считает что облагодетельствовал человечество. Вот только обычно всем — пофиг.

Зачем же в одиночку? Как ни странно, но наше время вполне «мягкое» в плане нахождения «друзей по интересу». Рабочей группы или команды не получается только если собираются «болтуны» и «лоботрясы».

Могу заметить одно, главное что бы «не пофиг» было самому себе, остальное — пофиг.

Если пассивных доходов хватает — могу посоветовать попробовать попреподавать. Хотя и говорят «кто умеет — тот делает, а кто не умеет — тот учит, как надо делать», на самом деле все не та просто. С хорошим экспириенсом можно стать очень неплохим преподом на каких-нибудь курсах. Будешь этим опытом выгодно отличаться от тех, что сейчас кинулся в эту нишу именно потому, что знаний и умений на девелопмент не хватило, а пассивных доходов — не накопили. А общение с молодняком хорошо стимулирует головной мозг и не дает ему засохнуть. И близко к теме будешь оставаться, и нужным себя чувствовать, да и дело полезное делать будешь. А будут еще силы оставаться — можешь и пофрилансить, но уже без напряга, ублажения дурных зачазчиков и «рвания когтей» а исключительно ради удовольствия.

Преподавать — это совсем другой талант нужен! Одно дело знать и понимать самому — и совсем другое уметь объяснить кому-то у которого может просто не быть нужного бекграунда.

Ага. Как говаривал один умный человек: «хочешь что-то понять сам — объясни это другому» :-)

По стратегии — если эту хрень удается запустить под дебаггером, значит ее еще можно оживить (при условии, что она все же работала). Т.к. дальше рулит метод последовательного прохождения минного поля с переменными прыжками в разные стороны (в другие модули, потоки, переходы по шинам на другие сервера и т.д.).
Разумеется нужно хоть примерное представление, что должно получаться на выходе.
Но если входы-выходы из бинарных библиотек не описаны и валится в том числе и там — лошадь мертва окончательно. Молитва и бубен уже тоже не помогут.

Но если входы-выходы из бинарных библиотек не описаны и валится в том числе и там — лошадь мертва окончательно. Молитва и бубен уже тоже не помогут.
Фокус в том что там постоянно что-то валится, но при этом идет дальше! Т.е. ошибки это часть ее рабочего процесса: не нашли что-то, вылетела ошибка — подавили, создали новое или пошли по другому пути. Например, пытается лезть на одни порт — ошибка, значит пытается на следующий — а там ответили и пошло дальше. Таким образом при дебаге отличить важную ошибку от неважной — проблематично. Самая распространенная — таймауты. Что-то не успело прогрузиться или загрузилось не в том порядке (некоторые аффтарфы любили асинхронность и промисы) — значит пробуем по-новой. На каждом запуске можно получить разные результаты.
Т.е. ошибки это часть ее рабочего процесса: не нашли что-то, вылетела ошибка — подавили, создали новое или пошли по другому пути
Это-то более-менее нормально, трюк в том, чтобы определить прошли ли мы по итогу дальше. Так можно хотя бы примерно изолировать такие блоки со всей требухой и не натыкаться на них в последствии. Попутно обвешивать логированием все удачно прошедшие части.
По таймаутам и респондерам — ну да, отпрыгивать в их код при первом вылавливании обращения и допиливать сначала его, остановив на это время проход по реквестору. Тут 9 женщин за месяц не родят...
Работа просто на дохрена слабопосчитываемого времени и никакая автоматика тут не поможет. Менеджмент и клиент должны это понимать и принять.
Есть еще неприятное предположение, что сырцы могли отдать не в релизном состоянии и собранная по итогу система так и не заработает как та, которую клиент «щупал». Это будет полный эпик фейл без вариантов.

Посоветую.
Во первых, реши для себя дорожишь ли ты этой работой. Если не дорожишь предъявляешь ультиматум: я этим проектом заниматься не буду, точка. Хотят — пусть увольняют.
Если хочется поработать ещё некоторое время, делаешь следующее:
1) Доводишь в письменном виде до начальства свои соображения о временных перспективах разработки этого проекта. Делаешь это ОДИН РАЗ.
2) Ни на какие ухищрения подписаться под более сжатыми сроками не ловишься. Дескать вы сроки назвали — вы за них и отдувайтесь.
3)Работаешь четыре часа в день, время засекаешь с помощью технологии помидор ru.wikipedia.org/wiki/Помидор_(метод. К человеку, который пишет код/тестирует/думает в течении чистых четырёх часов по помидору вопросов по производительности быть не может. Я вот пишу три часа, полёт нормальный.
4) Ни при каких обстоятельствах не работаешь овертайм. Пришёл в девять — в шесть часов вечера домой. При попытках навязать овертаймы ссылаешься на писмо в п. 1. Дескать это займёт ОЧЕНЬ много времени и никакие овертаймы положения не спасут.
5) Ни при каких обстоятельствах не делаешь того, чего тебя делать не просили. Успех тебе ничего не принесёт, в случае неудачи всех собак повесят на тебя. У тебя какая задача? Тесты поднять? Вот и поднимай тесты, без самодеятельности! Людей прямо и неукоснительно выполняющих указания начальства наказывать не за что.
6) Когда начальство клюнет жареный петух и оно начнёт тебя подгонять опять же ссылаешься на письмо отправленное в п.1: я предупреждал, времени надо ОЧЕНЬ много, предупреждал в начале работы. Остальное не моя проблема.

p.s. Умение говорить «нет» очень развивают тренировки в каком то мордобое. После удушающего от мастера спорта какой то там дрыщ — менеджер уже такие мелочи.

1) Доводишь в письменном виде до начальства свои соображения о временных перспективах разработки этого проекта. Делаешь это ОДИН РАЗ.
Ну. Предсказываешь будущее, а потом тебя же этим презсказанием и пинать будут. Мой совет такой глупости ни в коем случае не делать, если не уверен в предполагаемых сроках на 100% (а такое не возможно).
5) Ни при каких обстоятельствах не делаешь того, чего тебя делать не просили. Успех тебе ничего не принесёт, в случае неудачи всех собак повесят на тебя. У тебя какая задача? Тесты поднять? Вот и поднимай тесты, без самодеятельности! Людей прямо и неукоснительно выполняющих указания начальства наказывать не за что.
А вот это правильный путь.
а потом тебя же этим презсказанием и пинать будут.
Это займёт стотыщмильонов лет.

Думаю ответ начальника будет: «тогда и зарплату получишь через стотыщмильонов лет».

Так ты отвечаешь: я завтра здесь не работаю тогда, ищите кого другого.

Ну и пошел вон. Так нельзя делать. Разумно найти путь ухода вначале, а потом уже можно сказать «видел я вас с вашим говном в гробу в белух тапочках».

Так есть другой вариант: ищем работу, новую. Увольняемся.

И пока не нашел, лучше не выпендриваться.

Ой, в Харькове, Java программисту и работу не найти?

Вот с оценкой времени и есть главная проблема!

предупреждал, времени надо ОЧЕНЬ много, предупреждал в начале работы. Остальное не моя проблема.
Если назвать время полного перебора — то это годы. Сказать менеджеру что это займет ОЧЕНЬ много времени (больше чем новое написать!) — вы результатов скоро не ждите, а деньги мне платите все равно. Это, фактически, заявление на выход.
Девелопер должен или назвать какие-то обоснованные сроки (а для этого — выбрать стратегию) или отказаться делать. Но как только назвал — попал в ловушку. Ведь прогресс сложно оценить. Например ковырял 10 часов — а узнал только что смотрел не то и не там. Как понять: продвигаешься вперед или топчешься на месте?
Успех тебе ничего не принесёт, в случае неудачи всех собак повесят на тебя.
Вот в этом главная печаль такой работы. По итогу месяца работы может оказаться что надо было всего-лишь разложить файлы в правильные каталоги на диске — и все заработает. Т.е. девелопер за месяц сделал работу, которую можно сделать за час! А сколько времени он разбирался — это ведь его проблемы. Долго разбирался — значит тупой, другой может быть за день бы догадался. А если не разобрался и за месяц (или сколько там назвал)? Тут уже понятно что некомпетентный.
Поэтому да: начальство «клюет», сидишь овертаймишь и не оставляет чувство что зря потратил кучу времени и шел не туда. И где-то на краю сознания: а может и правда — тупой и не увидел очевидной вещи? И начинаешь все перепроверять.
Отказаться от работы — не проблема. Но придя на другой проект или в другую компанию скорее всего попадешь в такую же ситуацию. Старый проект, куча кода, нет документации и т.д. Опять нужно будет разбираться в овертайм — платить синьорскую зарплату за «я буду разбираться очень долго и остальное — не моя проблема» никто не будет.
Сказать менеджеру что это займет ОЧЕНЬ много времени (больше чем новое написать!) — вы результатов скоро не ждите, а деньги мне платите все равно
можно сказать иначе: разработка с нуля — где-то два года ±полгода, переделка существующей — два месяца на инвестигирование(которое также тратится на разбор тестов, в первую очередь), которое только должно дать основу. или не дать.
ну, типа, вилка: гарантированные траты + практически гарантированный конечный результат или отсутствует гарантия, но в любой момент можно сказать «ой, всё», забрать промежуточную версию и уйти.

Насколько я могу понять точка зрения менеджера примерно такая: клиента в лучшем случае можно развести на несколько месяцев — может полгода. Клиенты сейчас на дороге не валяются: мало кто не отвалит услышав про Украину и найдя на карте Харьков рядом с лугандоном и рашей.
Поэтому беремся делать по-любому: все равно девелоперы на бенче сидят без дела после ухода других клиентов — и наклоняем их по-полной. Теперь уже никто на +500 в Харькове никуда не сбежит. Сделают за несколько месяцев овертаймов — хорошо. Не сделают — ну выгоним или на другой такой-же проект пристроим.

Поэтому беремся делать по-любому: все равно девелоперы на бенче сидят без дела после ухода других клиентов — и наклоняем их по-полной.
Так ты не наклоняйся, делов то
Теперь уже никто на +500 в Харькове никуда не сбежит.
За тебя погуглить вакансию в харькове?

Ты работал руководителем когда? Думаю, что нет.
Всё что ты написал, это фантазии девелопера, озвучивание которых никак не в твою пользу будет в глазах твоего руководителя.
Самое лучшее в стьуации Бобра плыть по течению и не сопротивляться этому течению, а там может и на мель какую вынесет и перебраться в чистую речку сможет.

Нет. В большинстве фирм нормальные проекты. Это ты,выбираешь такие

Ни в коем случае не ввязывайся в игру с угадыванием времени. Проиграешь. Просто делай то, что говорит начальство дословно.

Сказать менеджеру что это займет ОЧЕНЬ много времени (больше чем новое написать!) — вы результатов скоро не ждите, а деньги мне платите все равно. Это, фактически, заявление на выход.
Или на отказ фирмы от этого проекта :)
Девелопер должен или назвать какие-то обоснованные сроки
Тебя об этом просили? Нет? Вот и не дёргайся. Просто скажи, что эта задача сложная по вышеуказанным причинам.
Поэтому да: начальство «клюет», сидишь овертаймишь и не оставляет чувство что зря потратил кучу времени и шел не туда.
Пошли начальство нахй. Можно в буквальном смысле.

То что бред — понятно, но нужны цифры, о каких порядках идет речь?
Откуда взялись тысячи, а не там миллионы человеко-часов на изучение и/или написание нового? Похоже на попытку объять необъятное.
На основе чего взята версия, что новое будет быстрее старого? Ведь клиент такой же болван, который сам не знает чего нужно, а другие болваны впарили халтуру еще более глубоких болванов и оно даже работало. С чего вы взяли, что новая версия будет кристально-чиста не пройдет 7 кругов ада под те же неопределенные требования, которые никто не знает и выйдет в 3 раза дольше, чем поднимать старое как делали все до вас?
Отмывать карму клиента (который успешно ее слил на вас) и делать ему хорошо конечно «благородное занятие» за баксочас, но иногда лучше сделать отмену, чем сойти с ума.
Сколько файлов/классов/строк/таблиц/уровней вложенности и т.п.?
Если количество не бесконечно велико, то можно использовать LiveComment для утрирования блоков информации. LiveComment уже исцелил несколько проектов, например помог освоить гору кода WebKit в довольно сжатые сроки, а там как в вашем проекте — все как-попало чтобы было по-больше проблем.

То что бред — понятно, но нужны цифры, о каких порядках идет речь?
Откуда тут можно взять точные цифры? Это все равно что спросить: сколько времени надо, что бы собрать огромный пазл не зная как он должен выглядеть собранный? Может день, может — месяц, а может так часть кусков вообще от другого пазла.
С новым немного проще: можно прикинуть за сколько времени уже делали проекты похожего типа и масштаба. Хотя, конечно, есть риск что в старом использовался какой-то свой мега-крутой алгоритм, который просто-так не повторить и не найти готовый.
Сколько файлов/классов/строк/таблиц/уровней вложенности и т.п.?
Много. Статический анализ кода (цикломатическая сложность, вложенность и т.д.) просто «зашкаливает». Таблиц — сотни, классов — тысячи. Но многие таблицы могут быть просто «разбиением» данных или логами, или архивами, или остатками миграции. Сколько из них нужных и уникальных сущностей — сходу не определить. В коде много похожих мест. Так что классы могут быть просто «клонами» или «старыми версиями».
Что-то я пока не понял как LiveComment поможет разобраться в чудом запутанном коде? Кто комментарии-то писать будет?

Тысячи классов не проблема, вся паника от физических ограничений мозга, поскольку нельзя уместить много кода в голове в один момент, вам кажется, что в проекте полный хаос. Но если хаос упорядочить, то все станет ясно и не так ужасно. LiveComment именно для этого создан (как раз причиной создания был подобный хаос в коде, когда невозможно было держать десятки классов с сотнями взаимосвязей в голове, а дебаг был безсилен из-за рандомных крешей).
Можно провести наглядный эксперимент на скриншоте самого LiveComment, поскольку он сам используется для своей же разработки, что значительно ускоряет прогресс.

Эксперимент:
С одной стороны код, который новый для вас и возможно на неизвестном вам языке, а с другой стороны отображение этого же кода понятными словами в деревовидном виде. Через 30 секунд чтения какой части все становится понятно правой или левой? Думаю слева у возникнет паника, а справа вроде как и не сложно понять что есть в коде и как он работает.
acpul.tumblr.com/image/116725190130

Тоже самое уже проделывалось с большими объемами кода и все завершилось удачно, говнкод был расшифрован в разумные сроки и программа чудесно презентовалась на выставке. Не это ли вы ищите?
Из плюсов можно отметить, что командная работа ускорит расшифровку не линейно, а экспоненциально.
Конечно есть моменты и для ваших задач/восприятия/погоды может не подойти (противопоказание: может вызывать истерику в слабых организмах), потому советовал уделить этому не более дня-двух, чтобы прочувствовать пойдет ли. Но если поможет, тогда было бы хорошо увидеть feedback после чудотворного исцеления.

Думаю слева у возникнет паника, а справа вроде как и не сложно понять что есть в коде и как он работает.
Что-то я так и не понял что правая часть-то показывает? Это лог выполнения? Что цифры значат?

Правая часть это этот же код, что и слева, но в ином представлениии (отображается в браузере, снизу адресная строка). Комментами выделены блоки. Блоки выделяются на свое усмотрение любыми названиями (позже можно подкорректировать), главное определить начало и конец:
// a [
bla-bla-bla
// a ]
То есть, изучаете код, сортируете говн0код по пакетикам и потом уже ничего не теряется и все ясно. Независимо какой человек это делал, будет ли он потом работать или нет. и так далее.
С нормальной скоростью можно расшифровывать 30 классов/день, через 10 дней будет уже 300 классов, что уже достаточно для того, чтобы спокойно ориентироваться в коде.

цифры это строки — удобно для навигации и не только

З таким ніколи не стикався, але можу висказати своє ІМХО з позиції рядового девелопера.
Якщо морально-етичне питання «Найо.увати замовника чи ні» не стоїть, то я б робив наступне:
Зібрав би свою команду, розповів як насправді є і почав писати з нуля, використовуючи всі нові ліби технології і т.д. Замовнику б через місяць-два показати перші результати з постановою «Вдалося підняти частину системи, ось вже працює це і це, працюєм над підняттям всього іншого.» і так радувати раз в місяць якимось новим функціоналом аж до необхідного рівня задоволеності замовника.
Паралельно вся команда могла б витрачати 1-2 години в день на колупання старої системи аби, можливо, більш краще розуміти задачу і, можливо, випадково підняти якийсь функціонал.
Плюси:
— Девелоперам буде цікаво, вони будуть зайняті саме девелопментом а не незрозуміло чим і, як наслідок, вірогідність текучості кадрів набагато зменшиться.
— Гарантовано, що через 1,2,4.... місяців буде готова система.
— Якщо хтось піде з проекту, його можна буде безболісно замінити.
Мінуси:
— Дуже маленька вірогідність запуску старої системи
— Час на розробку нової.
— Якщо замовник дізнається, що його обманювали, можливий розрив контракту, фінансові та репутаційні втрати.

Як девелопер, я завжди виступав би за варіант, де є девелопмент, як менеджер, намагався б пояснити замовнику, що без контактів зі старими розробниками цієї системи доведеться писати нову.

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

Откуда взялись тысячи, а не там миллионы человеко-часов на изучение и/или написание нового?
На основе чего взята версия, что новое будет быстрее старого?
С чего вы взяли, что новая версия будет кристально-чиста не пройдет 7 кругов ада под те же неопределенные требования, которые никто не знает и выйдет в 3 раза дольше, чем поднимать старое как делали все до вас?
Но менеджер не согласился на такую авантюру.
И правильно не согласился. Менеджер на порядок опытнее тебя, учись у него.

переписывания заканчиваются тем что из одного говна получаются два несовместимых говна, если нормально писать с первого раза не получилось, то и со второго не получится, только рефакторить по чуть-чуть в пределах новых фич или багофикса

Неможливо рефакторити те, що в принципі не працює і не відомо як працювало.

ну да желание такое делать обычно мало у кого есть, но любой говнокод можно отрефакторить и привести в порядок; денег на переписать никто не даст, а если даст, то закончится тем что на +500 уйдут те кто начали, а те кто будут дописывать сделают как было, а то и хуже, потом денег уже точно не дадут на переписывание

В такому випадку ви, як Lead, можете сказати менеджеру щось типу: «Я слишком стар для этого дерьма». Лідів цінять скрізь, ліди можуть собі дозволити таке говорити, на крайняк лід може за тиждень знайти нову роботу на +$$$$ баксів, у нас на фірмі, наприклад, вже місяць шукають ліда на новий проект, при чому на девелопмент, з правами робити і будувати все як хочеш.

P.S. Будете розглядати вакансії лідів у Львові — пишіть в приват, поділим бонус за рекомендацію :D

Спасибо за приглашение. Но если рассматривать вакансии в других городах то я скорее буду выбирать между Германией и Штатами. Проблем с переездом нет: перевозит как наша компания, так и другие. Плюс есть знакомые которые уже там и могут порекомендовать в местные компании. Деньги я не люблю, жить привык очень скромно.
Есть только одна беда: как правильно сказали «Я слишком стар для этого дерьма». Выгорел на унылых проектах до тлена, осознал безысходность и вместо изменений и переездов часто хочется только залезть в «черный ящик» и упокоиться на родине.

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

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

Ну наймите агэнта. За месячную зп хрюши землю будут рыть, даже учитывая настрой бобра, а что много — так бабки его не особо интересуют. Хоть тут клич кинуть — думаю найдутся запросто.
Там ведь ещё минус, что контора под откос пошла — т.е. лучше врядли будет.

Куда воткнуть этого агента? От хрюш толк разве что в убое их, всё остальное расходы.
А вот найти приличного менеджера, чтобы заказчиков искал по моему профилю и договаривался я не смог за 25 лет. Хотя искал всю жизнь. Еще для всякой веб хрени такого найти можно у нас, для чего-то посложнее не реально. Такие наверное водятся только в Америке. Вот есть у меня знакомый менеджер, уже владелец своей конторки, грамотный и именно поэтому берет простые заказы в стандартной аутсорсиногой области, причем те, которые сделать несложно и в заранее четко прогнозируемые сроки. С рапознаванием же образов всё сложнее — никогда не знаешь, получится или нет в итоге и рисков выполнения заказа море.
И меня бабки тоже особо не интересуют, если мне интересна задача, могу и за бесплатно сделать, только никому не надо и за бесплатно здесь (про РБ и не говорю, тут задница с заказами больше чем у вас).
Не забывай, что здесь рулит аутсорс и типичные заказы УЕБ да подтирание задниц за индусами.

До принятия оффера — никаких расходов. И у тебя профиль узкий и не лезет никуда. Бобёр по-моему гораздо более универсален, как раз подтиранием занимается)

Возможно этот вариант и сработает. Я бы на его месте к твоему совету прислушался.

Есть только одна беда: как правильно сказали «Я слишком стар для этого дерьма». Выгорел на унылых проектах до тлена, осознал безысходность и вместо изменений и переездов часто хочется только залезть в «черный ящик» и упокоиться на родине.
Сходи к психиатру (не поликлиничному) за антидепрессантами. Пока не ввалился в депрессию полностью, эти колеса реально действуют. Да есть побочка, в течении времени их приема будешь немного поддтормаживать, но зато депрессивные настроения уйдут.
Для текущей твоей работы это подтормаживание мешать не будет, но будет сильно проще воспринимать окружающее. А там может решишься свалить, настроение-то уже не депрессивное будет. Да, алкоголь при антидепрессантах противопоказан полностью.
— А может втихаря делали новую версию «с нуля» что бы потом удивить клиента?
Удиви меня. Подари мне $1000000. Я тебе хотя бы мозг не выношу. Или ты даришь только тем, кто тебя хорошо имеет?

Повтори вслух «я нормальный» столько раз, пока сам в это не поверишь. Обязательно вслух.

Обязательно вслух.
Тогда в это перестанут верить 100 коллег, которые сидят со мной в «конюшне» опенспейса.

Читая твой пост выше в твоей нормальности уже сомнения есть.

За это не беспокойся, они думают что ты бобёр.

Хочешь совет?
Спрячься и так, чтобы не видели. Делай то, что говорит начальник, побольше митингуй и обсуждай. И никаких обещаний не давай. Всё протоколирую и пиши в отчетах. Будь просто старательно выглядящим гребцом на вашей галере.
Всё одно эту «мертвую лошадь» вы не оживите, с зомби еще опаснее. За полгода, год само всё отвалиться. Клиента на бабки твои начальники поразводят, а потом у того деньги кончатся и отвалит.

Иконы не помогут, нужно чистить карму. Мои соболезнования :(

Иконы не помогут, нужно чистить карму.
Похоже — вот прямо чувствую как в последнее время тяжелая карма на меня давит. Такая тяжелая что утром веки не поднять. Да и жизнь испортилась: друзья бегут из этой страны, компания вывозит сотрудников, проекты один хреновее другого, в душе боль, тлен и безысходность.
Как же ее чистить-то эту карму?
Такая тяжелая что утром веки не поднять. Д
А вот эот уже физиология и возраст. Дуй за колесами, пока не поздно.
И если есть возможность обрубить корни, вали из этой страны. В европах, америках, твой возраст еще возраст молодого и активного. Это в постсовке после 45 ты уже дедушка и пора лодку готовить.
Дуй за колесами, пока не поздно
Да ну нафиг. Тоже ж иллюзия и надолго ее не хватит. Зато потом даже в нормальной ситуации без них будет печально.
Лучше всего бы выдурить отпуск и отвалить в какое-то в меру глухое место на пару недель хотя бы. Полностью закрывшись от всего новостного и фейсбучного дерьма (ну реально — ничего же не изменится от того, что не прочтешь свежие новости, даже про войну, а переживать будешь сильно меньше) и перекрыв по возможности рабочие контакты (чтобы этот зомби тебя не достал). Заняться каким-то хобби, чтобы полностью занимало мозг и руки или там спортом и думать только о своих успехах в нем.
Нужно полностью выпасть из виртуального мира, это он, сволочь, давит кмк.
Лучше всего бы выдурить отпуск и отвалить в какое-то в меру глухое место на пару недель хотя бы.
Проходил. До какого-то возраста работает, а потом нет.
Заняться каким-то хобби, чтобы полностью занимало мозг и руки или там спортом и думать только о своих успехах в нем.
Чел уже слишком глубоко в программазме и так просто от него не уйдёт. Разве что поучаствовать в АТО, пострелять живых человечков. Но у вас там сейчас всё сильно стихло и уверен, что сейчас там больше дурдома, чем возможности пострелять по бегающим мишеням.
Но дальше он потеряет доход от программинга и путь в охранники в супермаркете останется.
Да ну нафиг. Тоже ж иллюзия и надолго ее не хватит. Зато потом даже в нормальной ситуации без них будет печально.
Не иллюзия, но вероятнее всего уже подсядешь на употребление до смерти. Но при выборе алкоголь или антидепрессанты, выбор очевиден.
До какого-то возраста работает, а потом нет
Пока не приелось — лучше это пробовать. Когда перестанет помогать — тогда уже дальше думать. Все лучше, чем сразу на колеса.
Разве что поучаствовать в АТО
Да ну нафиг. Я не про «совсем свалить», а временно, вычистить мозги не теряя работы. Я, например, занимался бильярдом. На работе весь мозг вынесут, к вечеру куча негатива и злости, а как сядешь в машину ехать с работы, вспомнишь что сейчас пойдешь в клуб и там оторвешься (а если ярко сыграешь, так еще дня три греть будет), так и отпускает практически моментально и мозг переключается полностью.
Но при выборе алкоголь или антидепрессанты
Синька вообще не выход. Кто решил, что оно помогает? Помогает на пару часов и то далеко не всем, многим еще хуже становится и злость только нарастает. Зато с утра + еще одна проблема к уже имеющимся.
Я, например, занимался бильярдом.
Почему-то мне кажется, что у Бобра нет подобного хобби.
А так да, хобби у тебя очень правильное: и общение с совершенно другими людьми, отличными от твоего офиса и мозг конкретно нагружает, чтобы играть хорошо и удовольствие получаешь от хорошей игры.
Как же ее чистить-то эту карму?
Слабительное и в туалет. Слить не забудь.
Что делать?
Валить оттуда, епт!!!!11стоадыннадцать
Дуыт! www.youtube.com/watch?v=ZXsQAXx_ao0
есть примеры когда искренняя молитва помогала запустить приложение?
Конечно. Мы ведь по сути только тем и занимаемся, что молимся Богу-Машине.
Практикуете ли вы
Да. Надо только правильного б-га выбрать. Когда надо превозмогать — советую Императора Человечества. Также можно поговорить об отсутствии г-спода б-га нашего, Нирване.
Когда надо превозмогать — советую Императора Человечества.
Знаком с этой вселенной.
И первое озарение от кода у меня как раз возникло когда я понял что в нем нет никакой логики. Хаос какой-то...
Хаос — это и есть верный ответ! Теперь становится очевидным что мозги девелоперов этого проекта были поражены порчей Варпа. Если присмотреться, то в коде можно найти явное поклонение цифре восемь: восемь классов вызывают друг-друга пока не сделают простую операцию, восемь уровней наследования, восемь вложенных ифов... наверняка где-то будут даже 8 вложенных циклов по 8 итераций. Что символизирует цифру 88 — и это то же не случайно!
Учитывая что Тзинча называют «изменяющим пути» то думаю такой спагетти-код (scrap code) именно литания этому темному богу:
warhammer40k.wikia.com/wiki/Tzeentch
А вот мертвый код и гнилой код — это скорее влияние Нургла:
warhammer40k.wikia.com/wiki/Nurgle
И откуда порча проникает в мозги девелоперов то же можно понять: мы не верим в Бога-Машину и считаем что когитаторы и машины не имеют душ. И в отсутствии нужных ритуалов и защитных печатей Варп свободно проникает в Интернет. Мерзости варпа постоянно вылазят на разных сайтах: изображения отвратительных мутаций, сцены извращенной похоти, описания ужасных болезней, кадры кровавых преступлений... Хаос ловит девелоперов в ловушку!
Сначала наивный девелопер — «магос» пишет код без использования шаблонных конструкций, без должных молитв Богу-Машине и без обязательного ревью и благословения кода Экклезиархией. Потом разгневанные духи машины перестают работать как должно. Девелопер пытается все починить и в борьбе со своим же нечестивым кодом теряет веру в Омниссию и впадает в уныние. Что бы отвлечься он лезет в интернет — а там его ослабленную душу поджидает Хаос. И дальше начинается замкнутый цикл — он вносит в код все больше хаоса и все больше от этого страдает. Порча уже не только проникла в его код — она начинает пожирать его мозг. Девелопер впадает в депрессию, спивается, сходит с ума... А проклятый код ждет новых жертв, которые придут на его место.

белый ящик, и вперед — с песней!

белый ящик, и вперед — с песней!
Тоже поначалу пробовали с этого начать. Так и обнаружили насколько «чудесный» код нам достался. Можно днями блуждать и потом выяснить что весь этот код относился к «версии 1», а где-то есть переключатель, который все переключает на «версию 2». Коду много лет и в нем вполне ожидаемо можно увидеть несколько копий одного метода или класса для разных версий.
У меня вообще есть чувство что из всего объема кода только 30% — реально работало. А остальное это были старые версии или фичеры, которые давно отключили. И когда мы пытаемся их по-незнанию включить — то они, естественно, не работают.
А клиент, естественно, не будет долго платить денег за наши поиски без результатов. Его цель — не изучение системы, а запуск ее хотя бы в каком-то виде и получения дохода для покрытия уже понесенных затрат.
Есть риск что мы изучим 50% системы (изувечив себе мозг) и на этом клиенту надоест и проект закончится без результата. А еще раньше менеджер начнет политику репрессий: что бы спасти проект вина валится на «недостаточно старательного и умного» члена команды и он с позором изгоняется, после этого клиенту говорят что нашли нового спеца и уж он-то все сделает.
Поэтому теперь перешли к стратегии Б.2 и стараемся совмещать погружения в код с экспериментами «на удачу». Только удача как-то пока не улыбается :(

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

но у вас и реально другого выхода нет. это как бы беда менеджеров что они взяли проект который практически не выполним
Но постоянно кажется что еще вот-вот и вдруг все запустится! Может быть ответ «где-то рядом» — и его просто заслоняет от нас туман кода. Может лучше отвлечься от кода, забыть какой он сложный, и статься найти в «черном ящике» хотя бы один рабочий выход.
Но постоянно кажется
Тогда креститься надо.
— Время разработки системы «с нуля» значительное (около тысячи часов). Оно зависит от изменений требований.

а требования то хоть есть?

а требования то хоть есть?
Есть фантазии в голове заказчика — далекого от ИТ. Ему нужна система, кто-то недорого впарил ему «мертвую лошадь»: показал что-то, убедил что это очень поможет его бизнесу и после продажи «сделал ручкой».
Поэтому пойти методом «нового ящика» честным образом — невозможно. Не скажешь же клиенту что оживить то, за что он заплатит денег, обойдется в общей сумме ему дороже, чем было написать новое с нуля. Особенно если старое уже как-то работало а как должно работать новое клиент и сам не до конца представляет.
Можно только как-то втихаря делать новое, показывая прогресс как будто это удалось оживить часть старого. Но на такую авантюру менеджер идти не хочет.

почему? берете все ваши тут рассказы с + и — , добавляете расчет стоимости ресурсов, делаете диаграмму сравнения, выбираете самый малозатратный(новый ящик). ну достался клиент, которого развели на бабки, ну бывает. пусть либо выбивает уже с них необходимое, либо судится( вы тут будете рукой, которая открыла глаза бедолаге).либо терять клиента(если там совсем клиника), либо теряются кадры и создается вечная текучка.
отпинайте менеджера, в конце-концов.

Дело в том, что «новый ящик» — это совсем не самый малозатратный вариант!
Ведь система-то теоретически рабочая. Самый малозатратный вариант — это если она завтра вдруг заработает. Или заработает через месяц мучений. В любой случае это дешевле чем минимум полгода переписывания. С другой стороны есть риск что и за полгода не удастся запустить.
Это вечный выбор между: выбрасывать немного денег каждый месяц на ремонт старой машины или купить новую в кредит и потом возвращать. Выбор тут не такой очевидный.

С другой стороны есть риск что и за полгода не удастся запустить.
Тебе-то что от этого. Главное ты пытайся запускать и не забывай об своем упорном труде додкладывать начальству.
А аналогии твои в данном варианте кривее некуда.

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

Ооо! Да Вам достался «ящик Пандоры». И как Вас так угораздило-то?
Мои искренние соболезнования.

Это Харьков — здесь все очень уныло. Хотя ИТ компании явно не сокращаются — но заметно что тенденция в сторону «релокации» и что радужных перспектив у харьковских офисов компании не видят.

Подкиньте монетку пару раз, что ли...

Подписаться на комментарии