프로그래밍 「 추천 편」Java 풀 스택 개발자에게 필요한 기술은 무엇입니까?

소프트웨어 개발에는 다양한 방향이 있으며 결과적으로 서로 다른 경력 경로가 포함됩니다. 그들 중 많은 사람들이 매우 간단하지만, 말하자면 가장자리에 위치한 다른 소프트웨어 엔지니어링 직업도 있습니다. 이미 Java를 배우기로 결정했다면 Java Full Stack 개발자와 같은 소프트웨어 엔지니어링 작업에 대해 이야기해야 합니다.

Java 풀 스택 개발자는 누구입니까?

풀 스택 개발자를 정의하는 가장 간단한 방법은 "소프트웨어의 백엔드 (서버 측)와 프론트 엔드 (클라이언트 측) 모두에서 작업하는 엔지니어"입니다.

직무 설명 및 일반적인 대화에서 "풀 스택"이라는 용어는 지원자가 매우 특정한 영역에서만 작업하기 위해 다소 좁은 엔지니어링 기술을 갖는 유용성의 개념과는 대조적으로 더 넓은 기술을 공개하고 다른 영역에서 더 T 자형이며 능숙하다는 것을 입증 할 것으로 예상된다는 것을 구체적으로 (어느 정도까지) 강조하기 위해 사용될 수 있습니다.

프로젝트의 복잡성과 세부 사항에 따라 풀 스택 개발자는 소프트웨어의 특정 부분을 담당할 수도 있고 담당하지 않을 수도 있습니다.

예를 들어, 회사에는 복잡한 데이터베이스 관련 논리를 다루는 전담 데이터베이스 개발자, 프론트엔드 작업의 상당 부분을 수행하는 웹 디자이너(그래픽 디자이너와 혼동하지 말 것) 또는 모든 배포 및 유지 관리를 인수하는 DevOps 엔지니어가 있을 수 있습니다. 그들 모두는 풀 스택 개발자의 판에서 특정 작업을 수행합니다.

특히 대기업과 팀에서 일반적인 풀 스택 개발자는 두 부분에서 50/50 비율로 작업하지 않습니다. 대부분의 경우 이 사람은 영역 중 하나(프론트엔드 또는 백엔드)에서 더 깊이 작업하지만 다른 영역에서도 제한된 작업을 수행합니다. Java Full Stack Developer에 대해 구체적으로 이야기하면 Java 기반 백엔드에 약간 더 많이 노출될 가능성이 큽니다.

그렇다면 Java Full Stack 개발자가 되려면 어떤 기술이 필요합니까? 부분적으로 자세히 살펴 보겠습니다.

 

Java Full Stack 개발자가 되기 위한 리소스

1. 코드짐

CodeGym : 고급 프로그래밍 온라인 교육 플랫폼

사실, CodeGym은 가장 진보된 온라인 교육 플랫폼 중 하나이며, 온라인 교육의 주요 영역이기 때문에 Java를 배우고자 할 때 특히 좋습니다. 가장 기본적인 과정부터 시작하여 Java 구문, 핵심 개념, 데이터베이스 계속 및 선택한 스택을 매우 고급 챕터까지 익힐 수 있습니다.

또한 게임화된 방식으로 흥미진진한 학습 경로를 탐색하고 Snake 또는 Mine Picker와 같은 인기 있는 게임의 고유한 버전을 만들 수도 있습니다. 이 플랫폼은 또한 좋은 지원을 받을 수 있는 광범위한 동료 학생 커뮤니티에 대한 액세스를 제공합니다.

2. Pluralsight의 Java 기초

Pluralsight : 고품질의 Java 코스가 많이 포함 된 멋진 플랫폼

Pluralsight는 초보자부터 고급 개발자까지 다양한 수준의 고품질 코스 세트를 제공했지만 후자의 코스 수는 제한되어 있습니다. 이상한 것은 없으며 최고 수준의 전문가의 필수 학습 및 지원만 있으면 됩니다. 특히 초급 및 중급 수준의 경우 모든 중요한 주제를 철저히 다루었으며 최종 결과는 첫 번째 앱을 작성하는 것임을 확신할 수 있습니다.

3. 자바 개발자를 위한 Kotlin

JetBrains의 Kotlin on Cousera: 기술 제작자로부터 배우기

기술을 배우는 가장 좋은 방법은 제작자의 말을 듣는 것입니다. JetBrains의 Coursera 과정을 통해 Java와 상호 운용 가능한(대부분의 경우 JVM에서 실행되는) 최신 언어인 Kotlin을 접할 수 있으며, Android 개발을 위한 공식 선호 언어로 간주되지만 요즘에는 백엔드 개발에도 널리 사용됩니다.

Kotlin에 익숙해지면 특히 최신 스택 프로젝트와 젊은 팀을 찾고 있는 경우 구직 옵션이 크게 확장되고 경험에 많은 도움이 됩니다.

백엔드(Java) 기술

핵심 Java 및 Java 에코시스템

가장 먼저 해야 할 일: 소프트웨어 엔지니어(모든 종류)가 되려면 일반적으로 코딩을 배워야 합니다. 선택한 언어가 Java라는 점을 감안할 때 언어의 구문, 기본 및 개념과 같은 "핵심" Java 기술 세트를 얻는 것으로 시작합니다.

사실 이미 이 작업을 마쳤을 수도 있지만, 그렇지 않은 경우를 대비하여 변수와 리터럴, 루프와 if-else 절, 배열과 컬렉션, 클래스와 인터페이스, 예외, 멀티스레딩의 기초, 이 모든 중요한 주제는 맨 처음에 배우게 될 것입니다. 이를 수행하는 가장 좋은 방법은 고전적인 "필독" 책이나 좋은 온라인 교육 플랫폼을 사용하는 것입니다(자세한 내용은 아래 참조).

Java의 세계에서 자신을 발견하는 동안 Java 생태계를 더 깊이 파고드는 것이 중요합니다. 공기가없는 비행기처럼, 자바는 자바 가상 머신 (JVM)과 자바 런타임 환경 (JRE) 없이는 작동 할 수 없습니다 - 나는 당신이 매우 초기 단계에서 그 용어를 적용하고 자바 응용 프로그램이 그 후드 아래에서 어떻게 작동하는지에 대한 적절한 이해를 얻는 것이 좋습니다.

그것은 모두 연습과 더 많은 연습에 관한 것입니다. 프로그래밍 방식으로 해결하려는 문제에 대해 생각하고 Java에서 수행하십시오. 아마도 개인 재정에 대한 작은 계산기, 쇼핑 목록 앱 및 이와 유사한 것들이지만 너무 복잡하지 않고 구현할 수 있습니다.

데이터를 저장하는 방법 알아보기

데이터 지속성 없이 구현할 수 있는 응용 프로그램은 그리 많지 않으며 데이터를 저장하는 방법에는 여러 가지가 있습니다. 이것은 모든 종류의 데이터베이스가 제자리에 있는 곳입니다.

데이터베이스를 사용하는 것과 파일에 일부 정보를 넣는 것의 차이점은 데이터베이스에는 데이터를 적절하게 정렬하고 중요한 액세스 및 데이터 조작 기능을 제공하는 기술이 함께 제공된다는 것입니다 : 정렬, 쿼리, 필터링, 검색, 필요한 경우 액세스를 제한하는 액세스 제어 정의 등.

데이터베이스 및 데이터베이스 관리 시스템(개발자와 데이터베이스 사이에 있는 실제 소프트웨어 제품)에 대해 말할 수 있는 단어가 많이 있습니다. 실제로 SQL과 NoSQL이라는 두 가지 주요 데이터베이스 클래스를 대략적으로 생각할 수 있습니다.

첫 번째는 모든 기업 및 엔터프라이즈 응용 프로그램의 첫 번째 세계 시민이기 때문에 Java 개발자에게 가장 중요하고 중요하며 데이터 작업의 안정성과 고급 기술에 대해 고맙게도 아마도 Oracle, PostgreSQL 또는 SQL Server와 같은 큰 고래에 대해 들어 보셨을 것입니다.

또한 관계형 데이터베이스와 비관계형 데이터베이스에 대해서도 듣게 되는데, 이는 데이터가 구성되는 방식이 서로 다른 데이터 유형 간의 관계를 기반으로 하는지 여부를 의미합니다. 실제로 거의 항상 SQL 데이터베이스는 관계형이지만 NoSQL은 거의 항상 그렇지 않습니다.

학습 곡선의 초기 단계에서 SQL 데이터베이스와 상호 작용하는 데 사용되는 몇 가지 SQL 언어 기본 사항을 배우고 첫 번째 애플리케이션의 데이터에 대해 매우 기본적인 CRUD(만들기, 읽기, 업데이트, 삭제의 약자) 작업을 수행하는 방법을 배우고 싶을 것입니다. 아기 단계는 JDBC 드라이버를 직접 사용하는 가장 간단한 방법으로 수행하는 것입니다.

좀 더 능숙해지면 곧 ORM(Object Relational Mapping) 시스템의 사용법을 더 잘 적응하게 될 것입니다: SQL 쿼리를 명시적으로 작성하지 않고도 보다 자연스럽고 사람이 읽을 수 있는 형식으로 데이터로 작업할 수 있는 특수 소프트웨어 라이브러리입니다. 의심 할 여지없이 가장 인기 있고 널리 사용되는 Java ORM 중 하나는 Hibernate입니다.

스택은 무엇입니까?

기본 사항을 성공적으로 익히고 나면 이제 자신의 수준을 높이고 선택한 백엔드 스택, 즉 프로젝트를 작성하는 데 사용되는 주요 기술 세트로 바로 뛰어들 때입니다. 대부분의 중대형 프로젝트에서 응용 프로그램을 실행할 환경을 충족시키고 많은 표준 상용구 및 표준 반복 기능을 제공하는 많은 기술, 프레임 워크 및 라이브러리를 사용해야합니다.

Java의 두 가지 주요 스택 옵션은 Spring Framework 및 JavaEE(Java Enterprise Edition)입니다. 솔직히 말해서, 사과와 오렌지를 비교하기 때문에 Spring과 JavaEE를 서로 바꿔서 사용할 수있는 것으로 비교하는 것은 실제로 옳지 않습니다 : Spring은 프레임 워크의 집합이고 JavaEE는 사양과 표준의 집합입니다.

실제로 Spring은 JavaEE와 호환 될 수 있습니다. 그러나, 그것들을 같은 줄에 넣는 것이 일반적인데, 왜냐하면 보통 그 개념들은 실제로 섞이지 않기 때문이다: 당신은 전체 봄을 선택한다... 아니면. 저것과 같이 쉬운.

Spring Framework는 단순한 라이브러리 코드가 아니라 백엔드를 구축하기 위한 큰 생태계입니다. 오늘날 가장 인기 있고 지배적인 스택이라고 해도 과언이 아니며 Java 위에 기본 기술로 채택한 프로젝트를 통해 많은 취업 기회를 확실히 찾을 수 있을 것입니다. 가장 확실하게 직면하게 될 Spring의 가장 중요한 부분은 다음과 같습니다.

• 일반적으로 DI(Dependency Injection), IoC(Inversion of Control) 및 Spring MVC와 같은 핵심 Spring 구성 요소. 물론 비교적 현대적이지만 널리 사용되고 커뮤니티에서 높이 평가되는 Spring Boot입니다. 당황하지 마십시오 : 압도적으로 들리지만 실제로 이러한 구성 요소는 매우 간단하고 함께 작동하도록 잘 설계되어 첫 번째 Spring 웹 응용 프로그램을 함께 사용하고 우아하고 전문적인 방식으로 실행할 수있는 간단한 상용구를 제공합니다. 여기의 학습 곡선에는 Spring 앱이 구축되는 필수 디자인 패턴 (특히 Dependency Injection 및 MVC)에 대한 지식이 포함되며 Spring 주석 및 하위 구성 요소의 동작에 익숙해 질 것입니다.
• 스프링 보안. 인증, 권한 부여 및 기타 사용자 액세스 관련 사항에 관해서는 이 프레임워크가 구출에 적합합니다. 모든 종류의 액세스 제어 로직이있는 Spring 기반 프로젝트에서 찾을 수 있습니다.
• 스프링 데이터. 이 구성 요소는 모든 곳에서 사용되지 않을 수 있지만 일부 프로젝트에서는 확실히 볼 수 있습니다. 그것은 후드 아래의 ORM 위에 멋진 추상화를 추가하고 이력서의 확실한 점으로 보입니다.
• 봄 AOP. 예를 들어 모든 컨트롤러 메서드에 대한 기본 동작을 추가하거나 몇 가지 간단한 주석으로 메서드를 트랜잭션으로 만드는 것과 같은 중요한 엣지 케이스를 처리하는 순간 삶을 단순화합니다. 매일 연습할 때 유용한 도구이며, 면접관에게 당신이 또 다른 초보자 이상임을 보여주는 좋은 방법입니다.

JavaEE (Java Enterprise Edition) 또는 더 정확하게는 현대 교단의 Jakarta EE는 더 긴 역사를 가진 또 다른 코끼리입니다. 이미 말했듯이 프레임워크 자체가 아니라 사양과 API의 집합이며 추가 소프트웨어 라이브러리가 이를 구현합니다.

Enterprise Edition의 개념은 당신이 그것에 대해 생각하는 방식과 당신이 그것을 사용하는 방식, Spring 방식과 약간 다르며, 이것이 바로 우리가 비교할 수있는 이유입니다. Spring은 프레임 워크를 사용하고 앱이 서블릿 컨테이너 (Spring Boot를 사용하면 즉시 사용할 수 있음) 위에서 실행된다는 것을 의미하지만 앱은 서비스로 실행할 수있는 단일 jar 파일이됩니다. 대신 JavaEE 철학에서 응용 프로그램 서버가 있습니다. 완전한 환경과 모든 라이브러리를 앱이 실행되는 컨텍스트로 제공합니다. 따라서 기본적으로 JavaEE 스택을 사용하려면 다음을 수행해야합니다.

• 응용 프로그램 서버를 선택합니다. 일반적으로 LGPL 옵션을 사용할 수 있지만 크고 값 비싼 엔터프라이즈 급 소프트웨어 패키지입니다. 고전적인 예로는 WebLogic, GlassFish 및 WildFly (예 : JBoss)가 있습니다.
• JavaEE의 일부를 구성하는 API에 대해 학습합니다. 그들 중 많은 중요한 것이 있습니다. 다음은 가장 필수적인 몇 가지 예입니다.

— EJB(Enterprise JavaBeans): 앱의 비즈니스 로직을 작성하는 일반적인 구조와 방법을 정의합니다.

— JPA(Java Persistence API) - 관계형 SQL 데이터베이스를 사용하여 데이터 지속성 작업을 수행합니다.

— JMS(Java Message Service): 대기열 및 pub/sub 방식의 메시지 교환을 위한 사양입니다.

— 응용 프로그램 UI 관련 기술 : JSP (JavaServer Pages) 및 JSF (JavaServer Faces).

• 위에서 언급 한 API 중 일부를 구현하는 라이브러리를 선택하십시오.이 라이브러리는 응용 프로그램 서버와 함께 즉시 사용할 수 없거나 사용하기만 하면 됩니다. 예를 들어 다음을 사용할 수 있습니다.

— PrimeFaces, 멋진 템플릿 라이브러리 및 JSF 구현.

— JPA의 주요 구현 중 하나인 Hibernate.

— 메시징을 위한 AWS SQS, JMS의 구현 등.

초기 noughties에서 시작하여 약 10 년 후 봄 꽃이 만발한시기로 곧장 JavaEE 접근 방식은 기본값이었으며 대기업이 기업 시스템을 개발할 수있는 유일한 (신기원을 위해) 선택이었습니다. 그렇기 때문에 이 스택이 은행, 보험 회사, 항공사 등을 지원하는 거대하지만 비교적 오래된 시스템에서 널리 사용되는 것을 종종 볼 수 있습니다. 앞으로 오랫동안 지원되어야 하고 앞으로도 지원될 것이며 복잡성과 미션 크리티컬 특성으로 인해 다른 스택으로 쉽게 마이그레이션할 수 없습니다.

동전의 양면: 프론트엔드

나는 이제 디자이너가 되어야 하는 걸까?

짧은 대답은 '아니오'입니다. 그러나 실제로 특정 역할의 제한 사항에 따라 사용자 인터페이스(UI) 및 사용자 경험(UX)에 대해 어느 정도 작업해야 합니다.

회사 응용 프로그램의 인터페이스에서 매일 작업하여 일부 기능을 추가하거나 변경할 수 있습니다. 대부분의 경우 대중을 향한 프론트엔드를 많이 개발할 필요가 없을 것입니다. 또한 전체 응용 프로그램 디자인을 만들어야 하는 경우가 자주 발생하지 않을 것입니다 — 대부분의 경우 응용 프로그램을 처음부터 만드는 경우를 대비하여 그래픽 스케치 또는 html 템플릿에서 이미 사용할 수 있습니다.

또한 응용 프로그램 디자인이 중요하고 특히 소프트웨어가 백오피스 도구가 아닌 회사 고객이 사용하는 경우를 대비하여 팀에 디자이너 또는 전담 프론트엔드 개발자가 있을 것으로 예상할 수 있습니다.

웹 기반 프론트엔드에 대해 이야기할 때 기존의 특정 대체 접근 방식이 있지만 여전히 Javascript를 통과할 수 있는 방법은 거의 없습니다. 이것은 직간접적으로 많이 사용되는 주요 언어이며, 확실히 꽤 많이 배워야 할 것입니다.

또 다른 중요한 언어는 Typescript로, 그 위에 데이터 유형을 도입하여 Javascript에 비해 추가적인 다양성과 견고성을 제공합니다. 일부 프로젝트는 이를 적용하고 일부는 적용하지 않습니다. 조금 익숙해지고 특히 금융 또는 의료 관련 앱과 같이 데이터 정밀도와 정확성이 필요한 프로젝트에서 사용하는 것이 좋습니다.

일부 Java 프로젝트에서는 Javascript에 직접 직면하지 않을 수 있습니다. 이것은 프론트엔드가 GWT 또는 이와 유사한 구식에 의해 구동될 때 발생하며, 이를 통해 내부적으로 Javascript로 추가로 변환하여 Java에서 UI를 정의할 수 있습니다. 경우에 따라 Struts 2 또는 JSF 구현 중 하나와 같은 구식 프레임 워크는 Javascript 노출이 최소화되는 방식으로 설계 될 수 있습니다 - JavaEE 기반 백엔드가있는 오래된 응용 프로그램의 경우 특히 그렇습니다.

이 활기찬 프론트엔드 세계에서 집처럼 편안하게 지내세요

오늘날 풀 스택 개발자로서 유능한 능력을 갖추는 가장 좋은 방법은 Javascript 및 Typescript 위에 인기 있는 프론트엔드 프레임워크 및 라이브러리 중 하나 이상을 최신 상태로 유지하는 것입니다.

첫 번째 예는 Angular입니다. 이를 통해 프론트엔드를 개발할 때 고전적인 스타일의 MVP 및 종속성 주입 패러다임을 유지할 수 있으며, 마치 백엔드인 것처럼 동일한 접근 방식을 유지할 수 있습니다. 구성 요소, 서비스, 모델, 설계 방식을 통해 프론트엔드를 다른 서비스와 상호 작용하는 서비스로 생각할 수 있습니다. Angular는 지난 몇 년 동안 React에 서서히 자리를 잃어가고 있지만 엔터프라이즈 스타일 애플리케이션에서 Java 백엔드의 쌍으로 여전히 인기 있는 선택입니다.

다음으로 요즘 매우 인기 있는 기술은 앞서 언급한 React입니다. React를 배우면 많은 문이 열릴 것입니다. Angular와 달리 UI를 설명하는 보다 간단한(선언적 및 기능적) 방법이 제공되며 철학의 일부로 구성 요소 코드 내에서 HTML과 Javascript를 혼합합니다.

Vue.js는 또한 여기에서 언급 할 가치가 있습니다 : 시장 점유율을 상당히 차지하는 성공적인 미니멀리즘 초보자. 매우 간단하고 간단하며 React와 약간 유사하지만 덜 혁신적인 접근 방식을 가지고 있으며(말하자면) 지면에 더 가깝기 때문에 너무 복잡한 프론트엔드 로직을 사용하지 않는 실무 지향적인 개발자를 끌어들입니다.

Google 트렌드는 언급된 기술 간의 시장 점유율에 대한 아이디어를 보여줍니다(슬프게도 팬데믹으로 인해 우회되지 않음).

프론트엔드 프레임워크 동향

현대 프레임 워크 외에도 Backbone, .js, Ember.js 및 물론 오래된 jQuery 라이브러리와 같은 일부 프로젝트에서 여전히 사용되는 오래된 프레임 워크가 많이 있습니다. 해당 프로젝트에서 Full Stack 작업을 시작하는 경우 그 중 하나를 배워야 할 것입니다.

자동화된 테스트 및 DevOps

기계가 기계를 테스트하게 하십시오.

전문 Java 개발자와 일반 Java 개발자(사기는 말할 것도 없음)와 다른 한 가지 공통점이 있다면 그것은 자동화된 테스트 기술입니다. 자동화된 테스트에는 여러 종류가 있지만 기본적으로 단위 테스트와 통합 테스트의 두 가지 주요 범주가 있습니다.

단위 테스트를 통해 개발자는 모든 내부 응용 프로그램 구성 요소가 다른 구성 요소와 완전히 격리되어 있을 때 올바르게 작동하는지 확인할 수 있습니다. 예를 들어, 데이터베이스 또는 파일에서 실제 데이터를 가져 오는 대신 해당 데이터 소스와 동일한 인터페이스를 제공하는 "조롱"또는 "가짜"구성 요소에서 입력 데이터를 가져옵니다 (또는 실제 데이터베이스에서도, 특별히 채워지고 단위 테스트에만 사용됨).

이 데이터 소스의 입력 데이터는 구성 요소의 모든 중요한 사용 및 엣지 케이스에 해당하도록 신중하게 준비됩니다. 따라서 개발자는 모든 입력에 대해 예상되는 구성 요소 응답을 정확히 알고 있으며, 이는 알려진 입력 데이터에 대해 구성 요소를 실행하고 실제 출력 데이터를 예상과 비교하는 단위 테스트의 목표입니다.

올바르게(또는 부정확하게) 응답하는 구성 요소는 문제를 훨씬 더 쉽게 지역화하는 데 도움이 되며, 구성 요소를 개발하거나 업데이트할 때 프로젝트 전체를 테스트할 때 감지하기가 훨씬 더 어려운 엄청난 수의 절름발이 실수와 버그를 방지하는 데 도움이 됩니다.

단위 테스트의 또 다른 중요한 부작용은 모든 구성 요소가 충분히 독립적이어야하고 다른 구성 요소와 적절하게 분리되어야한다는 것입니다.이 구성 요소를 개별적으로 테스트 할 수 있으며 프로젝트 지원 및 개발 측면에서 매우 유용합니다.

단위 테스트를위한 가장 중요한 "반드시 배워야하는"Java 라이브러리는 JUnit 및 Mockito입니다.

통합 테스트는 더 높은 수준의 테스트의 또 다른 다양성입니다. 단위 테스트와 달리 여러 구성 요소가 함께 작동하거나 실제 외부 종속성 (데이터베이스, API 등)과 함께 작동하는 반대 사항을 테스트하도록 지정되었습니다. 그러나 아이디어는 매우 유사합니다 : 알려진 입력 데이터를 제공하거나 미리 채우고 출력을 예상 출력 데이터와 비교합니다.

도구에 대해 말하면 때로는 통합 테스트에 사용되는 것과 동일한 JUnit 일 수 있습니다. 때로는 요청을 에뮬레이트하고 응답을 읽는 자체 작성 스크립트이거나 구성 요소 체인이 있는 작은 앱을 만들 수 있습니다. 특히 외부 테스트 제품군도 이러한 목적에 매우 유용할 수 있습니다(예: Selenium 또는 Cypress). 후자의 두 가지는 브라우저의 UI 테스트에도 널리 사용되며, 이를 정의하는 "기능 테스트"라는 용어를 들을 수도 있습니다.

... 그리고 기계를 만드십시오.

애플리케이션 복잡성이 증가함에 따라 애플리케이션 구성 요소 오케스트레이션에 대한 훨씬 더 체계적인 접근 방식이 필요합니다. 여기에서 DevOps가 작동합니다.

우리 세기의 세 번째 10년 동안의 경험 법칙은 응용 프로그램을 수동으로 빌드, 테스트 및 배포하지 않는다는 것입니다. 고급 CI/CD 파이프라인은 프로젝트 및 회사 성숙도의 고유한 신호가 되었습니다. 컴퓨터에 jar 파일을 만들고, Slack에서 서버에 수동으로 배포하는 방법을 알고있는 팀의 한 사람에게 보내고, 서비스를 다시 시작하고, 로그를 읽는다고 말하십시오. 그리고 나는 당신이 당신의 프로젝트에 참여하기 위해 경험 많은 개발자를 고용하지 않을 것이라고 말할 것입니다. 그 상태를 개선하기 위해 그들에게 백지 위임장을 주지 않고는 아닙니다.

프로젝트 배포에 대한 현대적인 접근 방식은, 특히 이 프로젝트가 거대하고 다른 대륙의 많은 서버에서 실행되는 경우 수동 작업을 가능한 한 적게 수행하는 것입니다. 최소한 Github에서 끌어오기 요청을 생성하기만 하면 프로젝트 빌드, 자동화된 테스트 실행 및 병합 시 자동화된 배포가 트리거됩니다.

고급 프로젝트의 경우 이러한 체인에는 훨씬 더 복잡하고 고급 작업이 포함되며, 경우에 따라 풀 스택 개발자로서 작업이 될 수도 있고 회사에서 이 작업을 수행하기 위해 전담 DevOps 엔지니어를 고용하기를 원할 수도 있습니다.

후자의 경우에도 일상적인 엔지니어링 작업에서 사용할 가능성이 가장 높은 몇 가지 관련 기술에 익숙해지면 여전히 엄청난 이점을 얻을 수 있으며 무엇보다도 Docker와 Kubernetes가 있습니다.

Docker는 오늘날 매우 널리 사용되는 애플리케이션을 컨테이너화하기 위한 도구입니다. 기술적 세부 사항을 너무 많이 파고들지 않고 기본적으로 앱을 위한 가상 환경(운영 체제 및 사전 설치된 소프트웨어)을 생성하며, 이는 마치 실제 서버인 것처럼 이 컨텍스트에서 실행됩니다.

컨테이너 사용의 주요 이점은 전체 서버를 다시 만들거나 기존 서버에 모든 소프트웨어를 다시 설치하지 않고도 필요한 환경을 프로그래밍 방식으로 매우 빠르고 쉽게 정의할 수 있다는 것입니다. 또한 정확하게(거의 정확하게) 모든 곳에서 투명하게 구성 가능한 동일한 환경(로컬, 테스트 중 및 프로덕션)에서 앱을 실행할 수 있습니다.

쿠버네티스는 이른바 '오케스트레이션' 기술로, 도커 또는 다른 컨테이너화 시설 위에 컨테이너 클러스터를 통합하고 실행하는 데 사용됩니다. 요즘에는 실제 물리적 아키텍처 위에 앱의 일부를 형성하고 추상화하는 적절한 수의 다양한 서비스를 시작하는 것이 매우 인기가 있습니다. 쿠버네티스에 익숙해지면 모든 면접에서 큰 우위를 점할 수 있습니다.

소프트웨어 설계 및 아키텍처

이 두 가지는 틀림없이 당신이 성장하고 연공서열을 높이는 한 소프트웨어 개발 프로세스의 가장 중요한 단계가 될 것입니다. 큰 그림을 보고 당면한 문제를 생각하고 앱을 구현하는 데 적합한 아키텍처와 기술 스택을 결정할 수 있는 것은 Java 개발자뿐만 아니라 모든 소프트웨어 개발자에게 중요한 기술입니다. 그러나 책임과 통합을 분할해야 하는 요구 사항이 증가하기 때문에 전체 스택의 경우 특히 중요합니다.

디자인 패턴

디자인 패턴의 개념은 기본적으로 몇 가지 "템플릿" 또는 패턴이 있음을 의미하며, 이를 통해 코드 구성 요소를 구성하는 방법과 상호 작용 방식에 대해 덜 생각할 수 있습니다. 전체 아키텍처를 다시 만들 필요 없이 주어진 시나리오에서 잘 알려진 접근 방식이 작동할 수 있는지 생각할 수 있습니다. 시간이 지남에 따라 일부 패턴이 문자 그대로 모든 두 번째 또는 첫 번째 프로젝트 (예 : Dependency Injection 또는 Abstract Factory)에서 사용된다는 것을 알 수 있습니다.

이 주제를 발견한 고전 책은 유명한 "Gang of Four"의 "Design Patterns: Elements of Reusable Object-Oriented Software"입니다.

마이크로서비스

마이크로 서비스는 엔지니어가 단일 모놀리식 앱을 사용하는 대신 서로 상호 작용하는 완전히 독립적인 여러 개의 작은 애플리케이션으로 애플리케이션을 분할하도록 권장하는 인기 있는(특히 지난 몇 년 동안) 아키텍처 접근 방식입니다. 이 기술은 백엔드와 프론트엔드 자체가 대부분 두 개 이상(실제로는 일반적으로 더 많은) 독립적인 마이크로서비스를 구성하기 때문에 풀 스택 Java 개발자에게 특히 중요합니다. Spring 대 JavaEE 비교로 돌아가서, 기본적으로 Spring을 사용하여 마이크로 서비스 아키텍처를 수행하는 것이 훨씬 쉽다는 것을 언급 할 가치가 있습니다 : JavaEE는 역사적으로 모 놀리식 앱으로 설계되었습니다.

이 측면의 효율적인 해결에 대해 적극 권장되는 자료는 Sam Newman의 "Building Microservices: Designing Fine-Grained Systems"입니다.

REST API

REST API는 백엔드/프론트엔드 상호 작용에 가장 널리 사용되는 표준 중 하나이기 때문에 이것은 풀 스택 엔지니어에게 중요한 개념입니다. 아주 간단한 용어로, 이 표준의 관행은 프론트엔드가 백엔드와 통신하는 방식을 구현하기 위해 HTTP(백엔드와 통신하기 위한 기본 프로토콜로) 메소드 및 URI를 사용해야 하는 방법을 정의하며, 항상 후자가 API를 제공하는 독립형 마이크로서비스로 빌드되고 프론트엔드도 독립형 웹앱일 때 정의됩니다.

REST는 GET, POST, PUT, DELETE, PATCH 및 기타 HTTP 메서드에 대해 CRUD 작업을 매핑하여 프런트 엔드가 독립적으로 작동하고 백 엔드에서 필요한 것을 얻을 수 있도록 하는 관행을 포함합니다. 다양한 종류의 작업에 대한 URI를 작성하는 방법을 제안하고 기본 페이로드의 형식을 지정하는 아이디어도 제공합니다. 요즘 많은 프로젝트에서 REST 기반 접근 방식에 직면하게 될 것입니다. 짐작할 수 있듯이 HTTP 프로토콜에 대한 훌륭하고 포괄적인 지식이 필요합니다.

결론

Java Full Stack Developer는 개방적이고 T자형 사람들을 끌어들이는 흥미롭고 믿을 수 없을 정도로 다재다능한 고급 역할입니다. 간단한 단계를 따르고 학습과 경력 경로 내에서 열정적이고 일관성을 유지하면 이 역할에서 성공하는 데 필요한 모든 기술을 습득하고 모든 수준의 연공서열에 대해 많은 직업 기회를 얻을 수 있습니다.