Java 베테랑이 주의해야 할 13가지 실수

제작 과정에서 발생하는 문제는 점차 중간 및 최고 경영진의 관심을 받고 있습니다. 개발자이든 아키텍트이든, 앞으로 당황스러운 상황에 빠지지 않도록 다음 항목에 충분히 주의해야 합니다. 문제 해결 참고 사항으로 사용할 수도 있습니다.

#1. 속성 파일이나 XML 파일에서 구성 속성을 외부화하지 마세요. 예를 들어 일괄 처리에 사용되는 스레드 수는 속성 파일에서 구성 가능하도록 설정되지 않습니다. 배치 프로그램은 DEV 환경이든 UAT(User Acceptance Test) 환경이든 원활하게 실행될 수 있지만 일단 PROD에 배포된 후 더 큰 데이터 세트를 처리하기 위해 멀티스레드 프로그램으로 사용되면 IOException이 발생합니다. , 이는 JDBC 드라이버 버전이 다르기 때문이거나 #2에서 설명한 문제 때문입니다. 속성 파일에서 스레드 수를 구성할 수 있으면 단일 스레드 애플리케이션으로 만드는 것이 매우 쉬워집니다. 더 이상 문제를 해결하기 위해 애플리케이션을 반복적으로 배포하고 테스트할 필요가 없습니다. 이 방법은 URL, 서버, 포트 번호 등을 구성하는 데에도 적합합니다.

#2. 테스트에 사용된 데이터 세트의 크기가 부적절합니다. 예를 들어, 프로덕션 환경의 일반적인 시나리오는 테스트에 1~3개의 계정만 사용하는 것입니다. 이때 계정 수는 1000~2000이어야 합니다. 성능 테스트를 수행할 때 사용되는 데이터는 실제이고 잘리지 않은 데이터여야 합니다. 실제 환경에 가깝지 않은 성능 테스트로 인해 예측할 수 없는 성능, 확장성 및 멀티스레딩 문제가 발생할 수 있습니다. 더 큰 데이터 세트로 애플리케이션을 테스트해야만 해당 애플리케이션이 올바르게 작동하고 비기능적 속성에 대한 SLA(서비스 수준 표준)를 충족하는지 확인할 수 있습니다.

#3. 애플리케이션에서 호출되는 외부 및 내부 서비스가 안정적이고 항상 사용 가능하다고 순진하게 믿습니다. 서비스 호출 시간 초과 및 재시도를 허용하지 않으면 애플리케이션의 안정성과 성능에 부정적인 영향을 미칩니다. 적절한 서비스 중단 테스트가 필요합니다. 오늘날의 애플리케이션은 대부분 분산되고 서비스 지향적이어서 많은 수의 네트워크 서비스가 필요하기 때문에 이는 중요합니다. 사용할 수 없는 서비스를 끝없이 요청하면 애플리케이션이 손상될 수 있습니다. 또한 각 노드의 균형을 유지하기 위해 로드 밸런서가 제대로 작동하는지 테스트해야 합니다.

#4. 최소 보안 요구 사항을 준수하지 않았습니다. 위에서 언급한 것처럼 네트워크 서비스는 어디에나 존재하므로 해커가 서비스 거부 공격에 이를 악용하기 쉽습니다. 따라서 Secure Sockets Layer를 사용할 때에는 기본 검증을 완료하고 Google Skipfish와 같은 도구를 사용하여 침투 테스트를 수행하는 것이 필수적입니다. 안전하지 않은 애플리케이션은 자체 안정성을 위협할 뿐만 아니라 고객 "A"가 고객 "B"의 데이터를 볼 수 있는 상황과 같은 데이터 무결성 문제로 인해 회사의 평판에 부정적인 영향을 미칠 수도 있습니다.

#5. 브라우저 간 호환성 테스트는 없습니다. 오늘날의 웹 애플리케이션은 대부분 JavaScript 프로그래밍 언어 및 Angle js와 같은 프레임워크를 사용하는 풍부한 단일 페이지 애플리케이션입니다. 구축한 웹 사이트가 다양한 장치와 브라우저에서 원활하게 실행되도록 하려면 해당 디자인을 구현해야 합니다. 따라서 앱이 모든 기기와 브라우저에서 작동하는지 확인하려면 호환성 테스트를 거쳐야 합니다.

#6. 자주 변경될 수 있는 비즈니스 규칙을 외부화하지 마세요. 예를 들어 세법, 정부 또는 산업 관련 요구 사항, 분류 등이 있습니다. Drools와 같은 엔진을 사용하여 비즈니스 규칙을 처리할 수 있으며, 이는 이러한 비즈니스 규칙을 데이터베이스나 Excel에 저장하여 외부화하는 데 도움이 됩니다. 기업이 이러한 비즈니스 규칙을 익히면 최소한의 변경과 테스트만으로 세법이나 관련 요구 사항에 신속하게 대응할 수 있습니다.

#7. 다음 문서는 제공되지 않습니다

단위 테스트 문서를 작성하고 코드 커버리지가 양호하도록 만듭니다.

통합 테스트.

수정되거나 새로 생성된 클래스, 스크립트, 구성 파일 등과 같은 모든 소프트웨어 구성 요소를 나열하는 포괄적이거나 백과사전적인 페이지입니다.

모든 구성 요소, 상호 작용 및 구조를 묘사하는 상위 개념 다이어그램입니다.

기본 문서에서는 개발자에게 "데이터 소스에 대한 자세한 정보를 기반으로 개발 환경을 구축하는 방법"을 알려줍니다.

마인드맵에서 만든 양식인 COS(Conditions of Satisfaction) 외에도 애자일 개발에는 크게 두 가지 문서 양식인 1과 2가 있습니다.

#8. 적절한 재해 복구 계획과 시스템 모니터링 및 보관 전략이 없습니다. 프로젝트 마감일이 가까워지면 프로젝트 배포를 서두르느라 이러한 사항을 놓치는 경우가 많습니다. Nagios 및 Splunk를 사용하여 적절한 시스템 모니터링을 설정하지 않으면 애플리케이션 안정성이 위협받을 뿐만 아니라 현재 진단 및 향후 개선 노력에도 방해가 됩니다.

#9.created_datetm, update_datetm,created_by,timestamp와 같은 데이터베이스 테이블에 대한 편리한 열 디자인이 없습니다. 또한 'Y' 또는 '와 같은 레코드를 순서대로 삭제하는 열도 없습니다. N. '활성' 또는 '비활성'일 수 있는 '삭제된' 열 또는 'record_status' 열입니다.

#10. 적절한 되돌림 계획 개발 실패. 따라서 시스템에 장애가 발생하면 배포하기 전에 시스템을 안정적인 상태로 복원할 수 있는 방법이 없습니다. 이 계획은 관련 팀에서 신중하게 고려하고 서명해야 합니다. 계획에는 이전 버전의 소프트웨어로 롤백하고 데이터베이스에 삽입된 모든 데이터와 속성 파일의 모든 항목을 제거하는 것이 포함됩니다.

#11. 프로젝트 시작 전에는 용량 계획이 수립되지 않았습니다. 오늘날 플랫폼 요구 사항을 언급할 때 단순히 "Unix 시스템, Oracle 데이터베이스 서버 및 JBoss 애플리케이션 서버가 필요합니다"라고 말하는 것만으로는 충분하지 않습니다. 귀하의 요구 사항은

특정 버전의 운영 체제, JVM 등에 대해 정확해야 합니다.

메모리 양(물리적 메모리, JVM 힙 메모리, JVM 스택 메모리 및 JVM 영구 생성 공간 포함)입니다.

CPU(코어 수).

로드 밸런서, 필요한 노드 수, 액티브/액티브 또는 액티브/패시브와 같은 노드 유형 및 클러스터링 요구 사항.

예를 들어 파일 시스템 요구 사항은 애플리케이션에서 생성된 보고서를 수집하고 보관하기 전에 1년 동안 저장할 수 있습니다. 이 경우 충분한 하드 드라이브 공간이 필요합니다. 일부 응용 프로그램에서는 다차원 분석 보고를 위해 다른 시스템 프로세스나 데이터 웨어하우스 시스템에서 사용할 데이터 추출 파일과 임시 저장소를 생성해야 합니다. 또한 내부 또는 외부 시스템에서 제공되며 보관되기 전에 12~36개월 동안 보관해야 하는 보안 파일 전송 프로토콜(Secure File Transfer Protocol)을 기반으로 하는 데이터 파일도 있습니다.

아래 #12는 "java.dzone"의 "David DeCesare"의 댓글에서 따온 것입니다.

#12, "작업에 가장 적합한 도구를 사용하지 마십시오." 많은 경우 개발자는 프로덕션 시스템에서 배우고 싶은 언어나 도구를 사용하게 됩니다. 일반적으로 이는 최선의 선택이 아닙니다. 예를 들어 이미 실제로 관계형인 데이터에 NoSQL 데이터베이스를 사용합니다. 어떤 도구를 채택하든 향후 3~5년(또는 그 이상) 동안 제품을 유지 관리해야 한다는 점을 기억하십시오.

#13. 16개 핵심 기술 분야에 대한 지식 보유량이 부족합니다. 이러한 영역에는 1) "동시성 문제", 2) 트랜잭션 문제, 3) 성능 문제를 식별하고 수정하는 것이 포함됩니다. 많은 인터뷰에서 저는 새로운 계약을 맺기 위해 이 세 가지 지식 측면에 의존했습니다.