어디에서나 데이터 검사를 도입 할 수있는 좋은 코드 스타일?

나는 크기가 충분히 커서 프로젝트를 더 이상 머리 속에 담을 수 없습니다. 나는 많은 클래스와 함수를 다루고 있으며 데이터를 전달하고 있습니다.

시간이 지남에 따라 오류가 계속 발생한다는 것을 알았습니다. 데이터를 다른 함수에 전달할 때 데이터의 정확한 형식을 잊어 버렸습니다. 예를 들어 하나의 함수는 문자열 배열, 다른 함수는 나중에 작성하여 사전 등에 보관 된 문자열을 허용하므로 작업중 인 문자열을 배열에 포함시키는 것에서 사전에 포함시키는 것으로 변환해야합니다 .)

항상 어떤 부분이 고장 났는지 파악하지 않으려면 각 함수와 클래스를 외부 코드에 의존하여 올바른 입력을 제공 할 수 없으며 입력 확인 자체를 수행해야한다는 의미에서 "격리 된 엔티티"로 취급하기 시작했습니다. 경우에 따라 데이터가 잘못된 형식으로 제공되는 경우 데이터를 다시 전송하십시오.

이것은 클래스와 함수 자체가 일부 입력이 잘못되었을 때 경고하고 때로는 수정하지 않기 때문에 내가 전달하는 데이터를 모든 함수에 맞추는 데 소요되는 시간을 크게 줄였습니다. 더 이상 전체 코드를 통해 디버거와 함께 가야 건초가 어디로 갔는지 알아낼 수 있습니다.

다른 한편으로는 전체 코드가 증가했습니다.
내 질문은이 코드 스타일 이이 문제를 해결하는 데 적합한 지 여부입니다.
물론 가장 좋은 해결책은 프로젝트를 완전히 리팩토링하고 데이터가 모든 기능에 대해 균일 한 구조를 갖도록하는 것입니다. 그러나이 프로젝트가 꾸준히 성장하고 있기 때문에 실제로 새로운 것을 추가하는 것보다 더 많은 비용을 지출하고 깨끗한 코드에 대해 걱정하게됩니다. .

(FYI : 저는 아직 초보자입니다.이 질문이 순진한 경우 실례합니다. 프로젝트는 Python입니다.)

더 나은 솔루션은 Python 언어 기능과 툴링을 더 활용하는 것입니다.

예를 들어, 함수 1에서 예상되는 입력은 문자열 배열이며, 첫 번째 문자열은 제목을 나타내고 두 번째 문자열은 서지 참조를 나타냅니다. 함수 2에서 예상되는 입력은 여전히 ​​문자열 배열이지만 문자열의 역할은 반대로됩니다.

이 문제는로 완화됩니다 namedtuple. 가볍고 배열 구성원에게 의미 론적 의미를 쉽게 부여합니다.

언어를 전환하지 않고 일부 자동 유형 검사의 이점을 얻으려면 유형 힌트를 활용할 수 있습니다 . 좋은 IDE는 이것을 사용하여 바보 같은 일을 할 때 알려줍니다.

요구 사항이 변경 될 때 기능이 오래가는 것에 대해 걱정하는 것 같습니다. 이것은 자동화 된 테스트에 의해 포착 될 수 있습니다 .

수동으로 확인하는 것이 결코 적절하지 않다는 말은 아니지만 사용 가능한 언어 기능을 더 잘 사용하면이 문제를 유지 관리하기 쉬운 방법으로 해결할 수 있습니다.

실제로 실제 문제는이 답변 아래의 주석에 설명되어 있습니다.

예를 들어, 함수 1에서 예상되는 입력은 문자열 배열이며, 첫 번째 문자열은 제목을 나타내고 두 번째 문자열은 서지 참조를 나타냅니다. 함수 2에서 예상되는 입력은 여전히 ​​문자열 배열이지만 문자열의 역할은 반대로됩니다.

여기서 문제는 순서가 의미를 의미하는 문자열 목록을 사용하는 것입니다. 이것은 실제로 오류가 발생하기 쉬운 접근 방식입니다. 대신 title및 이라는 두 개의 필드로 사용자 정의 클래스를 작성해야합니다 bibliographical_reference. 그렇게하면 당신은 그것들을 섞지 않을 것이며, 나중에이 문제를 피할 것입니다. 물론 많은 장소에서 이미 문자열 목록을 사용한다면 약간의 리팩토링이 필요하지만 장기적으로는 저렴할 것입니다.

동적 유형 언어의 일반적인 접근 방식은 "오리진 입력"입니다. 즉, 전달 된 객체의 "유형"에 신경 쓰지 않고 호출하는 메소드를 지원하는 경우에만 신경을 써야합니다. 귀하의 경우, bibliographical_reference필요할 때 호출되는 필드를 간단히 읽을 수 있습니다. 이 필드가 전달 된 객체에 존재하지 않으면 오류가 발생하며 이는 잘못된 유형이 함수에 전달되었음을 나타냅니다. 이것은 유형 검사만큼이나 좋습니다.

우선, 지금 당장 경험하고있는 것은 코드 냄새 입니다. 냄새를 인식하게하는 원인을 기억하고 코드 냄새 가 빨리 나타날수록 "정신적 인"코를 연마하십시오. 근본적인 문제를 해결할 수 있습니다.

항상 어떤 부분이 깨 졌는지 파악하지 않으려면 각 함수와 클래스를 외부 코드에 의존하여 올바른 입력을 제공 할 수 없으며 입력 확인 자체를 수행해야한다는 의미에서 "격리 된 엔티티"로 취급하기 시작했습니다.

이 기술을 사용하는 방어 적 프로그래밍은 유효하고 자주 사용되는 도구입니다. 그러나 모든 것과 마찬가지로 적절한 양의 검사를 사용하는 것이 중요하며 너무 적은 수의 검사를 수행하면 문제가 발생하지 않으며 코드가 과도하게 늘어납니다.

(또는 경우에 따라 데이터가 잘못된 형식으로 제공되는 경우 데이터를 다시 전송하십시오).

좋은 생각이 아닐 수도 있습니다. 프로그램의 일부가 형식이 잘못된 데이터로 함수를 호출하는 것을 발견하면 FIX THAT PART 는 호출 된 함수를 변경하여 나쁜 데이터를 소화하지 못하도록합니다.

이것은 클래스와 함수 자체가 일부 입력이 잘못되었을 때 경고하고 때로는 수정하지 않기 때문에 내가 전달하는 데이터를 모든 함수에 맞추는 데 소요되는 시간을 크게 줄였습니다. 더 이상 전체 코드를 통해 디버거와 함께 가야 건초가 어디로 갔는지 알아낼 수 있습니다.

코드의 품질 및 유지 관리 성을 향상시키는 것은 장기적으로 시간을 절약 해줍니다 (여러 가지 기능에 내장 된 자체 수정 기능에 대해 다시 경고해야합니다. 버그의 교묘 한 소스 일 수 있습니다. 프로그램이 충돌하지 않으며 화상이 올바르게 작동한다는 것을 의미하지는 않습니다 ...)

마지막으로 귀하의 질문에 대답하려면 : 그렇습니다. 방어 적 프로그래밍 (즉, 제공된 매개 변수의 유효성을 확인하는 것)은 좋은 전략입니다. 즉 , 자신이 말했듯이 코드가 부적절 하고 냄새 가 나는 부분을 ​​리팩터링하는 데 약간의 시간을 할애 할 것을 강력히 권장합니다. 깨끗한 코드에 대해 항상 걱정하고 더 많은 시간을 소비하고 싶습니다 - 당신은 깨끗한 코드를 유지하지 않을 경우 새로운 기능을 구현하는 부수 버그 깨끗한 코드를 유지하고 힘든 시간을하지 않습니다에서 "저장"두 배의 시간을 보내고 있습니다 ... 새로운 기능에 대한보다 "청소" 기술 부채 캔 당신을 분쇄하십시오.

괜찮아요. 나는 FoxPro에서 코딩을했는데, TRY..CATCH를 거의 모든 큰 기능에서 사용했습니다. 이제 JavaScript / LiveScript로 코딩하고 "내부"또는 "개인"기능의 매개 변수를 거의 확인하지 않습니다.

"확인해야 할 양"은 선택한 프로젝트 / 언어에 따라 코드 기술에 따라 다릅니다.