Мы находимся в этой же лодке в моем бизнесе: первая фаза прошла в направлении, которое сработало, но не было идеальным. Вторая фаза изменила бизнес-модель и логику ..... эта фаза была офшоринга, что само по себе не было бы проблемой, если бы компания действительно поняла рамки, которые они решили использовать.Итак, здесь мы пытаемся закончить фазу 3 (отменив беспорядок фазы 2, правильно используя структуру, как она была задумана), в то же время оплакивая работу над такой плохо написанной кодовой базой. Существовали серьезные проблемы - использование двух javascript-фреймворков, неуклюжий пользовательский интерфейс, нежелательный код и большое обновление для фреймворка, которое делает версию, на которую мы устарели и почти невозможна, перейти на новую версию.
Вот что мы решили сделать ... это может быть не идеально для вашей ситуации. Во-первых, наш вице-президент по разработке продукта занял две недели и полностью переработал структуру базы данных. Он решил, что наш персонал по программированию может изменить существующий код, если это необходимо, чтобы разместить надлежащие эффективные структуры БД. Как только этот (болезненный) шаг был сделан, мы сделали двухнедельный перерыв, чтобы добиться прогресса в новых функциях. Затем я отступил от своих обязанностей, чтобы полностью реорганизовать пользовательский интерфейс, не используя одну структуру Javascript, так что мы находимся на одной общей платформе (какая концепция, подсказка - ужасная оффшорная компания ...) и эффективное использование современных, эффективных, текущих элементов пользовательского интерфейса. Мы будем следовать задаче 80% -20%, пока продукт не будет готов к бета-тестированию - 80% достигнут окончательных требований, 20% -ный код рефакторинга и очистку прежнего беспорядка. Каждому сотруднику была предоставлена область, в которой они отвечают за «очистку» или повышение эффективности. Документация процессов также является задачей, которая была делегирована и является необходимым процентом рабочей недели каждого сотрудника.
Я думаю, что ключом к успеху нашего процесса является взгляд на фазу 4 еще до завершения фазы 3. Новый код строится с максимальной эффективностью и взаимозаменяемостью, поэтому, если и когда мы покинем эту устаревшую платформу, потребуются минимальные изменения. Я экспериментирую с возможностью разделения наших процессов (а не только на код), чтобы теоретически их можно было по отдельности переместить в новую структуру, когда пришло время. Наши планы на будущее находятся на бумаге, при этом разрабатывается список требований и ведутся исследования для поиска лучших инструментов. Самое главное, лидер команды является хорошим игроком в правильном и эффективном действии, поэтому ничто из настоящего или будущего не продвинется вперед, это не сделано правильно.
Трудно оправдать руководство, что вам нужно идти назад, чтобы идти вперед. Это еще сложнее, когда будущее вашей компании зависит от продукта, который застрял в бета-версии, как и мы. Я сравниваю это с тем, чтобы тратить больше денег на экономичное топливо ... теперь это будет стоить дороже, но в конечном итоге это принесет огромные финансовые награды. Я думаю, что хитрость к успеху в этой ситуации - найти медианную для вашего продукта, где она «достаточно хороша», чтобы стоять в одиночестве, пока вы тратите время, чтобы сделать продукт отличным. Разработка стратегии для решения этой медианной проблемы будет препятствовать тому, чтобы бизнес-единица была терпеливой, и в конечном итоге сделает вас героем, когда ему это удастся. Разработайте прочный план, сообщите этот план, хорошо поработайте с другими и отработайте свой хвост. В мгновение ока вы снова будете наслаждаться жизнью!
Да, я немного читал об обсуждении перезаписи и рефакторе ... в этом случае, хотя это не переписывание. Я на самом деле добавляю функции и размышляю, не стоит ли тратить много времени на поиск существующего кода, который я мог бы использовать повторно, чтобы избежать дублирования ... или просто написать все для новых функций и быть комфортным в моем бюджете времени, а затем рефакторировать дублирующий код в более позднее время. Никакой старый код не будет затронут. –
лучшее, что я мог предложить, не глядя на базу кода, - это узнать о старой базе кода. в первой статье мне очень нравится, потому что это напоминает мне, сколько времени и усилий исправления ошибок ушло в устаревшие вещи. почему этот-то странный случай? вероятно, потому, что кто-то провел неделю, разыгрывая непонятную ошибку. не злоупотребляйте глобальными переменными, если вам не нужно - и иногда унаследовательность настолько изобилует ими, что вам нужно, потому что глобалы теперь являются частью «интерфейса». возвращая много воспоминаний о 20-летнем fortran 2 работах назад. :-) – eruciform
Я согласен, я понимаю, что происходит довольно много переменных, и это не так сильно и сухо, я полагаю, поэтому я задаю вопрос. Я думаю, что я могу попробовать и получить лучшее от обоих миров - дать себе х количество времени, чтобы найти код для повторного использования, а затем перейти оттуда. –