저는 취미 프로그래머 (VBA로 시작하여 더 빨리 엑셀 만들기)이고 VB.NET/C#.NET으로 작업 해 왔으며 ADO.NET을 배우려고합니다.
항상 나를 실망시키는 프로그래밍의 한 측면은 '좋다'가 어떤 모습일까요? 나는 전문가가 아니므로 비교할 것이 거의 없습니다. 더 나은 프로그래머를 만드는 것은 무엇입니까? 그것은 :
다시 말해, 전문 프로그래머의 코드를 살펴보면 내 코드와 관련하여 가장 먼저 눈에 띄는 것은 무엇입니까? 예를 들어, Wrox press의 'Professional ASP.NET'과 같은 책을 읽었습니다. 그 책의 코드 예제는 '세계적 수준'입니까? 그게 정점입니까? 최고의 프로그래머가 그 코드를보고 좋은 코드라고 생각할까요?
답변:
아래 목록은 포괄적이 아니지만 귀하의 질문을 고려하면서 생각한 것입니다.
좋은 코드는 잘 정리되어 있습니다. 클래스의 데이터와 작업은 서로 맞습니다. 클래스간에 외부 종속성이 없습니다. "스파게티"처럼 보이지 않습니다.
좋은 코드 주석은 작업이 수행되지 않은 이유를 설명합니다. 코드 자체는 수행되는 작업을 설명합니다. 의견의 필요성은 최소화되어야합니다.
좋은 코드는 가장 일시적인 개체를 제외한 모든 개체에 대해 의미있는 명명 규칙을 사용합니다. 무언가의 이름은 개체를 사용하는시기와 방법에 대한 정보를 제공합니다.
좋은 코드는 잘 테스트되었습니다. 테스트는 코드의 실행 가능한 사양 및 사용 예제로 사용됩니다.
좋은 코드는 "영리한"것이 아닙니다. 간단하고 분명한 방식으로 일을합니다.
좋은 코드는 작고 읽기 쉬운 계산 단위로 개발됩니다. 이러한 단위는 코드 전체에서 재사용됩니다.
아직 읽지 않았지만이 주제에 대해 읽을 예정인 책은 Robert C. Martin의 Clean Code 입니다.
가장 먼저 눈에 띄는 것은 코드가 일관된 코딩 스타일을 따른다는 것 입니다 . 그들은 항상 구조 블록을 동일하게 작성하고 종교적으로 들여 쓰기하고 적절한 곳에 주석을 달습니다.
두 번째로 눈에 띄는 점은 코드가 최대 수십 줄에 이르는 작은 메서드 / 함수로 분할된다는 것입니다. 또한 자체 설명 메서드 이름을 사용하며 일반적으로 코드를 매우 읽기 쉽습니다.
세 번째로, 코드를 약간 엉망으로 만든 후에는 논리를 따르기 쉽고 수정하기 쉬우므로 쉽게 유지 관리 할 수 있습니다.
그 후 소프트웨어 설계 기술에 대한 지식과 경험이 있어야 코드 아키텍처를 구성하는 특정 선택 사항을 이해할 수 있습니다.
책에 관해서는 코드가 "세계적 수준"으로 간주 될 수있는 책을 많이 보지 못했습니다. 책에서 그들은 매우 간단한 문제를 해결하는 데 관련 될 수 있지만 더 복잡한 상황을 반영하지 않는 간단한 예를 주로 제시하려고합니다.
개인적 으로 Tim Peters 의 "The Zen of Python" 을 인용해야합니다 . Python 프로그래머에게 코드가 어떻게 생겼는지 알려주지 만 기본적으로 모든 코드에 적용됩니다.
못생긴 것보다 아름다운 것이 낫습니다.
명시적인 것이 암시적인 것보다 낫습니다.
단순한 것이 복잡한 것보다 낫습니다.
복잡한 것이 복잡한 것보다 낫습니다.
플랫이 중첩보다 낫습니다.
희소가 밀도보다 낫습니다.
가독성이 중요합니다.
특별한 경우는 규칙을 어길만큼 특별하지 않습니다.
실용성이 순결을 능가하지만.
오류는 조용히 전달되지 않아야합니다.
명시 적으로 침묵하지 않는 한.
모호함에도 불구하고 추측하려는 유혹을 거부하십시오.
이를 수행하는 분명한 방법은 하나, 바람직하게는 하나만 있어야합니다.
네덜란드 사람이 아니라면 처음에는 그 방법이 분명하지 않을 수도 있습니다.
지금은 결코하지 않는 것보다 낫습니다.
결코 종종보다 낫지 만바로 지금.
구현이 설명하기 어렵다면 그것은 나쁜 생각입니다.
구현이 설명하기 쉽다면 좋은 생각 일 수 있습니다.
네임 스페이스는 훌륭한 아이디어 중 하나입니다. 더 많은 작업을 수행해 보겠습니다!
코드는시입니다.
이 논리 지점에서 시작하면 원하는 코드의 많은 특성을 도출 할 수 있습니다. 가장 중요한 것은 코드가 작성된 것보다 훨씬 더 많이 읽히므로 독자를 위해 코드를 작성하는 것입니다. 독자를 위해 재 작성, 이름 변경, 편집 및 리팩터링하십시오.
추론에 대한 후속 :
독자는 코드 생성 날짜로부터 n 시간에 당신이 될 것입니다. 독자를위한 코드 작성의 대가는 n의 단조롭게 증가하는 함수입니다. 처음으로 코드를 보는 독자는 n == 무한대로 표시됩니다.
즉, 코드를 작성한 시점에서 코드를 다시 방문 할 때까지의 시간 간격이 클수록 독자를 위해 작성하려는 노력에 더 감사 할 것입니다. 또한 코드를 넘겨주는 사람은 리더가 가장 먼저 고려한 코드를 통해 큰 이점을 얻을 수 있습니다.
두 번째 결과 :
독자를 고려하지 않고 작성된 코드는 이해하거나 사용하기가 불필요하게 어려울 수 있습니다. 독자에 대한 고려가 특정 임계 값 아래로 떨어지면 독자는 코드를 다시 작성하여 얻은 값보다 코드에서 더 적은 가치를 얻습니다. 이것이 발생하면 이전 코드는 버려지고 비극적으로 재 작성하는 동안 많은 작업이 반복됩니다.
세 번째 결과 :
추론 2는 잘못 문서화 된 코드와 강제 재 작성의 악순환에서 여러 번 반복되는 것으로 알려져 있습니다.
저는 28 년 동안 프로그래밍을 해왔고이 질문에 답하기가 어렵습니다. 나에게 좋은 코드는 완전한 패키지입니다. 코드는 의미있는 변수 및 메서드 이름으로 깔끔하게 작성됩니다. 코드의 의도를 설명하는 주석이 잘 배치되어 있으며 이미 읽을 수있는 코드를 역설하지 않습니다. 코드는 리소스를 낭비하지 않고 효율적인 방식으로 원하는 작업을 수행합니다. 또한 유지 보수 가능성을 염두에두고 작성해야합니다.
그러나 결론은 그것이 다른 사람들에게 다른 것을 의미한다는 것입니다. 다른 사람이 싫어할 수있는 좋은 코드로 분류 할 수있는 것. 좋은 코드는 위에서 확인한 몇 가지 공통된 특성을 가질 것입니다.
할 수있는 최선의 방법은 코드에 자신을 노출하는 것입니다. 다른 사람의 코드를보십시오. 오픈 소스 프로젝트는이를위한 좋은 소스입니다. 좋은 코드와 나쁜 코드를 찾을 수 있습니다. 더 많이 볼수록 좋은 코드와 나쁜 코드가 무엇인지 더 잘 알 수 있습니다.
궁극적으로 당신은 당신 자신의 판사가 될 것입니다. 선호하는 스타일과 기법을 찾으면 시간이 지남에 따라 자신 만의 스타일을 생각해 내고 시간이 지남에 따라 변경됩니다. 여기에는 지팡이를 흔들고 좋은 것과 다른 것은 나쁜 것이라고 말할 수있는 사람이 없습니다.
Code Complete 책을 읽으십시오. 이것은 코드를 구조화하는 방법과 그렇게하는 이유에 대한 많은 아이디어를 설명합니다. 그것을 읽으면 좋은 것과 나쁜 것을 구별하는 데 필요한 경험을 얻는 데 시간이 단축 될 것입니다.
거의 10 년 동안 프로그래밍을 해왔고 다른 사람들과 함께 일하면서 좋은 프로그래머와 일반 프로그래머 코드 사이에는 차이가 없다고 편견없이 말할 수 있습니다.
유능한 수준의 모든 프로그래머 :
한번 동료의 말 엿 " 내가 개발 즐길 왜 항상 매우 논리적이고 마음 합리적인있었습니다을. 그의를 생각한다 "
제 생각에는 보통 프로그래머의 생각입니다. 규칙과 논리의 관점에서 세상을보고 궁극적으로 프로그램을 설계하고 작성할 때 그 규칙을 따르는 사람.
전문 프로그래머는 규칙뿐만 아니라 컨텍스트도 이해합니다. 이것은 궁극적으로 전문 프로그래머의 표식 인 새로운 아이디어와 구현으로 이어집니다. 프로그래밍은 궁극적으로 예술 형식입니다.
간단히 말해서 좋은 프로그래머의 코드를 읽고 이해할 수 있습니다.
제 생각에 좋은 프로그래머의 코드는 언어에 구애받지 않습니다 . 잘 작성된 코드는 사용되는 프로그래밍 언어에 관계없이 최소한의 생각으로 짧은 시간에 읽고 이해할 수 있습니다. 코드가 Java, Python, C ++ 또는 Haskell인지 여부에 관계없이 잘 작성된 코드는 특정 언어로 프로그래밍하지 않는 사람도 이해할 수 있습니다.
읽기 쉬운 코드의 몇 가지 특성은 이름이 잘 지정된 메서드, "트릭"이없고 복잡한 "최적화"가없는 클래스, 예를 들어 클래스가 잘 설계된 것입니다. 다른 사람들이 언급했듯이 코딩 스타일은 일관되고 간결하며 간단합니다 .
예를 들어, 얼마 전 Stack Overflow에 대한 질문 중 하나에 답하기 위해 TinyMCE 의 코드를 살펴 보았습니다 . 제가 거의 사용하지 않는 언어 인 JavaScript로 작성되었습니다. 그러나 코드 자체의 구조화와 함께 포함 된 코딩 스타일과 주석으로 인해 상당히 이해할 수 있었고 몇 분 안에 코드를 탐색 할 수있었습니다.
좋은 프로그래머의 코드를 읽는 것과 관련하여 저에게 눈을 뜨게 한 책 은 Beautiful Code 입니다. 다양한 프로그래밍 언어로 다양한 프로그래밍 프로젝트의 저자가 작성한 많은 기사가 있습니다. 그러나 내가 그것을 읽었을 때 나는 그 특정 언어로 프로그래밍 한 적이 없다는 사실에도 불구하고 저자가 그의 코드에 무엇을 쓰고 있는지 이해할 수 있었다.
아마도 우리가 염두에 두어야 할 것은 프로그래밍은 컴퓨터뿐만 아니라 사람에 대한 의사 소통에 관한 것입니다 . 따라서 훌륭한 프로그래머의 코드는 거의 잘 쓰여진 책과 같으며 전달하려는 아이디어에 대해 독자에게 전달할 수 있습니다. .
다른 모든 것은 선조
좋은 코드는 읽기 쉽습니다. 좋은 전문 프로그래머가 작성한 코드를 처음 읽을 때 코드가 수행하는 작업을 이해하는 데 문제가 없습니다.
그런 다음 다른 모든 사람의 훌륭한 제안을 반복하는 대신 Steve McConnell의 Code Complete 책을 읽는 것이 좋습니다.
기본적으로이 책은 기능과 스타일 모두에 대한 프로그래밍 모범 사례로 가득 찬 책입니다.
[순수한 주관적 답변]
저에게 좋은 코드는 그림과 같은 예술의 한 형태입니다. 더 나아가서 실제로 문자, 색상, 코드의 "형식"또는 "구조"가 포함 된 그림이라고 말할 수 있습니다.이 모든 것이 읽기 쉽고 성능이 뛰어납니다. 가독성, 구조 (예 : 열, 들여 쓰기, 같은 길이의 변수 이름까지!), 색상 (클래스 이름, 변수 이름, 주석 등)의 조합은 모두 내가보고 싶은 것을 "아름다운"그림으로 만들 수 있습니다. 내 코드를 매우 자랑 스럽거나 혐오하게 만듭니다.
(이전에 말했듯이 매우 주관적인 답변입니다. 영어로 죄송합니다.)
코드에 내 2 센트를 추가하고 싶었습니다. 일반적으로 코드 자체에 코드가 무엇을하는지, 이제 어떻게하는지 설명해야합니다. 다른 코드를 호출하는 코드 인 '클라이언트'코드 (가장 간단한 예는 메서드를 호출하는 코드)의 개념이 있으면 항상 "클라이언트"의 관점에서 코드를 이해할 수 있도록 만드는 것에 대해 가장 걱정해야합니다. 코드가 커짐에 따라 이것이 ... 어, 좋습니다.
좋은 코드에 대한 다른 많은 것들은 당신이 만들 수있는 정신적 도약에 관한 것입니다. (확실히,주의를 기울이면) ... 99 %는 당신에게 많은 양을 절약하기 위해 지금 조금 더 많은 일을하는 것과 관련이 있습니다. 나중에 작업하고 재사용 할 수 있습니다. 또한 올바른 일을하면서 : 거의 항상 정규 표현식을 사용하는 것보다 다른 방식으로 실행하고 싶지만, 정규 표현식에 들어갈 때마다 모든 사람들이 내가 작업하는 모든 단일 언어에서 사용하는 이유를 알 수 있습니다 (난해하지만 일하고 아마 더 좋을 수 없습니다).
책을 볼지 여부에 관해서 는 내 경험으로 는 분명히 말할 수 없습니다 . API와 프레임 워크, 코드 규칙, 다른 사람의 코드를 살펴보고 자신의 본능을 사용하고, 사물이 왜 그런지, 사물의 의미가 무엇인지 이해하려고 노력하세요. 책의 코드가 거의하지 않는 것은 계획되지 않은 것에 대한 계획이며, 이것이 오류 검사의 전부입니다. 이것은 누군가가 당신에게 이메일을 보내고 "이봐, 앱이 고장났습니다."대신 "오류 321이 발생했습니다"라고 말할 때만 효과가 있습니다.
좋은 코드는 프로그래머의 관점과 사용자의 관점에서 미래를 염두에두고 작성됩니다.
이것은 FAQ 인 것 같습니다. 이 ACM 기사 최근 아름다운 코드에 대한이. 읽기 / 이해하기 쉬움이 강조되는 것 같습니다. 나는 이것을 "도메인 전문가가 읽기 / 이해하기 쉬움"으로 한정하고 싶다. 정말 좋은 프로그래머는 주어진 문제에 대해 (순진하고 이해하기 쉬운 O (n ^ 2) 알고리즘 대신) 최상의 알고리즘을 사용하는 경향이 있습니다. 알고리즘에 익숙하지 않은 경우에도 따라하기 어려울 수 있습니다. 프로그래머는 알고리즘에 대한 참조를 제공합니다.
좋은 프로그래머를 포함하여 완벽한 사람은 없지만 그들의 코드는 다음을 위해 노력 하는 경향이 있습니다 .
나는 밥 삼촌의 "깨끗한 코드"에 대한 추천을 두 번째로 받았다. 그러나 http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 을 살펴보면 특정 질문을 좀 더 잘 처리한다고 생각할 수 있습니다. 좋은 코드는 페이지에서 튀어 나와 그것이 무엇을 / 어떻게 작동하는지 알려줘야합니다.
Jeff Atwood는 코더가 타이피스트가 처음 참조하는 방법에 대한 멋진 기사를 작성했습니다. http://www.codinghorror.com/blog/archives/001188.html
타이피스트가 될 때는 항상 우아하게 작업해야합니다. 구조적이고 적절한 "문법"을 갖는 것이 매우 중요합니다. 이제 이것을 "프로그래밍"타이핑으로 변환하면 동일한 결과를 얻을 수 있습니다.
구조
코멘트
지역
저는 소프트웨어 엔지니어입니다. 교육 기간 동안 여러 언어를 접했지만 제 프로그래밍은 항상 똑같이 "느껴집니다". fekberg.wordpress.com에서 저술 한 것처럼 저는 타이핑에 "특별한"방법이 있습니다.
이제 Java, C #, Assembler, C ++, C와 같은 다른 언어로 다른 응용 프로그램을 프로그래밍하고 있습니다. 저는 제가 좋아하는 "표준"작성에 도달했습니다.
나는 모든 것을 "상자"또는 지역으로보고 각 지역에 주석을 설명하고 있습니다. 영역은 "Person 클래스"일 수 있으며이 영역 내부에는 속성에 대한 몇 가지 메서드가 있습니다.이 메서드는 "액세스 방법"등으로 호출 할 수 있으며 각 속성 및 영역에는 고유 한 설명 주석이 있습니다.
이것은 매우 중요합니다. 저는 항상 API 구조를 만들고 우아함이 매우 중요 할 때 "API의 일부가되는"코드를 사용 합니다.
이것에 대해 생각하다. 또한 내 종이 읽고 Communication issues when adapting outsourcing당신으로 같은 러프에 설명하는 방법 나쁜 코드 캔 충돌, Enterpret을 : http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/
좋은 코드는 메서드가 이름에서 무엇을하는지 아는 곳입니다. 잘못된 코드는 이름을 이해하기 위해 코드가 수행하는 작업을 해결해야하는 곳입니다.
좋은 코드는 당신이 그것을 읽으면 그것을 읽는 데 걸리는 시간보다 훨씬 더 많은 시간 안에 그것이 무엇을하는지 이해할 수있는 곳입니다. 나쁜 코드는 그것이하는 일을 해결하려고 노력하면서 결국 그것을 보는 곳입니다.
좋은 코드에는 사소한 주석을 불필요하게 만드는 것과 같은 이름이 있습니다.
좋은 코드는 짧습니다.
좋은 코드는 목적과는 무관 한 것에 의존하지 않기 때문에 다른 곳에서하는 일을하기 위해 재사용 할 수 있습니다.
좋은 코드는 일반적으로 간단한 작업을 수행하기위한 간단한 도구 집합입니다 (더 정교한 작업을 수행하기 위해 잘 조직 된 방식으로 결합 됨). 잘못된 코드는 깨지기 쉽고 사용하기 어려운 거대한 다목적 도구 인 경향이 있습니다.
코드는 프로그래머의 기술과 사고 방식을 반영합니다. 좋은 프로그래머는 항상 미래를 주시합니다. 요구 사항이나 상황이 현재와 정확히 일치하지 않을 때 코드가 어떻게 작동 할 것인지에 대한 관심이 있습니다. 얼마나 비판적일까요? 이 코드를 관리하는 사람이 아니라면 얼마나 편리할까요? 코드를 얼마나 재사용 할 수 있는지, 비슷한 일을하는 다른 사람이 코드를 재사용하고 다시 작성하지 않을 수 있습니다. 다른 사람이 내가 작성한 코드를 이해하려고 할 때 어떨까요?
프로그래머가 그런 마음가짐을 가지면 다른 모든 것들이 제자리에 있습니다.
참고 : 코드베이스는 시간이 지남에 따라 많은 프로그래머가 작업하며 일반적으로 프로그래머에 대한 코드베이스의 특정 지정이 없습니다. 따라서 좋은 코드는 회사의 모든 표준과 직원의 품질을 반영합니다.
(I "는 그는"이것이 내가 그 사람 때문에 아래 사용하는 바램이 때때로 성공, 수).
좋은 프로그래머의 철학의 핵심은 그가 항상 "이 작업에 대한 모든 것을 잊을 때, 내가이 작업을 수행 한 이유, 위험은 무엇이 었는지, 심지어 어떻게이 작업에 대해 코드가 작동해야했습니다. "
따라서 그의 코드는 다음을 수행해야합니다.
반면에 좋은 프로그래머는 절대로 이런 일을해서는 안된다고 생각합니다.
반어 더 나은 프로그래머가 덜 필수적인 생산 코드 (에 란 Galperin에 의해 일반적인 동의에 의해 명시된 바와 같이) 누구나 더 나은 유지 관리하기 때문에 그 / 그녀가된다.
내 경험에 따르면 그 반대도 사실입니다. 나쁜 프로그래머는 더 어려워 유지하기 때문에, 그 / 그녀의 코드가 더 필수 불가결 한 다른 영혼이 제작 한 수수께끼를 이해할 수 있기 때문에, 그 / 그녀가됩니다.