얼마나 효율적인 코드로 코드 가독성을 희생해야합니까? [닫은]

얼마나 효율적인 코드로 코드 가독성을 희생해야합니까?

예를 들어 3 줄의 코드를 1 줄로 만듭니다.

저는 Pete Goodliffe의 Code Craft 에서 가독성이 중요하다고 읽었습니다 .

당신의 생각?

"더 적은 라인"이 "더 효율적인"과 항상 같은 것은 아닙니다. 나는 당신이 "가독성을 희생하여 프로그램을 더 짧게 만들어야한다고"가정합니다.

사람들이 읽을 수 있도록, 그리고 기계가 실행할 수 있도록 프로그램을 작성해야합니다.

-Abelson & Sussman, 컴퓨터 프로그램의 구조 및 해석

일반적으로 프로그램을 짧게 만드는 것보다 쉽게 ​​이해하는 것이 더 중요하다고 생각합니다. 그러나 프로그램을 더 짧게 만들면 프로그램을 더 읽기 쉽게 만들 수 있습니다 (코드가 라인 노이즈처럼 보일 때 시작하는 확실한 임계 값이 있지만 그 시점까지는 간결하게 표현하면 더 명확하게 보입니다).

개인 셸 스크립트 또는 하나의 데이터 뭉치 코드와 같은 특정 예외는 유지 관리 할 필요가 없으며 사용자 만 읽을 필요가 있습니다. 그러한 상황에서, 여전히 이해하기 만한다면 편의성을 위해 가독성을 희생하는 것이 좋습니다.

어쩔 땐 그래.

가독성은 노력하는 것이 좋습니다. 일반적인 업무용 응용 프로그램 용으로 작성된 대부분의 코드는 충분히 성능이 좋으며 가독성에 초점을 맞추는 것이 중요합니다. 비디오 게임 프로그래밍이나 무거운 계산과 같이 성능이 많이 요구되는 영역에서는 읽기가 쉽지만 성능이 뛰어난 특정 언어 기능을 선호하는 가독성을 포기하는 것이 중요 할 수 있습니다.

후자의 예는 Wikipedia 의 Fast Inverse Square Root 기사를 참조하십시오.

나는 일반적으로 O (n) 대신 O (n ^ 2) 알고리즘을 선택하지 않는 것과 같은 상식적인 예방 조치를 취하면 먼저 읽을 수있는 것을 만들고 성능에 대해 걱정하는 것이 낫다고 생각합니다. 간결함을 위해 가독성을 희생하는 것은 제 생각에는 잘못된 것입니다.

가독성을 희생 할 수있는 유일한 시간은 코드에 성능 병목 현상이있는 것으로 나타 났을 때 다시 작성하면 문제가 해결됩니다. 이 경우, 버그가있는 경우 더 쉽게 추적 할 수 있도록 코드 의 의도 를 잘 문서화해야합니다.

물론 다시 쓰기를 읽을 수 있어야한다고 말하는 것은 아닙니다.

나는 그것을 전에 인용 , 나는 다시 인용합니다 :

정확
하고 명확
하게 작성하고 간결하게
작성하고 빠르게 작성하십시오.

그와 같은 순서로.

웨스 다이어

얼마나 효율적인 코드로 코드 가독성을 희생해야합니까?

코드 측면에서, 자체 문서화하는 것이 항상 좋습니다. 그러나 때때로 그것은 일어날 수 없습니다. 때로는 최적화해야 할 필요가 있으며 때로는 코드 자체가 읽기 쉽지 않을 수도 있습니다.

이것은 주석이 발명 된 것입니다 . 그것을 써. 어셈블리조차 의견이 있습니다. 대량의 코드를 작성했지만 눈에 띄지 않는 의견이 있으면 걱정됩니다. 주석은 런타임 성능에 영향을 미치지 않지만 진행 상황에 대한 몇 가지 참고 사항이 항상 도움이됩니다.

제 생각에는 몇 가지 기본 의견이 없다는 변명이 없습니다. 분명히 if ( x == 0 ) /* check if x is 0 */전혀 쓸모가 없습니다. 코드에 불필요한 노이즈를 추가해서는 안되지만 다음과 같은 것이 좋습니다.

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

매우 도움이됩니다.

얼마나 효율적인 코드로 코드 가독성을 희생해야합니까?

효율성이 현재 목표 (최적화 단계에서와 같이)이고 알고 계신 경우 메트릭이 있습니까? -해당 코드 줄이 현재 병목 현상입니다.

그렇지 않으면, no : 가독성은 이해하기 쉽기 때문에 나중에이 코드를 변경하여보다 효율적으로 만들 수있게합니다.

아무도 코드 골프에서 이기지 못합니다

예 : 3 줄의 코드를 1 줄로

특히 끔찍한 아이디어.

코드 골프 비용-매우 높습니다.

읽을 수없는 프로그램을 유지하는 비용-천문학.

이러한 종류의 최소화 된 코드의 값은 0입니다. 여전히 작동하지만 "더 나은"작동하지 않습니다.

현명하게 선택된 효율성

적절한 알고리즘과 데이터 구조를 선택하는 비용-보통

올바른 알고리즘과 데이터 구조를 유지하기위한 비용-낮음

올바른 알고리즘과 데이터 구조의 가치-높음. 리소스 사용량이 적습니다.

어리석은 ( "미세 최적화") 효율성

마이크로 최적화를위한 비용-높음.

읽을 수없고 미세 최적화 된 코드를 유지하기위한 비용-매우 높습니다.

미세 최적화의 가치는 다릅니다. 여기에 0이 아닌 값이 있으면 비용이 여전히 중요합니다.

코드가 얼마나 빨리 실행되는지 또는 개발자가 코드를 얼마나 빨리 작성할 수 있는지에 대한 효율성에 대해 이야기하고 있는지에 달려 있습니다. 코드를 매우 빠르게 입력 할 수 있기 때문에 코드의 가독성을 희생하는 경우 디버깅 측면에서 시간을 절약 할 수 있습니다.

그러나 코드 실행 속도 측면에서 코드 가독성을 희생하는 것에 대해 이야기하는 경우 코드가 효율적인 방식으로 수행되어야하는 한, 이는 적절한 트레이드 오프 일 가능성이 높습니다. 성능이 핵심 인 빠른 역 제곱근 과 같은 것이기 때문에 가능한 한 빨리 실행되는 것을 작성하는 것은 거의 이유가 될 수 없습니다 . 비결은 코드의 균형을 맞추고 소스를 읽기 어려울 수 있지만 진행 상황을 설명하는 주석이 있는지 확인하는 것입니다.

컴파일러 가 매우 영리 해 지거나 ( 대부분의 개발자보다 영리하기도하다) 기계가 어리석게 빠졌기 때문에 코드를 더 빠르게 만들지 만 코드를 읽기 어려운 경향이있는 많은 트릭이 더 이상 필요하지 않습니다 .

나는 "가독성에 대한 가독성"주장을 받아들이지 않습니다. 다른 스핀으로 답을 드리겠습니다.

어떤 배경 : 당신은 나를 아프게하는 것을 알고 있습니까? 내 컴퓨터를 두 번 클릭하면 실제로 컴퓨터가 채워질 때까지 기다려야합니다. 5 초 이상 걸리면 정말 실망합니다. 어리석은 것은 마이크로 소프트를 비난하는 것이 아니라 어떤 경우에는 어떤 아이콘을 표시할지 결정해야한다는 것입니다. 맞습니다. 그래서 여기에 앉아 있습니다 .C : 드라이브로 이동하는 데 관심이 있으며 드라이버가 CD-ROM에 액세스하여 아이콘을 읽을 때까지 기다려야합니다 (드라이브에 CD가 있다고 가정).

승인. 내 컴퓨터를 두 번 클릭하고 실제로 드라이버를 통해 CD-ROM으로 말하는 사이의 모든 계층을 잠시 상상해보십시오. 이제 모든 레이어가 ... 더 빠르다고 상상해보십시오.

여러분은이 코드 뒤에 "더 읽기 쉬운"코드를 가지고 있기 때문에 1000 명의 행복한 프로그래머가 있습니다. 훌륭합니다. 나는 당신을 위해 행복 해요. 그러나 사용자의 관점에서 볼 때 그것은 단지 기술적 인 용어입니다. 따라서 밤에는 코드를 더 읽기 쉽고 느리게함으로써 올바른 일을했다고 자신에게 말하는 소리를 자게됩니다. 그것보다 약간 느리다. 따라서 수천 명의 개발자가이 작업을 수행하므로 사용자 때문에 PC를 기다리게됩니다. 내 의견으로는 당신은 가치가 없습니다. 나는 당신의 첫 줄이 최고가되어야한다고 말하지 않습니다.

내 접근 방식은 다음과 같습니다. 먼저 작동시키고 더 빠르게 만듭니다. 항상 효율적인 코드 작성을 목표로하고 가독성을 희생해야하는 경우 주석으로 보완하십시오. 나는 평범한 프로그래머가 그것을 유지할 수 있도록 효율성을 희생하지 않을 것입니다. 그러나 내 코드를 설명하지만 충분하지 않으면 죄송합니다. 여기서 일하는 것이 무능합니다. 여기서는 빠르고 읽기 쉬운 코드를 작성하기 때문에 균형이 있지만 읽을 수있는 코드는 설명 할 수 있지만 비 효율성은 용납 할 수 없습니다.

이 질문은 사무실에서 면담을 논의 할 때 자주 떠 오릅니다. 몇 년 전 졸업생으로서 "코드가 자기 문서화라고 생각하십니까?"라는 질문을 받았습니다. 이제 저는이 질문에 프로그래머로서 대답해야했고, 면접관에 관한 한 흑백 문제 였으므로 중간 근거가 없었습니다. 사람들이 활발하게 오가는 것 이상으로 프로세스가 개별적으로 오래 지속되어야하며 가능한 빨리 새로운 시작을 준비하고 코드를 쉽게 읽을 수있을수록 진행 상황을 더 빨리 이해할 수 있습니다.

나는 도메인 주도 개발 : 도메인 중심 설계 : 소프트웨어 중심의 태클 복잡성 이라는 꽤 좋은 책을 한동안 읽었습니다. 이것은 자신을 잘 문서화하는 시스템으로 이끄는 좋은 접근 방식을 보여줍니다. 언어는 솔루션을 전달하는 수단이므로 솔루션이 명확하게 표현 될수록 성능이 중요한 요소가 될 경우 더 쉽게 적응할 수 있습니다. 그것은 나의 믿음이고 그것은 나를 위해 잘 작동 한 것 같습니다.

가독성을 희생하면서 코드를 더 빠르게 실행시키는 ROI가 그다지 가치가 없습니다. 최신 컴퓨터는 너무 빨리 실행되므로 원하는 시나리오가 있을지 의심됩니다. 컴퓨터에서 코드를 실행중인 경우 해당 코드를 유지해야합니다.

이를 위해 가독성이 매우 중요합니다. 물론 여러 번 언급했듯이 코드를 읽을 수 있다고해서 속도가 느릴 필요는 없습니다.

좋은 예는 변수 이름입니다. $a

무엇입니까 $a?? 이것은 문맥에 맞지 않으므로 대답 할 수는 없지만 실제 코드 에서이 문제를 겪어 보셨습니까? 이제 누군가가 썼다고 가정합니다. $file_handle이제 무엇입니까? 상황에 관계없이 명확합니다. 변수 이름의 길이는 컴퓨터와 크게 다르지 않습니다.

나는 여기에 상식이 있다고 생각합니다.

일부 응용 프로그램은 모든 것이 이해하지 못하는 비트 시프트 단축키를 보증 할 수 있지만 어떤 시점에서는 수익이 감소하고 시나리오를 찾는 것이 거의 없다고 생각합니다.

* 이것은 산업과 다른 것들에 달려 있습니다. 비즈니스 소프트웨어 개발자 (Business Information Systems)의 관점에서 이것을보고 있습니다.

이것을 또 다른 관점에서 보려고 (그러나 엉망이 아닌) SAAS를 수행하는 회사에서 일합니다. 사이트가 다운 될 때, 우리는 사이트를 정말로, 정말 빨리 고쳐야합니다. 보통 다른 누군가가 다른 개발자의 코드를 고치고 있습니다.

나는 오히려 오히려 비효율적이지만 읽기 쉽고 무언가를 화려하고 "빠르게"만드는 것보다 훨씬 더 많은 일을 하고 싶습니다 . 우리의 웹 서버는 최첨단이며 백만 분의 1 초 안에 요청을 전달할 필요가 없습니다. 로드 문제가 없습니다.

실제로, 나는 당신이 당신 자신이나 다른 사람들을 해칠 가능성이 더 크다고 생각합니다 ...

대부분의 경우에 대한 대답은 "컴파일러가 작업을 수행하도록 신뢰"하고 읽을 수있는 코드를 작성하는 것입니다. 이는 코드가 논리적으로 구성되어 있고 (스파게티가 없음) 자체 문서화 (즉, 변수, 함수 등의 이름이 명확함)를 의미합니다. 의미있는 주석으로 자체 문서화되지 않은 보충 코드. 논평을 위해 언급하지 마십시오. 즉,

x++; // Add one to x

오히려 6 개월이나 12 개월 또는 충분히 긴 시간 안에 독자 여러분을 위해 의견을 말하십시오. 코딩 표준을 채택하고 따르십시오.

깨끗한 코드는 빠른 코드입니다. 명확하게 작성되고 유지 관리가 쉬운 코드는 프로그래머가 작업을 이해했음을 나타 내기 때문에 코드를 핵심 목적으로 리팩토링했기 때문에 속도가 더 빨라지는 경향이 있습니다.

또한 최신 컴파일러는 명령을 매우 효과적으로 최적화합니다. 어떤 코드 행을 입력하여 몇 가지 작업을 수행하고 컴파일러가 명령어와 관련하여 작성하는 것은 반드시 관련이있는 것은 아닙니다. 그 이유를 이해하려면 컴파일러를 읽으십시오.

그래픽과 같은 성능 기반 작업을 수행 할 때 작은 최적화가 큰 영향을 미칠 수있는 가장 깊은 중첩 알고리즘을 작업 할 때 이미지 처리와 같은 작업을 수행 할 때 가독성 / 유지성을 희생하기도합니다. 그런 다음에도 프로파일 링 후에 만 ​​변경 사항이 실제로 속도를 높일 수 있도록합니다 . 컴파일러가 손으로 입력 한 코드를 최적화하는 방식으로 인해 실제로 앱 속도가 느려지는 것을 발견하기 위해 수작업으로 코딩 된 '최적화'를 몇 번 시도했는지 말할 수 없습니다.

가독성은 무능하고 게으른 프로그래머에게는 변명입니다 (실제로 크 래피 알고리즘 / 디자인을 방어하기위한 주장으로 사용될 때 "단순성"에 동일하게 적용됨)!

주어진 모든 문제에 대해 최적의 솔루션을 위해 노력해야합니다! 오늘날 컴퓨터가 빠르다는 사실은 CPU 사이클을 낭비 할 이유가 아닙니다. 유일한 제약은 "전달 시간"이어야합니다. 여기서 "최적의 솔루션"이란 귀하가 제시 할 수있는 솔루션을 의미합니다 (모두 최선의 솔루션을 제시 할 수는 없으며 구현할 수있는 기술 / 지식을 보유하고 있음).

솔루션의 "이해하기 어려운"측면이 있다면 다른 누군가가 언급했듯이, 이것이 바로 주석입니다. 다른 사람이 언급 한 "정확하고 읽기 쉽고 빠른"순서 (또는 이와 유사한 것)는 시간 낭비입니다.

나는 프로그래머가 있다고 생각하기가 정말 힘들다. 문제가 생길 때 그들은 "... 이것은 반드시 이렇게해야하지만 덜 효율적이지만 더 읽기 쉬운 방법으로 만들 것이다. 유지 보수 및 기타 쓰레기 ... ". 이것의 오류는 다음 개발자 (비효율을보고)가 코드를 수정하고 다음 코드도 같은 방식으로 작동한다는 것입니다. 최종 결과는 몇 가지 버전 이후에 코드가 원본이 될 것입니다. 개발자는 1 위를 작성해야합니다. 최초 개발자의 유일한 변명은 다음과 같습니다. 그 (그녀는)를 충분히 생각하지 않았고 (충분히) 그리고 (앞서 언급했듯이) b. 시간 및 자원 제약.

가독성을 줄이면 코드 성능 / 최적화에 도움이되는 경우 ( swfobject 및 기타 js 라이브러리 에서 와 같이 ) 형식화되고 명확하게 읽을 수있는 코드를 계속 작성하고 "컴파일"/ 릴리스 프로세스의 일부로 읽을 수 없거나 최적화 된 코드로 변환해야합니다.