70세 코딩

1. 프로그램 개발 완료 후, 수정하게 되는 경우 기 개발된 로직과의 충돌(상호모순) 또는 무시하게 되는 경우를
    사전에 예방할 수 있는 방법은?  또는 테스트 할 수 있는 방법은?
    (예) 계산서 발행 프로그램에서 거래명세서 발행분만 발행 할 수 있도록 변경 하였더니
        '매출할인'계산서(거래명세서 없음)도 발행 할 수 없게 되는 bug 생성.

2. 현업과의 업무분석 시 주의 점
  - 모든 현업의 요구사항은 그 앞에 하나의 말이 생략 되어 있다. 바로
     "지금은(현재는)" 이다.
  - 어떠한 요구사항도 변경 될 수 있다는 점을 간과해서는 안된다.
    "그런 프로세서는 없습니다." 라는 현업의 말 속에는
    "지금은 그런 프로세스는 없습니다. 그러나 나중에는 발생 할 수 있습니다." 라는 뜻임을 명심할 것!

3. 생산, 매출, 반품, 환입 .... 회계(계산서)
  - 생산 부터 이후의 모든 프로세스 까지 연결고리가 끊어지지 않도록 설계 되어야 한다.
  - 생산(제조사업장), 도매(판매사업장) 사업장간의 자유로운 재고이동 및 매출/반품이 고려 되어야 한다.
    (매출발생한 사업장으로 반품(재고, 계산서)이 발생)

4. 폐업이나 사업주 변경 등으로 거래처 잔고가 이동 할 때, 실적 또한 이동 해야 반품 시에 원래(변경전) 거래처를 
   찾아가서 단가정보 등을 찾을 수 있다.
   여기서 실적이동 이란 실제로 전표내역이 이동한다기 보다, 변경 된 거래처코드 간 이력을 관리해야 한다는 의미 임.
   변경된 거래처간 이력이 없을 경우 부동처조회에도 영향을 미친다. 즉 과거 거래처에서 수금이 6개월 이상 없어서
   부동처 임에도 불구 하고  신규 거래처로 잔고 이동할 경우, 이동한 일자가 6개월 미만이라면 수금부동처에서 누락이 된다.

5. 설계변경시 유의점
  - 변경하게 될 경우 과거 및 현재의 데이터를 어떻게 할 것인가?
    (과거 데이터의 마이그레이션 및 현재 발생중에 있는 데이터의 처리)