LINUX.ORG.RU

что делать с кодом?

 большие системы,


0

2

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

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

естественно люди и деньги --- все ценно, всего не хватает и вообще жалко.

переписывать сурово, поддерживать сложно, расширять архисложно. как быть? есть истории успеха?

поддерживать прямо скажем сложно

А вот с этого места можно по-подробнее. Что значит «сложно»?

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

Macil ★★★★★
()
Ответ на: комментарий от blexey

Если есть острая необходимость просрать <куча денег> и слить код налево без последствий — можно отдать код на растерзание компетентной конторе через тендер и т.п. формальности.

// dafix

shty ★★★★★
()
Ответ на: комментарий от vostrik

тут [..] Development а не Product Management

вот первое без второго приводит к таким тредам как этот

shty ★★★★★
()

ну, во-первых, поздравляю тебя дорогой «друк» это проект для настоящих камикадзе :)

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

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

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

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

PS купи себе лопату, ты в дерьме по уши :)

shty ★★★★★
()

А этот твой проект случаем не МВТУ (тот что SimInTech)?

solo1h
()

при таком обьёме кода ( если дельфи , то бери fpc)

начни с добавления в компилятор fpc(свою ветку) (который на вход вроде всё дельфи переваривает) всякого разного сбора статистики и крос линкинига Xref -лайка.

после получения в цвете на 3-метровой плазме всех возможных графов зависимостей (вызовов, данных и тп)

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

короче задача для фанатов автоматического компилинга - ожидаю в треде фанатов рефала.

qulinxao ★★☆
()

А если по теме, то моя история такая:

Есть, эм..., дофига рабочего говнокода - монолитное ядро системы. Написано все было лет 15 назад. Код каждый раз портируется под новыый набор штатного железа допиливанием острых углов и... система сдаетсяс в эксплуатацию. В один прекрасный день для очередной системы вся эта шняга завялась с черезвычайно большим верменем ответной реакции(over так 700% =). Допиливать отдали нам.

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

Чем все кончится - время покажет )

solo1h
()

Очевидно же, надо уволиться и дать фирме спокойно обанкротиться. Чем быстрее это случится, тем меньше пострадает человечество.

vasilenko ★★
()
Ответ на: комментарий от I-Love-Microsoft

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

значит писали балбесы-быдлокодеры-старперы

NO U!

я .. не супер-мега-хацкер-программист

Хорошо, хоть в тебе есть всё еще какой-то потенциал для исправления.

malbolge ★★
()
Ответ на: комментарий от Manhunt

Счет должен идти на десятки тысяч тестов

Это из разряда утопии. Я вот вижу что за год команда из ~150 человек осилилиа максимум тысячи три тестов написать всего, из которых интересных (регрессии, интеграция, компонентные - короче, не юнит тестов) хорошо если 300 наберется.

malbolge ★★
()
Ответ на: комментарий от Rastafarra

Ну, был у меня такой опыт, когда математики писали код в проект. Да, мышление у них не инженерное - это таксказать аксиома. Как мы выбрались их этого болота - как раз не модульно/хуёдульно/переписабельно, а серией мелкий рефакторингов в разных местах улучшали код. ИИЧСХ это спагетти улучшили, как минимум с т.з. связности и читаемости. Рассчитывать на одну итерацию рефактора даже не рассчитывайте.

malbolge ★★
()

оставить как есть?

А что с этим кодом собираетесб делать? Внести 1,5 фичи, или кардинально на многолет засесть за этот проект?

что с этим делать?

Зависит от ответа на предыдущий вопрос.

начать переписывать?

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

переписывать сурово, поддерживать сложно, расширять архисложно. как быть?

А как обычно делают? проводят декомпозицию одного большого куска на несколько более мелких, потом один из более мелких начинают изучать крутить-вертеть и улучшать, документируя. И так много-много раз до приемлемого вида.

malbolge ★★
()
Ответ на: комментарий от Rastafarra

2млн дельфикода? Херня. Я в одиночку не менее ~20% этого объема смогу в порядок привести за разумное время. Я-то думал это С++ какой, или еще что мрачное. А так... Дельфи всего лишь....

PS. Лукавлю, да :) Ибо нюанс - знание предметной области :) Но был случай что за 2 недели в 200000 строк дельфей (не говнокода) вкуривался баги-шняги подтирал.

malbolge ★★
()
Ответ на: комментарий от malbolge

Это из разряда утопии. Я вот вижу что за год команда из ~150 человек осилилиа максимум тысячи три тестов написать всего

Нет, не утопия. Наблюдал и наблюдаю IRL.

Можно посчитать. Если процесс нормально налажен, вполне реально скриптовать по тесту в пол-часа. В году примерно 2000 рабочих часов, так что в одно рыло за год пишется 2000 тестов - с учетом прочих активностей. Команда из 10 тестировщиков родит 20 тысяч тестов.

Интересно, а чем ваши 150 обалдуев занимались?

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

вполне реально скриптовать по тесту в пол-часа

ЩИТО?! Вы, наверное, про простейшие юнит-тесты тестирующие нечто очевидное. Как за полчаса можно заскриптовать тест, который (типичный случай для текущего набора проектов): 0. Поднять необходимую инфраструктуру для теста 1. Засосать тестовые данные в пачку БД 2. Отправить запросы сервисам, работающим с БД, получить ответы 3. Отправить выхлопы другим сервисам инфрастуктуры 4. И уже после обработки изучить их выхлоп на предмет совпадения с эталонным выхлопом? За полчаса даже инфраструктура не поднимается :) Реально я видел, что дня три команды на поодбное убивается, а если еще и моками обвешиваться - то и месяц незаметно проходит.

Команда из 10 тестировщиков родит 20 тысяч тестов.
а чем ваши 150 обалдуев занимались?

Очевидно, пивко попивали и в потолок поплевывали :)

malbolge ★★
()
Ответ на: комментарий от malbolge

0. Поднять необходимую инфраструктуру для теста
1. Засосать тестовые данные в пачку БД

пишется один раз и для нового набора данных добавляется строчка в конфиге

2. Отправить запросы сервисам, работающим с БД, получить ответы
3. Отправить выхлопы другим сервисам инфрастуктуры
4. И уже после обработки изучить их выхлоп на предмет совпадения с эталонным выхлопом?

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

За полчаса даже инфраструктура не поднимается

а у вас одна машина на всех, и запускать тесты надо там же, где они пишутся?

Реально я видел, что дня три команды на поодбное убивается, а если еще и моками обвешиваться - то и месяц незаметно проходит.

выкиньте своих тестировщиков на мороз с волчьим билетом

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

а у вас одна машина на всех, и запускать тесты надо там же, где они пишутся?

Отвлекаясь от подъебок - все очень по-разному - там сейчас что-то 14 агентов под винду и 2 под линукс - чиста чтобы билдить и гонять тесты (т.е. до вмешательства человека) + десятка 3 серверов на раличные нужды для разработки.

malbolge ★★
()
Ответ на: комментарий от malbolge

Вы, наверное, про простейшие юнит-тесты тестирующие нечто очевидное.

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

Как за полчаса можно заскриптовать тест

1. Тестер читает в тестплане, реакцию программы на какое воздействие он должен сейчас проверить.
2. Выполняет это воздействие вручную. Вручную убеждается, что поведение программы удовлетворительно.
3. Загоняет свои ручные воздействия в скрипт. Загоняет свои ручные проверки в скрипт. «Загоняние» сводится к вызову готовых функций тестировочной библиотеки.

Если всё идет совершенно гладко, то на эти действия достаточно 10 минут. Но поскольку гладко не бывает, то на разбирательства и въезжания ему отводится еще 20 минут.

0. Поднять необходимую инфраструктуру для теста

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

1. Засосать тестовые данные в пачку БД

Надеюсь, вы не печатали эти данные каждый раз заново в консоли СУБД? :D А шелловский скрипт зальет выбранную коллекцию данных за доли секунды.

2. Отправить запросы сервисам, работающим с БД, получить ответы 3. Отправить выхлопы другим сервисам инфрастуктуры 4. И уже после обработки изучить их выхлоп на предмет совпадения с эталонным выхлопом?

Ну и в чем проблема - три раза ткнуть мышкой и запустить комбинацию из sed-ов и diff-а?

За полчаса даже инфраструктура не поднимается :)

Ну так облегчите её. Должна подниматься со снапшота за единицы секунд.

Реально я видел, что дня три команды на поодбное убивается, а если еще и моками обвешиваться - то и месяц незаметно проходит.

Разруха не в клозетах, а в головах.

Очевидно, пивко попивали и в потолок поплевывали :)

Угу. Либо яростно колошматились головой об стенку. Третьего не дано.

Manhunt ★★★★★
()
Ответ на: комментарий от malbolge

не одобряю выбор ТС, но тогда мне в упор непонятно, кому интересно, за сколько _запускается_ тест и как его запуск тормозит написание тестов

vostrik ★★★☆
()
Ответ на: комментарий от malbolge

вот и мне непонятно, при чем здесь это:

За полчаса даже инфраструктура не поднимается

если речь шла о разработке

vostrik ★★★☆
()

переписывать и поддерживать пока работает. иначе никак.

Thero ★★★★★
()
Ответ на: комментарий от Manhunt

Я про функциональные тесты, имитирующие простые сценарии работы программы. Программа инсталлирована на тестовом стенде,

1. Ну вот у вас на одну программу 10 тестеров сидит. В нашем пандемониуме этих 10 чел на полсотни программ размазано :) 2. И я ж не про одну программу, а про программный комплекс. В нем этих программ как блошек.

хватит пары дюжин разных конфигураций инфраструктуры.

Уверяю вас - не хватит :) Часто на разработку даже одной фичи отдельной программы комплекса требуется не меньше пары подобных конфигураций. Вот и оцените в какую «пару дюжин» выливается тестирование для мало-мальски больших систем.

malbolge ★★
()
Ответ на: комментарий от vostrik

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

malbolge ★★
()
Ответ на: комментарий от malbolge

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

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

тащемта этим не тестировщик должен заниматься

совершенно правильно, для этого нанимается пачка билдинженеров. Но я полагаю, вы еще помните в контексте треда (большие системы, борьба со сложностью) тема тестов и конкретной организации тестирования - безусловно, важная, но не самая главная часть. Касательно конкретно тестов - @Manhunt со своей колокольни убежден, что написать 100500 тестов - не проблема, а если двумя руками писать, так это и все 201000 тестов вылетит. Я его понимаю - проект такой. Но его колоколенка - лишь одно из многих мнений, и никак не истина в последней инстанции.

malbolge ★★
()
Ответ на: комментарий от malbolge

написать 100500 тестов - не проблема, а если двумя руками писать, так это и все 201000 тестов вылетит

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

vostrik ★★★☆
()
Ответ на: комментарий от Manhunt

вполне реально скриптовать по тесту в пол-часа.

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

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

3. год (год!) угрохать только на написание тестов? без гарантий? :) год кормить десяток машинисток? :)

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Manhunt

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

ага, баттон1.онКлик. и...? дальше? :) лабел1.гетТекст? лабел2? :)

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Rastafarra

1. как тестить гуй и его поведение?

рискну предположить что DUnit'ом

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

про то, что существуют тестировщики, вам не сказали? жестокие

3. год (год!) угрохать только на написание тестов? без гарантий? :) год кормить десяток машинисток? :)

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

vostrik ★★★☆
()

Перепиши все на Си, будь мужиком!

anonymous
()
Ответ на: комментарий от anonymous

Лучше уж сразу haskell брать, зачем размениваться на эти jvm-язычки?

kamre ★★★
()
Ответ на: комментарий от Rastafarra

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

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

Ах,да ! Если рефкторинг, то в первую очередь отделяются мухи от котлет, то есть гуй от вычислительного ядра. Чтобы хотя-бы тестить по отдельности :)

MKuznetsov ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.