나는 최근에 다른 추상화 기술과 관련된 많은 질문을 발견했으며 기본적으로 해당 기술이 "너무 똑똑하다"고 대답했습니다. 프로그래머로서의 우리 업무 중 일부는 해결해야 할 문제에 대한 최상의 솔루션을 결정하는 것이며, 영리함이 그렇게하는 데 도움이된다고 생각합니다.

그래서 제 질문은 : 특정 추상화 기술이 영리 그 자체에 대해 너무 영리하다고 생각하는 사람들 입니까, 아니면 반대 이유가 있습니까?

편집 : 이 파서 결합기 는 영리한 코드로 간주되는 것의 예입니다. 나는 이것을 다운로드하고 약 30 분 동안 살펴 보았다. 그런 다음 종이에서 매크로 확장을 밟아 빛을 보았습니다. 이제는 Haskell 파서 결합기보다 훨씬 우아해 보입니다.

간단한 솔루션이 장기적인 유지 관리에 좋습니다. 항상 언어에 익숙하지는 않습니다. 복잡한 언어는 주어진 언어의 전문가라도 알아내는 데 시간이 걸립니다. 당신은 파일을 열고 읽기 시작합니다 : "좋아요, 간단하고 간단합니다, 그렇습니다, WTF ?!" 당신의 두뇌는 삐걱 거리는 소리에 멈춰서 이제 복잡한 줄을 멈추고 해독해야합니다. 해당 구현에 대해 측정 가능하고 구체적인 이유가없는 한 "너무 영리합니다".

복잡성이 영리한 방법에서 영리한 클래스로, 영리한 패턴으로 복잡 해짐에 따라 진행 상황을 파악하는 것이 점점 어려워집니다. 잘 알려진 접근법 외에도 "영리한"솔루션을 만드는 데 필요한 사고 과정을 파악해야합니다. 이는 매우 어려울 수 있습니다.

즉, 누군가가 패턴을 이해하지 못하기 때문에 패턴의 사용이 정당화되는 것을 싫어합니다. 학습을 계속하는 것은 개발자의 책임이며 우리가 무언가를 이해하지 못하면 그것을 피하는 것이 아니라 배우는 이유입니다.

키스 원리

간단하고 바보처럼 유지하십시오. 영리한 솔루션은 훌륭하지만 종종 가장 간단한 솔루션이 가장 좋습니다.

“디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 코드를 가능한 한 영리하게 작성하면 정의에 따라 코드를 디버깅 할만큼 똑똑하지 못합니다.”

브라이언 커니 건

바보는 복잡성을 무시합니다. 실용 주의자들은 그것을 겪는다. 전문가들은 그것을 피합니다. 천재가 그것을 제거합니다. -앨런 펄리스

최상의 솔루션이 항상 가장 영리한 솔루션은 아닙니다. 때로는 간단한 해결책도 똑같이 좋습니다.

소프트웨어에서는 항상 유지 관리 측면에서 생각해야합니다. 코드 조각을 유지하려는 사람에게 너무 영리한 코드라면 영리함이 가치가 없다고 말할 수 있습니다.

Brian Kernighan을 인용하려면 :

“디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 코드를 가능한 한 영리하게 작성하면 정의에 따라 코드를 디버깅 할만큼 똑똑하지 못합니다.”

영리함은 도구입니다. 그 자체로는 해롭지 않습니다. 필요하지 않은 상황에서만 해 롭습니다.

코드에 적용 할 때 "Clever"는 거의 항상 "필수없이 복잡한"이라는 완곡 어입니다.

훌륭하고 명확하며 간단한 코드를 읽는 것은 어렵습니다. "영리한"코드를 읽는 것은 라틴시를 다시 한 번 공부하는 것과 같습니다.

사람의 속성 인 "영리한"은 완전히 다른 의미를 갖기 때문에 혼란이 발생합니다. 이 사례는 실제 사람들을위한 소프트웨어를 설계하는 것이 어려운 이유의 예라고 볼 수도 있습니다. 모호하기 때문입니다.

그리고 일부 프로그래머들은 대부분의 사람들이 따르는 사회적 프로토콜을 이해하기 어렵 기 때문에 코드를 "불필요하게 복잡한"것으로 직접 비난하는 것을 금하기 때문에 영리한 단어의 두 가지 의미를 구별하기가 어려울 수 있습니다 . 일부 사람들이 생각하는 것과는 달리, 궁극적으로 더 나은 "사람들"(즉, 공감과 내성, 인내심이있는 사람들)은 더 나은 개발자를 만든다고 생각합니다. 그들은 누구를 써야하는지 알고 있기 때문에.

대부분의 사람들은 "코드가 무엇을하고 있는지 알아 내기에는 너무 많은 해독이 필요하다"라는 측면과

1. 그것을 유지 / 디버깅하는 것 외에는 아무도 그것을 알아낼 수 없습니다.
2. 쓴 사람은 그것이 무엇을하는지조차 모릅니다.
3. 실제로 시작하는 것이 전부가 아닐 수도 있습니다
4. 기타....

모든 좋은 점이지만, 영리함의 또 다른 부정적인 측면이 있으며 그것은 오래된 자아 문제입니다. 이것은 라인을 따라 문제를 일으킨다.

1. 다른 사람의 솔루션을 사용하기에는 너무 똑똑한 사람. 같은 고양이를 자신 만의 방식으로 만들 수있는 방법으로 다른 사람들이 한 일을 찾으십시오.
2. 자신이 문제에 대한 가장 멋진 해결책을 고안했다고 생각하는 사람은 종종 의견을 수렴하지 않을 것입니다.
3. 명백한 문제가 있거나 사소한 변경이 필요한 경우에도 "자신의"코드를 수정하도록 허용하지 않습니다.
4. 반대로, 그들은 영리하다고 생각하고 "최신"기술을 사용하여 자신들이 얼마나 영리한지를 입증해야하지만 개인 프로젝트 나 그렇지 않은 코드에서 중요한 부분으로 넘어 가기 전에이를 잘 처리하지 못합니다. 시스템.

우리는 때때로 너무 많은 자존심에 유죄를 선고 받지만 팀을 방해 할 때 문제가됩니다.

Good Clever-영리한 코드 라인과 비영리 한 대안 라인의 비율이 높습니다. 20000을 작성하는 데 도움이되는 20 줄의 코드는 매우 우수합니다. 좋은 영리한 일은 자신을 구하는 일입니다.

Bad Clever-작성된 코드 라인과 코드 라인 간 비율이 낮습니다. 5 줄의 코드를 작성하지 않아도되는 한 줄의 영리한 코드는 Bad Clever입니다. 나쁜 영리는 "구문 자위"에 관한 것입니다.

참고 : 나쁜 영리한 사람은 거의 "나쁜 영리한 사람"이라고 불리지 않습니다. 그것은 종종 "아름다운", "우아한", "간결한"또는 "간결한"이라는 별칭으로 여행 할 것입니다.

모든 사람의 영리한 정의가 궁금합니다.

개인적으로, 나는 어렵고 복잡한 문제를 겪었을 때 매우 영리한 것처럼 느껴지고 수용 가능한 수준의 효율성을 유지하면서 매우 간단하고 직접적인 방법으로 구현했습니다.

tl; dr 코드 검토 중에 리뷰어가 "와우, 그것이 생각했던 것보다 쉬웠습니다."라고 말하면 "wtf는이 모든 것"입니다.

나열된 이론 답변 외에도 종종 이것은 다른 모든 사람들에게 너무 영리한 상황에서 사용됩니다.

최고 수준의 성능 집약적 팀과 중간 수준의 유지 보수 팀 사이를 이동하여 "너무 영리한"내용의 실제 차이점을 확인하십시오.

이론적 논증을 제외하고, 너무 영리한 것은 종종 가장 숙련 된 팀원이 합리적으로 작업 할 수있는 것에 근거하기 때문에 환경과 매우 관련이 있습니다.

때때로 나는 너무 영리해서 내가 틀렸다.

솔루션을 측정하는 방법은 성능, 유지 관리 가능,시기 적절하고 저렴한 것입니다. 영리한 것이 그 특성에 부정적인 영향을 미치지 않는 한 해결책의 일부가 될 수 있다고 생각합니다.

영리한 코드 + 이해할 수있는 코드 <= 간단한 코드를 만드는 데 필요한 주석의 양이면 영리한 코드로 가십시오. 매번

"영리한 코드"를 작성하는 사람들이 의도적으로 코드를 제대로 작성하지 못하는 경우 문제가 발생한다고 생각합니다. 처음에는 이해할 수 없기 때문에 앞으로 오는 세대가 얼마나 영리한지 "감사"하는 데 시간을 소비해야하기 때문입니다.

좋은 인용구가 종종있는 것처럼, 내가 본 다른 인용문에 대한 인용구가 떠 오릅니다.

말을 바꾸려면 :

모든 똑똑한 사람은 단순한 복합물을 만들 수 있으며, 복합물을 단순하게 만드는 데 천재가 필요합니다.

복잡한 아이디어를 이해하고 이해하기 쉽게 단순화하면 생성자의 영리함을 알 수 있지만 간단한 아이디어를 취하고 복잡하게 만드는 것은 생성자가 영리한 것으로 보이기를 원합니다.

'영리한'솔루션을 파악하기 어려운 경우 사용해서는 안됩니다. 예를 들어 부작용을 통해 복잡한 계산을 한 줄로 축소 할 수 있다면 영리합니다. 그러나 다른 사람이 세상에서 무엇을했는지 알아내는 데 1 시간이 걸리면 너무 영리합니다.

제 생각에는 영리 그 자체는 문제가되지 않습니다. 일반적으로 "영리한"(sarcasm없이) 및 "inightfull"코드를 혼동 할 수 있습니다. 내가 문제로 생각하는 것은 일반적으로 "영리한"(sarcasm 포함) 코드에 암시적인 보이지 않는 요구 사항이 포함되어 있기 때문에 시간이 지남에 따라 디버그 및 유지 관리가 더 어렵다는 것입니다.

영리한 몇 가지 알려진 알고리즘이 있습니다. Quicksort 는 IMO 중 하나입니다.

"영리한"(sarcasm 포함) 코드는 일반적으로 설정중인 변수와 "영리한"코드와 실제로 연결이 끊어진 시스템 상태 (이전에 열린 파일, 네트워크 연결, 데이터베이스 등)에 대해 가정합니다.

"영리한"코드를 올바르게 유지하기 위해 두뇌에로드해야하는 데이터의 양은 일반적으로 큰 편익 비를 갖기 위해 크다.

"영리한 코드"는 프로그래머가 정말 열심히 생각하거나 고급 기술을 사용하여 작성해야하는 코드입니다. 이 문제는 Brian W. Kernighan이 가장 잘 표현한 특정 "영리한 마진"에 대한 필요성을 무시합니다.

"디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 코드를 최대한 영리하게 작성하면 정의에 따라 디버그하기에 충분히 똑똑하지 않습니다."

어떻게 생겼는지 때문에 영리 창조성의 버스트의 개발자에게 간단하게 전달할 수있는 혼란 과 단지가 될 읽을 수없는 , 이상 유지할 블록 모호한 수수께끼 다른 사람을 위해.

그래도 훌륭하고 영리하며 성능이 좋은 수수께끼 블록이지만 경험이 있다면 매체를 유지하는 데 비즈니스 비용 (개발자 아님)이 훨씬 더 많이들 것이라는 사실을 종종 알게 될 것입니다. 또는 장기. 따라서 동료 개발자의 열망을 진정시키는 것을 선호합니다.

물론 영리함에 대한 정당성이 있다면 예외입니다. 그리고 당신이 방금 쓴 난독 한 것과 함께 제공되는 좋은 문서가 있다면. 그 영리한 코드 조각에 대해 언급 했습니까? 의도, 왜 그런지, 어떻게 행동해야하는지 설명하십시오.

정당성이 없다면, 아마도 조기 최적화, 과도 엔지니어링 또는 YAGNI 종류의 문제 일 것입니다. 간단한 일을하기 위해 15 단계의 간접적 인 지시가 필요하다면, 이전 범주에도 속할 가능성이 높습니다. 문서화되어 있지 않으면 문제 일뿐입니다.

훌륭한 코드는 관리자가 항상 그것을 이해하기 위해 100 %에 있어야 할 필요는 없습니다. 좋은 코드는 영리합니다. 훌륭한 코드는 거의 효율적일 수 있지만 다른 여러 측면에서는 더 좋습니다. 훌륭한 코드는 애플리케이션 디자인을 따르기 위해 15 개의 뷰가있는 IDE가 필요하지 않습니다.

참고 : 이봐, 나는 영리하다고 생각하지만 WTF를 이끌어 낸 몇 가지 물건을 썼습니까? -공동 개발자가 아닌 경우-관리자의 입에서. 그들의 관점에서 그것을 봐야합니다.

나는 경향이 영리 ,하지만 난 할 노력하고 우아한 .

코드를 개발 이제 다른 사람들이 시도하고 피할 것을 나중에 .

이것은 내 경험과 다른 답변을 바탕으로 문제에 대한 나의 이해입니다.

1. 작성하는 데 영리하지만 읽기 쉽고 유지 보수가 가능한 코드는 유해한 것으로 간주되지 않습니다. 그러나 대부분의 개발자는 이러한 종류의 코드를 "영리한"것으로 부르지 않습니다. 그들은 "우아한"과 같은 다른 용어를 사용할 수 있습니다. 그러한 코드가 존재하는지에 대한 논쟁이있을 수도 있고 없을 수도 있습니다.
2. 언어에 익숙한 노련한 개발자라도 이해하기 위해 상당한 시간과 노력이 필요한 생산 코드는 "영리한"것이며 모든 사람에게 해로울 수 있습니다.
3. 경험이없는 개발자가 상당한 시간과 노력을 요구하는 생산 코드는 일부 사람들에게 유해한 것으로 간주됩니다. 나는 어느 쪽이든 대답을 보았고 모든 것을 "최소 공통 분모"로 유지하는 것을 선호한다고 명시 적으로 말한 개발자와 함께 일했습니다.

나는 남자를 안다. 그는 내가 만난 가장 훌륭한 사람 일 것이다. 그는 확실히 믿을 수없는 코더입니다. 아마도 평범한 프로그래밍 절단 측면에서 평생보다 더 좋을 것입니다. 그는 단어 문서를 입력하는 것처럼 코드를 작성하며 사용자가 믿지 않는 것처럼 연결된 목록을 되돌릴 수 있습니다. 매우 복잡한 코드를 작성하는 것에 대해 이야기하고 싶다면, 그는 당신의 남자입니다. 그러나 팀 환경에서 그와 함께 프로젝트를 진행하는 것은 매우 흥미 롭습니다. 그는 비즈니스 문제를 직접 목표로 삼고 논리적이고 효율적이며 간결한 솔루션을 제공 할 수 없습니다. 그에게 1000 줄의 코드 목록은 100보다 낫습니다. IDE 또는 프레임 워크를 통해 제공되는 도구를 사용하는 대신 자신의 초 최적화 된 도구를 사용할 것입니다.

이 복잡한 일을 할 수있는 그의 능력에 감탄하는 동안, 내가 필요한 것은 문제를 해결하고 발전 할 수있는 사람입니다. 말하거나 인정하는 것은 좋지 않지만 때로는 사업 환경에서 모든 것이 문제이며 문제를 해결하고 인생을 살아야합니다. 나중에 다시 돌아와서 지옥을 리팩토링하여 향상시킬 수 있습니다. 귀하의 코드. 영리한 사람과 엉덩이의 고통 사이에는 훌륭한 선이 있습니다. 우리 팀의 모토는 항상,이 상황에서 작동하고 거기에서 갈 수있는 가장 간단한 것입니다. 때로는 단순한 것이 항상 답이 아니라 시작하기에 좋은 곳입니다.

이러한 맥락에서 "영리한"은 "자신의 이익을 위해 너무 영리하다", 즉 지금은 작동하지만 나중에 이해하고 변화시키는 악몽이 될 것임을 의미합니다.

특히 프로그래밍 언어의 모호한 기능을 악용하거나 이상한 부작용을 사용하거나 대상 언어의 문제를 해결하는 기괴한 방법 인 경우 트릭입니다.

나는 간단한 솔루션을 선호하고, 루비 방식을 정말로 좋아합니다. 예를 들어 목록에서 처음 두 요소를 합산하려는 경우. 먼저 목록을 잘라서 크기 = 2가되도록 한 다음 합산하십시오.

일단 3 대신 1 목록을 사용하고 유지 관리 / 변경하기가 매우 어려운 하나의 큰 기능을 만들었 음을 기억합니다.

오늘날의 세계에서 우리는 성능을 위해 코드 명확성을 희생 할 필요가 없습니다 (c ++을 제외하고는 필요하지 않지만 그렇게 할 것입니다).

일반적으로 코드에서 문제를 해결하기 위해 '영리한'일 필요가있을 때. 해결 방법이 매우 간단하지 않은 경우 특정 조건을 가정 할 때 혼란 스 러운 얼굴이 많거나 다른 경우 이상한 부작용이 발생합니다 (코드 작성시 100 % 정확할 수 있음)

따라서 영리한 == 혼란스러운 == bad :( 그러나 제한된 문제에 대한 실용적인 솔루션으로 사용했을 때도 훌륭합니다.

맥락과 이해를 돕기 위해 다시 인용 :

"디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 코드를 최대한 영리하게 작성하면 정의에 따라 디버그하기에 충분히 똑똑하지 않습니다."

브라이언 케르 니건이 여기에 썼던 것은 분명히 컨볼 루션과 관련이 있으며 그는 실수로 영리한 단어를 사용했습니다.

"디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 코드를 가능한 한 [복잡하게] 작성하면 정의에 따르면 디버그하기에 충분히 똑똑하지 않습니다."

회선:

A thing that is complex and difficult to follow.

영리한:

Showing intelligence or skill; ingenious

교육을받은 프로그래머는 간단한 코드가 독창적이라는 것을 알고 있습니다. 가능한 영리한 코드는 정의상 단순해야합니다. 교육을받은 프로그래머는 전염병과 같은 복잡한 코드로 작업하거나 작성하지 않아도됩니다. 또한 기회가있을 때마다 복잡한 코드를 영리한 코드로 바꿉니다. 코드는 일반적으로 복잡하게 시작되고 프로그래밍에 대한 인간의인지 능력에 대한 이해와 영역에 대한 지식이 경험과 공유 된 지식을 통해 더 잘 이해되므로 영리하게 접근합니다.

이 인용의 인기와 Brian Kernighan이 업계에서 꽤 인기가 있기 때문에이 단어의 오용은 사회적으로 부정적인 영향을 미치며 솔직히 그 사람이 해결 한 것을보고 싶습니다. 이 기사를 작성하기 전에 간단히 전자 메일을 보낼 수 있는지 확인하려고했지만 이해했던 전자 메일 연락처 정보를 찾을 수 없었습니다.

내가 본 부정적인 사회적 영향은 이제 더 영리한 동료를 괴롭히는 다른 프로그래머들입니다. 그들은 이제 영리함을 문제로보고 있기 때문입니다. 실제 문제는 새로운 일관적인 방식으로 일을함으로써 영리하다고 생각하고 더 큰 공동체를 이해하고 영리한 아이디어를 최대한 재사용하는 대신 이점이 없을 때 끊임없이 새로운 것을 발명하는 바보 같은 동료입니다.

나는 종종 자신의 것을 발명하는 것보다 이해를 얻는 것이 더 어렵다는 것을 분명히해야합니다 . 비현실적인 마감일에 대한 업계의 일반적인 문제로 인해 작은 틈새 문제에 대한 자신의 발명은 시간을 절약하는 데 사용됩니다. 이것은 유용하고 재사용 가능한 것들이 일반적으로 더 큰 틈새 시장을 대상으로하거나 발명에 유용한 추상화를 제공한다는 관찰에 근거합니다. 또한 사람들이 더 큰 돈을 벌기 위해 큰 틈새 시장을 목표로 삼는다 는 사실 에 근거하고 있습니다. 이는 종종 광범위한 응용 분야에 사용할 수있는 복잡성으로 인해 도구를 사용하기가 매우 어려워집니다.

또 다른 부정적인 사회적 영향은 이것이 우리의 자아 중심 세계에서 우리 자신의 이해 부족을 즉시 거부하고 일단 이해되면 아이디어가 실제로 이해 되더라도 복잡한 코드를 작성하기 때문에 진보와 이해하려는 욕구를 방지한다는 것입니다 아주 영리합니다.

TODO 참고 자료를 인용하고 싶지만 정보 공유 능력을 방해하지 않는 참고 자료가 부족하므로 정보의 출처로 기억하는 내용을 빠르게 인용하고 실제 정보를 찾을 수 있습니다. 하루 (또는 당신은 나를 위해 그것을 찾을 수 있습니다! :)

• Guido Van Rossum의 이벤트 루프 및 이벤트 루프에 대한 이야기
• Y-Combinator에서 영리한 사람들을 고용하지 말라고 언급 한 GitHub 직원
• 파이썬 커뮤니티에서 진행되는 많은 토론과 학습. 파이썬 커뮤니티는 특히 새로운 아이디어에 대해 비판적이지만 이해하지 못하는 새로운 아이디어를 무시하지 않으며, 일반적으로 처음에는 복잡한 것으로 보였던 기능을 핵심 언어 기능 / 패키지로 볼 수 있습니다.
• 내 10000 발 관찰을 기반으로 한 내 자신의 경험과 전문적인 의견. 나는 실제로 모든 것을 깨달을 수있는 구체적인 내용을 볼 수는 없습니다.

자신의 인용을 자유롭게 추가하십시오! 또한 내 텍스트에 쉼표를 자유롭게 추가하십시오. 꽤 오랫동안 영어로 쉼표 사용법에 대한 지식을 새로 고치지 않았습니다 ...

사람들은 종종 언어, 숙어 및 패턴을 모르기 때문에. 그들은 책을 가져 가서 배울 수는 있지만 배울 수는 없습니다. 그리고 그러한 사람들 때문에 간단한 코드를 작성해야합니다.

영리하지 않습니다. 지식입니다.

여기 어디에서나 언급 된 징계라는 단어를 찾을 수 없었기 때문에 칩을 넣을 것입니다. 답변 을 게시 하고 싶지는 않지만 문제에 대한 다른 통찰력을 공유하려고합니다. .

영리한 개발자가 좋습니다.

그러나 영리하기 전에 다른 특성이 있습니다. 당신은 내가 징계 에 대해 이야기 할 것임을 깨달았을 것입니다 . 영리하고 훈련되지 않은 개발자는 시스템의 장기적인 유지 관리 능력이 매우 나쁠 수 있습니다.

버그가 발생하거나 새로운 요구 사항이 발생한다고 가정 해 봅시다. 영리한 개발자가 곧 로컬 수정 몇 가지로 2 분 안에 작업이 완료 될 것임을 알 수 있습니다. 해당 개발자가 훈련을 받으면 해당 수정 사항을 소스 코드에 적용하지 말고 대신 시스템에 원하는 동작을 구성 할 수있는 의미있는 방법을 찾으십시오. 이렇게하면 다음에 특정 코드 조각을 수정해야 할 때 관리자는 코드를 이해하고 아무 것도 훼손하지 않고 새로운 변경 사항을 쉽게 구현할 수 있습니다. 그렇지 않다면, 당신은 잘 그림을 얻는다.