"깨끗한 코드"사례와는 거리가 먼 코드를 사용하면서 어떻게 거대한 오픈 소스 라이브러리를 유지 관리합니까?

저는 여전히 양질의 코드를 작성하는 경험이 없어서 Robert C. Martin의 Clean Code 와 같은 문제를 다루는 책을 읽고 기술을 향상시키기 위해 잘 알려진 라이브러리의 코드를 계속 확인합니다.

많은 오픈 소스 라이브러리가 수년간 유지되어 왔지만, 올바른 경로에 있지 않을 가능성이 매우 높지만, 많은 코드가 깨끗한 코드를 작성하기 위해 해결 된 원칙과 거리가 멀다는 것을 알았습니다. 수백 줄의 코드.

그래서 내 질문은 : 깨끗한 코드의 원칙이 너무 제한적이며, 우리는 이것과 같은 많은 라이브러리에서 그것들 없이도 할 수 있습니까? 그렇지 않다면, 이러한 많은 원칙들을 고려하지 않고 어떻게 거대한 도서관들이 유지되고 있습니까?

간단한 설명을 부탁드립니다. 질문이 초보자 사람에게서 어리석은 것 같다면 사과드립니다.

편집하다

Android 커뮤니티에서 가장 잘 알려진 라이브러리 중 하나 인 버터 나이프 라이브러리 에서이 예제 를 확인하십시오 .

여기에 좋은 대답이 있지만 버터 나이프 예제 에 대해 한 번 말해 보겠습니다. 코드가 무엇을하는지 알지 못하지만 언뜻보기에는 실제로 유지할 수없는 것처럼 보이지 않습니다. 변수와 메소드 이름은 의도적으로 선택되고 코드가 올바르게 들여 쓰기되고 형식화되며 주석이 있고 긴 메소드는 적어도 일부 블록 구조를 보여줍니다.

그렇습니다. Bob 아저씨의 "깨끗한 코드"규칙을 따르지 않으며 일부 메서드가 너무 길 수도 있습니다 (아마도 전체 클래스). 그러나 코드를 살펴보면 블록을 자체 메서드로 추출하여 리팩토링 도구를 사용할 때 버그가 발생할 위험이 적기 때문에 쉽게 "정리"될 수있는 충분한 구조를 볼 수 있습니다.

이러한 코드의 실제 문제는 하나의 블록과 다른 블록을 추가하고 다른 블록을 추가하는 것은 때로는 수년에 걸쳐 어느 정도 작동한다는 것입니다. 그러나 매일 코드가 조금 발전하기가 어려워지고 코드를 수정하고 테스트하는 데 시간이 조금 더 걸립니다. 그리고 "다른 블록 추가"로 해결할 수없는 구조를 변경해야하지만 구조 조정이 필요한 경우 누군가가 코드를 더 일찍 정리하기 시작했으면합니다.

"청결 법"에 명시된 원칙이 항상 일반적으로 합의 된 것은 아닙니다. 대부분의 상식은 상식이지만 저자의 의견 중 일부는 논란의 여지가 있으며 모든 사람이 공유하지는 않습니다.

특히, 짧은 방법에 대한 선호는 모든 사람이 동의하지는 않습니다. 더 긴 방법으로 코드를 다른 곳에서 반복하지 않으면 코드 중 일부를 별도의 방법으로 추출하면 여러 개의 더 짧은 방법을 얻을 수 있으므로 전체적으로 복잡성이 증가합니다. 따라서 객관적인 개선이 아니라 절충입니다.

이 책의 조언은 모든 유형의 조언과 마찬가지로 특정 유형의 소프트웨어 인 엔터프라이즈 응용 프로그램을 대상으로합니다. 게임이나 운영 체제와 같은 다른 종류의 소프트웨어는 엔터프라이즈 소프트웨어와 다른 제약 조건이 있으므로 다른 패턴과 디자인 원칙이 적용됩니다.

클린 코드는 Java 또는 유사한 언어를 가정합니다. C 또는 Lisp를 사용하는 경우 많은 조언이 적용되지 않습니다.

요컨대이 책은 특정 종류의 소프트웨어에 대한 한 사람의 의견입니다. 모든 곳에 적용되지는 않습니다.

오픈 소스 프로젝트의 경우 코드 품질은 심연에서 화려한 수준까지 다양합니다. 결국 누구나 누구나 자신의 코드를 공개 소스로 게시 할 수 있습니다. 그러나 여러 기고자가있는 성숙하고 성공적인 오픈 소스 프로젝트를 살펴보면 그들이 자신에게 맞는 스타일을 의식적으로 설정했다고 확신 할 수 있습니다. 이 스타일이 어떤 의견이나 지침과 모순되는 경우, (직설적으로 말하면) 작업 코드가 의견보다 우선하기 때문에 잘못되었거나 관련이없는 지침이됩니다.

요약

JacquesB가 쓴 것처럼 모든 사람이 Robert C. Martin의 "Clean Code"에 동의하는 것은 아닙니다.

예상 한 원칙을 "위반"한 것으로 밝혀진 오픈 소스 프로젝트에는 다른 원칙이있을 수 있습니다.

내 관점

Robert C. Martin의 원칙을 매우 준수하는 몇 가지 코드 기반을 감독합니다. 그러나 나는 그들이 옳다고 주장하지 않으며 , 단지 그들이 우리 를 위해 잘 작동한다고 말할 수 있습니다 -그리고 "우리"는 사실

• 제품의 범위와 아키텍처
• 목표 시장 / 고객 기대
• 제품 유지 기간,
• 우리가 사용하는 개발 방법론
• 우리 회사의 조직 구조
• 개발자의 습관, 의견 및 과거 경험.

기본적으로 이것은 각 팀 (회사, 부서 또는 오픈 소스 프로젝트)이 독특합니다. 그들은 다른 우선 순위와 다른 관점을 가질 것이며, 물론 다른 절충점을 만들 것입니다. 이러한 장단점과 결과 코드 스타일은 주로 맛의 문제이며 "잘못된"또는 "올바른"것으로 입증 될 수 없습니다. 팀은 "우리에게 효과가 있기 때문에이 작업을 수행합니다"또는 "우리에게 효과가 없기 때문에이를 변경해야합니다"라고만 말할 수 있습니다.

즉, 수년에 걸쳐 큰 코드베이스를 성공적으로 유지할 수 있으려면 각 팀이 위에 주어진 측면에 적합하다고 생각되는 코드 규칙 세트에 동의해야합니다. 이는 Robert C. Martin의 관행, 다른 저자의 관행 채택 또는 자신의 발명을 의미 할 수 있습니다. 공식적으로 기록하거나 "예를 들어"문서화하는 것을 의미 할 수 있습니다. 그러나 그들은 존재해야합니다.

예

"긴 메소드에서 여러 개인 메소드로 코드를 분할"하는 방법을 고려하십시오.

간단한 예로서, 공개 방법은 아마 단지 같은 private 메소드 호출로 구성 것이다 - 로버트 C. 마틴은이 스타일 추상화 한 수준으로 각 방법의 내용을 제한 할 수 있다고 verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)그리고 마지막으로 sendJsonToClient(...), 이러한 방법은 것 구현 세부 사항.

• 독자들은 높은 수준의 단계에 대한 빠른 개요를보고 읽고 싶은 세부 사항을 선택할 수 있기 때문에 이런 사람들이 있습니다.
• 모든 사람들이 모든 세부 사항을 알고 싶을 때 실행 흐름을 따라 가기 위해 클래스에서 뛰어야하기 때문에 어떤 사람들은 그것을 싫어합니다 (JacquesB가 복잡성을 추가하는 것에 대해 글을 쓸 때 이것이 가능성이 있음).

교훈은 : 의견을 가질 자격이 있기 때문에 모든 것이 옳습니다.

많은 오픈 소스 라이브러리는 실제로 객관적으로 열악한 코딩 관행을 겪고 있으며 가장 빈번하게 유지되는 코드 부분에 매우 익숙하기 때문에 가독성이 좋지 않은 소규모 장기 기고자 그룹이 어려움을 겪고 있습니다. . 사실 이후의 가독성을 높이기 위해 코드를 리팩토링하는 것은 모든 사람이 같은 페이지에 있어야하기 때문에 허 큘린의 노력 인 경우가 많습니다. 재미없고 새로운 기능이 구현되지 않았기 때문에 비용이 들지 않습니다.

다른 사람들이 말했듯이, 깨끗한 코드에 관한 책은 반드시 보편적으로 합의되지 않은 조언을 포함하고 있습니다. 특히, 거의 모든 규칙에는 과도한 열성이있어 가독성 문제를 다른 것으로 대체 할 수 있습니다.

개인적으로, 나는 이름이 좋지 않으면 이름이 지정된 함수를 만드는 것을 피합니다. 그리고 좋은 이름은 짧아야하고 그 기능이 외부 세계에 어떤 역할을하는지 충실하게 묘사해야합니다. 이것은 가능한 한 적은 함수 인수를 사용하고 전역 적으로 쓸 수있는 데이터가없는 것과 관련이 있습니다. 매우 복잡한 함수를 더 작은 함수로 줄이려고하면 함수가 실제로 복잡한 경우 인수 목록이 매우 길어지는 경우가 종종 있습니다. 읽을 수있는 코드를 작성하고 유지하는 것은 상충되는 상식 규칙간에 균형을 맞추는 연습입니다. 책을 읽는 것은 좋지만 경험 만으로는 실제 가독성이 향상되는 허위 복잡성 을 찾는 방법을 배울 수 있습니다.

대부분의 오픈 소스 프로젝트는 잘못 관리됩니다. 분명히 예외가 있지만 오픈 소스 세계에는 많은 쓰레기가 있습니다.

이것은 내가 말하는 프로젝트의 모든 프로젝트 소유자 / 관리자에게 비판이 아니며 단순히 사용 된 시간 문제입니다. 이 사람들은 실제 임금을받는 일과 같이 시간과 더 나은 일을합니다.

처음에는 코드가 한 사람의 작품이며 아마도 작을 것입니다. 그리고 작은 코드는 깨끗할 필요가 없습니다. 또는 코드를 깨끗하게하는 데 필요한 노력이 이익보다 큽니다.

시간이 지남에 따라 코드는 많은 다른 사람들에 의해 패치의 더미입니다. 패치 작성자는 코드에 대한 소유권이 없다고 생각하며,이 기능 하나만 추가하거나이 버그를 가장 쉬운 방법으로 수정하기를 원합니다.

주인은 물건을 정리할 시간이 없으며 아무도 신경 쓰지 않습니다.

그리고 코드가 커지고 있습니다. 그리고 못생긴.

코드에서 길을 찾기가 점점 더 어려워지면서 사람들은 잘못된 위치에 기능을 추가하기 시작합니다. 버그를 수정하는 대신 코드의 다른 위치에 해결 방법을 추가합니다.

이 시점에서 사람들이 더 이상 상관 없어 그냥하지 감히 그들이 물건을 깨는 두려워하기 때문에 청소.

코드베이스를 "잔인하고 특이한 형벌"이라고 묘사 한 사람들이있었습니다.

내 개인적인 경험은 그렇게 나쁘지는 않지만 몇 가지 매우 이상한 것을 보았습니다.

나에게, 당신은 아무도 그들이하고있는 일을하고 있지 않으면이 물건이 어떻게 작동하는지 묻고있는 것 같습니다 . 그리고 그것이 효과가 있다면, 왜 우리는 이런 일을해야 합니까?

대답, 이럴가 작동한다는 것입니다 "충분" (가) "로 알려진, 악화가 더 낫다 " 철학 . 기본적으로 오픈 소스와 빌 게이츠 사이의 암석 한 역사에도 불구하고, 그들은 대부분 같은 사람들이 버그가 아닌 기능에 관심 을 갖는다는 동일한 아이디어를 채택했습니다 .

물론 이것은 우리를 " 탈선의 정상화 "로 이끌며 , 이는 Heartbleed 와 같은 상황으로 이어진다. 마치 마치 당신의 질문에 대답하는 것처럼 OpenSSL 이라는 오픈 소스 코드의 방대하고 자란 스파게티 더미 가 10 년 동안 " 깨끗하지 않은 "상태가 되었다. 하는와 권선 대규모 보안 결함 에 영향을 미치는 사람들의 수백만의 수천 .

솔루션 이라는 새로운 시스템을 발명했다 LibreSSL 하고, 깨끗한 틱 코드를 사용하려고를 , 물론 거의 아무도 그것을 사용하지 않습니다 .

그렇다면 어떻게 잘못 코딩 된 오픈 소스 프로젝트가 유지됩니까? 대답은 질문에 있습니다. 대부분은 깨끗한 상태로 유지되지 않습니다. 그들은되는 무작위 패치 에 의해 다른 사람의 수천 충당하기 위해 다양한 이상한 기계에 사용 사례 하고 상황 개발자를 에 테스트 할 수있는 권한이 없습니다. 코드는 "충분히 좋은"작동 할 때까지 그렇지 않습니다 , 모두가 패닉하고 결정할 때 이 문제에 돈을 던져 .

다른 사람이 없다면 왜 ' 올바른 길 '을해야 하는가?

대답은하지 말아야한다는 것입니다. 당신도 할 수 또는 당신이하지 않는 , 그리고 세계는 회전 계속 하기 때문에 관계없이 인간의 본성은 변하지 않는다 a의 규모에 인간의 수명 . 개인적으로, 나는 그것이 느끼는 방식을 좋아하기 때문에 깨끗한 코드를 작성하려고합니다.

좋은 코드를 구성하는 것은 상황에 따라 다르며 오픈 소스를 논의하기에 너무 오래되지는 않았지만 적어도 사내 코드베이스와의 끊임없는 전쟁을 벌이는 전통의 적어도 일부를 설명하는 고전 서적. 따라서 라이브러리의 목표가 완전히 다르다는 사실을 간과하기 쉬우 며 그에 따라 작성됩니다. 다음 순서를 특별한 순서없이 고려하십시오.

• 라이브러리를 가져 오거나 라이브러리에서 가져 오는 경우 내부 구조 전문가가 충분하지 않은 이유는 무엇입니까? 스택 교환 답변이 나에게 지시했습니다. 그래서 타이핑을 시작하고 from A import(파이썬이라면) 무엇이 나오는지 봅니다. 그러나 이것은 내가 본 것 중 내가 빌려야 할 논리적 작업을 반영해야한다는 것을 의미하며, 이것이 코드베이스에 있어야하는 것입니다. 그것을 짧게 만드는 수많은 도우미 메소드는 나를 혼란스럽게 할 것입니다.
• 라이브러리는 대부분의 사람들이 모호하게 들었던 알고리즘을 사용하려고하는 가장 숙련 된 프로그래머를위한 것입니다. 그들은 외부 문서가 필요하며 코드를 정확하게 반영해야하며, 짧은 방법과 일대일 준수자를 행복하게 만들기 위해 모든 것을 리팩토링하는 경우에는 할 수 없습니다.
• 사람들이 빌린 모든 도서관 방법은 코드가 중단되거나 이름이 변경 될 경우 전 세계적으로 코드를 파괴 할 수 있습니다. 물론, 나는 sklearn이 Calinski-Harabasz의 오타를 교정하기를 원 하지만 또 다른 왼쪽 패드 사고 가 발생할 수 있습니다 . 사실, 내 경험상 도서관 진화의 가장 큰 문제는 그들이 모든 것을 구성하는 방법에 대해 좋은 코드의 새로운 "개선"을 채택하기가 너무 어려울 때입니다.
• 사내에서, 의견은 대체로 필요하지 않은 모든 방식으로 기껏해야 필요한 악입니다. (그 점들이 다소 과장 되더라도) 좋은 의견은 코드가 작동하는 방식이 아니라 왜 작동하는지 나타냅니다. 그러나 도서관은 독자들이 종이 봉투에서 길을 잃은 선형 대수를 쓸 수없는 유능한 프로그래머라는 것을 알고 있습니다. 다시 말해, 모든 것이 주석을 달아야합니다. 왜 작동하는지! (이것은 또 하나의 과장입니다.) 그래서 서명란, 100 줄 주석 블록, 문자 그대로 서명란에 들어갈 수있는 1 줄의 코드가 보입니다 (물론 언어 허용).
• Github에서 무언가를 업데이트하고 코드가 허용되는지 기다리는 것을 가정 해 봅시다. 왜 코드 변경이 작동하는지 분명해야합니다. 필자는 기능적 커밋의 일부로 캠프장을 깨끗하게 만들기 위해 리팩토링을하면 많은 줄 절약, 재배치 및 이름 변경을 의미하므로 급여가없는 검토 자의 작업이 더 어려워지고 위에서 언급 한 다른 문제가 발생한다는 것을 알고 있습니다.

나보다 더 많은 경험을 가진 사람들은 다른 요점을 언급 할 수 있다고 확신합니다.

이미 좋은 답변이 많이 있습니다. 오픈 소스 관리자의 관점을 제시하고 싶습니다.

내 관점

나는 훌륭한 코드가 아닌 많은 프로젝트의 관리자입니다. 때로는 라이브러리가 매주 수백만 번 다운로드되기 때문에 호환성 문제로 인해 코드가 개선되지 않는 경우도 있습니다.

Node.js 핵심 멤버로서 내가 만질 것을 두려워하는 코드의 일부가 있지만 관계없이 사람들이 플랫폼을 성공적으로 사용하고 즐길 수있는 많은 작업이 있습니다. 가장 중요한 것은 작동한다는 것입니다.

읽을 수있는 코드

당신이 말할 때:

많은 코드가 깨끗한 코드를 작성하기 위해 해결 된 원칙과는 거리가 멀다는 것을 알았습니다. 예를 들어 수백 줄의 코드를 포함하는 메소드.

코드 줄은 코드를 읽을 수있는 정도 를 측정하는 데 큰 도움이되지 않습니다 . 이 연구에서 나는 리눅스 커널에 연결되어 분석되었으며 프로그래머에 대한 설문 조사에서 "일반"코드 (사람들이 기본적으로 기대하는 코드)와 일관성있는 코드가 이해하기 쉬운 "깨끗한"코드보다 낫다는 것을 발견했다. 이것은 또한 내 개인적인 경험과도 일치합니다.

일부 오픈 소스 프로젝트는 너무 환영받지 못합니다

Linus는 "유명하게도" 디버거를 사용하는 사람들이 리눅스에서 작업하기에 충분하지 않아서 더 많은 것을 끌어 들이고 싶지 않기 때문에 리눅스에 디버거가 내장되어서는 안된다고 말했다.

개인적으로 나는 그의 입장에 전혀 동의하지 않지만 사람들이하는 일이기도합니다.

오픈 소스 소프트웨어가 반드시 여러 저자가 관련되어 있음을 의미하지는 않습니다. 한 명의 작성자가 소프트웨어 (또는 소프트웨어 단위)를 작성하면 긴 기능이 자주 나타납니다.

이것은 개발 프로세스의 특성에서 비롯됩니다. 간단한 방법은 시간이 지남에 따라 확장되고 새로운 기능이 추가되고 버그가 수정됩니다.

긴 방법을 사용하면 새 작성자의 기능에 대한 이해가 크게 줄어 듭니다. 그러나 단일 작성자의 경우 이는 거의 문제가되지 않으며 문제가 간과되는 경향이 있습니다. 오픈 소스의 또 다른 특성은 많은 소프트웨어가 적극적으로 개발되지 않았기 때문에 복잡한 방법을 여러 간단한 방법으로 분리하는 리팩토링 작업이 없다는 것입니다.

당신은 어떤 예도 보여주지 않았지만 내 이해로 이것은 종종 개발 언어와 관련이 있습니다. 일부 언어는 처음부터 엄격한 단위 테스트 (또는 TDD)를 엄격하게 적용합니다. 보푸라기 및 단위 테스트는 일반적으로 해당 문제를 방지합니다 (복잡하고 긴 방법을 단위 테스트하기는 어렵습니다).

일반적으로 한 명의 작성자가 소프트웨어를 개발하고 다른 기고자들이 작은 문제 만 해결하면 코드를 깨끗하게 만드는 것이 더 어렵습니다.