요즘 개발하면서 이것저것

근래 회사에서 개발하는 것들이 꽤 재미있는 부분이 많았다. 생각도 정리할 겸 이것저것 적어 보는걸로.

새롭게 개발하는 것들이... 기존의 기능을 유지하면서 새로운 기능을 덧붙여야 하는데...기능이 많아! 이런 일들이 꽤 생겼다.

코드의 재사용성은 최대한 높이면서 다른 기능과는 붙이기 좋게 만들어야 한다. 라는 결론을 지극히 당연한 결론이긴 하지만,

상세 구현과 구현을 위한 언어의 스펙을 활용하는 것에 관해서 동료인(그리고 고수인) L과 이야기를 많이 하게 되었다.

(기억이 좀 부정확해서 아직 헷갈리는 점이 좀 있다.)

평소에 생각했던 것과 이야기, 개발을 통해서 느낀 걸 좀 정리해 보면..

1. 싱글톤 사용.

디자인 패턴에 보면 매우 좋은 것으로 설명이 되어 있긴 한데, 실제 써보면 딱히 좋진 않다.

일단 생성 시점이 명확하지 않으며, 해제 또한 그렇다. 만약에 유닛 테스트 등을 적용하기에도 매우 좋지 않다.

결정적으로 싱글톤 패턴을 사용하면 코드의 커플링이 매우 높아진다. 이는 유지 보수를 매우 어렵게 만든다.

프로세스에 하나 정도 있는 것은 나쁘지 않다. 물론 딱 하나만.

싱글톤이 좋은 점은 딱 하나다. 개발할 때 생각없이 데이터를 넣고 쓰기 좋다는 것.

2. 출력 타입의 통일

중간 데이터로 파일을 생성하거나 결과물을 생성할 때는 하나의 포맷으로 출력하는 편이 좋다.

xml 또는 json이 매우 적합하다고 본다.

처음 결과물은 빈약할지라도 서드 파티의 사용으로 데이터 가공이 매우 쉽다.

3. 참조

클래스 내부에 다른 기능을 하는 클래스의 참조를 최대한 제거하는 게 바람직하다. 참조를 가지게 되면, 인터페이스를 가지며 콘크리트 객체를 직접적으로 가지지 않는다. 만약 클래스간의 순차적 실행이 필요하다면 이벤트(이 부분은 언어적 특성에 따라 달라질 수 있다)를 사용하는 것이 바람직하다.

4. 상속

모든 부분에 상속을 적용하는 것이 바람직한가? 사실상 코드 뎁스만 늘리는 것이 아닌가?

상속의 depth 는 제한할 필요가 있다. 무분별한 상속은 구조만 복잡하게 만들 뿐이며 큰 이득도 존재하지 않는다.

상속이 필요한 부분은 state machine의 형식을 가지는 기능(뭔가 애매한 설명이긴 한데 더 정리가 안 된다.)이 적합하다.

제한적으로 type확정이 필요한 클래스에 사용하면 좋다.(기능은 같지만, 타입 자체는 다르고 혼용하면 안되는 기능)

코드를 보면서 이야기 할 때는 뭔가 설명이 잘 되는데 코드 없이 글로만 정리를 하려니 꽤 어려운 듯 하다.