저는 취미 프로그래머 (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 책을 읽으십시오. 이것은 코드를 구조화하는 방법과 그렇게하는 이유에 대한 많은 아이디어를 설명합니다. 그것을 읽으면 좋은 것과 나쁜 것을 구별하는 데 필요한 경험을 얻는 데 시간이 단축 될 것입니다.
