Статья была впервые опубликована в публичном аккаунте:Доска газеты консервированных яиц
Автор работает в JD.com и хорошо разбирается в обеспечении стабильности, гибкой разработке, продвинутом JAVA и микросервисной архитектуре.
Во многих статьях делается акцент на том, чтобы не перепроектировать свою собственную систему, но не указывается причина, поэтому в этой статье перечислены некоторые классические перепроектирования, в надежде вдохновить вас, установить некоторый баланс в разработке, избежать чрезмерного проектирования, чтобы заставить нас подтолкнуть к другая сложность
1. Инжиниринг умнее бизнеса
Инженеры часто считают себя самыми умными, и эта первая ошибка позволяет легко переусердствовать. Мы планируем 100 вещей, и бизнес-сторона придумает 101-ю вещь, которую мы раньше не учли. Если мы решим 100 задач, за ними может последовать 1000 задач. Мы думаем, что все под контролем, но совершенно не представляем, что произойдет в будущем
За свою R&D карьеру я ни разу не сталкивался с тем, что бизнес конвергент по спросу, но они всегда расходятся, это истинное лицо бизнеса, а не вина продакт-менеджера.
2. Повторно используемая бизнес-функциональность
Когда бизнес-сторона выдвигает все больше и больше требований, наша первая реакция состоит в том, чтобы сгруппировать и максимально обобщить бизнес.Вот причина, по которой большинство архитектур MVC в конечном итоге нагромождаются большим количеством моделей или контроллеров.Как уже упоминалось раньше дела никогда не сходятся, они всегда расходятся
В системе общая логика и абстракции должны быть стабильными, однако, поскольку функции повторяются снова и снова, они либо останутся стабильными, либо станут хрупкими. Когда происходит обратное, система становится слишком большой, чтобы выйти из строя.
Например, есть бизнес, который реализует управление атрибутами пользователей, мы придерживаемся мнения, что все аналогично, сначала мы выполняем общую CRUD-логику, но это требование фактически требует 13 различных процессов регистрации, код логики не имеет никакого смысла. . Точно так же просмотр заказа и процесс просмотра редактирования заказа совершенно разные, но некоторые люди будут объединять представления.
Прежде чем делить бизнес по горизонтали, надо сначала попробовать разделить по вертикали, а заодно продумать работоспособность и удобство перехода с одного метода на другой, иначе переписывание системы будет катастрофическим трудом, то есть разделение Лучшее поведение чем принудительное слияние
3、Все стандартно
Если вам нужно подключиться к базе данных, напишите обобщенный адаптер
Если вам нужно запросить базу данных, напишите обобщенный запрос
Если вам нужно проверить параметры, то напишите общий валидатор параметров
Если вам нужно обернуть результат, напишите общий преобразователь данных
и т.д
При реализации требований тратится много времени на то, чтобы придумать идеальный уровень абстракции, даже если ответ на исходный бизнес-вопрос очевиден. Даже когда идеальная абстракция чудесным образом обобщается, она имеет тенденцию быстро становиться неприменимой, и лучший дизайн кода сегодня должен быть сосредоточен на коде, который можно легко удалить, а не на слепом поиске легкого расширения.
На самом деле повторяющийся код лучше, чем неправильная абстракция, а абстракция лучше только тогда, когда вы видите код, который логически повторяется в системе, и в то же время повторяющийся код раскрывает множество вариантов использования и помогает сделать ограниченный контекст понятным.
4. Мелкие обертки
Мы привыкли инкапсулировать слой внешних библиотек.Эта инкапсуляция неглубокая.К сожалению,мы склонны к двусмысленности между предоставлением функциональности и написанием хороших оберток, путая много бизнес-логики, делая это ни хорошей оболочкой, ни хорошим бизнесом решение. На самом деле, чтобы инкапсулировать высококачественную библиотеку, вам нужно потратить много времени на ее написание, обеспечив при этом высокое качество кода и его идеальное тестирование с понятным, тестируемым и измеримым API. Следует отметить, что инкапсуляция должна быть исключением, а не нормой, не инкапсулируйте ради инкапсуляции
5. Применение качества как инструмента
Высококачественный код обычно соответствует принципам SOLID и использует соответствующие шаблоны проектирования и методы кодирования, такие как фабрика, построитель, стратегия, дженерики и перечисления. Если вы применяете концепцию качества не задумываясь, например, изменяя все декорации переменных на закрытый финал, это не улучшит качество кодирования или изменит способ наследования цепочки в прошлом, каждый класс имеет интерфейс и реализацию, а затем inject Переходим на следующий уровень, кажется, он удовлетворяет концепции SOLID. На самом деле первоначальный замысел SOLID призван противостоять злоупотреблению наследованием и другими концепциями ООП, однако большинство инженеров не понимают, откуда эти концепции берутся и как они появляются.
Выучите другой язык, попробуйте делать что-то с другим мышлением и станьте лучшим разработчиком. Старое вино в новой бутылке нам не поможет, нам не нужно возиться с четким дизайном, чтобы применить новую концепцию
6. Синдром чрезмерно усердного усыновителя
Обнаружены дженерики и изменен простой «HelloWorldPrinter» на «HelloWorldPrinter», даже если на самом деле они имеют только определенный тип данных или имеют достаточно общих сигнатур типов.
Обнаружен шаблон стратегии, теперь каждый условный оператор является стратегией
Используйте всевозможные классные методы, такие как перечисления/методы расширения/черты везде
Все вышеперечисленное отражает проблему переоснащения
7.
Пример 1. Внедрите систему CMS, которая требует масштабируемости, и бизнес-персонал может легко добавлять поля
Результат: деловые люди никогда не используют эту функцию, просят инженеров помочь, когда им это нужно, возможно, все, что нам нужно, это простое руководство разработчика, чтобы добавить новое поле за несколько часов вместо интерфейса «укажи и щелкни».
Пример 2. Разработайте всеобъемлющий уровень базы данных, который можно легко настроить. Мы можем легко переключать источники данных с помощью файловой конфигурации.
Результат: По прошествии длительного времени по какой-то причине необходимо было сменить источник данных, но модификация конфигурационного файла не соответствовала нашим требованиям.Сейчас в бизнесе много функциональных пробелов, что приводит к несовместимости
На самом деле рекомендуется относиться к базе данных как к части решения, отбрасывая конфигурируемость, иначе сложно гарантировать совместимость. При проектировании спросите себя, каковы сценарии использования, а затем копните глубже, вы можете обнаружить, что большинство функций не нужны, включая настраиваемость, безопасность, расширяемость, ремонтопригодность и наследование. Короче говоря, не добавляйте функции, когда они не требуются, но четко определяйте и оценивайте сценарии, пользовательские истории, требования, способы использования.
Перевод статьи изменен с:
Источник статьи:www.liangsonghua.me
Об авторе: Лян Сунхуа, старший инженер JD.com, хорошо разбирается в обеспечении стабильности, гибкой разработке, продвинутом JAVA и микросервисной архитектуре.