오다

 
일상적인 인코딩에서 빠질 수 없는 것은 코드의 이름을 짓는 것이다. 코드에서 이름을 짓는 중요성은 프로젝트 초기에 크게 느끼지 못할 것이다. 왜냐하면 이름을 만들면서 이름을 짓는 것이기 때문에 코드가 매일 보면 자연히 기억이 깊어진다.그러나 후기 상륙 후 반년 후 1년 후에 다시 돌아볼 때 내가 닦는다. 이 변수는 무슨 뜻입니까?이 방법은 틀렸어. 사용자 상태를 업데이트하는 거 아니야?다음은 각종 비난이다. 누가 쓴 코드가 이렇게 엉망이야. 제출 일지를 뒤져봐. 어?내가 쓴 것을 빨리 조용히 고쳐라.
 
자주 우리는 다른 사람의 코드가 썩었다고 비난한다. 그러면 당신은 당신이 생각하는 썩은 코드를 어떻게 정의합니까? 그것들은 어디에 썩었습니까?
 

코드가 도대체 어디에서 썩었는지

 
이 문제의 구체적인 점은 우리가 업무 논리를 정리하지 못한 상황에서 다른 사람의 코드를 직접 보는 것과 같다. 코드를 통해 업무 논리를 반추하는 것과 같다. 다른 사람의 이름, 프로그래밍 사고는 자신의 습관과 일치하지 않기 때문에 그의 논리와 습관을 소화하고 이해하는 데 시간이 필요하다. 그리고 코드가 엉망진창이다. if else 그리고 각종 이상한 이름, 마귀 숫자, OMG가 섞여 있다.너무 시원하게 하지 마.이상과 종합해 보면 아마도 모두가 생각하는 엉터리 코드일 것이다.
 
요약:
 

자신의 원인, 업무를 완전히 이해하지 못하고 코드를 직접 본다

여기에는 업무 논리와 관련된 실체나 데이터베이스 표를 먼저 파악하고 절차도나 시차도 보조 이해 코드를 간단하게 그려내는 것이 좋다. 전개하는 말이 많고 나중에 따로 한 편 쓸 기회가 있으면 한 편 쓰는 것이 좋다.
 

코드 스타일이 규범에 맞지 않음

각종 인터페이스, 방법, 변수의 명칭이 규범에 맞지 않고 코드 형식의 조판이 혼란스러우며 지나치게 긴 방법, 주석이 없거나 상세하지 않다는 등에 나타난다. 이 가장 구덩이를 주석하는 것은 주석이 없는 것이 아니라 잘못된 주석이다.자기 뇌보정 화면.
 

코드 논리 혼란

코드 논리가 명확하지 않고 불필요한 코드, 폐기 방법, 심층적인 끼워넣기 등에 나타난다. 어떻게 최적화하는지도 단독으로 몇 편 쓸 가치가 있다.
 
이름이 그 안에 자리를 잡고 있는 것을 볼 수 있다. 코드의 이름을 어떻게 짓고 아래를 내려다보는지.
 

네, 여기 보세요.

 
먼저 결론을 내리자면 좋은 명명에서 가장 중요한 점은 명지의, 명지의, 명지의, 중요한 내용을 세 번 반복하고 바탕색을 더하는 것이다.
 

자라는 것을 두려워하지 마라

나는 업무 중에 많은 사람들이 명명 습관을 가지고 있다. 나는 반명명 방식이라고 부른다. 예를 들어 하나의 업무 수요의 실체류를 정의한다. 정상적으로 명명지의의 명명은 이렇다BusinessRequirement. 그러나 그들은 이렇게 길다고 생각한다. 그들은 이렇게 할 것이다.BusRequi, (각 성의 절반)BusinessReq(절반 절약)BusinessXq(영어 반, 병음 반, 서양식)
이런 명명은 완전히 읽을 수 없을 뿐만 아니라 다른 뜻도 생기기 쉽다.그러니 긴 것을 두려워하지 마라. 사람과 유도사전을 읽을 수 있는 것이 전제다.
 
스프링북의 이름을 보십시오SpringApplicationJsonEnvironmentPostProcessor
길어요?읽을 수 있을 거예요. 그렇죠?
 
그러나 한 가지는 간소화할 수 있다. 바로 업계에서 모두가 공인하는 용어의 약칭이다. 예를 들어 전체 IP 도구 클래스를 생각하면 이렇게 명명할 수 있다IpUtil. 이렇게 만들 필요가 없다InternetProtocolUtil. 왜냐하면 Ip라는 단어는 업계에서 모두가 알고 있기 때문에 간략하게 쓸 수 있기 때문이다.
 

정확하다

정확히 명명은 현재의 업무 상황에 부합되어야 한다. 예를 들어 내가 예전에 한 시험 항목 중 하나의 문제 실체가 있는데 동료가 사용한 명명은Problem이다. 분명히 여기에 두는 것은 적합하지 않다. 마지막에 바로잡는다Question.정확하게 하려면, 역시 영어 기초의 기초를 비교적 시험해야 한다.
 

구체적이다

구체적으로는 변수나 클래스가 가리키는 코드의 의미를 정확하게 표현할 수 있다. 예를 들어 우리는 소프트웨어 버전 번호를 대표하는 그룹을 정의했는데 이렇게 정의할 수 있다.
 

int[] array = new int[] {1,2,3,4,5};

 
수조는 알아볼 수 있지만 이 줄의 코드만 보면 뭘 하는지 알 수 없다. 구체적인 코드 논리에 상하문 코드를 결합하면 수조에 정의된 구체적인 것이 무엇인지를 유도할 수 있다. 그러나 코드를 읽는 난이도가 높아지면 좋은 것은 당연히 아래와 같다.
 

int[] versionNumberArray = new int[] {1,2,3,4,5};

 
구체적인 의미를 명확히 말하고 어떤 수조를 나타내는 것이지 개수조의 개념만을 추상적으로 표현하는 것이 아니다.
 

덧붙이다

나는 코드부터 데이터베이스에 이르기까지 전체적인 명칭이 모두 병음 간략한 형식이라는 것을 본 적이 있다. 솔직히 병음 간략한 형식은 업무에 익숙하지 않은 사람에게 식별하기 어렵고 시간이 지나면 완전히 어리석고 완전히 추측에 의존해야 한다.
 
위의 업무 수요를 보면 병음을 정돈Ywxq하면 병음 조합은 여러 가지 해석이 가능하다.프로젝트가 지속적으로 유지될 수 있는 관건은 그들이 상세한 사전 설명 문서를 가지고 있다는 것이다. 사실상 전편에서 말한 것이다.  
그러나 여전히 고통스럽다는 것을 알 수 있다. 개별 영역 내의 전문 어휘가 아니면 영어를 표현하기 어려우므로 병음으로 해결할 수 있고 다른 상황은 가능한 한 영어로 명명할 수 있다.
 

총결산

 
좋은 명칭은 이름만 보고 뜻을 알 수 있도록 하는 것이다. 구체적으로 다음과 같은 몇 가지를 따른다.
 
1. 긴 것을 두려워하지 마라. 전문 용어 업계에 약칭이 있다. 약칭으로 할 수 있다.
2. 단어의 사용이 정확하다 3. 표현이 구체적이다
4. 가능한 영어 사용
5. 상기에서 언급하지 않은 부분은 회사가 규범이 있고 우선적으로 회사의 규범에 부합된다.
​
입사하기 전에 많은 사람들이 영문 기초가 인코딩에 도대체 영향을 미쳤는지, 얼마나 큰지 궁금해 한다. 여기서 알 수 있듯이 영향을 미친다. 적어도 명명할 때 장애가 있기 때문에 사전이나code if 같은 도구를 빌려야 한다.
 
그리고 앞으로 갈수록 영어의 중요성이 더욱 뚜렷해진다. 예를 들어 너는 영어 자료, 문헌 등을 직접 읽을 수 있다.
 

최후

옛느낌 을 다 썼는데 이 단어를 잘 못 쓰는데 어떻게 단어가 가난한지 우선 이렇게 하자.