Comments 32
А переписать AsyncMsgProcessor на нормальную очередь и на Executor не получилось?
не нашли причину почему исходники потерялись?
Причина в том, что продукт разрабатывался больше 15 лет в разных компаниях. За такой срок те вещи, которые никто особо не менял, покрылись большим слоем пыли.
Поэтому я подсел на репозитории… Их потерять сложнее
Не панацея. Представим, что у нас 10-20 разных команд (в разное время). Обязательно будут разные репозитории. Например, кто-то будет писать компонент в open-source на github'е, другие компоненты будут разрабатываться под SVN в силу каких-нибудь исторических причин, третьи — на внутренних git-репозиториях. Даже если проверить, что все собирается, нет гарантий, что в одном из компонентов не используется библиотека без доступных исходников, как собственно и произошло.
Ну тогда на будущее возьмите правило, чтобы пушить все в репозитории. Чтобы о вас потом не вспоминали плохо))
Я сам столкнулся с софтом который писали 10 лет назад незнакомые мне люди. И часто код переписывали под заказчика, компилировали и удаляли изменения. В итоге единственная версия оставалась у заказчика и как ее повторить никто не знает. Были бы репозитории с ветками было бы проще.
Я сам столкнулся с софтом который писали 10 лет назад незнакомые мне люди. И часто код переписывали под заказчика, компилировали и удаляли изменения. В итоге единственная версия оставалась у заказчика и как ее повторить никто не знает. Были бы репозитории с ветками было бы проще.
Дополню, даже в emacs 'е не так давно обнаруживалось, что нет части исходников, хоть всё и собиралось. А emacs это более 25 лет разработки.
Можно. Репозитории тоже умирают. Например, я недавно не смог собрать проект на gradle, т.к. там использовались некоторые сторонние репозитории, которые умерли за год.
К сожалению, иногда это не панацея из-за некоторых «новобранцев». У меня был такой случай с программой, которую я изначально разрабатывал и внедрял нескольким заказчикам. Когда я был занят на одном большом проекте, возникла потребность сделать небольшие доработки и установить программу новому заказчику — это поручили младшему специалисту.
Я ему показал что где лежит, куда что писать и вроде бы все хорошо закончилось — заказчику программу поставили, заказчик доволен, коллега все закоммитил в TFS. Через полгода, когда этот коллега уже уволился, заказчик заявил о какой-то неисправности и я занялся этой проблемой. Естественно, взял последний чекин от того коллеги, нашел источник бага, исправил и поставил заказчику. Вот тут то и началось самое интересное — заказчик чуть ли не через дирекцию написал гневное письмо, что лично я сломал ему работу программы, так как пропало 40% функционала.
Как оказалось — после формальной сдачи проекта по доработке, в рамках техподдержки мой коллега допилил заказчику еще пару функций, и, как на зло, не зачекинил. При этом никому особо про доработки не сказал (только руководителю проектов, который не счел нужным сказать мне, так как считал, что это сделал младший коллега). Коллега ушел — его комп по требованию безопасников отформатировали полностью. Исходников не достать. Как результат — недовольство от заказчика и восстановление функционала в сжатые сроки.
Я ему показал что где лежит, куда что писать и вроде бы все хорошо закончилось — заказчику программу поставили, заказчик доволен, коллега все закоммитил в TFS. Через полгода, когда этот коллега уже уволился, заказчик заявил о какой-то неисправности и я занялся этой проблемой. Естественно, взял последний чекин от того коллеги, нашел источник бага, исправил и поставил заказчику. Вот тут то и началось самое интересное — заказчик чуть ли не через дирекцию написал гневное письмо, что лично я сломал ему работу программы, так как пропало 40% функционала.
Как оказалось — после формальной сдачи проекта по доработке, в рамках техподдержки мой коллега допилил заказчику еще пару функций, и, как на зло, не зачекинил. При этом никому особо про доработки не сказал (только руководителю проектов, который не счел нужным сказать мне, так как считал, что это сделал младший коллега). Коллега ушел — его комп по требованию безопасников отформатировали полностью. Исходников не достать. Как результат — недовольство от заказчика и восстановление функционала в сжатые сроки.
Сервера сборок, значится, нет?
Сервер сборок от данной проблемы не спасет. «Новобранец» спокойно отошлет заказчику локально собранный проект.
У нас проекты не такие гигантские. Со сборкой даже самого большого нашего проекта справляется любая локальная машина сотрудника меньше, чем за минуту (у всех сотрудников минимум Core i3), Делать сервер сборок нецелесообразно со стороны дирекции (финансово), да и обычно проблем у нас никогда таких не было.
Я только один раз потерял исходники. Очень помогло то, что в то время уже писал на C#, а не на плюсах. К слову, местами приходил в ужас от декомпилированного кода.
даже потеря исходных кодов — не катастрофа
А вот это зависит от декомпиляторов\рефлекторов\дизасмов. В Java и .NET все ок, у АСМщиков таких проблем вообще нет, а вот сишникам придется хуже.
Кстати, краем уха слышал про подписанные библиотеки, вроде как в них врезать свой код совсем тяжко.
сишникам придется хуже
Не на много. Практически всегда можно сделать тонкий слой врезки и сделегировать основную часть работы в православно написанный код в своей любимой IDE. Если я конечно правильно понял суть высказывания.
Врезать код — да. Полагаю, операция почти одинаковая для любого популярного языка.
Восстановить исходный код из dll для анализа — сложнее. .NET код восстанавливается без проблем. При восстановлении С++ кода уже придется потрудиться.
Восстановить исходный код из dll для анализа — сложнее. .NET код восстанавливается без проблем. При восстановлении С++ кода уже придется потрудиться.
Ну как… Все зависит от навыков и желания:
habrahabr.ru/post/266385
habrahabr.ru/post/110395
Мне кажется, что больше всего отличается порог вхождения: чтобы научиться продуктивно реверсить компилируемый код, нужно больше времени.
habrahabr.ru/post/266385
habrahabr.ru/post/110395
Мне кажется, что больше всего отличается порог вхождения: чтобы научиться продуктивно реверсить компилируемый код, нужно больше времени.
>> Среди менее готовых для прямого использования тулзов есть отличная, очень мощная штука — ASM. Но из коробки не имеет возможности сначала вывести в виде текста, затем подредактировать и собрать обратно.
>> Но можно научить.
…
>> Симитируем поведение Reader
Пионеры не ищут лёгких путей?
Среди примеров к ASM есть «A ClassVisitor that prints a disassembled view of the classes it visits in Jasmin assembler format».
Вот он: http://websvn.ow2.org/filedetails.php?repname=asm&path=%2Ftrunk%2Fasm%2Fexamples%2Fjasmin%2Fsrc%2FJasminifierClassAdapter.java
А вот и тот самый ассемблер Jasmin, которым можно ассемблировать полученный при помощи вышеупомянутого посетителя листинг: http://jasmin.sourceforge.net/
Учитывая древность проблемного кода, вряд ли там было что-то, что не смог бы переварить Jasmin.
>> Но можно научить.
…
>> Симитируем поведение Reader
Пионеры не ищут лёгких путей?
Среди примеров к ASM есть «A ClassVisitor that prints a disassembled view of the classes it visits in Jasmin assembler format».
Вот он: http://websvn.ow2.org/filedetails.php?repname=asm&path=%2Ftrunk%2Fasm%2Fexamples%2Fjasmin%2Fsrc%2FJasminifierClassAdapter.java
А вот и тот самый ассемблер Jasmin, которым можно ассемблировать полученный при помощи вышеупомянутого посетителя листинг: http://jasmin.sourceforge.net/
Учитывая древность проблемного кода, вряд ли там было что-то, что не смог бы переварить Jasmin.
Я однажды столкнулся с подобной проблемой, только сорцов не было, т.к. либа была проприетарная. Декомпилировал один нужный мне класс, сделал проект с одним этим классом (в его оригинальном пакете), а исходную либу прицепил как зависимость. Скомпилировал и засунул в архив назад. Вроде так все было.
Этот дизассемблер отработал на ура в моем случае: github.com/Storyyeller/Krakatau. Отказался от JBE в его пользу, идеально для «поправить class файл».
У меня была такая же история, но не с явой, а с флешем.
кому интересно, заходите
Была одна нужная флешовая утилита. Захотел скачать её и юзать локально. Не работает. Путём экспериментов в Denwer'е выяснилось, что она проверяет домен, с которого запущена. ОК, будем крячить. Разобрал декомпилятором, пробил поиском нужную строку (имя домена), нашёл, запатчил… обратно не собирается — декомпилировалось криво. Хорошо — исправим в ассемблере. Разобрал Флеш Скальпелем (ассемблер/дизассемблер байткода ActionScript), снова нашёл строку, применил старую добрую инверсию условия (jne -> je и наоборот) и собрал назад. Заработало как часы.
Я чувствую, что пожалею о том, что спросил. Но серьезно — не стыдно такое в корпоративном блоге публиковать?
А почему может быть стыдно? Появилась проблема — решили. На будущее приняли решение (правда, только в комментариях), уменьшающее вероятность повторного наступания на те же грабли.
Я с вашего позволения оставлю ссылку на запись, в которой мы обсудили этот пост. Таймстэмп — в районе 01:53:15.
Есть одна проблема, которая порождает не до конца верные выводы. Если внутри компании теряются сорцы — это действительно бардак.
Но тут к в анекдоте — есть один ньюанс. Исходники библиотеки, используемой одним вспомогательным сервисом, потерялись не внутри компании, а при переходе из другой (причем, несколько лет назад).
Лично мне известен лишь один способ убедиться в том, что у вас есть все сорцы — все пересобрать. Это нетривиально даже для однородного проекта с одной кодовой базой. Но что если проект по-настоящему огромен? Если из 300+ сервисов все написаны в разное время, разными людьми и компаниями, на разных языках, с использованием разных систем сборки и систем контроля версий?
Всегда найдется краевой случай, когда кто-нибудь в одной из компаний закоммитит jar в репозиторий, вместо того, чтобы воспользоваться системой зависимостей (хотя, как известно, и это не гарантия).
Было бы здорово сделать выводы, как всего этого не повторить. Но бывают случаи, когда даже бэкап бэкапа, трижды проверенный и верифицированный, не спасет. И тогда есть три варианта:
1. Заплакать и убежать.
2. Переписать все 15 лет работы.
3. Подхачить.
Мы выбрали вариант №3, о чем собственно и статья.
Но тут к в анекдоте — есть один ньюанс. Исходники библиотеки, используемой одним вспомогательным сервисом, потерялись не внутри компании, а при переходе из другой (причем, несколько лет назад).
Лично мне известен лишь один способ убедиться в том, что у вас есть все сорцы — все пересобрать. Это нетривиально даже для однородного проекта с одной кодовой базой. Но что если проект по-настоящему огромен? Если из 300+ сервисов все написаны в разное время, разными людьми и компаниями, на разных языках, с использованием разных систем сборки и систем контроля версий?
Всегда найдется краевой случай, когда кто-нибудь в одной из компаний закоммитит jar в репозиторий, вместо того, чтобы воспользоваться системой зависимостей (хотя, как известно, и это не гарантия).
Было бы здорово сделать выводы, как всего этого не повторить. Но бывают случаи, когда даже бэкап бэкапа, трижды проверенный и верифицированный, не спасет. И тогда есть три варианта:
1. Заплакать и убежать.
2. Переписать все 15 лет работы.
3. Подхачить.
Мы выбрали вариант №3, о чем собственно и статья.
(Удалено)
Sign up to leave a comment.
Как мы себя заново писали, или как потерять исходники и не подать виду