추상화 , 언제나 좋아 , 늘 짜릿해

궁하면 통한다고 했었나

요새도 예전에 만지던 프로젝트를 여전히 회사에서 진행중이다.

리팩토링 할 시간 내기 너무 빡세고 , 점점 코드는 꼬여가고 기술 부채는 쌓여간다.

누군가의 탓을 하기에는, 모바일의 특성상, 수명이 짧다보니 큰맘먹고 시간은 오래 들여 리팩토링 하기엔 조금 무리다.

그래서 왠만하면 반복되는 클래스는 상속 대신 인터페이스로 구현하고 ,

그걸 하다보니 꽤 편리하다고 생각해서 , 요새는 다른 객체나 모듈의 함수조차도 함수 포인터로 박아서 쓰는 게 좋다고 믿는 편이다.

특히 , C# 에서는

delegate 보다도 , Func , Predicate , Action 등을 사용하면 굉장히 스무쓰하게 !

의존성에 대한 고민을 좀 덜해도 되는 형태로 구현할 수 있다 ㅠㅠ!

시간에 대한 생각

프로그래머로 일 하다보니, 당연히 시간에 대해서 자주 고민하게 되는 내 자신을 발견한다.

10일 내에 해결 할 수 있는 방법과, 1시간 내에 해결 할 수 있지만, 앞으로 몇달은 고통 받을 것과

오랜 시간 동안 들인 시간에 보답할 만한 생산성 좋은 구조를 짜는 것,

또는 같은 머신으로 더 적은 시간을 들여서 게임에 필요한 연산들을 처리할 수 있는 방법이라던가..

게다가, 어떤 요청이 들어오면, 예상 소요시간을 리턴하는 것도 프로세스로 건의해서 다시 하고 있는데,

( 전 회사에선 늘 했었지만, 안하다 하니 또 녹슨 것 같더라. 아니면 실력이 좀 변해서 그럴지도 )

우연히 아침에 공부할 시간이 나서, C++ 서적을 다시 보다가 ( 좋아하는 서적은 아니지만 … )

좋은 구조에 대해서, “미래의 내가 아닌 누군가가 사용하거나 변경해도 무리가 없는 “ 구조 라고 서술 하는 것을 보고

생각이 나름 정립되었다. 정보를 다루는 정보 공학이나 전산학, 프로그래밍, 소프트웨어 엔지니어링 , 코딩의 영역에서

결국 중요한 것은 시간이 되기 때문이다. 정보는 주 재료이긴 하고, 주로 다루는 것이지만, 이도 결국은

어떤 시간 내에 어떤 양이나 질의 데이터를 정보로서 뽑아내거나, 다루는 지가 중요하다고 이해했다.

시간 복잡도, 연산 처리 장치나 소프트웨어의 성능의 정의만 보더라도 , 시간은 프로그래밍으로 벌 수 있는 것 중 하나다.

파이프라이닝, 추상화 , 모듈화 , 객체지향, 함수형 패러다임 등등 …. 결국엔 생산성을 얻기 위함이거나,

인지 자원이나 시간을 아끼기 위함이니, 결국엔 시간을 들여 시간을 버는 업무가 프로그래밍의 본질이 아닐까?

하고 감히 초짜 프로그래머 주제에 , 붕 뜬 이야기를 여기다 정리헤 놓게 되었다.