이 글은 프로그래밍의 실무 경험과 《코드 읽기》를 대조하였다.
이것만 미리 컨트롤하고 싶은 항목을 뽑았습니다.

억제하고 싶은 거.

다른 사람이 이해하기 쉬운 코드를 쓰다

타인이 쉽게 이해할 수 있는 코드를 자주 의식한다.
이 글은 제1장에 쓴 것이 이 책의 핵심이다.
다른 장은 이 핵을 바탕으로 구체적인 사례에 포함시킨다.
타인이 쉽게 이해할 수 있는 코드는 프로그래밍에서 가장 중요하고 지속적인 의식이 필요하다.

이름에 정보를 기입하다

보기만 해도 처리할 내용을 전달할 수 있으니 주의해라.
일단 정해진 이름은 다시 고치기 어려우니 조심스럽게 이름을 바꿔야 한다.
또 사업 추진에 따라 추가 기능과 기능 변경이 발생할 수 있다.
Ex.) 킥 방법
→shoot?pass?kick?
Ex.) 축구뿐만 아니라 럭비도 하고 싶다(추가 개발)
→ 분명히 킥볼을 결정했다
이 경우 다음과 같은 대책을 강구해 주십시오
· 개발팀에 명명 규칙 전달
• config에 쓰기
· 학급과 방법에 대한 평론
잠깐만요.
시간이 있으면 팩스로 보내 주세요.

들여쓰기를 정리하여 가독성 증가

들여쓰기 규칙이 구성원에 따라 다를 경우 읽기 성능이 저하됩니다.
편집기를 활용하여 축소를 정리한 후git로 향상시킵니다.

뱀가죽과 낙타가죽

이 책에 기재되지 않은 항목.
나는 어떤 항목을 이용하느냐가 프로젝트에 달려 있다고 생각한다.(또는 모든 언어의 습관이 있다)
저는 Laravel 개발에서 낙타 껍질을 기반으로 하고 있습니다.

복잡한 처리에 주석을 달다

나는 독자들이 질문할 수 있는 일을 고려할 것이다.
처리 내용
경과
결함
자기 생각
다 쓸 필요 없어.(코드를 쓰지 않아도 금방 알 수 있는 내용)

순환과 조건 공식의 간소화

네스트가 깊을수록 읽기 성능이 떨어집니다.
제 프로젝트는 2층까지입니다.
복잡한 조건식을 무리하게 한 줄로 정리하면 가독성이 떨어진다.
(솔직히 세 개의 연산자는 읽기 어렵다)
사례 사례지만 초보자도 이를 인지하길 바란다.

감상

모든 비즈니스 파일에 대한 코드를 읽을 수 있습니다.

처음에 쓴'다른 사람이 이해하기 쉬운 코드를 쓴다'는 비즈니스 메일과 문서에서도 말할 수 있다.
원격근무가 늘어난 현재 글은'능력과 성격'을 표현하는 것으로 바뀌었다.
어렵고 오자가 많아 평가가 떨어지는 경우도 있다.
역설적으로 전달된 글만 쓰면 평가가 높아지고 비즈니스 활동도 순조롭게 진행될 것으로 보인다.
그렇기 때문에 상업의 기본이다.

행동은 이치상 당연한 것이다

지치거나 납기가 다가오면
움직이기만 하면 된다고 생각할 때가 많다.
하지만 전문가로서
나는 항상'행동은 당연하다'는 사상적 준비를 유지하는 것이 중요하다고 생각한다.