2012.08.13

최악의 소프트웨어 개발 프랙티스 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)을 도입한 가장 유능한 조직 중에서도 부하 테스트는 프로젝트의 끝부분에 하는 것으로 생각하는 조직이 종종 있다.
 
이것을 정당화하는 것은 “이른 최적화는 모든 악의 근원”이라는 격언이다. 이 말에도 일리는 있다. 그러나 지금의 의사 결정으로 인해 프로젝트가 성능 또는 확장성 요구 사항을 충족하지 못하게 될 수 있는지 여부를 알아야 한다. 이러한 의사 결정을 가장 비용을 덜 들여 잡아낼 수 있는 시점은 프로젝트의 초기다.
 
이것은 반복자가 나은지, 루프 또는 모나드가 나은지를 따지는 것이 아니다. 잘못된 데이터 저장, 잘못된 알고리즘, 잘못된 규칙 엔진과 심각한 동시성 문제에 대한 이야기다. 이러한 문제를 너무 늦게 잡아낼 경우 엄청난 분량의 코드를 재작성해야 할 수 있다.
 



2012.08.13

최악의 소프트웨어 개발 프랙티스 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)을 도입한 가장 유능한 조직 중에서도 부하 테스트는 프로젝트의 끝부분에 하는 것으로 생각하는 조직이 종종 있다.
 
이것을 정당화하는 것은 “이른 최적화는 모든 악의 근원”이라는 격언이다. 이 말에도 일리는 있다. 그러나 지금의 의사 결정으로 인해 프로젝트가 성능 또는 확장성 요구 사항을 충족하지 못하게 될 수 있는지 여부를 알아야 한다. 이러한 의사 결정을 가장 비용을 덜 들여 잡아낼 수 있는 시점은 프로젝트의 초기다.
 
이것은 반복자가 나은지, 루프 또는 모나드가 나은지를 따지는 것이 아니다. 잘못된 데이터 저장, 잘못된 알고리즘, 잘못된 규칙 엔진과 심각한 동시성 문제에 대한 이야기다. 이러한 문제를 너무 늦게 잡아낼 경우 엄청난 분량의 코드를 재작성해야 할 수 있다.
 

X