대규모 프로젝트를 위한 Java 개발 및 유지 관리에 대한 조언

당신이 2000개의 클래스와 많은 프레임워크를 사용하여 프로젝트를 개발 및 유지 관리하는 Java 개발자라고 가정해 보겠습니다. 이 코드를 어떻게 이해하나요? 일반적인 Java 엔터프라이즈 프로젝트 팀에서는 도움을 줄 수 있는 대부분의 수석 엔지니어가 바쁜 것처럼 보입니다. 문서도 드물다. 가능한 한 빨리 결과를 제공하고 프로젝트 팀에 자신의 능력을 입증해야 합니다. 이 상황을 어떻게 처리하시겠습니까? 이 기사에서는 새 프로젝트를 시작하는 Java 개발자를 위한 몇 가지 조언을 제공합니다.

1. 프로젝트 전체를 한꺼번에 이해하려고 하지 마세요

잘 생각해보세요. 프로젝트 코드 이해가 왜 우선일까요? 대부분의 경우 버그를 수정하거나 시스템의 기존 기능을 향상하라는 요청을 받습니다. 가장 먼저 해야 할 일은 전체 프로젝트의 아키텍처를 이해하지 못하는 것입니다. 전체 프로젝트 아키텍처를 이해하는 것은 프로젝트를 유지 관리할 때 많은 스트레스를 줄 수 있습니다.

10년의 탄탄한 프로그래밍 경험을 가진 Java 개발자라도 1년 이상 프로젝트를 진행했더라도 프로젝트의 핵심 작업을 이해하지 못할 수도 있습니다(원 개발자가 아닐 경우). ). 예를 들어 인증 메커니즘이나 트랜잭션 관리 메커니즘이 있습니다.

그들은 어떻게 했나요? 그들은 자신의 책임 영역을 매우 잘 이해하고 팀에 가치를 전달할 수 있습니다. 매일 가치를 제공하는 것은 미래에 갖게 될지 확신할 수 없는 것을 아는 것보다 훨씬 더 중요합니다.

2. 최대한 빠른 가치 전달에 집중

그렇다면 프로젝트 아키텍처를 이해하려는 열정을 제가 부정한 걸까요? 별말씀을요. 제가 요청하는 것은 가능한 한 빨리 가치를 제공하라는 것입니다. 일단 프로젝트를 시작하고 개발 환경을 설정하면 그것이 크든 작든 무언가를 제공하는 데 1~2주가 걸리지 않아야 합니다. 당신이 숙련된 프로그래머이고 2주 동안 아무것도 제공하지 않는다면, 당신이 실제로 일하고 있는지, 아니면 뉴스를 보고 있는지 관리자가 어떻게 알 수 있습니까?

그래서 배달은 모두를 편안하게 할 수 있습니다. 가치 있는 결과물을 만들기 전에 전체 프로젝트를 이해해야 한다고 가정하지 마십시오. 이것은 완전히 잘못된 것입니다. 자바스크립트 인증 코드를 추가하는 것은 비즈니스에 매우 중요하며, 관리자는 귀하의 배송을 통해 귀하에 대한 신뢰를 얻을 수 있습니다. 이를 통해 상사에 대한 귀하의 기여와 직원 가치를 입증할 수 있습니다.

날이 갈수록 계속해서 버그를 수정하고 기능을 향상시키면서 천천히 프로젝트 구조를 이해하게 될 것입니다. 시스템의 모든 측면을 이해하는 데 걸리는 시간을 과소평가하지 마십시오. 인증 메커니즘을 이해하는 데 3~4일, 거래 관리를 이해하는 데 2~3일이 소요됩니다. 이는 모두 유사한 프로젝트에 대한 이전 경험에 의존하지만, 핵심은 이를 완전히 이해하는 데 시간을 투자하는 것입니다. 일상 업무에 시간을 할당하고 관리자에게 특정 시간을 요청하지 마세요.

프로젝트에 지속적으로 유지 관리되는 단위 테스트 사례가 있는지 알아보세요. 효과적인 단위 테스트 사례는 대규모 프로젝트의 코드를 이해하는 좋은 방법입니다. 단위 테스트는 단위의 외부 인터페이스(단위 호출 방법 및 단위 반환 내용)와 내부 구현(단위 테스트 디버깅이 전체 실제 사용 사례를 디버깅하는 것보다 훨씬 쉽습니다)을 포함한 코드 조각을 이해하는 데 도움이 될 수 있습니다.

내용을 잘 이해할 수 있다면 메모를 하거나 클래스 다이어그램, 시퀀스 다이어그램, 데이터 모델 다이어그램을 그려서 나중에 자신이나 다른 개발자가 유지할 수 있도록 하세요.

3. 대규모 프로젝트를 유지하는데 필요한 능력

현재 직업을 가질 수 있다면 이미 좋은 Java 기술을 보유하고 있어야 합니다. 새로운 프로젝트에서 좋은 성과를 거두는 데 도움이 되는 다른 기술에 대해 이야기해 보겠습니다. 대부분의 경우 프로젝트의 작업은 버그를 수정하고 기능을 향상시키는 것입니다.

대규모 프로젝트의 코드를 유지하는 데 도움이 되는 두 가지 매우 중요한 기술이 있습니다.

　3.1 필요한 클래스를 빠르게 발견하는 능력

버그 수정이든 기능 강화든 모든 유지 관리 활동에서 첫 번째 작업은 현재 수정되거나 향상된 사용 사례에서 호출되는 클래스를 식별하는 것입니다. . 수정이나 개선이 필요한 클래스/메서드를 찾으면 절반은 완료된 것입니다.

　3.2 변경 영향 분석 가능

필요한 수정이나 개선을 완료한 후 가장 중요한 것은 수정으로 인해 코드의 다른 부분이 손상되지 않는지 확인하는 것입니다. 변경으로 인해 어떤 부분이 영향을 받을 수 있는지 알아보려면 Java 기술과 다른 프레임워크에 대한 이해가 필요합니다. 마지막으로 언급된 상황을 자세히 설명하는 두 가지 간단한 예는 다음과 같습니다.

a) 클래스 A의 equals() 메소드가 변경되면 A의 인스턴스를 보호하는 List의 Contains() 메소드 호출이 영향을 받습니다. Java에 대한 충분한 지식이 없으면 그러한 영향을 고려하기가 어렵습니다.

b) 웹 프로젝트에서는 "사용자 ID"가 세션에 저장되어 있다고 가정합니다. 새로운 프로그래머는 버그 수정으로 "사용자 ID"에 일부 정보를 추가할 수 있지만 "사용자 ID"와 관련된 사용 사례에 영향을 미칠 것이라는 점을 알지 못합니다.

위 두 가지 스킬을 향상시키면 해당 프로젝트에 대해 잘 모르더라도 대부분의 유지관리 작업이 훨씬 쉬워집니다. 버그를 수정하는 경우 해당 버그를 찾아 수정하고 변경 사항으로 인해 프로젝트의 다른 부분이 중단되지 않는지 확인합니다. 기능을 강화하거나 추가한다면 기본적으로 기존 기능을 복사해 유사한 디자인을 사용하면 됩니다.

온라인 뱅킹 프로젝트에서 '계좌 요약 보기'와 '거래 내역 보기'의 디자인이 왜 이렇게 달라야 합니까? "계좌 요약 보기"의 디자인을 이해하시면 "거래 내역 보기" 기능을 완벽하게 모방하고 발전시킬 수 있습니다.

버그 수정 및 개선 측면에서 2000개의 클래스가 모두 무엇을 하는지, 시스템을 구동하기 위해 코드가 어떻게 실행되는지 완전히 이해할 필요는 없습니다. 위의 기술이 있으면 수정해야 할 코드 부분을 빠르게 찾을 수 있고, 좋은 Java 및 프레임워크 기술을 사용하여 수정하고, 변경 사항으로 인해 프로젝트의 다른 부분이 중단되지 않는지 확인하고 전달할 수 있습니다. 프로젝트 디자인의 작은 부분만 알고 있을 수도 있습니다.

4. 도구를 사용하여 필요한 변경 사항과 변경 사항의 영향을 찾습니다.

가능한 한 빨리 제공한다는 주제를 이어가면서 프로젝트 구현에 도움이 될 수 있는 도구를 찾아야 합니다. 가능한 한 적은 이해로 최대한 빨리 제공된 도구는 보조 도구 역할을 합니다.

　4.1 변경이 필요한 도구를 빠르게 검색

버그 수정이든 시스템 개선이든 먼저 수정해야 하는 유스 케이스에서 호출되는 클래스와 메소드를 찾아야 합니다. 기본적으로 사용 사례의 작동 방식을 이해하는 방법에는 정적 코드 분석과 런타임 분석이라는 두 가지 방법이 있습니다.

소스 코드 분석 통계는 모든 코드를 스캔하여 클래스 간의 관계를 표시합니다. 시중에는 많은 장치와 도구가 있습니다. 예: Architexa, AgileJ, UModel, Poseidon 등

모든 정적 코드 분석 도구의 단점은 사용 사례에서 클래스나 메서드의 런타임 호출을 정확하게 표시할 수 없다는 것입니다. 따라서 Java에는 콜백 패턴과 같은 새로운 기능이 추가되었습니다. 예를 들어, 정적 분석 도구는 페이지 제출 버튼을 클릭했을 때 어떤 서블릿이 호출되었는지 추론할 수 없습니다.

런타임 분석 도구는 사용 사례가 실행될 때 클래스 및 메서드의 상태를 표시할 수 있습니다. 도구에는 MaintenanceJ, Diver, jSonde, Java Call Tracer 등이 포함됩니다. 이러한 도구는 런타임 스택 상태를 캡처하고 사용 사례에 대한 시퀀스 다이어그램 및 클래스 다이어그램을 생성할 수 있습니다.

시퀀스 다이어그램은 런타임 시 사용 사례에서 호출되는 모든 메서드를 보여줍니다. 버그를 수정하는 경우 해당 버그는 호출되는 메서드 중 하나일 가능성이 높습니다.

기존 기능을 강화하는 경우 시퀀스 다이어그램을 사용하여 호출 프로세스를 이해한 다음 수정하세요. 새로운 검증 추가, DAO 수정 등이 있을 수 있습니다.

새로운 기능을 추가하는 경우 유사한 기능을 찾고 시퀀스 다이어그램을 사용하여 호출 프로세스를 이해한 다음 새로운 기능을 모방하고 개발하십시오.

런타임 분석 도구를 선택할 때는 주의하세요. 정보가 너무 많으면 이러한 유형의 도구에서는 큰 문제가 됩니다. 유효하지 않은 정보를 간단하게 필터링하고 다양한 보기를 편리하게 볼 수 있는 도구를 선택하세요.

　4.2 변경이 필요한 콘텐츠를 빠르게 발견하기 위한 도구

단위 테스트가 효과적이면 단위 테스트를 실행하여 변경으로 인해 다른 테스트 사례가 파괴되는지 확인할 수 있습니다. 대규모 엔터프라이즈 애플리케이션을 효과적으로 유지 관리하고 다룰 수 있는 단위 테스트는 아직 상대적으로 적습니다. 이 상황에 대한 몇 가지 도구는 다음과 같습니다.

정적 코드 분석과 런타임 분석이라는 두 가지 기술을 사용할 수 있습니다. 시중에는 다양한 정적 코드 분석 도구가 있습니다. 예: Lattix, Structure101, Coverity, nWire 및 IntelliJ의 DSM.

클래스가 변경되면 위 도구를 사용하여 클래스에 종속된 클래스 집합을 식별할 수 있습니다. 개발자는 이 정보를 기반으로 영향을 미칠 수 있는 사용 사례를 "추측"해야 합니다. 왜냐하면 이러한 도구는 런타임 클래스 간의 호출 관계를 표시할 수 없기 때문입니다.

MaintenanceJ를 제외하고 런타임 영향 분석에 사용할 수 있는 도구는 시중에 많지 않습니다. MaintenanceJ는 먼저 사용 사례에서 호출되는 모든 클래스와 메서드를 캡처합니다. 모든 사용 사례에 대한 위의 정보가 캡처되면 클래스 변경이 사용 사례에 미치는 영향을 쉽게 찾을 수 있습니다. MaintenanceJ가 효과적으로 작동하기 위한 전제 조건은 런타임 종속성을 얻을 수 있도록 프로젝트의 모든 사용 사례를 먼저 실행해야 한다는 것입니다.

즉, 현재로서는 변경의 영향을 빠르고 정확하게 분석하는 데 있어 도구의 도움을 제한적으로 받을 수 있습니다. 먼저 필요에 따라 일부 영향 분석을 수행한 다음 자신이나 팀의 다른 고위 구성원의 검토를 기반으로 변경의 영향을 판단합니다. 자신의 판단을 다시 확인하려면 위에서 언급한 도구가 필요할 수 있습니다.

5. 위 내용에 대한 두 가지 조언

5.1 코드 품질을 낮추지 마세요

빠르게 전달하려면 아키텍처를 완전히 이해하지 마세요. 그러나 코드 품질을 저하해서는 안 됩니다. 빠른 전달에만 집중함으로써 발생할 수 있는 몇 가지 코드 품질 문제는 다음과 같습니다.

코드 수정에는 많은 종속성이 포함되므로 새 코드를 추가하는 것이 상대적으로 덜 위험합니다. 예를 들어, 모두 특정 메서드를 호출하는 5가지 사용 사례가 있습니다. 사용 사례를 개선하려면 이 메서드의 구현을 수정해야 합니다. 가장 간단한 방법은 메서드를 복사하고 이름을 바꾼 다음 수정된 사용 사례에서 새 메서드를 호출하는 것입니다. 절대 이렇게 하지 마세요. 코드 중복은 확실히 매우 해롭습니다. 메서드를 래핑하거나 다시 작성하거나 직접 수정한 다음 모든 사용 사례를 다시 테스트해 보세요. 일반적으로 잠시 멈추고 생각한 다음 직접 구현하는 것이 더 좋습니다.

또 다른 예는 다른 클래스에서도 호출할 수 있도록 "private" 메서드를 "public"으로 변경하는 것입니다. 불필요한 부분은 노출하지 않도록 하세요. 더 나은 디자인을 위해 리팩토링이 필요하다면 이를 수행해야 합니다.

대부분의 애플리케이션에는 구현해야 할 특정 구조와 패턴이 있습니다. 프로그램을 수정하거나 강화할 때 이 패턴에서 벗어나지 않도록 하세요. 규칙이 확실하지 않은 경우 다른 수석 개발자에게 변경 사항을 검토해 달라고 요청하세요. 계약을 위반하는 구현을 해야 한다면 더 작은 클래스에 배치해 보세요(200줄의 코드가 있는 클래스의 비공개 함수는 애플리케이션의 전체 디자인에 영향을 주지 않아야 합니다)

　5.2 하지 마세요. 파헤쳐보기 프로젝트 아키텍처 이해

기사에 나열된 방법에 따라 프로젝트에 대한 이해가 부족한 상태에서 전달하고 계속할 수 있다고 가정하면 프로젝트 아키텍처에 대한 깊은 이해가 중단될 수 있습니다. 이는 장기적으로 귀하의 경력에 ​​도움이 되지 않습니다. 경험이 늘어남에 따라 더 큰 모듈 작업을 수행해야 합니다. 완전히 새로운 기능을 구축하거나 프로젝트의 일부 기본 디자인을 수정하는 등의 주요 개선 사항입니다. 이러한 개선을 수행할 수 있으면 프로젝트의 전체 아키텍처를 잘 이해해야 합니다. 기사에 나열된 방법은 전체 프로젝트를 완전히 이해하는 것을 방해하기보다는 가능한 한 짧은 시간에 자신을 향상시킬 수 있도록 하기 위한 것입니다.

6. 결론

전체 글은 프로젝트에 대한 필요한 이해를 바탕으로 빠른 배송에 초점을 맞췄습니다. 코드 품질을 손상시키지 않고 이를 수행할 수 있습니다.

버그를 수정했다면 빠르게 찾아서 수정하세요. 필요한 경우 런타임 분석 도구를 사용할 수 있습니다. 새로운 기능을 추가하면 비슷한 기능을 찾아보고, 과정을 이해하고(도구가 필요함) 글을 쓸 수 있습니다.

간단해 보이지만 과연 실용적일까요? 틀림없이. 하지만 전제는 먼저 코드를 수정한 다음 변경의 영향을 분석할 수 있을 만큼 우수한 Java 기술과 프레임워크에 대한 충분한 이해가 있어야 한다는 것입니다. 변경의 영향을 분석하려면 변경을 구현하는 것보다 더 많은 기술이 필요합니다. 변경의 영향을 분석하는 데 도움을 줄 선임 개발자가 필요할 수도 있습니다.

IT 운영 예산의 약 50%가 간단한 버그 수정 및 기능 개선에 지출됩니다. 기사의 제안에 따르면 유지 관리 활동에 드는 비용을 절약하는 것이 매우 도움이 될 것입니다.