실제로 '깨끗한 코드'를 작성합니까? [닫은]

나는 일부 프로그래머들이 코드를 '작동하게'만들뿐만 아니라 '보기 좋게'만들기 위해 반복해서 수정하는 것을 보았습니다.

IMO 'clean code'는 실제로 코드가 우아하고 완벽하게 이해 가능하고 유지 관리 가능하다는 것을 나타내는 칭찬입니다. 심미적으로 매력적인 코드와 스트레스가 많은 코드 중에서 선택해야 할 때 차이가 발생합니다.

그렇다면 실제로 얼마나 많은 사람들이 '깨끗한 코드'를 작성합니까? 좋은 습관입니까? 이것의 다른 장점이나 단점은 무엇입니까?

나는 우리 중 많은 사람들이 깨끗한 코드를 작성하지 않는다고 주장한다 . 그리고 일반적으로, 그것은 우리의 일이 아닙니다 . 소프트웨어 개발자로서 우리의 임무는 제 시간에 작동하는 제품을 제공하는 것입니다.

Joel Spolsky의 블로그 게시물 인 Duct Tape Programmer를 생각 나게 합니다.

그는 직장 에서 코더에서 인용 :

하루가 끝나면 f ***** g 물건을 배송하십시오! 코드를 다시 작성하고 깨끗하게 만드는 것이 좋으며 세 번째로 실제로는 예쁘게 보일 것입니다. 그러나 그것은 요점이 아닙니다. 여러분은 코드를 작성하지 않았습니다. 당신은 제품을 배송하기 위해 여기에 있습니다. -제이미 자윈 스키

또한 Robert Martin의 블로그 응답을 상기시킵니다 .

그래서. 똑똑하세요. 깨끗하게 간단하게 배! 그리고 작은 덕트 테이프 롤을 준비 상태로 유지하고 사용하는 것을 두려워하지 마십시오. -밥 아저씨

개발자가 작성한 코드가 깨끗하고 작동하는 경우 (제공 가능) 모든 사람에게 적합합니다. 그러나 개발자가 적시에 코드를 제공 할 수있는 비용으로 깨끗하고 읽기 쉬운 코드를 만들려고 애 쓰고 있다면 좋지 않습니다. 작동시키고 덕트 테이프를 사용하여 배송하십시오. 나중에 리팩토링하여 화려하고 효율적으로 만들 수 있습니다.

예, 깨끗한 코드를 작성하는 것이 좋지만 제공 할 수는 없습니다. 덕트 테이핑 제품을 제 시간에 제공하는 이점은 완료되지 않은 깨끗한 코드의 이점을 능가합니다.

내가 만난 좋은 코드 덩어리는 깨끗하지 않습니다. 일부는 못 생겼습니다. 그러나 그들은 모두 출시되어 생산에 사용되었습니다. 지저분한 코드를 작성하는 것은 비전문가라고 말할 수도 있습니다. 동의하지 않습니다. 전문적인 것은 깨끗하거나 지저분한 작동하는 코드를 제공하는 것입니다. 개발자는 배송 전에 할당 된 시간에 관계없이 최선을 다해야합니다. 그런 다음 정리로 돌아가서 전문가입니다. 전달 된 코드는 순수한 덕트 테이프가 아니며 '충분히 깨끗합니다'.

코드를 매우 읽기 쉽고 깨끗하며 유지 관리 할 수 ​​있는지 확인해야합니다. 이것이 모든 프로그래머가 해야 할 일입니다.

그러나 당신은 저자의 자아 외에는 아무것도 제공하지 않는 ( 소녀 코드over styling 보다 나은 용어) 말하고 있습니다.

나는 과거에 많은 개발자들이 그들의 제작을 자랑스럽게 생각하는 것을 보았습니다 (화장실에서와 같이). 코드를 청소하고 연마하는 데 몇 시간을 보냈습니다. 그들 중 일부는 너무 세심하여 회원들 사이의 올바른 공백이 존중되도록했습니다.

너무 많아

나는 그런 종류의 행동이 비생산적이라는 것을 안다. A의 전문 컨텍스트, 당신은해야합니다 전문 . 깨끗하고 읽기 쉽고 유지 관리가 쉬운 코드를 작성하고 행복한 사용자 또는 동료와 대화함으로써 만족도를 얻을 수 있습니다.

이 질문에 대한 답변에 동의하지 않습니다.

귀하의 책임은 명백히 배송해야하지만 일반적으로 귀하와 미래 개발자가 가능한 한 비용 효율적으로 유지 보수 할 수있는 것을 배송 할 책임도 있습니다.

나는 문서화되지 않은 거대한 시스템을 이해하고 디버깅 해야하는 사이트의 유지 보수 프로그래머 나 컨설턴트가 좋지 않은 시간을 보냈으며, 나쁜 디자인과 혼란스러운 코드로 인해 몇 시간 또는 며칠의 노력이 낭비 될 수 있다고 말할 수 있습니다. 초기 개발자의 추가 N 시간 노력으로 내 시간면에서 5N 비용 절감으로 이어질 수있는 많은 상황을 생각할 수 있습니다.

나는 이것에 관해 통계가 떠 있다는 것을 알고 있지만, 여러 프로젝트에서 경험 한 바에 따르면, 작성된 각 코드 줄은 확장 및 유지 보수 중에 5-20 번 읽습니다.

그래서 코드 수명을 1 인치 내로 정리 한다고합니다 . 시간이 걸리지 만 프로젝트 수명 동안 순 비용이 절감 될 수 있습니다.

후드 아래에서 문제 해결, 유지 관리 또는 수정이 어려우며 실행하는 데 더 많은 리소스가 필요하다는 것을 알고 있다면 자동차를 구입하겠습니까?

소프트웨어와 다른 이유는 무엇입니까?

최종 사용자가 후드를 볼 수 없다고해서 결코 그것을 알 수 없다는 의미는 아닙니다. 조만간 나타납니다.

"실제로 '클린 코드'를 작성합니까?" -- 오 예.!

'깨끗한 코드'로 말하면 가능한 한 코드가 명확하도록하기 위해 나아갈 수 있습니까?

그렇습니다.

코드가 깨끗하고 명확할수록 유지 관리가 쉬워 져 장기적으로 시간을 절약 할 수 있습니다. 깨끗한 코드를 허영심으로 보지 마십시오. 미래의 노력과 시간을 절약하기 위한 투자 로 생각하십시오.

솔직히 그것은 달려 있습니다. 나는 모든 사람들이 "잘 정리 된 코드를 정리하는 것보다 순전히 비극적 인 방법"에 대해 파티 라인을 내놓는 것을 좋아하지만, 어리석은 배포주기와 제로 감독이없는 비즈니스에서 일하고 있습니다. 많은 코드 다른 사람들이 작성 한다고 주장 하는 완벽한 코드를 작성하는 것은 매우 어렵습니다 .

나는 거의 내 능력을 가진 사람이 쉽게 유지할 수있는 코드를 작성하려고합니다. 나는 까다로운 부분에 대해 언급하고, 프로그램, 변수 및 클래스에 친숙한 이름을 지정하고 배포하고 계속 진행합니다. 다른 일을 할 시간이 없습니다.

때때로 나는 그것에 대해 약간의 죄책감을 느낍니다. 내가 다루는 공포의 일부를 매일보아야합니다. 설명서가 불분명 한 모호한 언어로 된 수십 개의 사용자 정의 코드. 내 동료 중 하나가 Visual Basic 6.0에서만 개발하고 암호로 명명 된 이진을 모든 곳에 배포합니다. 내가 교체 한 여성은 RPG 에만 독점적으로 프로그래밍되었습니다 .

프로그래머로서 몇 년 동안 내가 본 것처럼 끔찍한 쓰레기는 모두 가 깨끗한 코드 만 생성 한다고 믿기가 매우 어렵습니다 .

"소녀 코드"라는 용어는 마음에 들지 않지만 깨끗한 코드 = 유지 관리 가능한 코드입니다. 덜 전문적인 것은 없습니다.

원칙적으로, 나는 내 혼란을 봐야 할 다음 개발자를 고려합니다.

몇 달 후 ... 어떻게 작동하는지 기억 나지 않을 때 ... 그리고 시간을 내야 할 시간이 훨씬 적습니다.

Bob Martin 의미에서 "깨끗한 코드"를 작성하려고합니다 (예 : OO 디자인). 이 좋은 깨끗한 코드를 작성하는 가치는. 훨씬 더 유지 관리가 가능합니다.

그런 다음 ReSharper가이를 "예쁜 코드"(예 : 정렬, 줄 바꿈 등)로 만들었습니다. 예쁜 코드를 작성 하면 좋은 가치가 있습니다. 그러나 수익이 감소하고 있습니다. 일부 prettification은 읽기 쉽기 때문에 조금 더 유지 관리가 가능합니다.

큰 코드 블록을 깔끔하게 정렬해야 읽을 수 있다고 생각한다면 문제는 엄청난 코드 블록입니다! 너무 커. 나는 잘 설계되지 않은 코드를 확인하기 위해 큰 고통을 겪는 사람들의 많은 예를 봅니다.

ReSharper가없는 경우에도 여전히 코드가 깨끗하지만 꽤 예쁘지는 않습니다.

코딩 시간의 ~ 5 % 이상을 정제에 소비해서는 안된다고 생각합니다. 내 편집자가 더 강력하고 능숙할수록 더 많은 설교를 할 수 있습니다.

회사의 최대 관심사에 대한 요점을 아무도 제기하지 않는 것 같 습니까?

항상 그렇지는 않지만 프로그래머는 단순히 직원 일뿐 아니라 경영진의 결정에 실망을 줄 수 있지만 종종 모든 데이터가있는 것은 아닙니다.

예를 들어, 회사에 소프트웨어가 적시에 준비되어 있지 않으면 돈을받지 못할 것이라는 조항이 회사에 계약되어 있다고 가정합니다. 예, 깨끗한 코드는 중요하지만 지불 일까지 코드를 작동시키는 것이 더 중요합니다!

또 다른 예-회사는 재무 상태가 좋지 않고 돈을 모아야합니다. 누가 품질에 관심이 있는지 추측? 나중에 수정해야 할 경우 배송 만하면됩니다.

"왜 크 래피 코드를 팔아서 써야합니까?"라는 주장이있을 수 있습니다. 글쎄, 왜 당신 회사는 매월 좋은 수표를 지불해야합니까? 선택, 내 친구 이상주의를 따르는 경우 자유 소프트웨어 재단 (Free Software Foundation)을 사용해보십시오 . 나는 그들이 아주 멋진 일을하고 있다고 들었습니다 (이것을 의미하며 FSF와 OSS를 존중합니다).

다른 한편으로, 폭발적인 사용 증가가 예상되는 프로젝트 (그러한 예측이 거의 정확하지는 않지만)에서 작업하는 경우 거의 특정 유지 보수가 필요하기 때문에 필요한 최상의 코드 품질로 견고한 기초를 배치하는 것이 좋습니다 프로젝트 비용이 더 큽니다.

프로그래머는 그것이 무엇이든 '깨끗한'코드를 좋아합니다. 우리는 깨끗한 것에 동의 할 수 없지만 그것을 좋아합니다. 그러나 때로는 유용성과 정확성만큼 중요하지 않습니다. 이것들은 동의어처럼 보이지만 그렇지는 않습니다.-진정한 Perl 해커가 4 시간 안에 작성한 코드를 두 번 사용하여 버릴 의도로 본다면 코드가 깨끗하지 않다는 것을 인정할 것입니다.

그래서 때때로, 자아를 제쳐두고, 우리는 그것을 작동시켜야합니다. 습관으로 나쁜 코드를 작성하지 않는 것이 좋습니다. 나는 그것이 필요할지도 모른다고 지적하고있다. 완벽에는 회사에없는 시간이 걸립니다. 따라서 고용주가 신경 쓰지 않으면 소프트웨어를 제작해야하지만 작업 코드를 작성 해야하는 경우 '청결도'를 신경 쓰지 마십시오. 그것은 '하나의 크기가 모두에게 맞는'대답이 아닙니다. 우선 순위를 정해야합니다.

나는 "좋아 보인다"고 확신하지 못하고 "우아하고 완벽하게 이해 가능하며 유지 보수가 가능하다"는 것은 동등합니다.

코드를 작성하려고합니다. "우아하고 완벽하게 이해할 수 있고 유지 관리가 가능합니다." 해당 기준에 더 잘 맞도록 자체 코드를 리팩터링합니다.

결과적인 시간 비용을 제외하고는 단점이 없습니다.

코드가 "보기 좋게"보이기 위해서는 원하는대로 모든 것을 올바르게 들여 쓰고 간격을 두는 자동화 된 도구가 많이 있습니다.

너무 많은 것은 결코 좋은 것이 아닙니다.

그러나 "불법적 인"코드를 염두에 두어야 할 중요한 점은 " 깨진 창 "으로 쉽게 이어질 수 있다는 것 입니다. 코드의 형식이 매우 틀리면 코드 기반을 처음 접하는 많은 사람들이 유지 관리 및 진화를 통해 좋은 일을하는 경향이 적어 결국 소프트웨어의 작동 조건에 영향을 줄 수있는 하향 나선형이 발생한다고 생각합니다.

따라서 코드에서 특정 수준의 청결도를 유지하는 것은 동료 개발자 이상의 도움이됩니다. 그것에 너무 많은 시간을 소비하지 마십시오 (~ 5 %가 언급되었습니다). 공예 도구를 사용하여 수동 작업 (이 경우 코드 형식)을 자동화하는 방법을 배웁니다. 자신이하는 일에 대해 책임을지고 항상 회사 / 고객 / 사용자에게 가장 유익하다고 생각하는 것을하십시오.

이것은 Bob Martin의 Clean Code의 인용문입니다.

이 시점을 집으로 몰아 가려면 의사가었고 시간이 너무 많이 걸리기 때문에 수술 준비에서 모든 바보 같은 손 씻기를 중단하라고 요구 한 환자가 있다면 어떨까요? 분명히 환자는 보스입니다. 그러나 의사는 절대로 준수를 거부해야합니다. 왜? 의사는 질병과 감염의 위험에 대해 환자 이상을 알고 있기 때문입니다. 의사가 환자를 준수하는 것은 비전문가 일 것입니다.

따라서 프로그래머가 혼란을 일으킬 위험을 이해하지 못하는 관리자의 의지에 구애하는 것은 전문가가 아닙니다.

"깨끗한 코드"는 물리 / 엔지니어링 / 수학 시험에 쓰던 방법보다 깨끗하거나 깨끗해야한다고 생각합니다. 너무 지저분하면 그레이더는 작업 내용을 이해하지 못하고 옳더라도 잘못 표시 할 수 있습니다.

코드를 읽을 수는 있지만 가장 중요한 것은 일관성입니다. 나에게 그것은 명명 규칙 과 함수 사이의 간격, 같은 줄의 괄호, if 문의 다음 줄 등을 의미합니다.

물론 누군가가 일관된 코드 스타일로 무언가를 프로그래밍하고 여전히 나를 미치게 만드는 경우가 있습니다. 특히 "숨 쉬지 않는"코드. 예를 들면 다음과 같습니다.

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

글쎄 ... Objective-C 메서드와 중첩 된 if 문이 많고 줄이 80 자보다 훨씬 길면 더 나빠 보입니다. 그러나 그것은 여전히 ​​나를 귀찮게합니다 :)

코드를 정리하기 위해 많은 시간을 할애합니다. 버그가 눈에 띄는 데 크게 도움이된다고 생각합니다.

깨끗한 코드는 미래에 대한 투자이기 때문에 나는 "지금 빌어 먹을 배"개념에 동의하지 않습니다. 또한 너무 많은 소프트웨어가 너무 많은 버그와 함께 제공됩니다. 제 생각에 하나의 버그를 해결하는 것이 하나의 새로운 기능을 구현하는 것보다 낫습니다.

또한 프로그래머 생산성 추정치 를 보면 점수가 그렇게 나쁘지 않다고 생각합니다. 깨끗한 코드를 작성하는 것은 습관이며, 프로그래머로서의 경험이 많을수록 더 효율적입니다. 시도하지 않으면 분명히 경험하지 못할 것입니다.

고려해야 할 또 다른 요점은 대부분의 개발자 시간이 코드를 읽는 데 걸리므로 읽을 수있는 코드는 읽는 시간을 크게 줄입니다. 예를 들어 문서화되지 않은 알고리즘을 이해하면 많은 비용이 들고 새로운 버그가 발생할 수 있습니다.

내가 놓치고 하루를 보내고 싶은 한 가지는 내 스타일에 적응할 수있는 자동 코드 포맷터입니다. 특히 다른 사람들의 코드를 읽을 때 시간을 절약 할 수 있습니다.

깨끗한 코딩은 완벽 화와 연결되어있어 결코 실현할 수없는 위험이 있습니다.하지만 나중에 투자 할 때나 경험과 함께 자신 만의 우아한 코드를 재사용 할 때 주로 문제라고 생각합니다 나이가 들수록 지저분한 코더보다 생산성이 높고 버그가 적습니다.

이것은 내 코딩 스타일을 보여주는 코드입니다.

"허영 코드"는 피하십시오. 순수하게 허영심에서 (또는 OCD로 인해) 일을하는 개발자가 많이 있습니다. 내 팬티는 정말 그 사람들과 뒤틀려 있습니다.

주어진 문제를 가장 효율적이고 이론적으로 '우아한'방식으로 해결하려고 시도하는 코드를 작성합니다. 그런 의미에서만 깨끗합니다. 내가 끝났을 때 '예쁘다'면, 그렇게하십시오.

제한된 경험에서 내가 찾은 것은 사람들이 '깨끗한 코드'에 대해 불평 할 때, 추악함은 일반적으로 코딩 규칙보다는 끔찍한 해결책의 결과라는 것입니다.

더 깨끗한 코드를 작성하려고 노력하고 있지만 시간 제약으로 인해 또는 어려운 작업을 수행하는 경우 변경 될 수 있습니다. 작동시키는 데 집중할 때 지저분 해지는 경향이 있습니다. 그런 다음 다시 돌아가서 정리하겠습니다. 코드로 돌아가서 메모리를 새로 고치는 데 너무 많은 시간을 소비해야한다면 충분히 언급하지 않았습니다.

깨끗한 코드는 좋지만 다른 모든 것과 마찬가지로 깨끗해야합니다. 5 줄의 코드 4 칸과 1 줄의 5 칸을 들여 쓰기해도 읽기 어려움이 커지지는 않습니다.

나는 그것이 당신이하는 일에 달려 있다고 생각합니다. 개념 증명 응용 프로그램을 작성하는 경우 기본적으로 엉덩이를 카우보이 코딩하고 뒤돌아 보지 않습니다. 실제로 실제로 작업 할 응용 프로그램을 작업하는 경우 한 달 안에 이해할 수있을뿐만 아니라 충분히 코딩해야합니다.

나는 당신의 코드를 스타일링하는 것이 약간 iffy라고 생각합니다. 위에서 언급했듯이, 당신의 임무는 형식화 된 코드가 아닌 제품을 만드는 것이지만 최소한 정의 된 주석 및 코딩 스타일을 고수해야한다고 말하고 싶습니다. 나는 낙타의 절반의 변수와 헝가리의 다른 절반을 보는 것이 싫어.

또한 'clean-code'가 의미하는 바에 따라 다릅니다.

나는 그렇게하는 것을 인정한다. 내가 볼 때마다 그 이점은 짜증나 지 않습니다. 읽기가 더 쉽다고 생각하기 때문에 버그가 더 분명해집니다. 그러나 진짜 이유는 못생긴 코드를 견딜 수 없기 때문입니다.

코드를 우아하게 리팩토링하면보다 쉽게 ​​읽고 유지 관리 할 수 ​​있습니다. 변수 할당 정렬과 같은 사소한 것 :

int foo    = 1;
int bar    = 2;
int foobar = 3;

보다 읽기 쉽다

int foo = 1;
int bar = 2;
int foobar = 3;

나중에 디버깅 할 때 쉽게 넘어갈 수 있습니다.

또한 PHP에서는 임의의 수의 임의 코드 블록이 허용됩니다. 나는 이것을 사용하여 논리적 작업을 그룹화합니다.

// do x
{
    // ...
}

// do y
{
    // ...
}

이것은 관련 코드에 명확한 정의를 추가합니다.

편집 : 추가 보너스로 if (false)일시적으로 건너 뛰려 는 경우 논리 코드 블록 중 하나를 쉽게 처리 할 수 있습니다.

회사 표준에 따라 코드를 작성합니다. "예쁘게"원한다면 코드 미화기를 통해 실행할 수 있습니다.