소프트웨어 개발에 있어서 개발을 마무리하고 종료하는 능력은 매우 중요하다.

항상 경험했지만 첨 개발 시작시 의욕과 패이스를 개발 막바지에도 유지하는 일은 어렵다.

개발이 마무리되어야 할 시점에는 시간이 모자르기 일수이며 때문에 오버타임을 감수하고 일을 진행해야 할 경우가 많다. 이미 그 시점에는 코드량 또한 늘어나고 시간에 쫒겨 코딩을 하기 때문에 설계나 코드등 잘 정리된 개발을 유지해 나가기 어렵다. 특히 초기 설계가 디테일한 부분까지 정해져 있는 않은 상황에는 개발자에 의해 스파게티 코드들이 마구 추가된다.

누구도 즐거워하지 않을 이런 상황에서 개발 초기의 의욕은 이미 없어지고 단지 마감날에 밀려 억지로 개발을 해나간다. 의욕 없는 개발은 개발 패이스를 떨어뜨리고 진행되지 않는 프로젝트는 또 다시 의욕을 떨어뜨리는 악순환으로 이어진다.

이때 문제 상황을 타계할 방법을 찾아 성공적으로 프로젝트를 완료하는 사람이 바로 *인정받는 개발자*일 것이다.

난 이런면에서 특히 약하다. 끈기라고 할까… 프로젝트 막바지 이런 문제 상황이 도래하면 그 상황을 해결하려는 의지 보다는 피하려는 의지가 더 많음을 느낀다. 그러면 안되는데…

ps) 다기능을 갖는 소프트웨어나 UI 중심적인 소프트웨어인 경우 더욱더 이런 *마무리 능력*이 요구되는 듯하다.

database intensive 작업들을 하다보니 데이터베이스 테이블이나 뷰, 스토어드프로시져의 랩퍼 클래스의 필요성을 느낀다. 더 나가 이러한 테이블 랩퍼 클래스의 작성을 자동화하거나 skeleton 코드를 자동 생성해 주는게 있으면 좋겠다는 생각이 든다.

자동으로 생성된 테이블 래퍼 클래스는 …

* 데이터 쿼리 및 업데이트, 삭제기능. 쿼리시 조건 지정할 수 있으면 금상첨화

* 데이터 쿼리시 페이징 기능도 있으면 웹인터페이스에서 유용하겠다.

* 필드 타입에 따른 필드 값의 안전한 접근 및 수정(프로그래밍 언어의 타입으로 맵핑, 임계값 체크에 의해)

* 한 단계 발전된 값 조회. 포린키에 의해 매핑되는 다른 테이블의 값 접근, 파일 시스템의 파일 접근 등이 그 예가 될것이다. 이때 또 다른 테이블 랩퍼 클래스를 사용할 것이냐 아니면 데이터베이스를 JOIN등의 쿼리문으로 새로 쿼리하느냐. 파일 시스템 접근은 FTP로 할것이냐 HTTP로 할것이냐.. 아니면 로컬 파일시스템 내의 파일냐 등등 주워진 컨텍스트에 적합한 여러가지 구현 방법이 있을 것이다. 따라서 이런 발전된 값 조회의 경우는 자동화되기 힘들 수 있다.

이런 테이블 래퍼 클래스들은 rich functionality를 제공해 주는 클래스는 아지만 ADO 등의 데이터베이스 접근 컴포넌트 보다 컨텍스트에 맞는 편리한 데이터 접근방법을 제공해 줄것이고, 프로그래머의 계속적인 기능 추가되어 편리하게 데이터 핸들링을 할 수 있게 할것이다.

dudgh에게 새롭고 낫선 얘기를 들었다.

A 사이트 IIS 서버에서 B 사이트 IIS 웹서버로 접근했을 때 세션 아이디가 생성된다.

이때 클라이언트가 B 사이트를 접근했한다면 그 세션아이디는 A 서버가 B 서버로 접근했을 때 생성된 세션아이디과 같다. 이때 클라이언트는 같은 프로세스여야 한다.

그림에서 번호 순서대로 요청이 수행될때 2번 요청에서 생성된 세션아이디와 3번 요청에서 생성된 세션아이디가 동일하다는 얘기… 즉, 동일한 세션이다!

미치겠군!

이는 요청이 어떤 경로로 들어왔건 클라이언트에 따라 세션아이디가 생성된다는 얘기인데… 그렇다면 클라이언트의 프로세스등 정보가 서버로 전송된다는 얘기인가?

흠…

확인할 필요가 있겠군.

프로젝트관리에서 중요한 영항을 미치는 범위, 인원, 기간의 요소들과 비용과의 관계를 생각해보자

비용은 범위나 인원, 기간과 비례관계이므로

비용 = 범위 * 인원 * 기간

범위, 인원, 기간 앞에는 적당한 상수가 곱해지면 얼추 맞을거 같은 생각이 든다. 더 많은 요소들이 비용에 영향을 주지만 이상적인 경우만을 생각하도록 하고…

기간과 범위, 인원과의 상관관계를 생각해보자.

기간은 범위에 비례, 인원과는 반비례 이다.

기간 = 범위/인원

이것을 첫번째 식에 대입해보면

비용 = 범위^2

계약 이전에 범위, 기간이 정해지고 그에 따르는 인력도 정해지는 것이 맞는 얘기이다.

그러나…

범위는 고객의 요구사항에 의해 결정되는데 그 요구사항이란 것이 XP에서 얘기하듯이 계속 변한다.

고객은 중간 산출물들을 보면 “이런 기능이 있으면 좋겠군”하는 식으로 요구사항을 늘려나간다.

어떨때는 “이건 이런식으로 바꾸자구” 식의 요구사항 변경도 일어난다. 물론 갑에 의해서…

갑에 대한 을의 대응이 좀 무르다 싶으면 이런 식의 요구는 더 많아진다.

요구사항의 추가나 변경은 생각하는 이상의 비용 증가를 초래하고, 비용증가 없이 요구사항을 반영하고자 개발자들을 다그치게 되지만 개발자의 능력 한계는 분명이 있는 것이고, 결과적으로 과 비용으로 프로젝트를 마치게 된다.

과 비용은 수익을 감소를 의미한다. 어떤 경우에는 마이너스 수익을 내게 된다.

항상 범위의 변경이 비용에 얼마나 중요한 영향을 미치는 factor인지 염두해 두어야 한다.

ps) XP는 개소리일지 모른다는 생각이 문득 든다. -_-;