최악의 소프트웨어 개발 프랙티스 10가지 - Andrew Oliver | InfoWorld

최악의 소프트웨어 개발 프랙티스 10가지 - Andrew Oliver | InfoWorld

훌륭한 소프트웨어를 만들기란 그다지 어렵지 않다. 그러나 제대로 된 코드를 작성하려는 소프트웨어 개발자의 가장 큰 적은 바로 자기 자신이다. 잘못되거나 엉뚱한 습관에 빠질 수 있기 때문이다.

 

아니, 사실 개발자의 최대 적은 더 빨리 프로젝트를 완료하려는 조급한 마음에 개발자를 잘못된 습관으로 몰아넣는 IT 책임자이다. 특히 대규모 엔터프라이즈 또는 웹 프로젝트에서 이는 큰 재앙으로 이어질 수 있다.

 

다음과 같은 함정은 익히 알려진 것들로, 여기에 이의를 제기하는 개발자는 아마 거의 없을 것이다.

 

1. 하루 종일 유닛 테스트를 한 줄도 작성하지 않는다

개발자는 유닛 테스트와 기능 테스트의 차이점과 같은 세부적인 부분에 집착하길 좋아한다. 하지만 사실 뭐든 상관이 없다. 중요한 것은 충분한 커버리지를 확보해 무언가 잘못되었을 때 이를 식별할 수 있는 것이다. 디버거에서 적절한 코드 실행 시작 지점을 두고 중단점을 설정하는 것이 중요하다. 이를 위한 유일한 방법은 “작업하면서 동시에” 해나가는 것이다.

 

또한 테스트는 여러분의 요구 사항을 표현하는 좋은 수단이기도 하다. 확고한 증거를 제시해도 여전히 “유닛 테스트에 시간을 투자할 가치가 있는지 관리자에게 증명해야 한다”는 말을 듣곤 한다.

 

이러한 관리자들은 마치 기후 변화를 부정하는 사람들과 같다. 아무리 많은 증거가 있어도 이들이 요구하는 검증을 충족할 수 없다. 이들은 필연적으로 기한보다 한참 늦게 프로젝트를 완료하며, 그나마 버그투성이로 사용자 기대를 충족하지 못한다.

 

2. 하루 종일 빌드를 하지 않는다

젠킨스(Jenkins) CI와 같은 도구가 있는 마당에 변명의 여지는 없다. 대부분의 프로젝트에서 적절한 젠킨스를 설정하는 데는 VM 하나와 몇 시간 정도면 충분하다. SVN 또는 Git와 같은 리비전 제어 시스템에 코드가 체크인할 때 빌드가 실행되도록 구성할 수도 있다. 무언가 잘못되면 유닛 테스트를 실행하고 지표를 수집하고 이메일을 전송할 수 있다. 반복되는 빌드는 건강한 프로젝트의 심장 박동이다. 심장 박동 없이는 살 수 없다.

 

3. 클리어케이스(ClearCase)를 사용한다

클리어케이스(ClearCase)는 느리다. 지독하게 느린 버전 관리 시스템은 클리어케이스 외에도 더 있다. 개발자가 코드를 체크아웃 또는 체크인하기 위해 “기다리도록” 하는 모든 요소는 개발자 생산성을 갉아먹는 요소다. 게다가 위험도 누적된다. 반복되는 빌드에도 불구하고 개발자가 체크인할 시간이 생길 때까지 기다리게 되면 빌드는 거의 쓸모가 없어진다.

 

더 나쁜 점은 이것은 장시간에 걸친 개발자 작업의 복사본이 하나의 시스템에만 존재할 수 있음을 의미한다는 것이다. 긴 기간에 걸쳐 보면 모든 하드웨어의 생존율은 0에 가깝다.

 

비관적 잠금(pessimistic locking)은 “앗, 체크인하는 것을 잊고 휴가를 가버렸네”와 같은 경우에만 재앙인 것은 아니다. 이러한 시스템은 지속적으로 프로젝트를 소모시킨다. 두 사람이 동시에 같은 파일에 대한 작업을 수행할 가능성이 있는 것보다(같은 파일이라도 대부분의 경우 작업하는 부분은 서로 다르고, 이렇게 다른 부분들은 어차피 자동으로 병합됨), 팀의 절반이 파일 잠금이 풀리기를 기다리게 하는 편이 좋다고 믿는 사람들이 있다는 사실이 놀라울 뿐이다.

 

4. 분기 없이 프로덕션 단계로 이행한다

많은 조직이 아직 분기를 만드는 방법을 모른다. 분기는 릴리스를 완성하고, 이 릴리스에서 버그를 수정할 수 있게 해주되 절반쯤 개발된 새 코드를 프로덕션 단계로 릴리스하지 않게 해주는 매우 유용한 방법이다. 분기는 사실 어렵지 않다. 여러 가지 효과적인 분기 방법이 존재한다. 필자가 지난 2년 동안 사용해 본 모든 버전 관리 시스템에서 분기를 지원한다. 그러나 분기를 위해서는 개발자가 자신의 버전 관리 시스템에 익숙해져야만 한다.

 

5. 부하 테스트는 마지막까지 기다렸다가 한다

테스트 우선(test-first), 페어 프로그래밍(pair programming)을 도입한 가장 유능한 조직 중에서도 부하 테스트는 프로젝트의 끝부분에 하는 것으로 생각하는 조직이 종종 있다.

 

이것을 정당화하는 것은 “이른 최적화는 모든 악의 근원”이라는 격언이다. 이 말에도 일리는 있다. 그러나 지금의 의사 결정으로 인해 프로젝트가 성능 또는 확장성 요구 사항을 충족하지 못하게 될 수 있는지 여부를 알아야 한다. 이러한 의사 결정을 가장 비용을 덜 들여 잡아낼 수 있는 시점은 프로젝트의 초기다.

 

이것은 반복자가 나은지, 루프 또는 모나드가 나은지를 따지는 것이 아니다. 잘못된 데이터 저장, 잘못된 알고리즘, 잘못된 규칙 엔진과 심각한 동시성 문제에 대한 이야기다. 이러한 문제를 너무 늦게 잡아낼 경우 엄청난 분량의 코드를 재작성해야 할 수 있다.

6. 용량/성능 요구 사항 없이 개발한다

성능 또는 확장성 문제로 고민하는 사람들을 도울 때 필자가 가장 먼저 던지는 질문은 “기대 사용자 수는 몇 명인가?”다. 기술적인 측면에서 문제의 근원이 무엇이든, 진짜 문제는 이 질문에 대해 답하지 못하는 것이다. 성공적인 프로젝트는 최소한 막연한 추정치라도 갖고 있다.

 

단지 좋은 소프트웨어를 위한 요소가 아니라 기본적인 비즈니스 예측이다. 적절한 부하 테스트를 개발하려면 성능에 대한 예상치가 필요하다. 시스템에서 감당해야 하는 사용자가 몇 명인지 알아야 한다.

 

7. 마지막 단계에 가서야 사용자들과 접촉한다

마케팅 담당자들은 수십 년 동안 포커스 그룹을 사용해왔다. 제품 개발 그룹이 목적을 이루었고 누군가 그 제품을 구입할 것임을 확인해야 하기 때문이다. 소프트웨어 개발에서도 마찬가지다. 고객이 내부에 있든 외부에 있든 누군가는 최종 제품이 최대한 신속하게 사용자들의 검열에 통과할 것임을 확인해야 한다.

 

“다듬어지지 않은” 소프트웨어를 보여준다는 것은 당황스럽고 골치 아픈 일이 될 수 있지만 그렇게 하지 않으면 사용자의 기대를 충족할 것인지 아닌지를 전적으로 운에 맡겨야 한다.

 

8. 무조건 구입하는 것으로 소프트웨어 개발을 해결하려고 한다

구입하느냐, 구축하느냐는 IT에서 가장 근본적인 난문 중 하나다. 물론 내부 애플리케이션 개발보다 상용 애플리케이션이 더 적합한 경우가 있다. 그러나 예를 들어 전체 오라클 또는 웹스피어 스택을 라이선스하고도 아무런 결과를 얻지 못하는 경우도 있다. 개발팀이 무언가를 흡수해서 활용할 수 있는 역량에는 한계가 있고, 이를 넘어서게 되면 스택의 복잡성이 기술적인 혜택을 상쇄하게 된다.

 

9. 캐시, 데이터베이스, 쓰레드 풀, 연결 풀, 트랜잭션 매니저 등을 작성한다

이들 중 하나를 개발 중인 회사 또는 오픈소스 프로젝트에 속해 일하는 것이 아니라면 이러한 것을 만들 이유는 사실상 없다. 무수히 많은 사람들의 QA를 거친 안정적인 솔루션이 있는데 굳이 코드를 직접 작성하지 말라. “더 나은 코드를 만들어야 할” 이유가 무엇이든, 그러한 다수의 인증을 앞서는 경우는 거의 없다.

 

10. RDBMS에 직접 코딩한다

요즘에는 객체 관계형 매핑 시스템과 관련하여 무의미한 코드가 상당히 많이 만들어진다. 사실 객체관계형 매핑 시스템에 대해서는 예전부터 항상 무의미한 코드가 많이 만들어진다. ORM을 포기하고 JDBC나 OleDB에 “직접” 코딩하는 것을 정당화하는 데는 보통 한두 가지의 극단적인 사례가 활용된다. 그러나 사실 외부 CRUD 코드를 디버그할 수는 없다. 필자가 사용해 본 모든 ORM 시스템은 이러한 한두 가지 극단적 사례를 버리지 않고 처리할 수 있는 방편을 제공한다.

연구 학습정보 출처 : http://www.itworld.co.kr/news/77264