Tistory Project review 조금

1. Code Review
최종적으로 Service에 Deploy 되기 전에 Review를 하는 것은 몇번 엄한 코드가 나갈뻔한 상황을 제어할 수 있었다. 형상관리툴(이 프로젝트에서는 SVN)을 사용하고 서비스 적용 전에 그 변화들을 확인해 가는 것은 품질 확인에 많은 도움이 된다.
다만 이것이 쌓여버리면 역시 터진다. 리뷰 시간도 줄어들고 작성자도 기억이 가물가물해 진다. 커밋 후 짧은 시간 안에 이루어 지는 것이 필수.

2. Ticket System/Issue Tracking
Trac을 사용하였고 이는 현재의 사안들을 적절히 추적할 수 있게 한다. 과거를 따라 갈 수도 있다. 버그를 보고받고 재현하고 수정한다는 과정을 자연스럽게 확립할 수 있고 다시 이슈가 발생한 경우 많은 정보를 찾을 수 있다.
귀차니즘이 문제라고 큰 이슈임에도 한 이슈로 뭉쳐서 처리해 버리는 경우 정보가 부족해 질 가능성이 높다.

더불어 형상관리시 Ticket과 연관이 있어야만 code의 commit을 가능토록 강제하였다. 트랙킹이 좀더 강력해 진다. Trac은 SVN과 연동이 되므로 평소에 약간만 수고해 주면 트랙킹이 무척이나 편해진다. 허나 가짜 Ticket을 만드는 등의 오용 사례가 있었으니 주의. (나조차도 ㅠ.ㅠ)

3. 땜빵 곱하기 땜빵은 땜빵
실 서비스를 한다는 특성상 땜방의 연속은 어쩔 수 없는 숙명일지도 모른다. 허나 분명 프로젝트 기간동안 보면 정공법이 역시나 뒷탈이 없었다. 일정상 땜빵을 선택한다고 했을 때, 그 이슈가 풀린다고 바로 잊어 버리면 안되는 것이 중요한 것 같다. 실리콘으로 일단 금을 보수 했으면 다시 정석으로 금의 원인을 분석하고 대응 방안을 제대로 고민하는 것이 좋다. 바쁘다고 뒤로 미루면 역시 실리콘 떨어진다.

4. 버그 회귀성
단위테스트 시스템을 아직 도입하지 못하였기에 역시 발생하는 문제인것 같다. 과거의 버그가 재발되는 경우도 종종 있었다. 같은 위치에서 발생하는 것보다도, 비슷한 모듈에서 동종의 버그가 발생되는 것이 사실 크다. 이는 단위테스트에서 충분히 커버할 수 있는 것들이다.
적극 도입을 검토할것.

5. 과감한 리팩토링
일정상의 이유로 전면적인 수정은 주저하게 된다. 그리고 그것은 끊임없는 밤샘의 원동력이 된다. 시간이 나는데로 쓸데없는 상상하지 말고 즉각즉각 유지보수하자.