Readtrend Weekly

Issue #79

2016-10-25 ~ 2016-11-08

Headline

  • 확장하기 쉬운 코드가 아니라 삭제하기 쉬운 코드를 작성하자
    • * 우리가 작성한 모든 코드에는 유지보수라는 형태의 대가가 따른다. 그래서 우리는 대가를 치뤄야 하는 코드가 너무 많아지는 것을 방지하기 위해서 재사용할 수 있는 소프트웨어를 만들려고 노력한다. 하지만 코드를 재사용하면 다른 문제가 발생한다. 나중에 코드를 바꾸려 할 때 재사용된 코드가 방해를 한다는 점이다. 그래서, 우리는 재사용할 수 있는 소프트웨어가 아니라 쉽게 버릴 수 있는 소프트웨어를 만들려고 노력해야 한다.
    • * 한 라이브러리를 다른 라이브러리로 감싸는 것은 세부사항을 감추는 것보다는 관심사(concern)를 분리하는 것이 목적이다.
    • * 꼭 프로토콜같은 종류의 라이브러리가 아니더라도 서드 파티 라이브러리는 래퍼로 감싸주는 것이 좋을 때가 많다. 그러면 프로젝트 전체에 걸쳐서 특정 서드 파티 라이브러리에 락인되는 대신, 자신의 코드에 적합한 라이브러리를 직접 만들 수 있다. 사용하기 편한 API를 만드는 것과 확장이 쉬운 API를 만드는 것은 상충할 때가 많다.
    • * 재사용 여부를 중심으로 모듈을 만드는 것이 아니라, 바꿀 수 있는지 여부를 중심으로 모듈을 만드는 것이다.
    • * 안타깝게도 어떤 문제들은 서로 깊이 엮여 있어서 다른 문제들보다 분리하기가 더 어렵다. 단일 책임 원칙에 따르면 ‘하나의 모듈은 하나의 어려운 문제만 다뤄야 한다’고 하지만, 이 경우에는 ‘하나의 어려운 문제는 하나의 모듈에서만 다뤄져야 한다’는 쪽이 더 중요하다.
    • * 에러 핸들링과 회복은 코드 베이스의 외곽에서 하는 것이 최선이다. 이는 엔드-투-엔드원칙이라고도 알려져 있다. 이 원칙에 따르면 연결의 각 끝단에서 실패를 처리하는 것이그 사이의 어떤 중간지점에서 실패를 처리하는 것보다 더 쉽다.
    • * 건강한 코드 베이스는 완벽하게 모듈식으로 구성될 필요는 없다. 하지만 모듈 형식으로 된 부분에는 훨씬 즐겁게 코드를 작성할 수 있는데, 이는 코드끼리 서로 잘 맞아 떨어지기 때문이다. 레고 부품을 가지고 노는 것이 재밌는 이유와 똑같다. 건강한 코드 베이스는 조금 장황하고 조금 반복적이지만, 덕분에 동작하는 코드 사이에 충분한 공간을 남겨두어서 코드를 다루다가 손이 끼어버리는 사고가 발생할 일이 없다.
    • * 레이어 나누기, 격리, 공용 인터페이스, 컴포지션 등 내가 이 글에서 논의한 전략들의 목표는 좋은 소프트웨어를 만드는 것이 아니라 시간이 지나도 변화할 수 있는 소프트웨어를 만드는 것이다.
    • * 작성한 코드를 통째로 버릴 필요는 없지만 그 중 일부는 삭제해야 할 것이다. 좋은 코드는 한 번에 제대로 만든 코드가 아니다. 좋은 코드는 나중에 방해가 되지 않는 레거시 코드다. 좋은 코드는 삭제하기 쉽다.

SPONSOR

생활코딩은 일반인에게 프로그래밍을 알려주는 활동으로, 온라인/오프라인 무료 강의를 제공합니다.

* https://opentutorials.org/course/1
* Youtube 구독하기

FrontEnd

BackEnd

IT_Knowledge

Books