"영리한"코드 작성을 피하기 위해 자신을 훈련시키는 방법? [닫은]

새로운 트릭을 보여 주거나 세 가지 다른 절차를 일반화 해야 할 때의 느낌을 알고 Expression있습니까? 이것은 아키텍처 우주 비행사 규모에있을 필요는 없으며 실제로 도움이 될 수는 있지만 다른 사람이 같은 클래스 또는 패키지를보다 명확하고 간단하고 때로는 지루한 방식으로 구현할 수는 있습니다.

나는 종종 고의적으로 그리고 때로는 지루함 에서 문제 를 극복함으로써 프로그램을 설계하는 것을 알아 차렸다 . 어느 쪽이든, 나는 정직하게 내 증거가 보일 때까지 내 솔루션이 명확하고 우아하다고 생각하지만 일반적으로 너무 늦습니다. 코드 중복과 단순성에 대한 영리함을 문서화하지 않은 가정을 선호하는 저도 있습니다.

내가 뭘 할 수있는 "cleverish"코드를 작성하는 충동을 저항 할 때 벨 링을해야한다고 나는 그것은 잘못하고 있어요 ?

경험이 풍부한 개발자 팀과 함께 일하면서 문제가 더욱 심화되고 있으며 때로는 스마트 코드를 작성하려는 시도가 시간이 지나도 나에게 어리석은 것처럼 보입니다.

경험이 풍부한 개발자 팀과 함께 일하면서 문제가 더욱 심화되고 있으며 때로는 스마트 코드를 작성하려는 시도가 시간이 지나도 나에게 어리석은 것처럼 보입니다.

당신의 해결책은 여기에 있습니다. 이 맥락에서 "경험이있다"는 것은 "당신보다 경험이 많다"는 것을 의미합니다. 최소한, 당신은 그것들을 분명히 존중합니다. 자아가 타격을받을 수 있다고 가정 할 때 이것은 귀중한 학습 기회입니다. (사악한 일, 자아. 우리가 필요로하는 것이 유감입니다.)

이 사람들과 코드 리뷰가 있습니까? 그렇다면, 아직 그렇게하지 않는 경우, 헛소리를하도록 명시 적으로 요청하십시오. 간단한 클로 망치로 충분할 때 세 심하게 디자인 된 최고급 공압 잭 해머 (일부 자동화 된 도로 작업자 안드로이드가 사용)를 사용하는 경향이 있음을 언급했습니다. .

코드를 검토하는 동안 얼굴이 빨갛게 변하는 동안 종종 좌석에서 몸이 엉망이 될 수 있습니다. 참아 당신은 배우고 있습니다.

그런 다음 벨트 아래에이 중 몇 개가 있으면 과도하게 디자인 된 것으로 의심되는 순간에주의를 기울이십시오. 그 순간이 오면 스스로에게 물어보십시오. "코드 검토 중에 누군가가이 문제를 불러 내면 가능한 한 최상의 솔루션으로 내 솔루션을 변호 할 수 있습니까? 아니면 더 간단한 솔루션이 있습니까?"

때로는 동료 검토가 자신의 작업을 잘 볼 수있는 가장 좋은 방법입니다.

최선의 방법은 Brian Kernighan의 최대 값을 명심하는 것입니다.

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

일반적으로 의미가있는 소프트웨어 문제에 대한 최소한 3 가지 해결책이 있습니다 : 명백한 방법, 명백하지 않은 복잡한 방법 (영리한 방법) 및 명백하지 않은 간단한 방법 (우아한 방법). 저자에 대한 인용문은 여기에 적용됩니다 :

머리에 나오는 모든 것을 내려 놓으면 작가가됩니다. 그러나 저자는 동정없이 자신의 물건의 가치를 판단하고 대부분을 파괴 할 수있는 사람입니다. — 콜렛

동정없이 자신의 코드 가치를 판단하고 대부분을 파괴 할 때까지 우아한 코드를 작성할 수 없습니다. 최종 결과로 우아한 코드를 판단하는 경우 매우 쉬운 것처럼 보이지만 속도를 늦추고 많은 초안을 살펴보고 다른 사람들의 조언을 구하고 페이지에 맞지 않는 내용을 소비해야합니다. 즉, 코드가 완벽하게 작동하더라도 자신이나 동료에게 왜 대답이 만족스럽지 않은지 왜 뭔가 잘못된 느낌이 드는지 묻습니다. 어쩌면 너무 길거나 반복적으로 느껴지거나 컴파일러가 특정 종류의 버그를 잡을 수 있어야한다고 생각합니다. 경험이 많은 대부분의 프로그래머 는 우아한 코드를 쉽게 인식 할 수 있습니다. 비결은 이유를 알아내는 것 입니다.

더 우아한 코드를 작성하는 방법론적인 방법입니다. 또한 새로운 방식으로 문제를 보는 데 도움이되는 통찰력이 필요합니다. 이것은 달성하기가 더 어렵지만 코딩에 들어가기 전에 속도를 늦추고 문제를 생각하는 데 도움이됩니다. 좋은 해결책을 찾으면 더 좋은 해결책을 찾으십시오. 다른 코드를 읽으면 도움이됩니다. 모범 사례에 대한 수업을 받거나 책을 읽는 것이 도움이됩니다. 다른 프로그래밍 패러다임을 배우면 도움이됩니다. 자신이 좋아하는 코드를 가진 동료에게 조언을 구하십시오.

기존 답변에 추가하고 TDD 방식으로 개발하므로 먼저 코드의 기능에 대한 테스트를 작성한 다음 테스트를 친환경으로 만들기 위해 구현하십시오. 이렇게하면 테스트에서 요구하는 요구 사항 만 충족하게됩니다. 테스트를 작성할 것이기 때문에, 스스로 훈련 된 접근 방식을 개발하는 좋은 방법입니다.

여러 기술과 수년에 걸친 대규모의 역동적 인 팀에서 근무할 때, 개발은 현재 또는 과거에 가장 보수적이거나 가장 지적 능력이 부족한 팀원 중 가장 낮은 수준으로 "진보"하는 자연스러운 진보를 겪습니다.

영리한 코드는 디버깅하기 어렵고 기술 사양에서는 전달하기가 어렵고 작성 시간이 길어 개발 시간이 느려질 수 있기 때문에 반드시 나쁜 것은 아닙니다.

영리한 코드가 성능이 요구 사항이 될 때 소프트웨어의 성숙주기에서 나중에 효율성과 성능 향상을 제공하는 경우와 같이 영리한 코드가 중요한 경우가 있습니다.

영리한 코드는 새로운 언어 기능이나 라이브러리 호출에 노출되지 않을 수있는 팀에보다 신속하게 개발하고 더 읽기 쉽고 이해하기 쉬운 코드를 전달하는 방법도 있습니다. 예를 들어, 주니어 개발자가 Linq를 처음 소개했을 때 필자는 불필요하고 디버그하기 어리 석고 "영리한"것으로 즉각 혐오감을 나타 냈습니다. 직접 사용 해보고 Linq 쿼리가 얼마나 유용하고 강력한 지 알아 낸 후에는 배우는 데 시간을 투자했으며 DAL 코드는 더 깨끗하고 읽기 쉬웠으며 디버그 및 확장이 더 쉬웠습니다.

나는 열린 마음을 가지지 않은 것을 후회하며 그런 "영리한"하급 개발자에게 그렇게 가혹하지 않았 으면 좋겠다.

필자의 요점은 "영리한"코드가 의심 스럽다는 점이지만 창의성과 혁신을 저해 할 수 있기 때문에 이에 대한 성전을 계속해서는 안된다.

편집 : 나는 당신의 질문에 완전히 대답하지 않았다는 것을 깨달았습니다. 프로젝트에서 영리한 코드를 매우 쉽게 작성할 수있는 능력이 있다면 팀은보다 엄격한 코딩 표준을 채택하여 균일하고 뚜렷한 템플릿과 스타일을 따라야합니다. 이렇게하면 샌드 박스의 선을 그려서 공을 쫓는 거리로 방황하지 않아도됩니다.

추가 된 라인의 20 % (%가 다를 수 있음) 이상을 문서화해야하는 경우에는 물러서서 다시 생각해야 합니다.

나는 당신이 영리 해지기 위해 노력해야한다고 생각합니다. 그것은 더 능숙 해지는 자연스러운 부작용입니다. 자신을 명확하게하는 데 필요한 의견의 %와 같은 일반적인 지침을 제공하는 것은 배운 새로운 것을 사용하는 것이 현명한 선택인지 아니면 새로운 장난감을 과시 할 수있는 방법인지를 스스로 판단하고 평가하는 좋은 방법입니다.

나는 영리한 것을 시도하는 것을 거부 할 수 없다.

그래서 나는 집에서 장난감 프로젝트, 내 자신의 시간에 그것을합니다.

참신이 사라지면 문제가 해결됩니다.

코드가 너무 "영리한지"확인하는 한 가지 방법은 한 걸음 물러서서 다음과 같이 자문 해 보는 것입니다.

이 프로젝트 / 코드를 작업 한 적이없는 사람 에게이 코드를 출력하려면 코드를 읽고 기능이 무엇인지 설명해 줄 수 있습니까 (약간의 컨텍스트를 제공 한 후)? 그렇지 않다면 얼마나 설명해야합니까? CS101을 복용하는 사람에게 이것을 어떻게 설명 할 수 있습니까?

메소드 또는 클래스의 모든 라인 또는 대부분의 라인을 통해 누군가를 걸어야한다는 것이 밝혀지면 아마도 너무 영리 할 것입니다. 익숙하지 않은 사람에게 언어 구성 (예 : LINQ)을 설명해야한다면 괜찮을 것입니다. 설명을하기 전에 한 줄을보고 조금 생각해야한다면 코드를 리팩터링해야합니다.

1) 불에 타서 나쁜 일임을 알게하십시오. 오래 전에 영리하게 쓰여진 무언가를 디버깅하는 것은 큰 즐거움입니다. 나는 당신이 그것을 커버했다고 생각합니다.
2) 코드에 주석을 달고 코드의 각 섹션 전에 수행중인 작업을 설명하십시오.
3) 설명하기 위해 고군분투하거나 다이어그램을 삽입해야 할 필요성을 느낀다면 방금 수행 한 작업이 너무 영리하고 더 깨끗하게 수행 될 수 있습니다.

디버깅하거나 확장해야 할 때까지 문제에 대한 영리한 솔루션은 환상적 일 수 있습니다. 때로는 유일한 솔루션입니다. 도대체 무엇을하고 어떻게 하는지를 정확하게 설명 할 수 있다면 영리한 해결책을 받아 들일 수 있습니다.

나는 보통 코드 섹션으로 무엇을하고 있는지 설명하기 위해 주석을 사용한다. 그것이 가장 혼란스러워 보인다면, 나는 그것을 어떻게하고 있는지 설명합니다. 이상적으로 코드는 직설적이고 자명해야합니다. 그러나 방금 내가 한 일을 설명하는 데 어려움을 겪고 있다면 물러서서 다시 시도해야한다는 분명한 신호입니다.

아마도 간단한 코드 작성을 시작하는 좋은 방법은 영리함을 요구 하는 프로젝트에서 영리한 열정 을 풀어내는 것 입니다. 나머지 답변은 .NET에만 해당되지만 다른 언어로 비슷한 수준의 프로젝트를 찾을 수 있다고 확신합니다.

있습니다 오픈 소스 의존성 주입 프레임 워크 단지를 요청하는 작업 Expression트릭 지식이,이 F 번호 하나가 그것을 시도 할 수 있습니다 작업의 훌륭한 범위.

당신은 수학에있어 (그리고 그 경우 언어 무신론자 ),이 프로젝트 오일러 당신을 위해.

마지막으로, .NET 세계에는 개발자의 관심이 필요한 많은 영역을 가진 Mono Project 가 있으며 그중 일부는 매우 복잡합니다. 오픈 소스 정적 .NET 코드 분석기 도구 에 기여하는 것은 어떻습니까? 일부 IL 분석과 고급 기능이 있습니다. Jb Evain 은 Cecil 리플렉션 라이브러리, 지원 또는 .NET 디 컴파일러에 관계없이 항상 흥미로운 작업을 수행합니다 .Expression

아무 것도 맞지 않으면, 자신의 조롱 프레임 워크를 시작하십시오 :-)

Expressions로 새로운 트릭을 보여 주거나 세 가지 다른 절차를 일반화해야 할 때의 느낌을 알고 있습니까?

아니

이것이 내가 새로운 개발자가 문서화되지 않은 speghetti 코드를 유지하고 리팩토링하는 큰 혼란에 빠질 때 항상 좋은 말을하는 이유 중 하나입니다. 그것은 그들이 작성하지 않은 지나치게 '영리한'코드를 유지하는 현실을 가르쳐 줄 것이며, 앞으로 5 년 후에 코드를 디버깅해야하는 빈약 한 schmuck에게 공감을 심어줄 것입니다.

주제가 잘 선택되었다고 생각합니다. 한 번에 10 만 개의 작업을 수행하는 Perl 라인을 작성하는 것은 "멋지다". 그러나 다시 방문해야 할 때 짜증 난다.

영리한지 아닌지에 관계없이 코드를 문서화해야합니다. 업계에서 수용되는 프로그래밍 언어와 인간으로서 우리가 생각하는 데 익숙한 고급 개념 간에는 고유 한 임피던스 불일치가 있습니다. 자체 문서화 코드는 자연어가 될 때까지 실현할 수 없습니다. 비록 높은 수준 일지라도 여전히 공식적인 코드이므로 프롤로그 코드조차 문서화되어야합니다.

세분화 된 명령형 코드는 문서화해야하는 굵은 세분화 된 계획을 구현하는 데 사용됩니다. 빠른 3 줄 로드맵 주석이있을 때 50 줄의 방법을 모두 읽고 싶지는 않습니다.

나중에 편집 : 더 웅변적인 예는 컴퓨터를 초월하는 것입니다. 책은 아주 잘 쓰여졌지만 종종 다른 수준의 추상화로 처리하려고합니다. 종종, 책의 요약이 할 것인데, 그것이 주석이 코딩에 제공 할 수있는 것입니다. 물론 잘 추상화 된 코드는 자체 문서화를 향한 먼 길을 갈 수 있지만 모든 수준의 추상화를 제공 할 수는 없습니다.

또한 주석은 책에서 탈선하지 않고 주장의 배후에있는 추론 과정을 설명해야 할 때 책에서 주석처럼 작용할 수 있습니다.

이러한 맥락에서, 나는 의견의 필요성을 초월하는 자연어를 언급하는 나의 이전 진술이 부정확하다는 것을 발견했다. 책에서와 같이 자연어조차도 문서에 빌려주거나, 본문에 구현 된 추상화를 드물게 설명하거나, 본문을 탈선하지 않고 우회를 제공 할 수 있습니다. 잘 추상화 된 코드는 이미 자체 문서화를 향한 먼 길을 갔다는 점에 유의하십시오.

마지막으로, 주석은 코더가 높은 추상화 수준을 유지하는 데 도움이 될 수 있습니다. 종종 나는 단계 목록에 포함 된 두 개의 연속적인 주석이 동일한 추상화 수준에서 말하지 않는다는 것을 알고 있습니다.

어떤 문제는 코딩을 초월하고 다른 활동과 마찬가지로 코딩에 영향을 미칩니다. 의견은 우리의 코드의 이론적 근거와 측면을 명확히하는 데 도움이 될 수 있으며, 사람들에게 변화를 가져 오기 위해 더 부드러운 언어를 사용하는 즐거운 동반자를 찾습니다.

어떻게? 숙련 된 개발자에게 코드를 계속 보여주십시오. 그리고 당신이 철학적이며 화려하다는 비명을 질렀을 때, 그것을 빨아 들여 그들이 어떻게했는지 그리고 왜 (대립하지 않는 방식으로) 물어보십시오.

-1에 비추어 편집 :

많은 달 전, 나는 같은 상황에 처해있었습니다. 델파이에서 포인터를 사용할 때마다 울부 짖는 보스 한 명이나 '구조물'이있었습니다. 0-1을 사용하고 모든 곳에서 단일 문자 변수를 사용합니다.

나는 왜 그런지 물어 봤기 때문에 배웠고 그들은 LOL ..

과시 할 필요가 있다고 생각합니까? 더 이상은 아닙니다. 어떻게 지나갔습니까? 대부분의 사람들이 다른 나쁜 습관을 겪는 것처럼 ... 적절한 기술의 의식적이고 의도적 인 연습. 모범 사례의 가치를 충분히 이해하고 지속적으로 사용함으로써 좋은 습관을 개발할 수 있습니다.

또한 기능성 소프트웨어에 초점을 맞추면 시간이 지남에 따라 쉽게 관리 할 수 ​​있으며 원하는 인식을 얻을 수 있습니다. 숙련 된 개발자가 여러분에게 "당신이 작성한 모듈은 잘 설계되었습니다. 내 프로젝트에 플러그인하기 위해 하나의 구성 요소 만 구현하면됩니다"라고 말합니다. "다른 구성 요소에서 사용하기 위해 작성한 전체 모듈을 재 작업해야합니까? Bob Martin 또는 Ward Cunningham에 대해 들어 보셨습니까?"

TLDR : 당신은 혼자가 아닙니다. 기술을 인정하는 것은 현명한 방법으로 문제를 해결하는 부산물로 달성됩니다.

나를 위해 지나치게 현명한 코드는 오늘날의 요구 사항에 초점을 맞추지 않고 미래의 미래 요구 사항을 해결하려고 노력합니다. 큰 함정!

지나치게 복잡한 코드 0 %는 달성 가능한 목표가 아닙니다. 어쩌면 최선의 목표는 아닙니다. 지나치게 복잡한 코드는 좋지 않지만 프로그래머로 성장하려면 새로운 것을 시도해야합니다. 피할 수 있다면 프로덕션 코드에서 시도해서는 안됩니다. 기계와는 달리 인간은 실수를합니다.

코드 검토가 도움이됩니다. 다른 사람의 "영리한"코드를 수정하는 데 몇 년이 걸리면 도움이됩니다. 오늘날 고객이 실제로 필요로하는 것에 집중하십시오.

학교와 비즈니스에는 청소 및 유지 보수 직원이 직원으로 구성되어 있습니다. 코드 정리 및 유지 관리도 필요합니다! 가능하면 엉망을 청소하십시오 (특히 자신의 것)! 나는 그것이 최선의 방법이라고 생각합니다.

지금까지 제공된 좋은 조언 (코드 검토, 디버깅, TDD 접근) 외에도 좋은 코딩 방법에 대한 (최고의 책 임호)를 수시로 읽어야합니다.

• 실용 프로그래머
• 코드 완성
• 깨끗한 코드

그리고 사용하는 기술에 따라 다른 것.

YAGNI를 기억하십시오 – 당신은 그것을 필요로하지 않을 것 입니다.

프로그래머는 필요할 때까지 기능을 추가해서는 안됩니다 ...

YAGNI는 XP가 "가장 간단한 일을 할 수있는 것"(DTSTTCPW)의 기본 원칙입니다. 지속적인 리팩토링, 지속적인 자동 단위 테스트 및 지속적인 통합과 같은 다른 여러 가지 관행과 함께 사용해야합니다. 지속적인 리팩토링없이 사용하면 지저분한 코드와 대규모 재 작업으로 이어질 수 있습니다 ...

YAGNI 접근 방식을 옹호하는 사람들에 따르면, 현재로서는 필요하지 않지만 앞으로있을 수있는 코드를 작성하려는 유혹에는 다음과 같은 단점이 있습니다.

• 소요 시간은 필요한 기능을 추가, 테스트 또는 개선하는 데 소요됩니다.
• 새로운 기능은 디버깅, 문서화 및 지원되어야합니다.
• 새로운 기능은 향후 수행 할 수있는 작업에 제약을가하므로 불필요한 기능으로 인해 필요한 기능이 향후에 추가되지 않을 수 있습니다.
• 기능이 실제로 필요할 때까지 기능을 완전히 정의하고 테스트하기가 어렵습니다. 새 기능이 올바르게 정의 및 테스트되지 않은 경우 결국 필요하더라도 올바르게 작동하지 않을 수 있습니다.
• 코드 팽창으로 이어집니다. 소프트웨어가 커지고 복잡해집니다.
• 사양과 어떤 종류의 개정 관리가 없으면 기능을 사용할 수있는 프로그래머에게는이 기능이 알려지지 않을 수 있습니다.
• 새로운 기능을 추가하면 다른 새로운 기능이 제안 될 수 있습니다. 이러한 새로운 기능도 구현되면 기능 크리프에 눈덩이 효과가 발생할 수 있습니다.