[번역] 좋은 코딩을 위한 13 가지 간단한 규칙

13 Simple Rules for Good Coding (from my 15 years of experience)를 번역한 글입니다.

나는 15년 이상의 경력을 가진 프로그래머이며 많은 여러 언어, 패러다임, 프레임워크를 사용해봤고 많은 삽질을 해봤다. 그리고 나는 좋은 코딩을 작성하기 위한 나만의 규칙들을 여러분에게 공유하고자 한다.

 

1.      최적화 VS 가독성. 최적화보단 가독성

코드는 항상 읽기 쉽고 개발자들이 이해할 수 있게끔 작성하라. 읽기 어려운 코드를 읽는데 소모되는 시간과 비용은 최적화로부터 얻을 수 있는 것보다 더욱 크다. 최적화가 필요하다면, DI (의존성 주입)을 사용해 독립적인 모듈로 만들고, 100%의 테스트 커버리지를 유지하여 최소 1년간은 건들지 않아도 되도록 만들어라.

2.      아키텍처 우선

나는 “우리는 빨리 개발을 해야하기 때문에 아키텍처를 설계할 시간이 없다”라고 말하는 사람을 많이 봐왔다. 그리고 그 중 99%가 이러한 생각 때문에 큰 문제를 겪었다.

아키텍처를 생각하지 않고 코드를 작성하는 것은 목표 달성을위한 계획없이 자신의 욕망을 꿈꾸는 것처럼 쓸모가 없다. 코드를 작성하기 전에 먼저 수행 할 작업, 사용 방법, 모듈화 방법, 서비스가 서로 어떻게 동작하는지, 구조가 무엇인지, 테스트 및 디버깅 방법, 업데이트 방법들을 먼저 생각하고 이해해야한다.

3.      테스트 커버리지

테스트는 좋은 일이지만 항상 비용 효율적인건 아니며 프로젝트에 따라 다르다.

테스트가 필요한 경우:

·         최소 한 달간은 건들지 않아도 될 모듈이나 마이크로서비스를 개발하는 경우

·         오픈소스 코드를 작성하는 경우

·         핵심 코드 또는 금전적인 부분과 맞닿는 코드를 작성하는 경우

·         코드를 업데이트 하는 것과 동시에 테스트를 업데이트 할 수 있는 충분한 비용이 있는 경우

테스트가 필요하지 않는 경우:

·         스타트업인 경우

·         팀이 작고 코드가 빠르게 변하는 경우

·         출력값을 보고 간단하게 수동으로 테스트가 가능한 스크립트를 작성하는 경우

나쁜 테스트 코드와 함께 코드를 짜는 것은 테스트가 없는 코드보다 더 위험할 수 있음을 기억하라.

4.      간단하고 단순하게

복잡한 코드를 작성하지 말라. 간단하게 작성하면 버그가 줄어들고 디버깅 시간도 줄어들 수 있다. 코드는 수많은 추상화 및 기타 객체지향적인 문제 (특히 Java 개발자와 관련이 있음) 없이 딱 필요한 일만을 수행해야하며, 추후에 간단한 방법으로 코드를 업데이트하기 위해 필요한 것의 20%를 수행해야한다.

5.      주석

주석은 나쁜 코드를 보여준다. 좋은 코드는 주석 없이도 이해할 수 있어야한다. 그러면 새로운 개발자를 위해 시간을 절약하기 위해 해야 할 일은 무엇인가? — 메서드의 정의와 사용법을 설명하는 한 줄짜리 간단한 문서를 작성하라. 이는 이해를 위한 많은 시간을 절약해 줄 것이며 — 더 많은 사람들에게 메서드를 더 잘 구현할 수 있는 기회를 제공해준다. 또한 이는 글로벌 코드 문서화를 위한 좋은 시작점이 될 것이다.

6.      강한 결합 VS 느슨한 결합

항상 마이크로서비스 아키텍처를 사용하도록 노력하라. 모놀리틱 소프트웨어는 마이크로서비스 소프트웨어보다 빠르지만, 단일 서버 환경에서만 그렇다. 마이크로서비스는 여러분의 소프트웨어를 여러 서버로의 분산뿐만 아니라 가끔은 하나의 머신에서의 분산처리 (프로세스 분산을 의미한다)도 할 수 있는 가능성을 제공해준다.

7.      코드 리뷰

코드 리뷰는 좋을 수도 있고 나쁠 수도 있다.

여러분의 팀에 코드의 95%를 이해하고 있고 시간 낭비 없이 모든 업데이트 사항을 모니터링 할 수 있는 개발자가 있는 경우에만 코드 리뷰를 도입하도록 하라. 이 외의 경우에는 단지 시간 낭비가 될 수 있으며 모두가 이를 싫어하게 될 것이다. 이 부분은 많은 질문을 가져오기 때문에 이를 좀 더 깊게 살펴보자.

많은 사람들은 코드 리뷰가 새로운 사람이나 코드의 다른 부분을 작업하는 팀원을 가르치는 좋은 방법이라고 생각한다. 그러나 코드 리뷰의 주요 목표는 코드 품질을 유지하는 것이지 가르치는게 아니다. 여러분의 팀이 원자로 또는 우주 로켓 엔진 냉각 시스템을 제어하는 코드를 작성했다고 가정해보자. 그리고 여러분은 아주 어려운 로직에서 큰 실수를 저질렀고, 이를 새로운 사람에게 코드 리뷰를 위해 제공했다고 해보자. 이 경우 여러분은 사고 위험에 대해 어떻게 생각하는가? — 내 대답은 70% 이상이다.

좋은 팀은 각자가 자신의 역할을 가지고 있으며 일의 한 부분에 대해 완전한 책임감을 갖고 있는 팀이다. 만약 누가 코드의 다른 부분을 이해하고 싶으면 해당 부분을 담당하고 있는 사람에게 찾아가 질문을 하면된다. 모든걸 아는건 불가능하며 전체보다는 코드의 작은 부분을 (하지만 적어도 30%는) 완전히 이해하는것이 더 낫다.

8.      리팩토링은 작동하지 않는다

나는 일하는 동안 “나중에 리팩토링 할거니까 걱정하지마라”라는 말을 많이 들었다. 그리고 나중에 이는 큰 기술적 부채로 돌아오거나 모든 코드를 다 삭제한 후 처음부터 다시 작성하게 되었다.

따라서 처음부터 여러번 소프트웨어 다시 개발할 수 있는 자금이 있는게 아니라면 부채를 만들지 말라.

9.      피곤하거나 컨디션이 좋지 않을때 코딩하지 말라

개발자들이 피곤할 땐 평소보다 2-5배 더 많은 버그와 실수를 만들어낸다. 따라서 과업은 매우 나쁘다. 그렇기 때문에 하루의 업무시간을 약 6시간으로 고려하는 국가가 점점 더 많아지고 있으며, 일부 국가에서는 이미 실천하고있다. 정신적인 일은 육체적인 일을 다루는 것과 같지 않다.

10.  모든걸 한꺼번에 작성하자 말라 - 반복적으로 개발하라

코드를 작성하기 전에 우선 여러분의 고객과 클라이언트가 정말로 필요로 하는걸 분석하고 예측하고, 짧은 기간동안 개발할 수 있는 MVF(Most Valuable Features)를 추려내라. 품질 업데이트를 배포하기 위해 이러한 반복을 사용하도록 하고 무리한 요구사항과 품질 희생에 시간과 자원을 낭비하지말라.

11.  자동화 VS 수동

자동화는 장기적으로 100% 성공이다. 따라서 지금 당장 무언가를 자동화 할 수 있는것이 있다면 바로 하도록 하라. “5 분 밖에 걸리지 않는데, 왜 자동화 해야해?”라고 생각할 수도 있다. 하지만 한 번 계산해보자. 예를 들어 5명의 개발자로 이루어진 팀의 일상적인 작업을 들어보자. 5분 * 5명 * 21일 * 12개월 = 6,300분 = 105시간 = 13.125 일 ~ 5,250$. 직원이 40,000명일 경우엔 비용이 얼마나 커질까?

12.  나가서 취미를 갖자

일의 차별화는 정신 능력을 향상시키며 새롭고 신선한 아이디어를 제공한다. 따라서 잠시 쉬고 신선한 공기를 마시거나 친구들과 이야기를 하거나 기타를 연주하는등의 취미를 가져라.

13.  여유 시간에 새로운걸 배워라

학습을 중단하면 퇴화하기 시작한다.

 

좋은 코드 작성에 대한 아이디어와 관행에 대한 의견을 공유해준다면 매우 감사하겠다.

 

[출처]

https://mingrammer.com/translation-13-simple-rules-for-good-coding