깔끔한 코드를 작성하는 방법
출처: Dev.to 깔끔한 코드를 작성하는 것은 시를 쓰는 것과 같습니다. 간결하고 이해하기 쉽고 변경 가능해야 하는 시입니다. 클린 코드는 확장 가능한 조직을 의미합니다. 즉, 변경을 해도 혼란이 발생하지 않습니다. 이러한 코드를 작성하는 능력은 숙련된 개발자의 주요 자질 중 하나입니다. 몇몇 분들이 『클린코드』라는 책을 읽어보라고 추천해주셨고, 마침내 용기를 내어 읽었습니다. 이 책은 표지가 주변의 과대 광고에 완전히 부응하는 책 중 하나라는 것이 밝혀졌습니다. 책에 담긴 권고사항은 명확하고 구체적이며 실용적이며 심지어 유머까지 담겨 있습니다. 오늘은 이 책의 주요 내용을 여러분과 공유하고 싶습니다.
1. 코드는 작동할 뿐만 아니라 읽기 쉬워야 합니다.
소프트웨어 비용의 대부분은 장기 지원과 관련되어 있습니다. 따라서 작성하는 코드는 의도를 명확하게 표현해야 합니다. 팀에 합류하는 새로운 개발자가 코드에서 정확히 무슨 일이 일어나고 있고 그 이유가 무엇인지 쉽게 이해할 수 있어야 합니다. 작성자가 작성한 코드를 이해하기 쉽게 만들수록 다른 개발자가 코드를 이해하는 데 걸리는 시간이 줄어듭니다. 이를 통해 결함과 유지 관리 비용이 줄어듭니다. 이것을 달성하는 방법은 무엇입니까? 좋은 이름 지정 + 단일 책임이 있는 클래스 및 함수 + 테스트 작성.2. 나중에는 절대 안 된다는 뜻
솔직하게 말하자면, 우리 모두는 때때로 나중에 다시 돌아와서 코드를 정리하겠다고 약속하지만 결국 잊어버리게 됩니다. 더 이상 필요하지 않은 쓸모없는 코드 조각을 남겨두지 마십시오. 이는 다른 개발자를 혼란스럽게 하며 가치가 없습니다. 따라서 기능을 변경할 때는 항상 이전 코드를 제거하십시오. 어딘가에서 문제가 발생하더라도 테스트에서는 즉시 이를 표시합니다. 이것을 달성하는 방법은 무엇입니까? 특히 대규모 아키텍처에서는 코드를 삭제하는 것이 두려울 수 있습니다. 따라서 여기서는 테스트가 핵심입니다. 이를 통해 자신 있게 코드를 제거할 수 있습니다.3. 기능은 작아야 한다
함수 작성의 첫 번째 규칙은 최대 20줄 정도로 작아야 한다는 것입니다 . 기능이 작을수록 하나의 작업에 더 집중할수록 해당 기능에 대한 좋은 이름을 찾는 것이 더 쉽습니다. 함수 인수의 경우 이상적인 숫자는 0입니다. 다음은 1, 2이지만 인수는 3개 이하로 유지해야 합니다. 이를 달성하는 방법은 무엇입니까? 기능은 단일 책임 및 개방형/폐쇄형 원칙에 따라 작성되어야 합니다.4. 코드 중복이 나쁘다
복제는 잘 구성된 시스템의 적입니다. 이는 추가 작업, 추가 위험 및 추가 불필요한 복잡성입니다. 어떻게 해야 할까요? 코드가 DRY 원칙에 따라 격리되고 모듈식으로 작성되었는지 확인하세요.5. 유일한 좋은 댓글은 글을 쓰지 않는 방법을 찾은 댓글입니다.
“적절한 곳에 좋은 의견을 남기는 것보다 더 유용한 것은 없습니다. 하지만 아무리 최선의 시나리오라도 댓글은 필요악입니다.” 주석은 우리의 생각을 코드로 표현하지 못하는 것을 보완하기 위한 것입니다. 즉, 이것은 처음에는 패배를 인정한 것입니다. 예, 코드를 사용하여 의도를 항상 명확하게 표시할 수는 없기 때문에 이를 사용해야 합니다. 하지만 이것이 축하할 이유는 아닙니다. 문제는 댓글이 거짓말을 하는 경우가 많다는 것입니다. 항상 그런 것은 아니고 고의로 그런 것은 아니지만 너무 자주 발생합니다. 주석이 오래되고 설명하는 코드에서 멀어질수록 부정확할 가능성이 높아집니다. 그 이유는 간단합니다. 프로그래머는 코드와 모든 주석을 모두 제대로 관리할 수 없기 때문입니다. 따라서 주석은 참조하는 코드에서 분리되어 정밀도가 낮은 고아 주석이 되는 경우가 많습니다. 어떻게 해야 할까요? 설명적인 이름 지정 방법을 사용해야 합니다. 변수 이름을 읽으면 그것이 무엇인지 즉시 이해해야 합니다. 다른 개발자가 어떤 기능이 가장 중요한지 이해할 수 있도록 테스트도 필요합니다.6. 객체는 행동을 나타내지만 데이터는 나타내지 않습니다.
모듈은 자신이 조작하는 개체의 내부에 대해 알 수 없습니다. 객체는 데이터를 숨기고 작업을 드러냅니다. 이는 객체가 접근자 메서드를 통해 내부 구조를 노출해서는 안 된다는 것을 의미합니다. 모든 사람이 당신의 알몸을 볼 필요는 없습니다. 어떻게 해야 할까요? 변수의 범위는 필요 이상으로 노출되지 않도록 가능한 한 지역적이어야 합니다.
7. 테스트
테스트 코드는 프로덕션에 들어가는 것만큼 중요합니다. 그러므로 프로젝트가 진행됨에 따라 변화하고 성장해야 합니다. 테스트는 코드를 유연하고 유지 관리 및 재사용 가능하게 유지합니다. 그것들이 없으면 어떤 변경이라도 버그가 발생할 수 있습니다. 테스트를 사용하면 문제가 발생할 염려 없이 코드를 정리할 수 있습니다. 따라서 테스트의 순수성을 유지하는 것이 매우 중요합니다. 테스트의 청결성은 가독성을 보장합니다. 테스트는 코드 작성자의 의도를 간단한 언어로 다른 개발자에게 설명할 수 있는 기회입니다. 따라서 우리는 각 테스트 함수에서 하나의 개념만 테스트합니다. 이렇게 하면 테스트를 설명적이고 읽기 쉽게 만들 수 있으며, 실패할 경우 원인을 추적하기가 더 쉽습니다. 이것을 달성하는 방법은 무엇입니까? Clean FIRST 테스트 의 원칙을 따라야 합니다 . 테스트는 다음과 같아야 합니다.- 빠른. 테스트는 빠르게 실행되어야 합니다. 테스트 실행을 너무 오래 기다려야 하면 테스트를 더 자주 실행할 가능성이 줄어듭니다.
- 독립/고립(Independent). 테스트는 가능한 한 서로 격리되고 독립적이어야 합니다.
- 반복 가능. 테스트는 개발, 준비, 프로덕션 등 모든 환경에서 반복 가능해야 합니다.
- 자체 검증 중입니다. 테스트 결과는 부울 값이어야 합니다. 테스트는 통과하거나 실패해야 합니다.
- 철저한. 우리는 테스트를 통해 모든 엣지 케이스, 모든 보안 문제, 모든 사용 사례(사용 사례) 및 행복한 경로(코드에 가장 유리한 시나리오)를 다루기 위해 노력해야 합니다.
8. 오류 및 예외 처리
발생하는 각 예외는 오류의 원인과 위치를 파악하는 데 충분한 컨텍스트를 제공해야 합니다. 일반적으로 예외에 대한 스택 추적이 있지만 스택 추적은 실패한 작업의 목적을 알려주지 않습니다. 가능하다면 코드에 null을 전달하지 마세요. 메서드에서 null을 반환하고 싶은 유혹을 받는다면 대신 예외를 발생시키는 것을 고려해 보세요. 오류 처리를 기본 논리와 독립적으로 볼 수 있는 별도의 작업으로 만듭니다. 이것을 달성하는 방법은 무엇입니까? 유익한 오류 메시지를 작성하고 예외와 함께 전달하십시오. 실패한 작업과 오류 유형을 지정합니다.9. 수업
수업은 작아야합니다. 하지만 계산해야 할 것은 코드 줄이 아니라 책임입니다. 클래스 이름은 해당 클래스가 담당하는 내용을 설명하는 데 핵심입니다. 우리 시스템은 소수의 거대한 클래스가 아닌 다수의 소규모 클래스로 구성되어야 합니다. 각각의 소규모 클래스는 단일 책임을 캡슐화해야 합니다. 각 클래스가 존재하는 이유는 단 하나여야 하며, 각 클래스는 시스템의 원하는 동작을 달성하기 위해 여러 다른 클래스와 "협력"해야 합니다. 공용 변수를 만드는 데에는 타당한 이유가 거의 없습니다. 캡슐화를 약화시키는 것은 항상 최후의 수단입니다. 또한 인스턴스 변수가 적어야 합니다. 좋은 소프트웨어 설계를 통해 대규모 투자나 재작업 없이도 변경할 수 있습니다. 변수 범위를 좁히면 이 작업이 더 쉬워집니다. 이것을 달성하는 방법은 무엇입니까? 관심사의 분리는 가장 오래되고 중요한 디자인 기술 중 하나입니다. 수업은 확장을 위해 열려야 하지만 수정을 위해 닫혀 있어야 합니다. 이상적인 시스템에서는 기존 코드를 변경하는 대신 시스템을 확장하여 새로운 기능을 활성화합니다.10. 포맷
각각의 빈 줄은 새로운 별도의 개념이 시작되었음을 식별하는 데 도움이 되는 시각적 신호입니다. 지역 변수는 함수 상단에 나타나야 합니다. 인스턴스 변수는 클래스 상단에 선언해야 합니다. 긴 줄보다는 짧은 줄이 더 좋습니다. 일반적으로 제한은 100~120자이므로 더 이상 입력하면 안 됩니다. 이것을 달성하는 방법은 무엇입니까? 대부분의 매개변수는 CI 또는 텍스트 편집기의 linter에 전달될 수 있습니다. 이러한 도구를 사용하여 코드를 최대한 깔끔하게 만드세요.프로그램 개발 원칙
다음 기술을 사용하면 코드가 항상 깔끔해집니다. 변수 이름 지정. 적절한 이름(좋은 이름 지정)을 선택하는 것은 코드를 읽기 쉽고 유지 관리하기 쉽게 만드는 데 중요합니다. “첫째 아이의 이름을 정하는 것처럼 책임감 있게 변수 이름을 선택해야 합니다.” 좋은 이름을 선택하는 것은 종종 개발자에게 어려운 일입니다. 이를 위해서는 훌륭한 설명 기술과 공유된 문화적 배경이 필요합니다. 클린 코드는 전혀 다른 개발자가 읽고 개선하는 코드입니다. 변수, 함수 또는 클래스의 이름은 이 엔터티가 존재하는 이유, 엔터티가 무엇이며 어떻게 사용되는지와 같은 모든 기본 질문에 답해야 합니다. 이름에 설명이 필요한 경우 해당 이름이 설명하는 내용의 본질을 충분히 드러내지 않는다는 의미입니다. 긴 이름이 짧은 이름보다 더 중요하며, 검색 가능한 이름은 상수보다 낫습니다. 단일 문자 이름은 짧은 메서드 내에서 지역 변수로만 사용할 수 있습니다. 이름 길이는 범위와 일치해야 합니다. 메소드 이름은 동사 또는 동사구여야 합니다. 클래스 이름은 동사가 아니어야 합니다. 종속성을 최소한으로 유지해야 합니다. 당신이 통제할 수 없는 것에 의지하는 것보다 당신이 통제하는 것에 의존하는 것이 더 낫다. 그렇지 않으면 이런 것들이 당신을 통제할 것입니다. 정확성. 모든 코드 조각은 독자가 찾을 것으로 예상되는 위치에 있어야 합니다. 코드베이스를 통한 탐색은 직관적이어야 하며 개발자의 의도가 명확해야 합니다. 청소. 코드베이스에 쓸모없는 코드를 남겨두지 마십시오(오래되어 더 이상 "만약의 경우"에 사용되거나 생성되지 않음). 중복을 줄이고 초기에 간단한 추상화를 만듭니다. 표준화. 코드를 작성할 때 저장소에 설정된 스타일과 방식을 따라야 합니다. 자기 훈련. 사용된 기술이 발전하고 새로운 기술이 등장함에 따라 개발자는 종종 기존 코드의 내용을 변경하고 개선하려는 욕구를 갖게 됩니다. 너무 빨리 과대광고에 굴복하지 마십시오. 특정 목적을 위해서만 새로운 스택을 철저하게 연구하십시오. 코드베이스를 깔끔하게 유지하는 것은 현재와 미래의 동료에게 예의를 갖추는 것 이상입니다. 이는 프로그램의 장기적인 생존을 위해 필수적입니다. 코드가 깔끔할수록 개발자는 더 행복해지며 제품은 더 좋아지고 수명도 길어집니다.대기 시간이 짧은 시스템에서 Java가 C++보다 나은 이유
출처: StackOverflow 개발자로서 우리 모두는 작업을 수행하는 방법에는 두 가지가 있다는 것을 알고 있습니다. 수동으로, 느리고 성가시게 수행하거나, 자동으로, 어렵고 빠르게 수행하는 것입니다. 나는 인공 지능을 사용하여 이 기사를 작성할 수 있습니다. 이렇게 하면 많은 시간을 절약할 수 있습니다. AI는 초당 수천 개의 기사를 생성할 수 있지만 편집자는 아마도 첫 번째 기사를 생성하는 데 2년이 걸린다는 사실을 알고 기뻐하지 않을 것입니다.
대기 시간이 짧은 소프트웨어 시스템을 개발할 때도 비슷한 상황이 발생합니다. 일반적인 통념은 C++ 이외의 다른 것을 사용하는 것은 미친 짓이라는 것입니다. 다른 모든 것에는 대기 시간이 너무 길기 때문입니다. 그러나 저는 이와 반대되고 반직관적이며 거의 이단적인 개념을 여러분에게 확신시키기 위해 왔습니다. 즉, 소프트웨어 시스템에서 짧은 대기 시간을 달성하는 데 있어서는 Java가 더 좋습니다. 이 기사에서는 짧은 대기 시간을 중시하는 소프트웨어, 즉 거래 시스템의 구체적인 예를 들어보고 싶습니다. 그러나 여기에 제시된 주장은 낮은 대기 시간이 필요하거나 원하는 거의 모든 상황에 적용될 수 있습니다. 단지 내가 경험한 개발 분야에 관해 논의하는 것이 더 쉬울 뿐입니다. 그리고 사실 대기 시간은 측정하기 어렵습니다. 그것은 모두 낮은 대기 시간이 의미하는 바에 달려 있습니다. 이제 이것을 알아 봅시다.
지혜를 얻었습니다
C++는 하드웨어에 훨씬 더 가깝기 때문에 대부분의 개발자는 이 언어로 코딩하면 속도상의 이점이 있다고 말할 것입니다. 밀리초가 실행 가능한 소프트웨어와 레거시 디스크 공간 낭비 사이의 차이를 만들 수 있는 고속 거래와 같은 대기 시간이 짧은 상황에서는 C++가 최적의 표준으로 간주됩니다. 적어도 예전에는 그랬습니다. 그러나 현실은 많은 대형 은행과 중개인이 현재 Java로 작성된 시스템을 사용하고 있다는 것입니다. 즉, 대기 시간을 줄이기 위해 Java로 작성된 다음 C++로 해석하는 것이 아니라 기본적으로 Java로 작성되었습니다. 이러한 시스템은 (아마도) 속도가 느리다는 사실에도 불구하고 1등급 투자 은행에서도 표준이 되고 있습니다. 그래서 무슨 일이야? 예, C++는 코드 실행과 관련하여 "낮은 대기 시간"을 가질 수 있지만 새로운 기능을 배포하거나 이를 작성할 수 있는 개발자를 찾는 데 있어서는 확실히 낮은 대기 시간이 아닙니다.(실제) Java와 C++의 차이점
개발 시간 문제는 실제 시스템에서 Java와 C++의 차이점에 대한 시작에 불과합니다. 이러한 맥락에서 각 언어의 진정한 가치를 이해하기 위해 좀 더 자세히 살펴보겠습니다. 첫째, 대부분의 상황에서 C++가 Java보다 빠른 실제 이유를 기억하는 것이 중요합니다. C++ 포인터는 메모리에 있는 변수의 주소입니다. 이는 소프트웨어가 개별 변수에 직접 액세스할 수 있으며 이를 찾기 위해 계산 집약적인 테이블을 크롤링할 필요가 없음을 의미합니다. 또는 C++를 사용하면 개체의 수명과 소유권을 명시적으로 관리해야 하는 경우가 많기 때문에 적어도 개체의 위치를 지정하여 해결할 수 있습니다. 결과적으로 코드 작성에 능숙하지 않은 경우(마스터하는 데 수십 년이 걸릴 수 있는 기술) C++에는 몇 시간(또는 몇 주)의 디버깅이 필요합니다. Monte Carlo 엔진이나 PDE 테스트 도구를 디버깅해 본 사람이라면 누구나 알겠지만, 기본적인 수준에서 메모리 액세스를 디버깅하는 것은 매우 시간이 많이 걸릴 수 있습니다. 단 하나의 잘못된 포인터만으로도 전체 시스템이 쉽게 중단될 수 있으므로 C++로 작성된 새 버전을 출시하는 것은 정말 두려운 일이 될 수 있습니다. 물론 그게 전부는 아닙니다. C++ 프로그래밍을 즐기는 사람들은 Java의 가비지 수집기가 비선형 대기 시간 스파이크로 인해 어려움을 겪는다는 점을 지적할 것입니다. 이는 레거시 시스템으로 작업할 때 특히 그렇습니다. 따라서 클라이언트 시스템을 중단하지 않고 Java 코드에 대한 업데이트를 보내면 시스템이 너무 느려져서 사용할 수 없게 될 수 있습니다. 이에 대해 저는 Java GC로 인해 발생하는 대기 시간을 줄이기 위해 지난 10년 동안 많은 작업이 수행되었다는 점을 지적하고 싶습니다. LMAX 디스럽터예를 들어, Java로 작성된 지연 시간이 짧은 거래 플랫폼이며, 실행되는 하드웨어와 "기계적 상호 작용"이 있고 잠금이 필요하지 않은 프레임워크로 구축되었습니다. CI/CD를 사용하면 테스트된 코드 변경 사항을 자동으로 배포할 수 있으므로 CI/CD(지속적인 통합 및 전달) 프로세스를 사용하는 시스템을 구축하면 문제를 더욱 완화할 수 있습니다. 이는 CI/CD가 가비지 수집 대기 시간을 줄이기 위한 반복적인 접근 방식을 제공하기 때문입니다. Java는 출시 전에 다양한 하드웨어 사양에 맞게 코드를 준비하는 리소스 집약적인 프로세스 없이 특정 하드웨어 환경에 맞게 점진적으로 개선하고 적응할 수 있습니다. IDE의 Java 지원은 C++보다 훨씬 광범위하므로 대부분의 프레임워크(Eclipse, IntelliJ IDEA)에서는 Java를 리팩터링할 수 있습니다. 이는 IDE가 낮은 대기 시간 성능을 위해 코드를 최적화할 수 있다는 것을 의미합니다. 하지만 C++로 작업할 때 이 기능은 여전히 제한됩니다. Java 코드가 속도 면에서 C++와 완전히 일치하지 않더라도 대부분의 개발자는 여전히 C++보다 Java에서 허용 가능한 성능을 달성하는 것이 더 쉽다고 생각합니다."더 빠르다"는 것은 무엇을 의미합니까?
실제로 C++가 Java보다 실제로 "더 빠르다"거나 심지어 "낮은 대기 시간"을 갖는다는 점을 의심할 만한 타당한 이유가 있습니다. 나는 내가 꽤 어두운 상황에 빠져 있다는 것을 깨달았고, 많은 개발자들이 내 정신 상태에 의문을 제기하기 시작할 것입니다. 하지만 내 말을 들어보세요. 이런 상황을 상상해 봅시다. 두 명의 개발자가 있습니다. 한 명은 C++로 작성하고 다른 한 명은 Java로 작성하고 처음부터 고속 거래 플랫폼을 작성하도록 요청합니다. 결과적으로 Java로 작성된 시스템은 C++로 작성된 시스템보다 거래 거래를 완료하는 데 더 오랜 시간이 걸립니다. 그러나 Java에는 C++보다 정의되지 않은 동작의 인스턴스가 훨씬 적습니다. 한 가지 예를 들면, 배열 외부의 인덱싱은 Java와 C++ 모두의 버그입니다. 실수로 C++에서 이 작업을 수행하면 세그폴트가 발생하거나 ( 더 자주) 임의의 숫자가 표시될 수 있습니다. Java에서는 범위를 벗어나면 항상 ArrayIndexOutOfBoundsException 오류가 발생합니다 . 이는 오류가 일반적으로 즉시 식별되고 오류 위치를 추적하기가 더 쉽기 때문에 Java에서의 디버깅이 훨씬 쉽다는 것을 의미합니다. 또한 적어도 내 경험에 따르면 Java는 실행할 필요가 없는 코드 조각과 소프트웨어 작동에 중요한 코드 조각을 더 잘 인식합니다. 물론 외부 코드가 전혀 포함되지 않도록 C++ 코드를 조정하는 데 며칠이 걸릴 수 있지만 실제로는 모든 소프트웨어에 약간의 부풀림이 포함되어 있으며 Java가 이를 자동으로 인식하는 데 더 좋습니다. 이는 현실 세계에서 표준 대기 시간 측정 기준에서도 Java가 C++보다 빠른 경우가 많다는 것을 의미합니다. 그리고 그렇지 않은 경우에도 언어 간 지연 시간의 차이는 고속 거래에서도 문제가 될 만큼 크지 않은 다른 요인에 의해 압도되는 경우가 많습니다.대기 시간이 짧은 시스템을 위한 Java의 이점
내 생각에 이러한 모든 요소는 Java를 사용하여 고속 거래 플랫폼(그리고 일반적으로 지연 시간이 짧은 시스템)을 작성하는 데 매우 설득력 있는 주장을 제시합니다. 그러나 C++ 매니아들을 약간 흔들기 위해 Java를 사용해야 하는 몇 가지 추가 이유를 살펴보겠습니다.-
첫째, Java로 인해 소프트웨어에 발생하는 초과 대기 시간은 인터넷 문제와 같이 대기 시간에 영향을 미치는 다른 요인보다 훨씬 적을 것입니다. 이는 잘 작성된 모든 Java 코드가 대부분의 거래 상황에서 C++와 마찬가지로 쉽게 수행될 수 있음을 의미합니다.
-
Java의 개발 시간이 짧다는 것은 실제 세계에서 Java로 작성된 소프트웨어가 C++보다 하드웨어 변경(또는 새로운 거래 전략)에 더 빠르게 적응할 수 있음을 의미합니다.
-
이에 대해 더 자세히 살펴보면 Java 소프트웨어를 최적화하는 것조차 C++의 유사한 작업보다 (전체 소프트웨어를 고려할 때) 더 빠를 수 있다는 것을 알 수 있습니다.
GO TO FULL VERSION