[Java] 함께하는 개발표준 만들어 가기

100자 요약 및 조감도

다양한  수준과 개성의 개발자들이 모인 개발 프로젝트에서 개발표준문서를 지속적으로 갱신하고 내용을 공유함으로써  생산성 있는 개발과 개발자들의 능력향상을 도울 수 있다.

 

상황

모 공공기관의 SI 프로젝트가 막 시작 중이고, 개발표준 문서 작성과 공통모듈 작성의 일이 맡겨졌다. 프로젝트의 개발자들은 신입과 타 개발환경 오랜 경험자 등 수준도 다양하고, 오랜 코딩 습관을 고수하는 개발자들도 다양하다. 이들에게 공통의 코딩표준을 따르도록 유도하고, 바람직하지 못한 코드의 사용을 지양하도록 안내하는 역할을 해야한다.

 

 그러나 보통 프로젝트에서는 다른 프로젝트의 문서를 배껴서 수정하는 수준의 개발표준 문서를 배포하고, 개발자들은 이에 잘 따르지 않거나 내용을 잘 숙지하지 못한 상태로 개발에 들어가게 된다. 한번 안 지켜진 것들은  점점 통제가 불가능해 진다. 그리고 공식산출물로 완성된 표준문서들은 지속적으로 갱신이 잘 되지 않으며, 개발 중에 나올 수 있는 아이디어, 지식들은 널리 공유되지 못한다. 그리고 코드예제와 같이 잘 정리되면 생산성을 높일 수 있는 자료들도 공식산출물이 아니란 이유로 관리가 소홀해진다 그 결과로 다음과 같은 문제점이 발생한다.

 

• 상이한 코딩스타일  : 각자의 습관대로 코딩함에 따라서 개발자간의 가독성이 떨어지고, 다른 사람이 이어서 개발을 할 경우에는 자신의 스타일로 수정하는데 시간을 쓰게 된다.
• 아키텍쳐에 대한 부족한 이해 : 각 layer별 역할에 대한 이해를 공유하지 못함에 따라 비효율적이고 문제점을 내포하는 코드를 작성한다. ( 예) business layer를 따로 정의하고 있음에도 web단에 business logic이 들어가서 트랜잭션 처리에 문제가 생기고 component 재활용성이 떨어지는 경우)
• 문제해결에 대한 중복된 시간 투자 : (예: 개발자마다 싸이베이스의 날짜표시 형식을 변환하는  함수 사용법을 찾아서 한참 매뉴얼이나 인터넷을 뒤지고, 아는 사람은 모르는 사람이 물어볼때마다 매번 말로 알려주고 있음)

• 중복된 모듈, 코드 작성
• 중간에 투입된 개발자에 대한 안내가 어려움. 담당자가 사람 새로 들어올때마다 중복된 교육을 해야함.

 

 

 

그러므로

다음과 같은 절차를 통해서  개발표준문서를 작성하고 내용을 공유해서 위의 문제점을 개선한다.

 

전체 과정에 걸쳐서 다음과 같은 유의사항을 인식한다.

• 개발 문서는 온라인으로 공유하고 지속적으로 갱신되고 있음을 알린다.

  • 위키나 프로젝트 게시판에 전체내용을 올리고 갱신된 내용을 공지한다. (위키라면 recent change에서 자동으로 될것이다.)
  • 내용 검색기능이 있는 도구가 바람직하다. (여건이 안되어서 파일서버를 사용할수 밖에 없다면 파일포멧을 txt나 html으로 해서 윈도우의 검색기능이라도 쓸수 있게 한다.)

   

• 표준담당자는 개발자를 감시,통제하고 가르치는 역할이 아닌 편리한 개발을 돕는 역할로 인식될 수 있어야 한다. 그렇게 하는 것이 개발자들의 내적동기를 유발할 가능성이 높다.
• 개발자가 제안하거나 스스로 작성한 내용이 많으면 좋을 것이다.  모범코드 사례나 참고자료들은 개발자들에게 자신의 능력과 지식을 자랑할 수 있는 기회가 될 수 있도록 한다.

• 코드의 개선점을 알릴 때는  특정인을 비방하는 분위기가 되지 않도록 주의한다. 다음과 같은 방법을 생각해 볼 수 있다.

  • 비행코드를 발표나 게시물의 형태로 알릴 경우, 코드의 일부를 가리거나 바꿔서 누구의 코드인지 드러나지 않도록 하는 방법을 쓸 수도 있다.
  • 개선할 코드를 담당 개발자를 밝히고 게시할 때는, 모두가 동의하는 기준으로 선정한 자료를 제기한다. (예: 메서드의 라인수. 중복된 코드 비율)
  • 코드 개선에 대해서 이야기할때 이것이 가지는 이득에 대해서 충분히 인식할 수 있도록 대화하고, 개선 작업에 대한 동기유발을 제공한다. 개선 작업이 눈에 안 보이는 작업이 되지 않고 그 가치오 성과에 대해서 모든 팀원이 인정할 수 있게 한다.

   

 

초기 개발자 회의

• 시기 : 프로젝트 시작 직후

• 개발자들의 의견을 취합한다.

  • 명명규칙,블럭 선언, 띄어쓰기 등은  모여서 합의하고 동의하는 과정을 거치면 각자의 선호하는 습관을 고집하지 않을 가능성이 크다.
  • 코딩스타일을 검사하는 툴을 도입할지도 합의한다.  툴의 적용이 잘못하면 개발자들에게 자신의 코딩이 통제 당한다는 거부감을 느끼게할 수도 있다.

   

 

• 전에 수행한  프로젝트 경험 공유,하고 재활용 가능한 모듈을 수집한다.

• 개발자들이 새로 적용해 보고 싶은 것들에 의한 의견교환을 한다.

  • 아무리 좋은 신기술, 방법론, 도구도 거부감을 가진 개발자가 많을 때는 성공이 힘듬. 마지못해 도입하게 되면 형식적으로 하게 되고, 결과가 안 좋을때도 자신의 성향을 합리화 하게 됨. (거봐~ 내가 그거 쓰면 잘 안될거라고 했잖아.) 선호하는 도구들은 개발자들이 그 것의 유용성을 증명하고 싶어서라도 열심히 사용.

   

• 아키텍쳐에 대해서 설명하는 기회를 가져서 전체 틀을 이해하고 개발에 들어갈 수 있도록 한다.
• 필요한 기초지식들을 공부할 수 있는 참조자료 목록을 상호 추천한다.  개발자들의 지적 호기심을 고취해서 같이 학습할 자료가 많아지도록 유도도록 한다.

 

가안재정  후 피드백

• 시기:  최초 코딩 시작 시
• 초기 회의에서 나온 의견을 바탕으로 가안 재정하고, 요점을 발표한뒤 피드백을 받는다.
• 코드 동료 검토를 해가면서 코드와 표준문서를 같이 보강해간다.

•  

적용버전 발표 , 갱신

• 시기: 종료까지 지속적으로

• 모든 개발자들이 같이 내용을 지속적으로 추가 한다.

  • 참고 기술 자료
  • 공통모듈 적용 예제
  • 트레블 슈팅 사례
  • 바람직하지 못한 코드 사례

   

 

적용예

모 공공기관의 2차 프로젝트에서 개발자 회의를 통해서 표준담당자가 바라는 점, 개발자가 필요로 하는 점등에 대해서 이야기하는 과정을 거쳤다. 그리고 프로젝트 중에 알게되는 적용된 프레웨임웍의 추천API들도 수시로 자료화 과정을 거쳤다.  그 결과 표준준수가 그 전프로젝트보다 잘 되었고, 프레임웍 기술에 대한 활용도도 높아졌다.

 

 

 

줄기패턴

 

 

 

페이지 히스토리

출처 : http://benelog.springnote.com/pages/349170