WebLogic 개발자를위한 생존 기술 - WebLogic 개발자로서

WebLogic 개발자는 응용 프로그램 및 개발 환경을 구성하는 방법을 알고 있어야합니다. 또한 문제가 생겼을 때 WebLogic 커뮤니티에 연락하는 방법을 알아야합니다. 이 기사에서는 작업을 완료하는 데 도움이되는 몇 가지 권장 사항 및 기타 정보를 제공합니다.

적절한 문서 보관

문서는 모든 응용 프로그램의 중요한 부분입니다. 개발자는 응용 프로그램이 제대로 문서화되었는지 확인해야합니다. 문서는 여러 범주로 분류됩니다.

프로그램 코드 문서. 가장 명백한 문서 형식은 소스 코드의 주석으로 구성됩니다. Javadoc은이 문서를 제공하는 좋은 방법이다.
개발자 핸드북. 기본적이지만 자주 간과되는 문서화는 새로운 프로그래머를 신속하게 유도하는 것입니다. 성숙한 응용 프로그램에서 개발자의 컴퓨터에는 응용 프로그램을 개발할 때 사용되는 파일이 혼합되어 있습니다. 새 개발자가이 환경을 재생성하는 것은 어려울 수 있습니다. 개발자 핸드북은 새 시스템에서 개발 환경을 설정하는 데 필요한 프로세스를 설명합니다.

프로그램 사양. 귀하의 신청서에 대한 변경 사항은 이러한 변경과 관련된 모든 사람들에게 알려 져야합니다.
최종 사용자 문서. 이것은 사용자가 시스템을 사용하는 방법에 대한 정보를 참조하는 문서입니다. 기능이 시스템에 추가되고 기존 기능이 변경되면 사용자 설명서를 업데이트해야합니다.

모든 형태의 문서를 적절하게 관리함으로써 개발자와 사용자는 최신 상태를 유지할 수 있습니다.

유즈넷 사용

인터넷의 가장 큰 장점 중 하나는 글로벌 커뮤니티 감각입니다. 인터넷의 어느 부분도 인터넷 사용자가 다양한 주제에 대해 게시하는 많은 메시지 모음으로 구성된 Usenet 이상의 것을 구현하지 않습니다.

여러 방법으로 유즈넷에 액세스 할 수 있습니다. 유즈넷 게시물을 다운로드하고 필터링하는 클라이언트 프로그램을 설치할 수 있습니다. 웹 기반 포털을 사용할 수도 있습니다. 가장 일반적인 웹 포털 중 하나는 Google 그룹스입니다.

개발 환경 설정

WebLogic을 사용하면 동일한 시스템에서 실행되는 여러 서버를 작성할 수 있습니다. 이것은 다음과 같은 여러 개발 환경을 제공하는 편리한 방법을 제공합니다:

개발. 개발 환경은 개발자가 코드를 테스트하는 곳입니다. 이를 통해 개발자는 제어 된 환경에서 코드를 테스트 할 수 있습니다.개발 서버의 안정된 버전은 일반적으로 테스트 서버에 롤오버됩니다.
테스트. 프로젝트 팀은 소프트웨어를 테스트하고 새로운 버그를보고하는 품질 보증 (QA) 직원으로 구성 될 것입니다. 서버가 너무 휘발성이어서 QA 담당자가 개발 서버에서 테스트하지 않아야합니다. 오히려 개발 서버에서 테스트 서버로 안정 버전을 배포해야합니다. 이 버전은 QA 직원이 테스트 할 수 있습니다.
데모. 소프트웨어를 제작 한 시스템의 진행 상황을 보여주기 위해 클라이언트에게 또는 시스템을 곧 사용할 내부 사용자에게 데모를해야합니다. 데모 서버를 만들지 않고 개발자가 개발 서버를 불안정하게 만들면 데모가 작성됩니다.
문서. 많은 사람들이 귀하의 신청서에 대한 문서를 작성하게 될 것입니다. 그들은 서버에 로그온하고 스크린 샷을 찍고 최종 사용자 문서와 관련된 다른 활동을 수행하게됩니다. 기술 문서 작성자에게 문서를 개발할 수있는 안정적인 환경을 제공하는 것이 중요합니다.
베타. 응용 프로그램을 제작할 준비가되었다고 생각하면 최종 사용자가 소프트웨어를 프로덕션 환경으로 출시하기 전에 마지막으로 테스트 해 보도록하십시오. 이 프로세스를 최종 사용자 승인 테스트라고합니다. 이 테스트는 특별한 베타 서버에서 수행하는 것이 좋습니다.
생산. 프로그램의 프로덕션 버전은 최종 사용자가 사용하는 버전입니다. 프로덕션 서버를 계속 사용할 수 있는지 여부는 서버 관리자가 결정합니다. 소프트웨어의 모든 버전이 롤오버되는 마지막 중지 지점이됩니다.

이러한 모든 환경을 다른 시스템에 설치할 필요는 없습니다. 이러한 환경 중 일부는 단일 시스템에서 결합 될 수 있습니다.

개발중인 제품 파악

개발자는 해결하려는 문제를 이해해야합니다. 이는 명백하게 보일지도 모르지만 대규모 응용 프로그램 개발자는 다음과 같은 여러 가지 이유로 목표를 쉽게 잃을 수 있습니다.

프로그램 사양이 명확하지 않음
프로그램의 자체 영역 만 인식하는 개발자
명세를 이해하는 사용자

도구 이해

개발자의 삶을 편하게하기위한 많은 도구가 제공됩니다. 불행히도, 프로그래밍 시간에 이득을 얻기 전에 이러한 도구를 사용하는 방법을 배우는 데 많은 시간을 할애 할 수 있습니다. 실제로 도구를 배우는 시간은 투자입니다. 개발자는 최소한 다음 도구가 있어야합니다.

텍스트 파일 편집기
디버깅을 지원하는 IDE (Integrated Development Environment)
ANT와 같은 빌드 도구
소스 코드 미화
WebLogic Resource Workshop
버전 관리

모듈화되고 분리 된 시스템 생성

대규모 애플리케이션에는 많은 클래스와 시스템이 얽혀 있습니다. 많은 모듈로 구성된 시스템을 만드는 데에는 몇 가지 이점이 있습니다.

공통 모듈을 재사용 할 수 있습니다.
큰 문제가 많은 작은 문제로 나뉘어져 있기 때문에 프로그램을 이해하기 쉽습니다.
서로 다른 프로그래머가 서로 간섭하지 않고 다른 모듈에서 작업 할 수 있습니다.

시스템이 커짐에 따라 특정 모듈이 활성화 된 개발에서 유지 관리 모드로 이동합니다. 이러한 모듈은 진행중인 개발로 인해 이전에 작동하는 코드에서 오류가 발생하지 않도록 구성되어야합니다. 이러한 오류를 회귀 오류라고합니다.

보안에 유의하십시오

미디어에는 소프트웨어의 보안 결함을 악용하는 사람들의 보고서가 가득합니다. 응용 프로그램을 설계하고 구현할 때 보안을 염두에 두어야합니다.

URL 변조
버퍼 오버런
SQL에 전달할 수있는 매개 변수로 명령 주입
알려진 보안 결함 사용 운영 체제 또는 서버 소프트웨어
많은 보안 결함은 운영 체제 또는 서버 소프트웨어에 대한 최신 패치가없는 결과입니다. 최신 패치가 있는지 확인하십시오.

소프트웨어 테스트

개발자는 다른 모듈과 통합되기 전에 항상 모듈을 테스트해야합니다. 이를

단위 테스트라고합니다. 모듈을 처음 만들 때는 모든 단위 테스트를 수동으로 수행해야합니다. 단위 테스트의 결과에 만족하면 모듈을 다른 모듈에서 개발 한 모듈과 통합 할 수 있습니다. 이 프로세스를

통합 테스트라고합니다. 통합 테스트에는 구성 요소를 처음으로 결합 할 때 다른 개발자와 팀웍이 필요합니다. 개발자가 수행 한 테스트 외에도 QA 담당자와 최종 사용자가 수행 한 테스트가 수행됩니다. 이 사용자는 소프트웨어를 테스트합니다. 그들은 버그를 발견 할 것이다. 수많은 QA 담당자와 개발자가있는 경우 버그 추적 도구를 사용하면 편리 할 수 있습니다. 또한 버그 추적 도구를 사용하면 개별 버그에 메모를 첨부 할 수 있습니다. 개발자 나 사용자가 버그를 발견하면 해결 방법을 문서화 할 수 있습니다. 이것은 모든 버그가 프로그래밍 오류의 결과이기 때문에 중요합니다.

프로덕션 서버에서 시스템을 거의 실행할 준비가되면

최종 사용자 승인 테스트를 수행해야합니다. 최종 사용자는 생산에 들어가기 전에 시스템을 테스트 할 수있는 최종 기회를 제공합니다.