Идея этого блога состоит в том, чтобы пройти через некоторые вопросы, которые вам нужно будет задать, чтобы выяснить, что вы можете сделать, и сможете ли вы изменить ситуацию или просто закончите тем, что выбираете по краям. никуда.
Итак, какие вопросы вы должны задать? Первое, что нужно выяснить — чего хочет добиться клиент? Какое будущее они предвидят? Куда они хотят пойти? В конце концов, вы обычно работаете над их кодом.
Предполагая, что ваш клиент хочет, чтобы вы продвигали его кодовую базу, вам нужно подумать, как вы собираетесь этого добиться. Это будет революция или эволюция ?
Революция или большой подход переписывания всегда, кажется, терпят неудачу. В лучшем случае вы переписываете свое приложение в это приложение-убийцу со всеми новыми функциями, но при переписывании основных функций вы потеряете позиции для своих конкурентов. В худшем случае вы в конечном итоге будете повторять ошибки, которые были допущены в первый раз, и ваша кодовая база все равно выродится в такой же беспорядок. Я всегда предпочитаю эволюционный подход, поочередно исправляя различные части кода, в то же время поддерживая работу всего приложения.
Вы должны также рассмотреть, как приложение построено. Придерживается ли это 10-минутного правила сборки ? Есть ли машина CI? Использует ли он Maven или Ant или что-то еще полностью? Если вы не используете Maven, то я предлагаю попытаться принять это как способ сделать что-то, хотя на самом деле реализация Maven может быть намного проще, чем получить разрешение на его использование. Политика эх …
Является ли Codebase модульной или аморфной массой?
Попробуйте выяснить, думал ли кто-нибудь о разделении кодовой базы на отдельные модули. Это хорошо наслоено или все вставлено в пакет по умолчанию? Если все это вместе, попробуйте разделить разные модули — по одному. Помните, что Maven предпочитает меньшие модули, чем Ant. При разделении модулей выберите, следует ли работать на уровне слоев (например, DAO и Business Logic) или на основе функциональных возможностей (например, «записать встречу»).
Это блюдо спагетти-кода?
Если код напоминает кучу спагетти, это не конец света, потому что вы можете задать следующий вопрос:
Есть ли в коде какие-либо юнит-тесты?
Если у него нет модульных тестов (и это не редкость), тогда начните писать некоторые. Чем больше тестов, тем лучше. При необходимости возьмите каждый класс и начните создавать некоторые модульные тесты. Это придаст вам уверенности в рефакторинге кода с применением обычных принципов SOLID. Начните с принципа единой ответственности и продолжайте применять его на уровне метода и класса, проходя повторное тестирование каждый раз, чтобы эти тесты прошли успешно. При использовании модульных тестов код спагетти должен скоро распутаться.
Если у него есть тесты, они хороши?
Есть тесты и есть тесты. Выясните, действительно ли тесты что-то значат. Относятся ли они к каким-либо сценариям или требованиям? Я видел тесты, которые просто сказали:
|
1
2
|
String result = testInstance.doSomething();assertNotNull(result); |
… И где результат — сложная строка XML. В этом случае проверка довольно бессмысленна, так как вам нужно убедиться, что строка XML — это ожидаемая строка XML, что обычно требует много анализа и проверки. Так что, если тесты бесполезны, напишите еще.
Следовали ли предыдущие владельцы хорошей или плохой практике?
Одна из худших практик, которые вы видите, — это старое доброе программирование « вырезать и вставить» . Может быть, ошибка, возникшая в одном классе или JSP, и кто-то пришел и нашел немного кода, который исправляет его где-то еще в базе кода и скопировал в сломанный класс. Когда это происходит, кодовая база становится ненужной, становится беспорядком, и когда дело доходит до исправления ошибки в вставленном коде, вы исправляете ее два, три, четыре раза и т. Д. ЭТОГО НЕ НУЖНО. Как гласит старая поговорка: «Не повторяйся сам» или «Дублирование — это зло»… Если вы когда-нибудь окажетесь в такой ситуации, самое малое, что вы можете сделать, — это создать простой статический вспомогательный класс и повторно использовать его код.
Унаследованный исходный код следует рассматривать как возможность применять инструменты в вашем наборе инструментов, будь то разработка через тестирование, принцип единой ответственности, непрерывная интеграция, внедрение зависимостей или что-то еще, но, сказав, что в конечном итоге вам нужно выяснить, что именно клиент хочет, чтобы ты сделал. Достаточно ли они уверены, чтобы позволить коду развиваться и совершенствоваться, или, возможно, потому что другие программисты не добавили никаких модульных тестов, они боятся что-то изменить в случае, если вы его тормозите? Если они боятся перемен, то все, что вам нужно сделать, это просто выбраться по краям и не добиться успеха. На этом этапе мне действительно следует поговорить о воспитании доверия клиентов, совместной работе, профессиональных отношениях и общении, но всегда помните, что в глубине души вы всегда должны знать, когда уходить…