Как вы реорганизуете интерфейс большого веб-сайта?

Question

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

Что хитро :

• Множество слишком сложных скриптов
• Слишком сложный CSS с колоссальным размером файла
• Нет тестов на селен
• Нет js тестов на месте
• Разработчики бэк-энда касались всего, что сломалось
• Сайт уже давно работает, и клиент доволен

Доступные инструменты :

• Несколько серверов для тестирования версий на
• Продолжение настройки интеграции
• Контроль версий

Answer 1

Некоторые мысли (после того, как были сделаны также большие рефакторинги, хотя больше на стороне сервера):

• создайте ветвь игры, где вы начнете «набрасывать» рефакторинг.там вы можете увидеть, как чувствует себя рефакторинг.Я часто нахожу, что особенно большие рефакторинги похожи на начало проектирования / программирования.Вы должны взять в руки и посмотреть, как ваша цель рефакторинга чувствует себя.Это также имеет большое значение для более точной оценки общих усилий.
• , так как ваш клиент доволен, и это больше инвестиции в будущее, применяйте поэтапный подход.Не делайте рефакторинг большого взрыва.Попробуйте разделить несколько областей рефакторинга (например, JavaScript или CSS), а также по страницам.
• Начните с более простых шагов рефакторинга.Они помогают вам «подойти» с более сложными.
• Сми - один из ваших самых больших друзей.Очень важно быстро вернуться и чувствовать себя в безопасности при рефакторинге.Даже в вашей ветке рефакторинга для более крупных работ вы можете создавать дополнительные «второстепенные ветви», чтобы выполнять большие шаги рефакторинга.
• регрессионные тесты жизненно необходимы.Получите тесты на месте в первую очередь.100% автоматизация тестирования вряд ли возможна, поэтому попросите одного из ваших членов команды QA / Test помочь вам пройти рефакторинг и регрессионное тестирование после каждого большого шага рефакторинга.«Это больше не работает» после 3-х месяцев рефакторинга просто сломало бы вас.
• для более сложных рефакторингов (сложно проверить) и нестабильная структура кода делают «парное программирование».
• Разработчики страха, не доверяющие большому рефакторингу, верны, относятся к ним серьезно и обращаются за помощью (особенно к требованиям регрессионного тестирования).

Answer 2

Вот несколько идей:

• Проведите несколько часов, просматривая сайт, просматривая его, получая представление о функциональности
• Обнуление основной страницы или страниц, которые вы хотитесосредоточить свои основные улучшения на.Потратьте час на это
• Начните смотреть на то, что важнее: A) удобство сопровождения / быстрая возможность для вас или кого-то другого зайти и расширить функциональность B) производительность загрузки страницы - как вы можете уменьшить ее на 100 КБ плюси подумайте, действительно ли это того стоит, исходя из типа сайта, это C) UI задержки.Как липкие, прерывистые переходы, как медленно сайт чувствует себя загруженным.

Придумай фигуру в голове.Это двухдневная работа для вас?2 недели?Какая польза от всего этого?Теперь подумайте, сколько времени может занять нового нанятого вами разработчика, которому теперь придется пройти через тот же процесс, что и вы, и быть на вашем уровне.

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

1. воссозданиета же иерархия файлов одной страницы на вашем собственном сервере, вне существующей медленной / ненадежной / изменяющейся среды / живого сайта или чего-либо еще, чтобы вы могли ускорить скорость, с которой вы собираетесь работать на этом (около 3/4 дня)
2. переключение свободного пространства между разработкой / исследованием / документированием чего-либо по ходу дела / прерываниями, управлением другими проектами и т. Д. (Приблизительно 1 час)
3. создание любых тестов, которые вы хотите, и разработка с нуля и эмуляция существующего фрагментаархитектура, написанная именно так, как вы бы этого хотели.(1 день для каждого компонента - html, accessibility, sass, js и т. Д.)
4. рассмотрите, как можно интегрировать этот единственный компонент в существующую архитектуру / среду и удалить существующий фрагмент, не нарушая ничего вокруг него.
5. интегрировать его обратно в окружающую среду.Время - деньги, но тщательное расследование, прежде чем приступить к проекту, защитит и подготовит вас к важному обсуждению с владельцем бизнеса.

Answer 3

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

Здесь вам определенно нужны тесты, потому что иначе наверняка будут некоторые ошибки или изменения, которые не нужны.Лично я перенесу сценарий в очень (!) Маленькие мусоры, чтобы вы могли очень быстро находить ошибки и запускать тесты для каждой мелочи, которую вы изменили.Это приведет к самым стойким результатам в моем опыте.

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

Answer 4

Ну, мне кажется, что главная проблема, с которой вы сталкиваетесь, - это отсутствие выхода из тестов JavaScript / Selenium. После того, как вы это сделаете, вы можете начать реальную работу по рефакторингу, делая небольшие шаги - уверенные, что ошибки будут обнаружены.

Никогда не проводите рефакторинг, не проведя тесты на месте.