Offcanvas

리더십|조직관리 / 애플리케이션

최악의 소프트웨어 개발 프랙티스 10가지

2012.08.13 Andrew Oliver  |  InfoWorld
6. 용량/성능 요구 사항 없이 개발한다
성능 또는 확장성 문제로 고민하는 사람들을 도울 때 필자가 가장 먼저 던지는 질문은 “기대 사용자 수는 몇 명인가?”다. 기술적인 측면에서 문제의 근원이 무엇이든, 진짜 문제는 이 질문에 대해 답하지 못하는 것이다. 성공적인 프로젝트는 최소한 막연한 추정치라도 갖고 있다.
 
단지 좋은 소프트웨어를 위한 요소가 아니라 기본적인 비즈니스 예측이다. 적절한 부하 테스트를 개발하려면 성능에 대한 예상치가 필요하다. 시스템에서 감당해야 하는 사용자가 몇 명인지 알아야 한다.
 
7. 마지막 단계에 가서야 사용자들과 접촉한다
마케팅 담당자들은 수십 년 동안 포커스 그룹을 사용해왔다. 제품 개발 그룹이 목적을 이루었고 누군가 그 제품을 구입할 것임을 확인해야 하기 때문이다. 소프트웨어 개발에서도 마찬가지다. 고객이 내부에 있든 외부에 있든 누군가는 최종 제품이 최대한 신속하게 사용자들의 검열에 통과할 것임을 확인해야 한다.
 
“다듬어지지 않은” 소프트웨어를 보여준다는 것은 당황스럽고 골치 아픈 일이 될 수 있지만 그렇게 하지 않으면 사용자의 기대를 충족할 것인지 아닌지를 전적으로 운에 맡겨야 한다.
 
8. 무조건 구입하는 것으로 소프트웨어 개발을 해결하려고 한다
구입하느냐, 구축하느냐는 IT에서 가장 근본적인 난문 중 하나다. 물론 내부 애플리케이션 개발보다 상용 애플리케이션이 더 적합한 경우가 있다. 그러나 예를 들어 전체 오라클 또는 웹스피어 스택을 라이선스하고도 아무런 결과를 얻지 못하는 경우도 있다. 개발팀이 무언가를 흡수해서 활용할 수 있는 역량에는 한계가 있고, 이를 넘어서게 되면 스택의 복잡성이 기술적인 혜택을 상쇄하게 된다.
 
9. 캐시, 데이터베이스, 쓰레드 풀, 연결 풀, 트랜잭션 매니저 등을 작성한다
이들 중 하나를 개발 중인 회사 또는 오픈소스 프로젝트에 속해 일하는 것이 아니라면 이러한 것을 만들 이유는 사실상 없다. 무수히 많은 사람들의 QA를 거친 안정적인 솔루션이 있는데 굳이 코드를 직접 작성하지 말라. “더 나은 코드를 만들어야 할” 이유가 무엇이든, 그러한 다수의 인증을 앞서는 경우는 거의 없다.
 
10. RDBMS에 직접 코딩한다
요즘에는 객체 관계형 매핑 시스템과 관련하여 무의미한 코드가 상당히 많이 만들어진다. 사실 객체관계형 매핑 시스템에 대해서는 예전부터 항상 무의미한 코드가 많이 만들어진다. ORM을 포기하고 JDBC나 OleDB에 “직접” 코딩하는 것을 정당화하는 데는 보통 한두 가지의 극단적인 사례가 활용된다. 그러나 사실 외부 CRUD 코드를 디버그할 수는 없다. 필자가 사용해 본 모든 ORM 시스템은 이러한 한두 가지 극단적 사례를 버리지 않고 처리할 수 있는 방편을 제공한다. editor@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.