SOLID 객체지향원칙을 지킨다.
- SRP (단일책임의 원칙: Single Responsibility Principle)
- OCP (개방폐쇄의 원칙: Open Close Principle)
- LSP (리스코브 치환의 원칙: The Liskov Substitution Principle)
- ISP (인터페이스 분리의 원칙: Interface Segregation Principle)
- DIP (의존성역전의 원칙: Dependency Inversion Principle)
KISS(Keep It Small Simple) 간단하고 단순하게
복잡한 코드를 작성하지 말라. 간단하게 작성하면 버그가 줄어들고 디버깅 시간도 줄어들 수 있다.
코드는 수많은 추상화 및 기타 객체지향적인 문제 (특히 Java 개발자와 관련이 있음) 없이 딱 필요한 일만을 수행해야하며, 추후에 간단한 방법으로 코드를 업데이트하기 위해 필요한 것의 20%를 수행해야한다.
- Dept를 깊게 하지 않는다. (2 dept 부터는 문제가 있어보임.)
- 주석이 없어도 이해하기 쉽게 개발해라
컨벤션을 지켜라.
컨벤션은 가독성을 높여준다.
최적화 VS 가독성. 최적화보단 가독성
- 코드는 항상 읽기 쉽고 개발자들이 이해할 수 있게끔 작성하라.
- 읽기 어려운 코드를 읽는데 소모되는 시간과 비용은 최적화로부터 얻을 수 있는 것보다 더욱 크다.
- 최적화가 필요하다면, DI (의존성 주입)을 사용해 독립적인 모듈로 만들고, 100%의 테스트 커버리지를 유지하여 최소 1년간은 건들지 않아도 되도록 만들어라.
테스트 커버리지
테스트는 좋은 일이지만 항상 비용 효율적인건 아니며 프로젝트에 따라 다르다.
테스트가 필요한 경우:
- 최소 한 달간은 건들지 않아도 될 모듈이나 마이크로서비스를 개발하는 경우
- 오픈소스 코드를 작성하는 경우
- 핵심 코드 또는 금전적인 부분과 맞닿는 코드를 작성하는 경우
- 코드를 업데이트 하는 것과 동시에 테스트를 업데이트 할 수 있는 충분한 비용이 있는 경우
테스트가 필요하지 않는 경우:
- 스타트업인 경우
- 팀이 작고 코드가 빠르게 변하는 경우
- 출력값을 보고 간단하게 수동으로 테스트가 가능한 스크립트를 작성하는 경우
나쁜 테스트 코드와 함께 코드를 짜는 것은 테스트가 없는 코드보다 더 위험할 수 있음을 기억하라.
아키텍처를 우선시 해라
나는 “우리는 빨리 개발을 해야하기 때문에 아키텍처를 설계할 시간이 없다”라고 말하는 사람을 많이 봐왔다. 그리고 그 중 99%가 이러한 생각 때문에 큰 문제를 겪었다.
아키텍처를 생각하지 않고 코드를 작성하는 것은 목표 달성을위한 계획없이 자신의 욕망을 꿈꾸는 것처럼 쓸모가 없다.
코드를 작성하기 전에 먼저 수행 할 작업, 사용 방법, 모듈화 방법, 서비스가 서로 어떻게 동작하는지, 구조가 무엇인지, 테스트 및 디버깅 방법, 업데이트 방법들을 먼저 생각하고 이해해야한다.
짧은 주석
주석은 나쁜 코드를 보여준다. 좋은 코드는 주석 없이도 이해할 수 있어야한다. 그러면 새로운 개발자를 위해 시간을 절약하기 위해 해야 할 일은 무엇인가?
- 메서드의 정의와 사용법을 설명하는 한 줄짜리 간단한 문서를 작성하라. 이는 이해를 위한 많은 시간을 절약해 줄 것이며
- 더 많은 사람들에게 메서드를 더 잘 구현할 수 있는 기회를 제공해준다. 또한 이는 글로벌 코드 문서화를 위한 좋은 시작점이 될 것이다.
강한 결합 VS 느슨한 결합
항상 마이크로서비스 아키텍처를 사용하도록 노력하라. 모놀리틱 소프트웨어는 마이크로서비스 소프트웨어보다 빠르지만, 단일 서버 환경에서만 그렇다. 마이크로서비스는 여러분의 소프트웨어를 여러 서버로의 분산뿐만 아니라 가끔은 하나의 머신에서의 분산처리 (프로세스 분산을 의미한다)도 할 수 있는 가능성을 제공해준다.
코드 리뷰
코드 리뷰는 좋을 수도 있고 나쁠 수도 있다.
여러분의 팀에 코드의 95%를 이해하고 있고 시간 낭비 없이 모든 업데이트 사항을 모니터링 할 수 있는 개발자가 있는 경우에만 코드 리뷰를 도입하도록 하라. 이 외의 경우에는 단지 시간 낭비가 될 수 있으며 모두가 이를 싫어하게 될 것이다. 이 부분은 많은 질문을 가져오기 때문에 이를 좀 더 깊게 살펴보자.
많은 사람들은 코드 리뷰가 새로운 사람이나 코드의 다른 부분을 작업하는 팀원을 가르치는 좋은 방법이라고 생각한다. 그러나 코드 리뷰의 주요 목표는 코드 품질을 유지하는 것이지 가르치는게 아니다. 여러분의 팀이 원자로 또는 우주 로켓 엔진 냉각 시스템을 제어하는 코드를 작성했다고 가정해보자. 그리고 여러분은 아주 어려운 로직에서 큰 실수를 저질렀고, 이를 새로운 사람에게 코드 리뷰를 위해 제공했다고 해보자. 이 경우 여러분은 사고 위험에 대해 어떻게 생각하는가? — 내 대답은 70% 이상이다.
좋은 팀은 각자가 자신의 역할을 가지고 있으며 일의 한 부분에 대해 완전한 책임감을 갖고 있는 팀이다. 만약 누가 코드의 다른 부분을 이해하고 싶으면 해당 부분을 담당하고 있는 사람에게 찾아가 질문을 하면된다. 모든걸 아는건 불가능하며 전체보다는 코드의 작은 부분을 (하지만 적어도 30%는) 완전히 이해하는것이 더 낫다.
자동화 VS 수동
자동화는 장기적으로 100% 성공이다. 따라서 지금 당장 무언가를 자동화 할 수 있는것이 있다면 바로 하도록 하라. “5 분 밖에 걸리지 않는데, 왜 자동화 해야해?“라고 생각할 수도 있다. 하지만 한 번 계산해보자. 예를 들어 5명의 개발자로 이루어진 팀의 일상적인 작업을 들어보자. 5분 * 5명 * 21일 * 12개월 = 6,300분 = 105시간 = 13.125 일 ~ 5,250$. 직원이 40,000명일 경우엔 비용이 얼마나 커질까?
