Телеграмм чат группы pofftop страница 8335

И так и будет бесконечное переписывание одного и того же на разные подходы.

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

А вместо этого можно было бы просто продолжать разрабатывать с тем, что было. И объективно сделать больше, т.к. не тратилось бы море времени на переделки.

источник

22:13пожаловаться #10

AD

Aleksey D. in Programming Offtop

Konstantin Dovnar

И так и будет бесконечное переписывание одного и того же на разные подходы.

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

А вместо этого можно было бы просто продолжать разрабатывать с тем, что было. И объективно сделать больше, т.к. не тратилось бы море времени на переделки.

ну… какая-то доля времени на рефакторинг должна тратиться, но это про случаи, когда иначе никак не выкрутиться)

источник

22:20пожаловаться #11

ML

Mikhail Levchenko in Programming Offtop

Konstantin Dovnar

И так и будет бесконечное переписывание одного и того же на разные подходы.

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

А вместо этого можно было бы просто продолжать разрабатывать с тем, что было. И объективно сделать больше, т.к. не тратилось бы море времени на переделки.

Я же не говорю про переписывание каждый день

источник

22:23пожаловаться #12

AN

Alexander Nozik in Programming Offtop

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

источник

22:23пожаловаться #13

ML

Mikhail Levchenko in Programming Offtop

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

источник

22:23пожаловаться #14

AD

Aleksey D. in Programming Offtop

Alexander Nozik

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

тут самое сложное - переубедить бизнес выделять это время

источник

22:25пожаловаться #15

KD

Konstantin Dovnar in Programming Offtop

Mikhail Levchenko

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

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

источник

22:27пожаловаться #16

AN

Alexander Nozik in Programming Offtop

Aleksey D.

тут самое сложное - переубедить бизнес выделять это время

Ну так эффективные менеджеры должны быть эффективными

источник

22:28пожаловаться #17

ML

Mikhail Levchenko in Programming Offtop

Konstantin Dovnar

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

Если затрагивается большой кусок функциональности – полезным будет привести его в порядок

источник

22:30пожаловаться #18

AD

Aleksey D. in Programming Offtop

Alexander Nozik

Ну так эффективные менеджеры должны быть эффективными

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

источник

22:30пожаловаться #19

I

Igor in Programming Offtop

Anton Korotkikh

ну так выбирайся из ведра, рынок труда же огромен в рф

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

Задача стоит не в "сменить фронт на бэк", а в

- получить независимоть в использование подходов
- писать все в ФП стиле

источник

22:31пожаловаться #20