내 코드는 걸레다, 개선을 위한 강한 자극이 필요하다.

문득.. 내 코드가 걸레로 보인다. 기분 탓일 수도 있겠지만.. 예전에 오픈소스로 공개한 코드를 살펴봤을때의 그런 일목요연하고 간결하며 체계적인 느낌이… 내가 작성한 코드에서는 느껴지지 않는다.

개발에 대한 체계적인 교육을 받지 못한 이유일까… 어쩌면 요즘 넘쳐대는 버그로 인해, 아직은 그 원인을 알지 못하는 이유로.. 코드가 전반적으로 꼬여있다라는 선입견 때문일까…

요즘에는 C++에 대한 감이 많이 상실된 느낌이다. 매일같이 사용하는 언어인데 말이다. 매일같이 바쁘게 사용하다보니, 늘 쓰는 것만 쓰게된다. 분명 어디선가 더 좋은 문법과 구문이 있다는 것을 알고 있음에도.. 비효율적이기는 하지만, 그냥 전에 썼던 방식대로 해 나간다. 그러다보니 전에 알고 있던 중요한 문법과 구문도 쓰지 않으니 기억속에서 희미하게 잊혀져간다.

정도(옳바른 길)을 걷지 못하고 있다는 느낌이다. 먼가 자극이 필요하다. 배움이 필요하다. 정도(옳바른 길)로 가는 깨닭음이 절실히 필요하다….

Software Design에 대한 짧은 생각과 팁

  • 파생 클래스 생성에 부담이 느껴진다면, 여전이 클래스 계층에 대한 추상화가 덜 되어 있다는 증거다.
2008년 1월 2일 오후 4시 29일

 

  • 속성 맴버 변수를 외부로 노출시키지 말고 get/set 함수를 두어 접근하도록 하는 것이, 클래스간의 독립성을 유지하는데 도움이 된다. get/set 함수를 만드는 수고로움에 대한 보상으로 말이다.
  • Class Diagram의 작성은 “인터페이스의 정의”로 시작된다.

12월 6일 오전 9시 56분

 

  • 데이터베이스에서 한번 정의된 스키마의 변경에 많은 소요비행이 발생한다면, 소프트웨어 개발에서는 클래스 관계도와 같은 UML 설계문서가 아닌 “전제조건”의 변경에 많은 소요비용이 발생한다. 여기서 말하는 전제조건이란, 어떤 기능을 실행하기 위해 준비되어야할 조건이다.

    11월 27일 오후 5시

     

  • 두렵다. 구현 단계에서 결국은, 비록 길지는 않은 시간이지만, 짧지만도 않은 시간 동안 설계한 내용을 폐기해야할지도 모른다는 생각에…. 그래서 분석 설계는 최대한 간결하게 하라고 했나보다. “어차피 내일은 변하다”니말이다. 하지만 최소한 설계 단계가 의미있는 이유는 실제 구현단계에서 마주치게 될 위험요소를 미리 파악할 수 있다는 큰 장점이 있다는 점이다. 그래서 인지… 설계를 하면 할 수록 두렵다….

10월 4일 오전 11시 36분

  • 영업인력이 고객에게 기술적으로  감동을 줄 수 있도록 개발인력은 소프트웨어를 설계하고 개발해야 한다.

9월 19일 14시 55분

 

  • 예를들어, Base라는 클래스로부터 상속받은 Derived라는 클래스가 있다고 할때, Base의 생성자의 인자가 (int a, int b, int c, int d)라고 하면, Derived 클래스의 생성자도 Base의 생성자를 실행하기 위해 인자로써 (int a, int b, int c, int d)를 최소한 가져야 하는데.. 만약 Base의 생성자의 인자가 하나 추가되면 Derived의 생성자의 인자도 동일하게 추가되어야한다. 하나의 변경으로 두개 이상의 변경이 발생하는 이 문제를 해결하기 위해 Derived의 생성자의 인자로 바로 Base를 받아 해결할 수 있다.
9월 19일 10시 12분

 

  • 서술식 글쓰기도 설계 방법 중의 하나.. UML과 글쓰기의 적절한 결합이 필요하다..
    9월 18일 12시 49분

     

  • 어디 쓸만한 꽁짜 UML 툴없나… 지금 쓰고 있는 StarUML은 결과는 그런대로 산뜻하긴 한데, UML 스펙을 지원하지 않는게 넘 많다. 지원하는 척… 하곤 결국 완벽이 지원하지 않는 그런 모습. 언제 쓸만한 공짜 UML 툴 찾아봐야겠다.

    9월 14일 12시 57분

     

 

  • 소프트웨어 설계라는 것이 유지보수와 소프트웨어의 생명주기를 길게 하는 효과는 있으나, 소프트웨어의 성능에 오히려 방해가 되는 것 같다는 생각이 든다.

    9월 13일 9시 54분