코드 냄새가 나면 어떻게해야합니까?

나는 초보자 프로그래머이며 종종 내 자신의 프로젝트를 수행 할 때 항상 코드 디자인이 최선이 아니라는 느낌을 얻습니다.이 느낌이 싫어요. 나는 물건을 찾는 데 시간을 소비하지만 결국 디자인 패턴과 추상 클래스 또는 인터페이스를 사용하는시기 등 많은 세부 사항으로 인해 쉽게 압도됩니다. 한 번에 조금만 배우려고 노력해야합니까?

몇 가지 제안 :

1. 기능을 별개의 빌딩 블록으로 분리하여 캡슐화 를 사용 하여 복잡성을 관리 하십시오 . 각 블록의 작동을 증명하고 (단위 테스트를 통해) 내부 세부 사항에 대해 걱정하지 않고 사용할 수 있습니다.

2. 소프트웨어 패턴을 배우고 연구하십시오 . 소프트웨어 패턴은 일반적이고 잘 알려진 특정 작업을 수행하기위한 검증 된 방법입니다.

3. 데이터 구조를 연구하고 이해하십시오 . 각 유형의 데이터 구조에 적합한 사용 및 성능 특성을 학습하십시오.

4. 프로그래밍 언어, 강점과 약점, 그 기능을 가장 잘 사용하는 방법을 잘 알고 있어야합니다.

이 모든 것을 한 번에 알 필요는 없지만 시간이 지남에 따라 모든 것을 공부 해야합니다 .

내 충고는 : 걱정하지 말라.

경험은 최고의 교사이며 코드를 작성하지 않으면 경험을 얻지 못합니다. 또한, 심하게 설계 코드 입니다 작성은 훌륭한 디자인보다 낫다 없습니다 .

더 많은 코드를 작성하십시오. 프로젝트를 완료하십시오. 코드가 이상적이지 않다는 느낌이 맞을 것입니다. 이 코드에 문제가있을 수 있습니다. 이러한 문제가 발생했을 때, 다음 나쁜 이유를 정확히 배울 것입니다. 당신은 "물건을 찾는 것"보다 직접 경험을 통해 더 많은 것을 배울 것입니다.

또한, "코드 냄새"라는 느낌이 사라지지 않기를 바랍니다. 나아질수록 일부 문제는 해결되지만 새롭고 모호한 / 고급 문제를 알아 채기 시작합니다.

이것은 프로그래머를 시작하는 일반적인 문제입니다. 모든 것이 완벽해야한다고 생각하여 자신을 마비시키지 마십시오. 그것이 프로젝트를 끝내지 않는 가장 확실한 방법입니다. 개발자가 사이의 차이로 가장 중요한 기술 중 하나는 배울 완전 하고 충분가 . 생성 한 모든 시스템을 개선 할 수 있다는 점에 동의하십시오. 프로젝트 마무리에 집중하십시오. 완료 한 후 돌아가서 개선 할 수 있습니다. 결국 우리는 2.0 버전을 사용합니다.

한 번에 조금만 배우려고 노력해야합니까?

내가하지 희망. 반면에, 당신 은 전체 시간을 배우고 향상 시켜야 합니다.

책을 읽고, 과정을 수강하고, 자격을 얻고, 일하고, 향상시켜야합니다.

최선의 조언은 Robert Harvey가 제안한 목록과 같은 기본 사항에 초점을 맞추는 것입니다. 소프트웨어 개발은 ​​복잡한 인터페이스로, 특히 우수한 인터페이스 디자인 주제에서 원격으로 능숙 해지기까지 몇 년이 걸립니다. 소프트웨어 개발의 많은 측면을 먼저 경험하지 않고 평가하는 것은 정말 어렵습니다. 주석 코드와 같은 기본적인 것조차 이해되지 않을 수 있습니다. 첫날부터 잘 문서화 된 코드를 작성하는 법을 배웁니다. 나는 좋은 의견의 가치를 진정으로 이해하기 전에 몇 달 전에 작성한 코드를 이해하려고 시도하는 $ $에 실제로 들어 가지 않을 때까지는 인정하지 않을 것입니다. 많은 프로그래밍 개념에 대해서도 마찬가지입니다. 예를 들어, 데이터 캡슐화, 낮은 결합 모듈 및 깨끗하고 깨끗한 인터페이스.

내가 만난 가장 귀중한 자원은 동료입니다. 코드 작성이 잘못되었습니다. 그냥 받아 들여 프로그래머로서 자신을 정의하는 시간이 지남에 따라 더 나은 코드를 작성하기 위해 수행하는 작업입니다. 예를 들어, 처음 작업을 시작했을 때 회사에는 공식 코드 나 디자인 검토 절차가 없었습니다. 나는 더 많은 일을하는 동료들의 비난에 정직하고 솔직 해지기 위해 자신의 일을 스스로 받아 들였다. 나는 첫 해의 일을 더 잘하기위한 바보처럼 느꼈다.

소프트웨어 개발은 ​​지속적인 학습 경험입니다. 수많은 질문을하고, 코드를 검토하고, 더 많은 상급자들이 제안하는 이유가 무엇인지 이해하고, 더 많은 상급 개발자들이 제안한 제안의 타당성을 의심하지 마십시오. 그리고 무엇보다도 잘못을 두려워하지 않습니다. 결국 협박 요인 또는 압도적 인 느낌이 사라집니다. 기록을 위해 ... 학습 곡선이 빨라집니다.

• 첫 번째 : 리팩토링 (여전히 냄새가 나지만 좀 더 조직화됩니다)
• 둘째 : 리팩토링 된 부분이 논리와 일치하도록 Design Patter를 사용할 수 있는지 확인하십시오.
• 셋째 : 상황이 나아지기 시작하면 첫 번째 단계와 두 번째 단계를 수행 한 시간을 기억하십시오. 이런 방식으로 새로운 기능을 작성할 때 다른 프로세스가 아닌 기능을 수행하는 동안 생각하게됩니다.

Martin Fowler 의 Refactoring : 기존 코드의 디자인 개선 이라는 책을 살펴보십시오 . 당신이해야 할 첫 번째 일은있다 코드 리팩토링 코드의 가독성을 개선하고 그것의 maintability을 개선하기 위해 복잡성을 줄이기 위해.

코드를 리팩터링 할 때는 이미 디자인 패턴 , 캡슐화 코드 등을 사용하고 있습니다.

이것은 제가이 주제에 관해 읽은 최고의 책 중 하나입니다. 유용한 레시피를 많이 제공합니다.

좋은 자료는 Pragmatic Programmer 입니다. "Broken Windows"에 대한 장에서는 자신이있는 위치를 설명합니다. 짧고 간결한 반응은 문제를 해결하는 것입니다.

디자인 수정을 시작하면 디자인이 마음에 들지 않는 것을 이해하는 데 도움이됩니다. "그냥 모든 곳으로 간다"또는 "내가 왜 그랬습니까?"와 같은 모호한 답변을 쉽게 내놓을 수 있습니다. 그러나 사용한 일반적인 패턴이 있는지 시간을 내십시오.

• 좋은 디자인은 코드베이스 전체에서 적은 수의 개념을 재사용 할 것입니다. 이상적인 개념은 하나의 개념이지만 실제로는 몇 가지가 더 필요할 수 있습니다.
• 좋은 디자인은 문제를 해결할 위치를 쉽게 파악할 수 있도록합니다 (DRY 원칙, SRP 원칙)
• 좋은 디자인은 좋은 오류보고 (위의 포인트와 관련이 있지만 종종 간과되는 측면이기 때문에 별도의 항목으로 호출 됨)를 갖습니다.

가고 싶은 곳을 찾으면 작고 쉽게 뒤집을 수있는 단계를 수행하십시오 (즉, 리팩토링 이 중요합니다 ). 코드를 개선 할 때마다 나머지 코드에 미치는 영향을 고려하십시오. 일을 더 나쁘게 만들었습니까? 이것은 적어도 질서를 혼란에 빠뜨리는 나의 접근법입니다.

이미 프로그래밍 경험이 있다면, 깨끗한 코드 를 가진 오픈 소스 프로젝트를 공부하지 않겠 습니까? 관련 링크가있는 SO 의이 질문을 살펴볼 수 있습니다.

또한 디자인 패턴은 반드시 알아야합니다. 패턴을 생각한다는 아이디어는 바퀴를 다시 만들거나 버그가있는 코드를 작성하지 않고도 알려진 문제를 해결하는 것입니다.

마지막으로, 머리를 깨끗이하기 위해 약간의 기능적 프로그래밍이 필요한 것처럼 보입니다. Haskell 또는 Ocaml을 살펴보고 시작하십시오.

위험한 괴물이 아닌 경우 코드를 검토 할 수있는 친구를 찾아야 하며 그 반대도 마찬가지입니다. 또한, 다시 방문하거나 다른 사람들이 감독 할 일을하는 경우 더 좋은 방법으로하는 것이 좋습니다.

잊지 말고 코딩 하기 전에 프로그래밍이 시작 되고 항상 아이디어와 계획을 다시 방문하십시오. 계획이 나쁜 경우, 그것을 버리는 것은 즐거운 행동입니다. 나쁜 계획에 따라 많은 코드 (및 생성 시간)를 버리는 좌절감을 방금 저장했습니다.

내 조언은 각 냄새를 심각하게 받아들이고 고치려고 노력하는 것입니다. 이 주제에 관한 많은 좋은 책들이 있습니다 (클린 코드와 GOOS가 최고의 IMHO입니다). 그러나 책보다 더 많은 사람들이 다른 사람들과 온라인 커뮤니티 (메일 링리스트, 그룹)를 듣고 토론하기 위해 회의에갑니다. 여전히 xxug (dotnetug, jug, xpug 등)에 가입하거나 찾은 것이 좋습니다.

다른 프로그래머와 토론하는 것이 내가 실제로 개선 할 수있는 유일한 방법입니다 (행운이 다른 전용 프로그래머와 함께 일할 수 없다면).