생산 과정에서 발생하는 문제는 점차 중간 및 최고 경영진의 주목을 받고 있습니다. 개발자이든 아키텍트이든, 앞으로 당황스러운 상황에 빠지지 않도록 다음 항목에 충분히 주의해야 합니다. 문제 해결 참고 사항으로 사용할 수도 있습니다.
#1. 속성 파일이나 XML 파일에서 구성 속성을 외부화하지 마세요. 예를 들어 일괄 처리에 사용되는 스레드 수는 속성 파일에서 구성 가능하도록 설정되지 않습니다. 배치 프로그램은 DEV 환경이든 UAT(User Acceptance Test) 환경이든 원활하게 실행될 수 있지만 일단 PROD에 배포된 후 더 큰 데이터 세트를 처리하기 위해 멀티스레드 프로그램으로 사용되면 IOException이 발생합니다. , 이는 JDBC 드라이버 버전이 다르기 때문이거나 #2에서 설명한 문제 때문입니다. 속성 파일에서 스레드 수를 구성할 수 있으면 단일 스레드 애플리케이션으로 만드는 것이 매우 쉬워집니다. 더 이상 문제를 해결하기 위해 애플리케이션을 반복적으로 배포하고 테스트할 필요가 없습니다. 이 방법은 URL, 서버, 포트 번호 등을 구성하는 데에도 적합합니다.
#2. 테스트에 사용된 데이터 세트의 크기가 부적절합니다. 예를 들어, 프로덕션 중 일반적인 시나리오는 테스트에 1~3개의 계정만 사용하는 것인데, 그 수는 1,000~2,000이어야 합니다. 성능 테스트를 수행할 때 사용되는 데이터는 실제이고 잘리지 않은 데이터여야 합니다. 실제 환경에 가깝지 않은 성능 테스트는 예측할 수 없는 성능, 확장성 및 멀티스레딩 문제를 가져올 수 있습니다. 더 큰 데이터 세트로 애플리케이션을 테스트해야만 해당 애플리케이션이 제대로 작동하고 비기능적 속성에 대한 SLA(서비스 수준 표준)를 충족하는지 확인할 수 있습니다.
#3. 애플리케이션에서 호출되는 외부 및 내부 서비스가 안정적이고 항상 사용 가능하다고 순진하게 믿습니다. 서비스 호출 시간 초과 및 재시도를 허용하지 않으면 애플리케이션의 안정성과 성능에 부정적인 영향을 미칩니다. 적절한 서비스 중단 테스트가 필요합니다. 오늘날의 애플리케이션은 대부분 분산되고 서비스 지향적이어서 많은 수의 네트워크 서비스가 필요하기 때문에 이는 중요합니다. 사용할 수 없는 서비스를 끝없이 요청하면 애플리케이션이 손상될 수 있습니다. 또한 각 노드의 균형을 유지하기 위해 로드 밸런서가 제대로 작동하는지 테스트해야 합니다.
#4. 최소 보안 요구사항을 준수하지 않습니다. 위에서 언급한 것처럼 네트워크 서비스는 어디에나 존재하므로 해커가 서비스 거부 공격에 이를 악용하기 쉽습니다. 따라서 SSL(Secure Sockets Layer)을 사용할 경우 기본 검증을 완료하고 Google Skipfish와 같은 도구를 사용하여 침투 테스트를 수행해야 합니다. 안전하지 않은 애플리케이션은 자체 안정성을 위협할 뿐만 아니라 고객 "A"가 고객 "B"의 데이터를 볼 수 있는 상황과 같은 데이터 무결성 문제로 인해 회사의 평판에 부정적인 영향을 미칠 수도 있습니다.
#5. 브라우저 간 호환성 테스트가 없습니다. 오늘날의 웹 애플리케이션은 대부분 JavaScript 프로그래밍 언어 및 Angle js와 같은 프레임워크를 사용하는 풍부한 단일 페이지 애플리케이션입니다. 구축한 웹 사이트가 다양한 장치와 브라우저에서 원활하게 실행되도록 하려면 해당 디자인을 구현해야 합니다. 따라서 앱이 모든 기기와 브라우저에서 작동하는지 확인하려면 호환성 테스트를 거쳐야 합니다.
#6. 자주 변경될 수 있는 비즈니스 규칙을 외부화하지 않습니다. 예를 들어 세법, 정부 또는 산업 관련 요구 사항, 분류법 등이 있습니다. Drools와 같은 엔진을 사용하여 비즈니스 규칙을 처리할 수 있으며, 이는 이러한 비즈니스 규칙을 데이터베이스나 Excel에 저장하여 외부화하는 데 도움이 됩니다. 기업이 이러한 비즈니스 규칙을 익히면 최소한의 변경과 테스트만으로 세법이나 관련 요구 사항에 신속하게 대응할 수 있습니다.
#7.다음 서류는 제공되지 않습니다.
MindMap에서 만든 양식인 COS(Conditions of Satisfaction) 외에도 애자일 개발 에는 두 가지 주요 문서 양식인 1과 2가 있습니다.
#8. 적절한 재해 복구 계획과 시스템 모니터링 및 보관 전략이 없습니다. 프로젝트 마감일이 가까워지면 프로젝트 배포를 서두르느라 이러한 사항을 놓치는 경우가 많습니다. Nagios 및 Splunk에서 적절한 시스템 모니터링을 수행하지 않으면 애플리케이션의 안정성이 위협받을 뿐만 아니라 현재 진단 및 향후 개선 노력에도 방해가 됩니다.
#9. Created_datetm, update_datetm, selected_by, update_by 및 timestamp와 같은 데이터베이스 테이블에 대한 편리한 열 디자인은 없습니다 . 또한 'Y' 또는 'deleted' 열과 같은 순서대로 삭제되는 레코드 열을 제공하지 않습니다. 또는 'record_status' 열을 'Active' 또는 'Inactive'로 선택할 수 있습니다.
#10. 적절한 되돌림 계획 개발 실패. 따라서 시스템에 장애가 발생하면 배포하기 전에 시스템을 안정적인 상태로 복원할 수 있는 방법이 없습니다. 이 계획은 관련 팀에서 신중하게 고려하고 서명해야 합니다. 계획에는 이전 버전의 소프트웨어로 롤백하고 데이터베이스에 삽입된 모든 데이터와 속성 파일의 모든 항목을 제거하는 것이 포함됩니다.
#11. 프로젝트 시작 전 용량 계획 수립 실패. 오늘날 플랫폼 요구 사항을 설명할 때 단순히 "Unix 컴퓨터, Oracle 데이터베이스 서버 및 JBoss 애플리케이션 서버가 필요합니다"라고 말하는 것만으로는 충분하지 않습니다. 요청은 정확해야 합니다.
아래 #12는 "java.dzone"의 "David DeCesare"의 댓글에서 가져온 것입니다.
#12. "작업에 가장 적합한 도구를 사용하지 마세요." 많은 경우 개발자는 프로덕션 시스템에서 배우고 싶은 언어나 도구를 사용하게 됩니다. 일반적으로 이는 최선의 선택이 아닙니다. 예를 들어 이미 실제로 관계형인 데이터에 NoSQL 데이터베이스를 사용합니다. 어떤 도구를 채택하든 향후 3~5년(또는 그 이상) 동안 제품을 유지 관리해야 한다는 점을 기억하십시오.
#13. 16개 핵심 기술 분야에 대한 지식 보유량이 부족합니다. 이러한 영역에는 1) "동시성 문제", 2) 트랜잭션 문제, 3) 성능 문제를 식별하고 수정하는 것이 포함됩니다. 많은 인터뷰에서 나는 새로운 계약을 성사시키기 위해 이 세 가지 지식 측면에 의존했습니다.