Два дня назад я сказал, что напишу проект для продолжения итерации.Многие мелкие партнеры выразили свою поддержку и одобрение.Разве это не первая часть проекта~
Я дал проекту название, английское название: austin, китайское название: austin
Никакого особого смысла в имени нет, мне просто кажется, что имя красивое, прямо скажем, оно мне нравится.
Называя проект, не говорите так грубо. Вы можете выбрать имя системы в соответствии с вашими собственными представлениями.Пока люди используют вашу систему, они, естественно, будут «делать то, что делают местные жители».
Не говоря ни о чем другом, давайте перейдем к сегодняшней теме.
Чтобы начать проект с нуля, вам также необходимо построить техническую среду, поэтому давайте сегодня поговорим о содержании построения технической среды.
План темы для этой статьи: Maven, SpringBoot и Git
Что такое МАВЕН? Зачем использовать MAVEN?
Мавен - это "управление проектом"Инструмент
Я помню, что когда я учился в колледже, я не использовал Maven, и каждый раз, когда я узнавал, самой неприятной вещью были различные зависимые jar-пакеты. Когда я узнал о Maven, моим первым впечатлением об этом инструменте было: эта штука "Управление пакетами зависимостей"Инструмент
После первого опыта я сказала, что это слишком ароматно! Больше не нужно искать баночки повсюду!
Фактически, Maven не только берет на себя функцию «управления пакетами зависимостей», но также выполняет «компиляцию», «тестирование», «упаковку», «развертывание» и другие функции при ежедневной разработке и использовании.
я здесьежедневное развитиеЧасто используемые команды maven:
1、mvn compile
2、mvn test
3、mvn clean
4、mvn pakage
5、mvn install
6、mvn deploy
7、mvn versions:set -DnewVersion=xxxx 设置Maven的版本
8、mvn dependency:tree 查看maven的依赖树（排查依赖很有效）
常用参数
-Dmaven.test.skip=true
-Dmaven.javadoc.skip=true
Многие серверные проекты Java теперь используют Maven в качестве инструмента «управления проектами», по крайней мере, это то, с чем я столкнулся.
Некоторым любопытно: в последние годы не было восходящей звездыGradleты
Если честно, то ни разу не пользовался(: Но тоже пошёл разбираться вкратце.
Насколько мне известно, в целом Gradle более гибкий и лаконичный, чем Maven, и в настоящее время используется для Android-проектов. Также есть очень важный момент, касающийся Maven,Gradle дороже учиться.
Сейчас бэкэнд-проекты на Java становятся все более и более легкими, и во многих случаях им не нужно быть такими «гибкими» (функций, предоставляемых Maven, в принципе достаточно). Для краткости, XML не является невозможным для чтения (в конце концов, сейчас все разрабатывают на IDE). Итак, на этот раз проект, который я построил, также напрямую использовал Maven.
Но ах, поскольку я не использовал Gradle в полной мере, я не могу сказать, что использую Maven лучше, чем Gradle (: Но, по крайней мере, на данный момент я думаю, что Maven еще может сражаться в течение 10 лет
ПОЧЕМУ SPRINGBOOT
На этот раз я выбираю SpringBoot в качестве базовой среды проекта, а насчет того, почему именно SpringBoot, я сначала поделюсь разговором в группе с вами.
Помню, однажды в группе маленький друг спросил: Я сегодня ходил на собеседование, и интервьюер спросил меня, в чем преимущества использования SpringBoot
Затем другой небольшой партнер ответил: «Самое большое преимущество использования SpringBoot в том, что он позволяет мне разрабатывать такой мусорный уровень.вошел в очередь, стал программистом.
Я изучил SSH и SSM в колледже, я не использовал Maven, когда изучал их, и особенно хлопотно было настроить среду. (В то время я также вел блог, чтобы записать, как я интегрировал SSH и SSM)
В проекте будет использоваться несколько стеков технологий, и разные стеки технологий должны иметь соответствующие конфигурации (общие Spring, SpringMVC, Mybatis) и т. д., а затем эти технологии должны быть совместимы с соответствующими версиями (обычно мы интегрируем эти технологии в Весна). Когда мы хотим представить новый фреймворк, нам, естественно, нужно выровнять версию Spring и иметь соответствующий файл конфигурации.
Это было действительно тогдаконфигурационный ад(Все фреймворки гибкие и помогают нам писать контент, который может потребоваться изменить в конфигурации XML, но со временем мы постепенно обнаруживаем, что не можем поддерживать эти конфигурации XML...)
На этом фоне и появился SpringBoot, что наиболее очевидно упрощает работу по настройке нашей разработки. Когда технология может уменьшить усилия по разработке, есть характеристика:соглашение о конфигурации(из коробки)
Пока SpringBoot введен, вы можете быстро написать соответствующий HTTP-интерфейс с нуля всего несколькими строками кода (см. Быстрый запуск SpringBoot на официальном сайте).
Прежде чем мы сделали такие вещи, нам нужно было интегрировать SpringMVC, нам нужно было настроить сервер Tomcat и нам нужно было выровнять их версии (независимо от того, были ли они совместимы)....
Я думаю, что как потребитель SpringBoot должен понимать следующие две вещи:
1. Когда в нашем проекте мы представили зависимости SpringBoot (spring-boot-starter-parent), нажмитеparentнайдуspring-boot-dependenciesЭтот помпон определяет многое "зависимости по умолчанию". Это избавляет от необходимости записывать версию, когда мы используем ее в проекте (поскольку SpringBoot уже записал ее за нас по умолчанию), и нам не нужно беспокоиться о конфликтах версий (:
Во-вторых, при запуске проекта SpringBoot это также поможет нам инициализировать многие конфигурации по умолчанию. (Это также место, которое часто осматривают для интервью».Автоматическая конфигурация»). В основном,@SpringBootApplicationЭквивалентно следующим трем аннотациям:
@SpringBootConfiguration@EnableAutoConfiguration@ComponentScan
в@EnableAutoConfigurationявляется ключом (включить автоматическую настройку), внутренняя фактически идет на загрузкуMETA-INF/spring.factoriesИнформация о файлах, затем фильтроватьEnableAutoConfigurationДанные ключа загружаются в контейнер IOC для реализации функции автоматической настройки!
Сейчас только что написанные Java back-end проекты в основном используют SpringBoot в качестве среды разработки (: В конце концов, это действительно круто
Меня, как программиста, больше всего раздражает иметь дело с различными конфигурациями окружения и зависимостями версий (настоящая грязная работа).Хотя мне нужно делать это только один раз много раз, я чувствую, что на самом деле это выглядит следующим образом:
Почему структура проекта многомодульная?
Я построил проект и назвал его: austin, а затем создал несколько модулей Maven в IDE, которые в настоящее время (могут быть добавлены позже):
- общий (основная информация -> конфигурация POJO/перечисления)
- поддержка (сбор данных-> DB/Redis/Elasticsearch)
- service-api (сервисный интерфейс)
- service-api-imp (реализация интерфейса службы)
- веб-интерфейс (HTTP-интерфейс)
Вначале, когда мы впервые научились писать код, мы не были в этом так уж привередливы.
Позже сказали субподряд, и код разных модулей писался в разные пакеты. Поэтому мы создадим новый соответствующий пакет (фактически папку) под проектом, например dao/service/controller
До сих пор он в основном разделен на модули, а коды различных обязанностей разделены на соответствующие модули. а такжеaustinнепосредственно подpomФайл обычно используется только для управления зависимостями (определение зависимостей и информации о версии в родительском pom и какой подмодуль необходимо импортировать)
<dependencyManagement>
<dependencies>
<!--mysql驱动包-->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.35</version>
</dependency>
</dependencies>
</dependencyManagement>
Так чем же этот подмодуль лучше предыдущего субподряда?
Предполагая, что мы заключаем субподряд, это эквивалентно записи всего кода в модуль. Каждый раз, когда мы модифицируем, нам нужно перекомпилировать весь модуль (возможно, я изменил только определенный класс реализации пакета Dao, но при компиляции весь модуль будет перекомпилирован).
Если это подмодуль, мы переходим непосредственно к модулюmvn compile -Dmaven.test.skip=trueВот и все.
Однако это только один аспект, и убедительность представляется недостаточной. Я думаю, самое главное, что после того, как мы разделим на модули, мы сможеммультиплекс
Например, сейчас у меняaustinВ этом проекте для обработки данных в это время мне нужно создать новый соответствующийFlinkзаявление. Может быть ограничено средой, код, связанный с flink, не будет написан наaustinпод проект
(Это всего лишь пример, который я хочу выразить так: зрелый проект часто охватывает всю функцию более чем одним адресом Git. В большинстве случаев разные функции будут разделены на разные проекты).
Под разными проектами очень вероятно, что вещи, которые нужно сделать, повторяются (например, мне нужно прочитать базу данных, чтобы получить данные). В настоящее время отражаются преимущества подмодулей: соответствующие пакеты jar (такие как пакеты поддержки и общие пакеты) могут быть импортированы напрямую.
Тогда вам не нужно писать один и тот же код в двух разных проектах (: можно использовать общий набор кода
Кто-нибудь задается вопросом, почемуapiа такжеapi-implОн разделен на два модуля? Это для того, чтобы: если вызовы RPC будут введены позже, то нам нужно будет только предоставитьapiМодуль выходит нормально.apiЗависимостей модулей, как правило, мало.
(Разрешение конфликтов версий — грязная работа. Люди, внедряющие ваш SDK, просто хотят использовать ваш сервис для получения соответствующей информации. Не давайте им много бесполезных зависимостей.)
Почему ГИТ
На данный момент полка проекта настроена. Я собираюсь загрузить проект в Gitee и повеселиться со всеми (:
Git — это инструмент контроля версий. ПучокaustinПосле управления Git каждый коммит, который я делаю, будет виден (: это особенно важно при совместной работе нескольких человек
Кроме того, с концепцией «версия» вы можете использовать Git для отката версии по желанию (есть лекарство от сожаления, которое нужно принять
Когда я впервые приехал на стажировку, компания использовала SVN (в то время у меня было очень смутное представление об инструментах контроля версий. В любом случае, на тот момент я считал, что нужно загружать написанный код на центральный сервер, но Можно сравнить сходства и различия каждой модификации)
Позже я связался с Git в компании (сейчас разработка в принципе неотделима от Git. Сама эта штука по-прежнему относительно проста в освоении, а пользоваться довольно круто)
Кстати, позвольте мне отправить волну команд Git, которые я использую каждый день:
1. git clone (克隆代码)
2. git checkout -b （新建分支）
3. git checkout (切换分支)
4. git add / git commit /git push （这几步我基本都是在IDE上用快捷键完成，很少自己敲命令）
5. git fetch (获取最新的修改信息)
6. git merge (合并代码)
7. git stash /git pop (有的时候临时会用，把代码放到暂存区中)
8. git reset --hard (代码写烂了，直接回退吧)
В общем, я использую командную строку для Git и встроенный в IDE инструмент. В общем, как вам удобно (нет предела сказать, что вы должны использовать командную строку, я делаю то, что делаю быстрее)
Для этого проекта главная причина, по которой я использую Git, заключается в следующем: у меня есть удаленный репозиторий для загрузки моего кода, и вы можете видеть (:
Ссылка на гите:gitee.com/austin
Ссылка на гитхаб:github.com/austin
Суммировать
Честно говоря, если вы еще не работали, рекомендую узнать больше об основах использования Maven и Git (так вам не придется путаться, когда вы идете в компанию)
Изучение SpringBoot бесконечно. Мое личное понимание состоит в том, что после понимания использования вы можете попытаться извлечь уроки из «вопросов интервью» (в конце концов, большинство вопросов интервью являются относительно основными, по крайней мере, не частичными. бесполезно)
сборка проекта Остина:
- Maven: диаметр пакета зависимостей + управление проектом (многомодульность)
- SpringBoot: построение базовой технической среды (из коробки)
- Git: инструмент контроля версий (загрузка кода в удаленный Gitee)
Приходи сюда сегодня. Я потратил одну ночь на сборку полки и две ночи на написание этого поста. С тех пор, как мне пришла в голову идея этого итеративного проекта, моя эффективность в ночное время резко возросла.
Обратите внимание на мой публичный аккаунт WeChat【Java3y】Давайте поговорим о другом!
[Онлайн-интервьюер + написание Java-проектов с нуля]Непрерывное высокоинтенсивное обновление! Спросите звезды!
Оригинал это не просто! ! Проси три! !