Через экран не пахнет)

Не легче) эт прям гарантированно. Мысли всё снести и написать, как надо, до добра не доводят)

Не легче) эт прям гарантированно. Мысли всё снести и написать, как надо, до добра не доводят)

ну почему же? вполне может быть и легче

но для этого надо видеть примерно код, что бы точно говорить))

ну почему же? вполне может быть и легче

Зависит по большей части от бизнеса. На скок времени он готлв проебать разраба. С учётом, что может ничего не получиться, или станет хуже (например, так же, но под другим соусом)

Зависит по большей части от бизнеса. На скок времени он готлв проебать разраба. С учётом, что может ничего не получиться, или станет хуже (например, так же, но под другим соусом)

для этого надо видеть контекс

не просто jqyery а планомерно интегрировать vue

(хотя хз почему вы так vue любите но это не мне судить о вкусах)

ну и "vue" вроде пока в нормальные подходы не полностью умеет (typescript))

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

короч ладно, надо еще разбираться что там в этом твоем jquery файлике

так это пустое нытье о тяжелой судьбе

ну да, ты мне будешь это рассказывать)

ну и "никаких кукисов для бизнес логики" - это пока у тебя не возникнет желания делать a/b тестирование какое

да и в целом это никакого отношения к SPA не имеет

я лишь к тому что ты выбираешь между: - переносить на SPA отдельные страницы по чуть чуть инкрементно повышая качество продукта - потратить 2-3 месяца на то что бы переписать все. то есть если бизнес устраивает что они не смогут никаких новых фич за 3-4 месяца запихнуть в скоуп - ну ок

ну вот у меня сейчас такая же история

бизнес не устраивает перенос всего скопом потому я переписываю покусочно

Да, так и работает. Тебе вообще за решение проблем платят а не за поиграться с webpack

мб не в коде вопрос?) блин, странное чувство дежавю)

ты случаем не в германии работаешь?)

это утопия

не, я так) просто спросил)

говорю же, странное чувство дежавю)

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

тут у всего чата был опыт общения с человеком с подобным опытом

наверно когда дешевле и проще рядом поднять такой же сервис(api) но которые будут понятны и поддерживымаемы и использовать стек технологий

чем брать апи которое написано чуть чуть на joomla, потом ошметки на kohana, и все это покрыто сверху первым yii например но не доконца, а с бд работа тоже идет по разному и куча легаси данных

и еще где то там внутри свой велосипед для работы с бд и получается там работа напрямую с бд через pdo, через active record от yii, через active record от kohana, велосипеды джумлы для работы с данными, свои велосипеды.

так-то бывает и хуже. Но всё это вполне можно изолировать и исправить

ну да все можно исправить вопрос цены

бывает и намного хуже видел проекты еще и хуже, magentoo +zend1 +symfony2 + свои велосипеды (и еще кучка других фв)

в мадженте зенд ток для запаха подмешали)

чтобы такое исправить надо уметь объяснить бизнесу что все тормозим разработку новых фитч

и всей командой хуярим нормально

но чтобы такое сделать надо чтобы уровень команды был соответствующим

и производительность команды

чтобы не получилось так что взял например лару 5.6

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

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

затянулось на год, вышла лара 6 например

а у вас на половину переписано

и так в зоопарк легаси добавили еще лару )))

таким образом все фв и появлялись в списке

Кстате кто какие способы знает по вытаскиванию проектов из жопы?

Я знаю 2 способа и даже несколько раз участвовал в гих

Главное руководство убедить в необходимости, получив время на ректальную процедуру)

берешь любой факап

с выкладкой релиза

затягивания сроков

или когда выложили релиз а он сломан и понесли финансовые потери

с тем что некоторые типовые действия делают слишком долго а значит дорого (надо оплачивать время)

что фитчи которые ставятся в очередь откладываются на несколько кварталов

пример из жизни после нг маркетологи говорят надо сайт к 8 марта разукрасить цветочками акцию и тд замутить

а там по плану задач столько что

ERROR: S client not available

ты говоришь за задачу возьмуться не раньше сентября и это оптимистично

и не факт что к следующему году к 8 марта успеем

а маркетолагам что ? им похуй они не слушают

говорят делайте

тут должен был быть анекдот про мебель в борделе.

ты берешь задачу прикидываешь 100часов например

и оринтируешься на сентяборь, думаешь к октябрю будет

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

а мы говорим так мы же говорили не раньше октября

и они не довольные

идут жаловаться

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

тех долг решать, потом он машет рукой и дает пол года

летом все в отпусках хули делать )))

ну и ты потом или делаешь збс или больше никогда не дадут пол года)

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

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

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

у меня 2 клавиатуры, другой ногами работаю

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

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

это всё следствие неправильного подхода)

Всем привет ,народ где можно скачать книги по front/back-end бесплатно.

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

Всем привет ,народ где можно скачать книги по front/back-end бесплатно.

Тут можете поискать https://t.me/itliba

​​Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems (2018) Авторы: Мартин Клеппман #databases #books При увеличении приложения данные о его пользователях начинают расти и способны тормозить работу сервиса. Чтобы этого не происходило, приложение требуется правильно обслуживать. В этом пособии вы прочитаете о ключевых принципах, алгоритмах и решениях, необходимость которых тем более очевидна при разработке высоконагруженных систем для работы с данными. Весь материал в книге рассматривается на примере внутреннего устройства популярных фреймворков и программных пакетов. В книге рассматриваются следующие темы: ➕ основы информационных систем; ➕ распределённые данные; ➕ производные данные; ➕ будущее информационных систем и многое другое. Недостатки: ➖ не обнаружено.

Есть у кого-нибудь?

Тут можете поискать https://t.me/itliba

Спасибо

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

не все могут сформулировать тз