훌륭한 프로그래머가 될 수 있도록'클린코드'라는 책을 추천합니다.

십여 년의 역사를 가진 은행 시스템을 유지한 적이 있고 여러 모듈의 기업 응용 시스템을 새로 개발한 적이 있다.여러 가지 작법의 코드를 겪어 보았는데 어떤 것은 유지하기 어렵고 어떤 것은 명확하며 어떤 것은 깊은 구덩이에 묻혀 있었다. 내 팀에서 나는 항상 신인에게 코드 정결의 사상을 주입했다. 나는 항상 그들에게 기능 완성은 가장 기본적인 요구일 뿐이고 더 중요한 것은 코드를 업무 논리를 명확하게 표현할 수 있기 때문에 다른 사람들이 네가 쓴 코드를 쉽게 이해할 수 있다고 말했다.코드 구축 수준 향상을 위해 클린 코드 - 코드 깔끔함의 길은 좋은 책이 추천할 만하다.
다음은 미단 기술팀 작가의 일부 귀납에서 발췌한 것으로, 작가의 사상은 내가 책을 본 후의 느낌과 완전히 일치하여 여러분께 공유합니다.
clean code는 말 그대로 깔끔한 코드나 뚜렷하고 예쁜 코드로 대부분의 엔지니어들이 이런 코드를 쓰기를 원한다고 믿는다.
아마도 이것은 수천 명의 화제일 것이다. 모든 엔지니어들은 자신의 이해를 가지고 있다.예를 들어 나는 매일 코드를 엉망으로 쓴다고 욕을 먹는 사람으로부터 점차 배워서 성장했고 지금까지도'인간모인'의 코드를 쓸 수 있게 되었다.그동안 경험을 좀 쌓은 셈인데 여러분과 나누고 싶고 벽돌을 던져 옥을 끌어올리고 싶어요.
본고는 주로 대상을 대상으로 프로그래밍하는 clean 코드에 대해 논술하고자 하는데 과정 코드에 대한 사고방식이 비교적 다르고 본고의 토론 범주에 포함되지 않는다.

코드는 대부분 유지보수에 쓰이는 것이지 기능을 실현하는 데 쓰이는 것이 아니다

이 원칙은 대부분의 공사에 적용된다.우리의 코드는 한편으로는 기계가 실행하고 기능 수요를 완성하도록 컴파일하는 것이다.다른 한편, 주변 팀원들과 자신에게 보여주는 것으로 장기적인 유지가 필요하며 대부분의 종목은 조생석사의 단명귀가 아니다.
대부분의 경우 뚜렷하고 보기 좋은 코드를 쓰지 못하면 자신이 일시적으로 시원해질 수도 있고 후속 유지보수의 대가와 비용은 생각보다 훨씬 높을 것이다.
선명하고 보기 좋은 코드에 대한 추구 정신은 모든 기교보다 중요하다.

우수한 코드는 대부분 문서와 주석보다 자기가 묘사할 수 있는 것이다

많은 소스 코드를 뒤적거릴 때, 주석은 심지어 우리가 쓴 항목보다 적지만, 매우 편안하게 볼 수 있다는 것을 발견할 수 있다.원본 코드를 다 읽었을 때 많은 기능 디자인이 명확해졌다.세심한 고려를 통해 명명되고 명확한 프로세스 제어를 통해 코드 자체를 문서로 사용할 수 있으며, 영원히 기한이 지나지 않을 것이다.
반대로 주석은 엉망으로 쓴 코드를 더 좋아지게 할 수 없다.만약 다른 사람이 주석에만 의존해서 당신의 코드를 읽을 수 있을 때, 당신은 반드시 코드에 무슨 문제가 생겼는지 반성해야 한다. (물론, 여기는 모두가 주석을 쓰지 말라고 한 것이 아니다.)
주석을 쓰기에 비교적 적합한 두 가지 장면:public 인터페이스는 다른 사람에게 당신의 기능의 의미를 명확하게 발표하고 입력과 출력을 입력하며 실현에 관심을 기울일 필요가 없다.기능은 다른 뜻이 있기 쉽거나 비교적 깊은 전문 지식과 관련이 있을 때.예를 들어 클라이언트를 쓰면, 각종 config 매개 변수의 의미 등이 있습니다.

코드 깔끔함의 흔한 기교

1. 단일 직책
이것은 코드를 정결하게 하는 가장 중요하고 가장 기본적인 원칙이다.간단하게 말하면 크게는 하나의 모듈, 하나의 패키지, 작게는 하나의class, 하나의method, 더 나아가서는 하나의 속성까지 모두 명확한 직책을 맡아야 한다.정의할 것은 한 마디로 직책을 명확하게 묘사하지 못하면 뜯어버려라.
우리가 평소에 코드를 쓸 때 가장 범하기 쉬운 오류는 한 방법이 여러 가지 일을 하거나 여러 가지 기능을 탑재하는 것이다.
먼저 방법에 대한 문제를 이야기해 봅시다.개인은 방법을 세밀하게 뜯는 것이 복용의 기초라고 매우 주장한다.만약 방법이 두 가지 일을 했다면, 그 중 한 가지 기능의 다른 업무가 차이가 나면 다시 사용하기 어려울 가능성이 매우 높다.그리고 의미도 명확하지 않다.get () 방법에서 데이터를 수정하는 것을 자주 보는데, 이 방법으로 당신의 인정을 어떻게 견딜 수 있겠습니까?만약 들어가서 실현을 보지 않는다면 프로그램을 버그에 빠뜨리고 테스트를 번거롭게 할 수도 있다.
다시 이런 문제를 이야기해 보자.우리는 자주'냄새나고 길다'는 서비스/biz층의 코드를 볼 수 있다. 그 안에는 몇 십 가지 방법이 있는데 무엇을 하든지 다 있다. 즉, 추가, 삭제, 수정이 있고 업무 논리의 집합도 있다.매번 방법을 찾을 때마다 힘이 든다.한 분야나 한 차원에 속하지 않는 기능은 함께 두지 마라.
우리 팀들이 코드 리뷰에서 가장 자주 비판받는 문제는 어떤 종류에 귀속되어야 하는가이다.
2. 명확한 명칭
상투적인 이야기는 여기서 전개하지 않겠지만, 반드시 마크를 해야 한다.때때로, 나는 코드를 쓰는 것보다 이름을 짓는 방법을 생각하는 시간이 더 길다.원인은 역시 그 논리이다.'temp','a','b'와 같은 변수를 쓸 때마다 뒤에 있는 모든 유지보수 코드를 사용하는 사람들은 몇 배의 정력을 들여야만 정리할 수 있다.
그리고 이것도 코드 자체 설명의 가장 중요한 기초이다.
3. 과도한 매개변수 방지
한 방법의 매개 변수 길이가 4개를 넘으면 경계해야 한다.한편, 이 함수들의 의미를 정확히 기억할 수 있는 사람은 없다.다른 한편, 코드의 가독성은 매우 떨어진다.마지막으로 만약에 파라미터가 매우 많다면 반드시 많은 파라미터가 있다는 것을 의미한다. 많은 장면에서 쓸모가 없기 때문에 우리는 기본값을 구성하여 전달할 수 밖에 없다.
이 문제를 해결하는 방법은 매우 간단하다. 일반적인 상황에서 우리는paramObject를 구성할 것이다.하나의 struct나class로 데이터를 불러옵니다. 일반적으로 이런 대상은value object이며, 변할 수 없는 대상입니다.이렇게 하면 코드의 복용성과 가독성을 크게 높일 수 있다.필요할 때, 상부 코드의 개발 비용을 간소화하기 위해 적합한build 방법을 제공합니다.
4. 너무 긴 방법 및 클래스
한 종류나 방법이 너무 길면 독자는 항상 붕괴된다.간단하게 방법, 유형, 직책을 세밀하게 따지면 왕왕 즉각적인 효과가 있을 수 있다.클래스를 예로 들면 분할의 차원이 매우 많은데 흔히 볼 수 있는 것은 가로/세로다.예를 들어 만약에 하나의 서비스가 하나의 라이브러리 대상과 관련된 모든 논리를 처리한다면 가로 분할은 업무에 따라 구축/갱신/수정/통지 등 논리를 서로 다른 클래스로 분리하는 것이다.한편, 세로 분할은 데이터베이스 조작/MQ 조작/Cache 조작/대상 검사 등을 서로 다른 대상에서 분리하여 주류 거리를 가능한 한 간단하게 제어할 수 있도록 하고 같은 종류로 하여금 가능한 한 같은 차원의 물건을 표현하도록 하는 것을 말한다.
5. 같은 길이의 코드 세그먼트로 하여금 같은 입도의 논리를 나타낸다
여기서 표현하고자 하는 것은private 방법을 최대한 많이 추출하여 코드가 스스로 설명하는 능력을 가지도록 하는 것이다.간단한 예를 들다

 public void doSomeThing(Map params1,Map params2){
   Do1 do1 = getDo1(params1);
   Do2 do2 = new Do2();
   do2.setA(params2.get("a"));
   do2.setB(params2.get("b"));
   do2.setC(params2.get("c"));
   mergeDO(do1,do2);
   }
   private void getDo1(Map params1);
   private void mergeDo(do1,do2){...};

이와 유사한 코드는 업무 코드 곳곳에서 볼 수 있다.Do1을 얻는 것은 하나의 방법이고,merge는 하나의 방법이지만,do2를 얻는 코드는 주류에 쓰여 있다.이런 코드는 절차가 길수록 읽기가 힘들다.많은 사람들이 코드를 읽는 논리는'광도 우선'이다.먼저 주요 절차를 이해한 다음에 세부 사항을 보아라.이런 코드와 유사하게 Do2를 구성하는 코드를 private 방법으로 추출할 수 있다면 훨씬 편할 것이다.
위에서 열거한 것은 가장 기본적으로 요구되는 탄탄한 기술이다.
자세한 내용은 다음을 클릭하십시오.http://tech.meituan.com/clean-code.html
본문은 전재한 것이니 원작을 존중해 주십시오.오리지널 2017-01-19 왕예미단 리뷰 기술팀 미단 리뷰 기술팀 연락처:[email protected]