인터페이스라는 사치

소프웨어 엔니지어링에서 가장 교조주의적인 덕목은 인터페이스를 위시한 유연성,확장성이 아닐까 싶다. (추가적으로 제네릭과 폴리모피즘의 환상 떡칠은 가독성을 최악으로 치닫게 만든다.) 그게 절실히 필요한 코드는 5%나 될까 싶은데 주로 공용 라이브러리겠지.나머지 95%의 코드를 만드는 사람들이 모든 책에 적혀져있는 "확장가능하게 만들어야한다" 를 맹목적으로 받아드리고 있는거 같기도 하며,교조적인 덕목에 따라 혹시 자신은 유연하게 만들지 않았는지에 대한 죄책감이 남아 있을지도 모르겠다. 물론 그 정도 고민을 하는 사람이라면 그것만으로도 훌륭하다고 볼 수 있겠다. 까놓고 말해보자. 자신이 만든 클래스가 100개 있다면, 그 중에 1년 후에 형제 클래스를 만들어야 했던 경우가 얼마나 되었는지. 내 경우는 하나 밖에 없다. 솔직히 말하면 오히려 안쓰던 클래스를 줄였다.일반 응용프로그래밍 작성시 확장성 있게 만들지 않아서 고통받는 코드는 거의 별로 없다. 성능문제와 마찬가지로 확장성이 필요하면 그때 가서 고쳐도 충분한 코드(팀내에서 조율 가능한)가 훨씬 더 많다.짐을 내려 놓아도 된다.

*

특히 대형 솔루션을 만들지 않는 마이크로 서비스 형태의 스타트업이라면 철저하게 빠른 구현 위주로 가야 하며, 뜯어 고치는거 & 더 좋게 새로 만드는 것은 눈감고도 기민하게 해야 한다.즉 비지니스 로직(예를들어 MVC 경우 Controlller 단, Service 단) 따위는 유연성을 따지는 것은 오바고, 다양한 외부인터페이싱이 요구될 가능성이 있는 DB 접속 (예를들어 MVC 경우 Repository단) 같은 경우에도 PostgreSQL 을 사용하다가 InfluxDB 를 추가시 기존에 공통 인터페이스가 없더라도 후딱 만들어 넣어야 한다는 야그~