남이 만든 프로그램 코드 수정 작업

이건머...

남이 만들어 놓은 프로그램 소스코드 수정하는것은 쉽지 않다.
이번에도 참, 어렵게도 만들어 놓았다.
돌리고, 돌리고, 돌려서,....
데이터 추적하려면, 왠만한 인내심으로는 매우 어렵다.
브레이크를 5번도 더 걸어야, 겨우 찾을 수 있고,
함수명이나, 기능등도 엉뚱한 클래스에 들어 있어,
전체가 한덩어리다.
분명히 클래스로 잘 나누어 놓았지만,
서로 관련되어 있어, 클래스 하나 빼는것이, 너무나 어렵다.
지금 몇번째 시도하고 있지만, 매번, 갑자기 나타나는 함정에 좌절하고 있다.


잘 작성된 프로그램 코드
========================
- 가독성이 좋아야 한다.
  함수,변수명 작성을 의미있는, 정확한 단어를 선택해야한다.
  처음에는 잘몰라서, 아무단어나 쓰는데,
  나중에는 엉뚱한 의미의 함수명, 변수명때문에 몇시간을 헤메는 경우도 적지않다.
  단순한 버그를 추적하는데도, 변수명, 함수명이 엉뚱하다면, 혼란스러워, 매우 오래걸리게된다.

- 전체적인 기능 분리가 잘되어 있어야 한다.
  GUI, 통신, 장비 데이터등을 교체하기 용이해야한다.
  보통 GUI애 통신+데이터를 같이 넣어서 작성하기때문에, 하나 고치려면, 거의 불가능에 가깝다.
  아무리 클래스로 분리해놓았더라도, 상속, 중복, 클래스간 비합리적인 연결이 많다면,
  분리가 어렵다.
  가장 좋은 방식은, 함수나 클래스의 내용만 바꾸면, 1:1로 치환이 되는 경우이다.
  또한, 동일한 인터페이스(함수,변수)를 갖는 다른 파일로 교체하면, 바로 컴파일이 가능해야한다.
  물론, 쉽지 않지만, 너무 많은 변수와 함수가, 서로 연관되어 있다면, 마치 거미줄 모양이되며,
  이런 프로그램을 부분적으로 교체하는 작업은 거의 불가능해진다.
  차라리 새로 작성하는것이 더 빠른경우도 많다.

- 안쓰는 코드는 주석처리
  안쓰는 코드인데, 오래되거나, 여러사람 거치다보면,
  용도를 몰라, 삭제할 수 없는 경우가 많다.

- 이벤트+쓰레드+FIFO 방식은 가능하면 자제
  이런 코드는 추적(디버깅)하기가 어려운것이 보통이다.
  가능하면, 함수를 호출하여, 결과가 바로 나타나는 방식으로 작성하는것이 좋다.
  쓰레드->이벤트->FIFO->이벤트->쓰레드->FIFO->쓰레드->...
  지금 이런 코드를 보고 있다. 농담이 아니다.