IK
Я уверен, что полностью переписывать почти всегда плохая идея
Size: a a a
2020 February 17
LL
Я уверен, что полностью переписывать почти всегда плохая идея
Не соглашусь. Иногда полностью переписать получается проще, чем чинить сотни багрепортов всем отделом
M
Чем ужаснее код, тем обычно теснее он завязан на бизнес процессы. И либо ты останавливаешь разработку всего и вся на полгода пока переписываешь (я утрирую но все же), либо ты начинаешь ступенчатые улучшения. Так вот во время этих улучшений ты просто рефакторишь наследие предков
Не всегда это работает. Хотя эволюционный подход понятное дело лучше революционного.
AN
Не соглашусь. Иногда полностью переписать получается проще, чем чинить сотни багрепортов всем отделом
по-хорошему на проде это надо делать частями, все переписать практически нереальная задача, т.к.:
- бизнес всатнет
- фичи не делаются
- ни у кого нет полного понимания архитектуры приложения
- не факт что получится лучше из-за большого объема работы в сжатые сроки
а если переписывать частями, перед этим покрыв тестами по всем бизнес кейсам, то в итоге получится и быстрее, и лучше, и все минусы выше отпадают
- бизнес всатнет
- фичи не делаются
- ни у кого нет полного понимания архитектуры приложения
- не факт что получится лучше из-за большого объема работы в сжатые сроки
а если переписывать частями, перед этим покрыв тестами по всем бизнес кейсам, то в итоге получится и быстрее, и лучше, и все минусы выше отпадают
AN
но иной раз проще рядом поднять эндпоинт api/v2/ и зафигачить все с нуля)
LL
по-хорошему на проде это надо делать частями, все переписать практически нереальная задача, т.к.:
- бизнес всатнет
- фичи не делаются
- ни у кого нет полного понимания архитектуры приложения
- не факт что получится лучше из-за большого объема работы в сжатые сроки
а если переписывать частями, перед этим покрыв тестами по всем бизнес кейсам, то в итоге получится и быстрее, и лучше, и все минусы выше отпадают
- бизнес всатнет
- фичи не делаются
- ни у кого нет полного понимания архитектуры приложения
- не факт что получится лучше из-за большого объема работы в сжатые сроки
а если переписывать частями, перед этим покрыв тестами по всем бизнес кейсам, то в итоге получится и быстрее, и лучше, и все минусы выше отпадают
Я просто написал это к тому, что в таких подходах нельзя быть однозначными
AN
ну да, тут надо взвешивать все за и против. Но обычно решение принимает один человек, он же и переписывает потом... вот ему-то и надо во время услышать, что так лучше не делать) или делать только в самом крайнем случае, перед этим потренировавшись на микросервисе в 100 строк.
DS
но иной раз проще рядом поднять эндпоинт api/v2/ и зафигачить все с нуля)
У меня так сейчас 3 клиентских модуля которые надо поддерживать, то еще увлекательное занятие
IK
Не соглашусь. Иногда полностью переписать получается проще, чем чинить сотни багрепортов всем отделом
На практике, это мало у кого получалось
IK
по-хорошему на проде это надо делать частями, все переписать практически нереальная задача, т.к.:
- бизнес всатнет
- фичи не делаются
- ни у кого нет полного понимания архитектуры приложения
- не факт что получится лучше из-за большого объема работы в сжатые сроки
а если переписывать частями, перед этим покрыв тестами по всем бизнес кейсам, то в итоге получится и быстрее, и лучше, и все минусы выше отпадают
- бизнес всатнет
- фичи не делаются
- ни у кого нет полного понимания архитектуры приложения
- не факт что получится лучше из-за большого объема работы в сжатые сроки
а если переписывать частями, перед этим покрыв тестами по всем бизнес кейсам, то в итоге получится и быстрее, и лучше, и все минусы выше отпадают
Яростно плюсую
AM
Помню пилили проект, чтобы побыстрее выйти в бету срезали углы везде где только можно, по итогу не смогли выйти из беты из-за перфоманса. Долго не могли найти ресурсов на улучшение, в итоге когда нашли наконец окно то справились за пару недель. В итоге если бы сразу нормально сделали, то продукт релизнули бы на год раньше. Но эксельки с оценками были беспощадны
V
Помню пилили проект, чтобы побыстрее выйти в бету срезали углы везде где только можно, по итогу не смогли выйти из беты из-за перфоманса. Долго не могли найти ресурсов на улучшение, в итоге когда нашли наконец окно то справились за пару недель. В итоге если бы сразу нормально сделали, то продукт релизнули бы на год раньше. Но эксельки с оценками были беспощадны
Пилили новый или перепиливали?
На каком языке?
"Перфоманс" - это производительность? Т.е. бета тупила нещадно?
На каком языке?
"Перфоманс" - это производительность? Т.е. бета тупила нещадно?
IK
Кстати, есть кто решал продакшн проблемы с rethinkdb?
AM
V
Пилили новый или перепиливали?
На каком языке?
"Перфоманс" - это производительность? Т.е. бета тупила нещадно?
На каком языке?
"Перфоманс" - это производительность? Т.е. бета тупила нещадно?
На джаве конечно, у нас серьезная организация. Перепиливали старое непроизводительное. Бета да, не могла нормально переварить объемы продакшн данных
V
На джаве конечно, у нас серьезная организация. Перепиливали старое непроизводительное. Бета да, не могла нормально переварить объемы продакшн данных
В чём была причина ошибки с производительностью?
Не техническую имею ввиду, а на уровне планирования и постановки задач.
Не техническую имею ввиду, а на уровне планирования и постановки задач.
AM
V
В чём была причина ошибки с производительностью?
Не техническую имею ввиду, а на уровне планирования и постановки задач.
Не техническую имею ввиду, а на уровне планирования и постановки задач.
Казалось, что делать нормально дольше и дороже
V
Казалось, что делать нормально дольше и дороже
Делать нормально - всегда дольше и дороже. Почему сделать быстрее и дешевле казалось допустимым по качеству? Не произносилось ли случайно на планёрках слово "ЭмВиПи"?
2020 February 18
LL
На практике, это мало у кого получалось
Лично был свидетелем, где клиентам предложили перейти на новую версию продукта с урезанным функционалом, но с
1) большей производительностью
2) большей дружелюбностью к пользователю
3) современным UI
И все клиенты согласились, а древнее легаси быстро и тихо забыли.
Если что, я говорю, про Qt приложение, где была поддержка версий от WinXP до Win10
1) большей производительностью
2) большей дружелюбностью к пользователю
3) современным UI
И все клиенты согласились, а древнее легаси быстро и тихо забыли.
Если что, я говорю, про Qt приложение, где была поддержка версий от WinXP до Win10
AM
V
Делать нормально - всегда дольше и дороже. Почему сделать быстрее и дешевле казалось допустимым по качеству? Не произносилось ли случайно на планёрках слово "ЭмВиПи"?
Да-да, произносилось конечно. Акцент на том, что после того как переделали нормально, это оказалось гораздо быстрее, чем когда изначально чесали репу. А релиз отложило далеко
V
> У нас серьёзная организация
Напомнило:
Напомнило:
На флоте любое начинание всегда делится на четыре стадии:
первая - запугивание;
вторая - запутывание;
третья - наказание невиновных;
четвертая - награждение непричастных.