Project - AFRC Futures : 1년 3개월동안 배운 것

영국에서의 첫 프로젝트 경험.

아직 결정 난 건 아니지만 떠날 때가 되었다. 뒤를 돌아 보자.

하나) 

보다 분업화 된 커다란 프로젝트 라이프 사이클 경험

AFRC 프로젝트 이전

AFRC 프로젝트

기획자와 고객사의 요구사항 분석 기획자가 화면과 기능 레이아웃 정리 화면 디자인 퍼블리싱 개발(Front-end, Back-end 코드작성), 개발 중 기획자와 협의 개발자 자가 기능 테스트 및 디버깅 고객사 QA 개발자에게로 피드백 (사실 기억이...)

Business Architecture (BA)가 Project Owner와 요구사항 협의 및 분석 BA는 Usecase 문서로 상세 기능 설명. WireFrame designer가 화면 명시 High level designer가 전체적인 클래스와 메소드명, 데이터베이스 필드까지 포괄적으로 포함한 큰 그림의 기술 기능명시 Low level designer가 상세 기능 구현을 어떻게 해야하는지 각 메소드 로직 명시 개발자는 Low level 명세 문서와 Usecase를 기반으로 하여 구현, 상세 정의가 되어 있다고 해도 의심이 되는 부분이나 기술적으로 이슈가 있을 경우 Designer들과 협의 QA 팀에서 자체 테스트 시나리오를 작성하고 그에 따라 테스트 진행 테스트 에서 기대했던 결과 얻지 못 할 경우, JIRA 상에 새로운 업무 형태로 Defect 이 등록 되고 개발자에게 다시 할당  모든 업무는 Story, Task JIRA Ticket으로 관리 DBA team, Build Team (Jenkins daily build) 별도 존재

둘) 

말로만 듣고 실제 개발 생황에서 경험해 보지 못했던 테스트 케이스 작성 경험 ( JUnit / DBUnit )

처음에는 뻔한 입력값을 주고 그것을 왜 다시 확인하는지 요점을 몰랐었는데 

미묘한 논리 흐름의 오류를 잡을 수 있는 기회를 배포하기 전에 찾아낼 가능성이 크다는 것을 깨달았다.

그런데 프로젝트가 바빠지니 또 무시당하는 테스트 케이스 작성이다.

DBUnit 작성을 조금 더 재미있었다.

셋)

XML 사용 방법에 조금 더 친숙 해 졌다.

필수 AUDIT LOG 작성을 할 때, 기존에 명시되어 있는 문서와 데이터베이스에 있는 기본자료를 연관지어 어떻게 작성하는지 주어진 정보 없이 이해하고 기능 제공 하는 과정에서 LOG 에 사용될 값들을 XML로 작성하고 그것을 라이브러리에서 사용하는 것을 보았을 때 재미를 느꼈다.

WSDL로 웹서비스 정의하는 건 아직 서툴지만 JSON 형태로 데이터를 주고받는 것만 하다가 XML 형태에 데이터 교환 방법을 경험할 수 있는 기회였다.

넷)

JSF라는 언어에 대한 경험을 하게 되었다.

여전히 당최 적응하기 어려운 언어중에 하나이다. 처음부터 왜 버튼 하나 누를 때 마다 서버에 왔다갔다 하는지 이해할 수 없는 언어지만, 파블로 말대로 이렇게 개발자가 계속 바뀌는 환경에서 자바스크립트를 사용했다면 이 프로젝트는 이미 손도 못 댈 상황이 되었을 거라는 게 눈에 훤히 보인다.

다섯)

또... 뭐가 있을라나.

To be countinue