이점 (!)더러운 코드 수

최초 발표my blog site.
나에게 있어서 첫 번째이자 가장 중요한 장점은 내가 그것을 정의할 필요가 없다는 것이다.😊! 거의 모든 프로그램을 작성한 사람들은 더러운 코드가 무엇인지 안다.모두가 이것이 또 다른 이야기라는 것을 의식하고 있는가.
인터넷은 원칙, 규칙, 기술, 최선의 실천과 코드를 작성하는 조작 절차로 가득 차 있다.현재, 거의 모든 프로그래머들은 매일 각자의 프로그래밍 언어로 코드를 작성할 때 따라야 할 기술에 대해 이야기하고 있다.코드를 작성할 때 이러한 기술을 사용하려면 우리는 많은 규칙과 최선의 실천을 따라야 한다.결국, 그것은 코드를 자유롭게 작성하는 데 많은 제한을 가져왔고, 우리의 속도를 늦추었고, 교부하는 시간표를 실현할 수 없게 하였으며, 그 어떤 진정한 프로그래머도 상상할 수 있는 것보다 훨씬 고통스러웠다.
다음은 다음과 같은 방법의 부작용에 대한 고급 요약입니다.

사물을 명명하는 데 많은 시간이 필요하다

모듈 간 불필요한 분리 필요

우리로 하여금 많은 추가 코드를 작성하게 하였는데, 이러한 코드는 제품 구축에 영원히 나타나지 않을 것이다

의견 추가 불가

고의적인 실수를 먼저 범하고 해결하도록 강요한다
부작용의 더 많은 세부 사항을 깊이 이해하고 얼마나 고통스러운지 봅시다.

사물을 명명하다

인터넷상에서 많은 사람들이 변수, 함수, 클래스, 모듈과 그에 필요한 생명명의 의미 있는 명칭에 대해 이야기하고 있다.그런데 왜 이렇게 필요하지?변수d가 아닌 변수numberOfDaysInTrailPeriod를 명명하면 어떻게 됩니까?

int d = 10;
int numberOfDaysInTrailPeriod = 10;

컴파일러는 어떤 오류도 생성하지 않고 실행할 때도 파괴하지 않습니다.
유사히

int rdsTrail(){//code}
int remainingDaysInTrailPeriod(){//code}

자, 사물의 적합하고 의미 있는 명칭을 생각할 시간을 낭비하지 말자.
만약 우리 자신이나 다른 사람이 이후에 이 코드를 처리하려고 한다면, 우리는 int d 과 int rdsTrail() 이 무엇을 대표하는지 디버깅하고 이해할 것이다.

모듈 결합 해제

이것은 서로 상호작용하는 모듈을 많이 포함하는 대형 프로젝트를 작성할 때 일부 기술에서 가장 많이 토론되는 또 다른 주제이다.모듈을 위한 인터페이스를 작성할 때도 이런 상황이 발생한다.나는 무엇이 그들로 하여금 실현을 이 인터페이스 뒤에 숨기려고 하는지 모르겠다.그들은 어떤 추상이라고 부른다.
아무도 이런 실현을 방해하지 않을 것이다.여기서 우리는 새로운 기능을 실현하고 버그를 복구하는 것에 싫증이 났다.우리는 왜 다른 사람의 실현을 바꾸어야 합니까?
만약 모듈 간의 상호작용이 이렇게 강렬하고 빈번하다면, 우리는 왜 모듈 간에 좋은 분리를 유지해야 합니까?우리는 이미 우리의 프로젝트를 위해 모듈을 작성했다. 만약 우리가 어떤 모듈을 삭제한다면, 우리의 프로젝트는 모두 쓸모가 없다.그렇다면 왜 우리가 각각의 모듈을 독립적으로 사용할 것이라고 생각하는가.
만약 장래에 우리가 어떤 모듈을 교체해야 한다면, 새로운 모듈에 따라 상응하는 코드를 수정하거나, 다른 프로젝트에서 그것을 다시 사용해야 한다면, 그것을 다시 쓰기만 하면 된다.

단원 테스트

프로그래머에 대한 신화가 하나 더 있다. 바로 점점 더 많은 정력과 시간을 들여 1분을 넘지 않는 간단한 코드를 작성하는 것이다.단원 테스트의 주요 목적은 우리의 코드가 예상대로 작동하는지 확인하는 것이다. 그러나 QA와 테스트 인원이 우리 옆에 앉아 있다면 왜 우리는 스스로 코드를 테스트해야 합니까?
단원 테스트는 우리가 크고 좋은fat 함수를 더 작은 블록으로 분할하도록 불필요하게 강요한다.함수의 줄 수를 제한하는 것도 우리가 그것들을 작성하는 속도를 제한할 수 있다.그리고 왜 우리는 항상 단일 책임과 위에서 아래로의 함수 호출 흐름의 규칙을 따릅니까?이것은 당연히 우리를 느리게 할 것이다.
만약 누군가가 약간의 변경을 하거나 더 많은 코드를 추가한 후에 코드의 조작성을 테스트하고 싶다면, 그/그녀는 프로그램을 테스트 인원에게 맡기기만 하면 된다.

가독성

코드를 작성하는 방식은 컴퓨터가 이해할 수 있을 뿐만 아니라 인류가 이해할 수 있도록 해야 한다고 사람들은 말한다.마찬가지로, 만약 우리가 이 규칙을 따르려고 한다면, 우리는 코드를 작성하는 데 시간을 낭비해야 하고, 다른 프로그래머들은 읽기만 하면 이 코드들을 쉽게 이해할 수 있다.그러나 간단하게 말하자면, 만약 우리가 이렇게 아름답고 강력한 IDE를 가지고 있다면, 왜 프로그래머는 코드를 직접 실행하고 출력을 관찰하는 것이 아니라 코드를 읽어야 하는가.
그들이 여기서 제기한 또 다른 제한은 코드에 더 많은 주석이 없다는 것이다.모든 IDE는 코드에 주석을 추가할 수 있습니다.코드를 읽어서 이해하려 하기보다는 설명을 필요로 하는 곳에 두는 것이 낫다.위의 예에서, 우리는 아래의 주석을 추가할 수 있다

int d = 10; //number of days in trail period

이것은 틀린 것이 아닙니다. 컴파일러가 오류를 던지지 않고 컴파일된 구축에도 이 주석이 포함되지 않습니다.
만약 우리가 코드를 읽을 수 있는 이해성을 걱정한다면, 디버깅, 컨트롤러 로그를 읽거나 주석만 읽을 수 있도록 하세요.

TDD

이제 나는 이 단어를 쓸 수 있어, 악몽!TDD는 모든 프로그래머에게 악몽이다. 특히 그것을 진정으로 따르는 프로그래머에게는 악몽이다.잘못을 저지르고 고치다.다시 한 번 해, 바로잡아...이게 얼마나 바보야?나를 믿어라. 이 흐름은 실제 프로그램보다 더 큰 병행 프로그램을 만들었고, 두 배가 넘는 시간이 필요하다.그것의 목적은 우리로 하여금 상술한 모든 규칙을 준수하도록 강요하는 것이다.
비록 아주 작은 수정이라도 우리는 상응하는 테스트를 먼저 수정하거나 작은 코드를 추가해야 한다. 우리는 먼저 테스트를 작성해야 한다.즉, 우리는 먼저 테스트를 고려한 다음에 실현을 고려해야 한다.이거 시간 많이 걸리지 않아요?
테스트가 우리의 개발을 구동시키기보다, 왜 우리는 직접 앞으로 나아갈 수 없고, 시작할 때 어떠한 잘못도 범하지 않는가.

마지막

내가 당신들과 논쟁하고 싶은 것은 다른 사람의 말을 믿지 말고 우리 코드의 다음과 같은 부작용을 소홀히 하는 것이다.

읽기 쉽고 이해하기 쉬움

교체가 쉬운 모듈, algos

디버깅 및 오류 수정 용이

수정 및 재사용 용이

새로운 기능 추가 용이성
우리는 장래에 필요할 때 이런 것들을 생각할 수 있다.그러니까 진정하고 코드 하나 써. 이건 그냥 일이야!

내 이 박문이 무슨 뜻인지 알아...!!!
(사진제공: [email protected]
만약 당신이 인코딩한 어느 한 쪽, 더러운 한 쪽, 혹은 다른 한 쪽에 있다면, 평론을 남겨 주시고, 🕔蕝를 주십시오!
참고 문헌: 밥 아저씨의 깨끗한 코드