향후 교정 코드

내가 일하는 개발자들은 항상 "나중에 이것을 위해 이것을 추가했다"또는 "언젠가 그것을 원할 것이기 때문에 이것을하는 것이 좋습니다"라고 말합니다. 나는 그들이 미래의 변화를 예측하려고 노력하는 것이 훌륭하다고 생각하지만 필요하지 않을 수도 있고 비생산적 인 코드를 작성하는 것이 불필요하고 위험하다고 생각할 수는 없습니다 (일부 개발자는 무언가를 시험 해보고 싶어한다고 생각합니다) 그것을 위해 새로운). 깔끔하고 체계적인 코드를 작성하면 미래의 증거에 대한 주장이 유효하지 않습니까?

우선 설명이 필요한 것이 있습니다.

• 미래 교정은 물건을 추가 하지 않습니다 .
• 향후 교정을 통해 기존 기능을 중단하지 않고도 코드 / 기능을 쉽게 추가 할 수 있습니다 .

이것은 "미래 증명"코드를 작성하고 코드가 느슨하게 결합 된 방식으로 충분히 추상적으로 작성되도록하지만 추상화 레벨을 완전히 숨기지 않는 코드를 작성하므로 항상 더 낮은 추상화 레벨로 갈 수있는 방법이 있음을 의미합니다. 필요하다면.

미래의 증명 코드를 작성하는 것은 그 자체로 예술이며 구성 요소 버전 관리, 우려 사항 분리, 기능 계층화 및 추상화에 대한 SOLID 사례와 밀접하게 연관되어 있습니다. 향후 교정은 기능을 미리 추가하는 것과는 관련 이 없지만 기존 코드 / 라이브러리의 우수한 설계를 통해 중단없이 미래에 기능을 추가 할 수 있도록합니다 .

내 2c

오랫동안 사용하지 않을 코드를 작성하지 마십시오. 그것은 당시의 요구에 맞지 않을 가능성이 있기 때문에 쓸모가 없습니다 (정의상 아직 알지 못합니다).

예상치 못한 문제 상황에 대비해 코드를 강력하게 만들어 정상적으로 복구하거나 신속하게 처리 할 수 ​​있지만 나중에 사용할 수 있도록 코드를 작성하지 마십시오.

이를 보장하는 좋은 방법은 테스트 중심 설계 및 개발을 사용하는 것입니다. 테스트 사례는 사양 및 사용 사례에서 파생됩니다. 모든 코드는 테스트를 통과해야합니다. 불필요한 코드는 작성해서는 안됩니다. 이 방법으로 수행하면 필요한지 여부를 쉽게 결정할 수 있습니다.

코드를 미래 에 대비하고 미래에 필요할 경우를 대비하여 코드 를 작성 하는 것이 매우 다른 두 가지 라는 것을 인식하는 것이 중요합니다 . 전자는 좋은 응용 프로그램에 중요하며 일반적으로 코딩 방법이 적을수록 적습니다.

• 나에게 미래의 코드 교정은 진화하는 기술과 상호 작용할 수있는 방식으로 코드를 작성하고 있습니다. 여기에는 코드 모듈화가 포함되므로 응용 프로그램의 각 부분이 응용 프로그램의 언어 및 기술과 독립적으로 상호 작용할 수 있습니다. 이에 대한 좋은 예는 XML 또는 JSON을 사용하여 응용 프로그램의 다른 부분간에 데이터를 전달하는 것입니다. 그러나 기술이 발전함에 따라 항상 XML과 JSON을 읽을 수있을 것입니다.

• 위와 유사하게 SOAP 또는 REST API를 통해 애플리케이션의 일부를 노출하면 비슷한 결과를 얻을 수 있습니다. 어떤 기술이 발전하든, 새로운 기술이 여전히 구식과 통신 할 수 있기 때문에 응용 프로그램의 모든 부분을 반드시 다시 작성할 필요는 없습니다.

• 코드 가 필요한 경우 코드를 작성하는 시점 에서 코드가 테스트가 거의 없거나 전혀 없기 때문에 매우 위험하다고 생각합니다.

따라서 반드시 미래의 코드를 작성하십시오 (NASA는 여전히 포트란을 사용하여 우주선을 전송합니다).

프로덕션 환경에서 몇 줄의 코드를 사용하도록 설정했는지 몇 번 생각하고 "2 년 전에 저에게 쓴 감사합니다!"라고 생각했습니다.

코드는 쉽게 수정 가능하고 확장 가능해야합니다. 즉각적으로 필요하지 않은 코드는 추가하지 마십시오. 보안에 대한 잘못된 인식을 제공하고 변화하는 요구 사항의 세계에서 개발 / 테스트 리소스를 낭비하기 때문입니다.

다른 많은 답변은 더 큰 디자인 문제를 해결하거나 다소 추상적입니다. 미래에 일어날 일에 대해 생각한다면 코드를 미래에 대비 하는 명확한 기술을 정의 할 수 있습니다 .

미래에는 누군가가 코드에 기능을 추가하려고 시도하거나 다른 곳에서 코드를 재사용하려고 시도 할 것이라고 생각합니다. 또한 코드의 기능을 수정하려고 할 수도 있습니다. 분명히 좋은 코드를 작성하는 것이 필수 출발점이지만, 수행 할 수있는 특정 기술도 있습니다.

방어 프로그래밍 : 현재 응용 프로그램에서 실제로 필요한 것 이상으로 입력 확인을 수행하십시오. API를 호출 할 때마다 해당 입력이 예상 한 것인지 확인하십시오. 앞으로 사람들은 새로운 버전의 코드를 혼합하여 오류의 범위와 API 반환이 현재 상태에서 변경 될 것입니다.

정의되지 않은 동작 제거 : 많은 코드에는 동작이 전혀없는 동작 이 있습니다. 특정 입력 조합은 실제로 의도하지 않은 특정 출력으로 이어지지 만 실제로는 발생합니다. 이제 누군가는 그 행동에 의존 할 것이지만, 정의되지 않았기 때문에 아무도 그것에 대해 알지 못할 것입니다. 미래에 행동을 바꾸려고 시도하는 사람은 부주의하게 물건을 깰 것입니다. 안전 점검을 지금 사용하고 정의되지 않은 모든 코드 사용을 제거 / 차단하십시오.

Automated Test Suite : 단위 테스트의 필요성에 대해 작성된 책을 찾을 수 있습니다. 그러나 향후 교정과 관련하여 누군가가 코드를 리팩토링하는 데 중요한 포인트입니다. 리팩토링은 깨끗한 코드를 유지하는 데 필수적이지만, 테스트 모음이 부족한 경우 안전하게 리팩토링 할 수 없습니다.

격리 및 분리 : 캡슐화 및 적절한 모듈화는 좋은 디자인 원칙이지만 그 이상을 넘어야합니다. 미래에 문제가있을 수있는 라이브러리 나 API 또는 제품을 사용해야하는 경우가 종종 있습니다. 품질 문제, 라이센스 문제 또는 저자의 지속적인 개발 때문일 수 있습니다. 이 경우 사용자와이 코드 사이에 레이어를 배치하는 데 시간이 더 걸립니다. API를 필요한만큼만 분할하면 커플 링이 매우 낮아 향후 쉽게 교체 할 수 있습니다.

훌륭하고 깨끗하며 잘 구성된 코드 는 변경 및 추가가 올바르게 구현되기 쉬워진다는 점에서 미래를 보장합니다.

"미래 증명"은 "느슨하게 결합 된 디자인"을 의미합니다. 사람들이 "미래 증거"라고 말할 때 시간의 80 %는 "유연성"을 의미합니다. 때때로 그들은 시원하게 들리라고 말합니다. 그러나 적어도 그들은 제 시간에 작동하는 무언가를 제공하고 있습니다.

최악의 "미래 증거"는 의미가 없습니다. 시간의 20 %는 단순히 무언가를 전달하는 대신 대체 기술을 연구하는 데 시간을 낭비하는 구실입니다. 그들은 어떤 것도 전달하지 않습니다 (또는 그들이 전달하는 것은 현재 문제에 비해 너무 복잡합니다).

두 가지 경우가 있습니다.

1. 확실한 선견지명. 실제로 미래를 정확하게 예측할 수 있습니다 . 이 경우이 강력한 예측을 적용하여 향후 코드를 증명하십시오. 더 나아가, 끊임없는 예측을 적용하여 시장 동향을 예측하고 조기 퇴직 및 코딩 중단.

2. 하나는 미래를 "운전"입니다. 즉, 미래에 배포 할 새로운 기술이 준비되어 있으므로 현재 제공되는 내용을 다시 작성해야합니다. 이 멋진 미래를 먼저 배포하지 않는 것이 이상합니다.

   프로젝트 "B"가 "A"를 즉시 다시 작성한다는 것을 알고 프로젝트 "A"를 제공해야합니다. 이 경우에만 "A"를 나중에 증명할 수 있습니다.

YAGNI = 당신은 그것을 필요로하지 않을 것 입니다.

본능은 정확합니다. 코드가 불필요하고 유지 보수 및 테스트 부담이 가중되고 구체적인 비즈니스 가치가없는 것들에 시간을 낭비합니다.

참조 : 금도금 .

질문의 제목을 무시하고 "누군가 언젠가 원하기 때문에 물건을 넣는 것"에 대한 요점을 고수합니다 ...

내 대답은 아니오 야. 못. 오늘날 필요하지 않은 코드를 작성하지 마십시오. 이유는 다음과 같습니다.

1. 프로그램은 이제 필요 이상으로 복잡해졌습니다.
2. 이 기능이 필요하지 않을 수 있으므로 시간을 낭비했습니다.
3. 나중에 누군가가 요청할 경우이 기능의 요구 사항이 무엇인지 모릅니다. 그래서 당신은 그것을 파악하고 어쨌든 수정해야합니다.

첫 번째 요점이 가장 중요하다고 생각합니다. 다른 고객을 위해 일반 코드로 가득 차거나 필요없는 기능으로 가득 찬 시스템으로 작업 한 적이 있다면 기능으로 인해 기능을 유지하거나 확장하는 데 얼마나 많은 시간과 노력이 필요한지 알 수 있습니다 그. 따라서 모든 비용을 피하십시오.