복잡한 소프트웨어는 얼마나 많은 중복성 / 강건성을 구현해야합니까?

이 질문의 초점 : 일부 소프트웨어는 소프트웨어의 하나 이상의 내부 오류에도 불구하고 "최종적으로 성공 / 만족스러운"결과의 가능성을 높이기 위해 "추가 작업"을 수행하므로 이러한 오류가 발생하면 실행 시간이 길어집니다. 결과가 성공적이면 사용자 모르게이 모든 것이 발생합니다.

복잡한 소프트웨어의 정의 :

• 평생 동안 10 명 이상의 개발자가 작성 (기여) 한 코드를 포함하며 동일한 시간대로 작성되지 않음
• 각각 10 가지 이상의 외부 라이브러리에 따라 달라짐
• 일반적인 소프트웨어 작업 (사용자가 원하는 결과를 생성하기 위해)에는 10 개 이상의 입력 매개 변수가 필요합니다. 여기서 대부분의 기본값이 있지만 사용자가 제어해야하는 경우 구성 할 수 있습니다.
• 가장 중요한 것은 수행중인 작업과 관련하여 적절한 복잡성을 갖는 소프트웨어, 즉 불필요하게 복잡하지 않은 소프트웨어입니다 .

편집 : 복잡한 것은 무엇입니까? Complex와 Complicated 사이에는 큰 차이가 있음을 참조하십시오 . (직접 링크)

이 질문에서 중복 / 견고성의 정의 :
(주석에 따라 견고성 추가)

• 현재 매개 변수 세트를 사용할 때 소프트웨어 태스크가 실패한 경우 다른 매개 변수를 시도하십시오.
  • 분명히 이러한 "다른"매개 변수가 다른 코드 경로를 사용하여 결과적으로 다른 결과를 얻을 수 있다는 내부 지식이 있어야합니다.
  • 때때로 이러한 다른 코드 경로는 외부 라이브러리의 관찰에 따라 선택됩니다.
• 마지막으로 수행 된 실제 작업이 사용자의 사양과 약간 다른 경우 사용자에게 불일치에 대한 보고서가 표시됩니다.
• 마지막으로 10 개 이상의 구성 가능한 매개 변수와 마찬가지로 중복 및보고도 구성 할 수 있습니다.

그러한 소프트웨어의 예 :

• 데이터베이스 마이그레이션
  • 사업 데이터베이스
  • 소스 제어 데이터베이스 등
• Word 문서와 OpenOffice 문서, PowerPoint 및 OpenOffice Draw 등의 일괄 변환
• 전체 웹 사이트 자동 번역
• Doxygen과 같은 소프트웨어 패키지를 자동으로 분석하지만 분석이보다 신뢰할 수 있어야하는 곳 (예 : 문서 도구가 아님)
• 패킷이 손실되고 여러 번의 재 시도가 예상되는 네트워크 통신

이 질문은 원래 의도적으로 잘못된 코드 를 어떻게 처리합니까?
그러나 이제 소프트웨어 팽창의 원인 중 하나에 만 초점을 맞 춥니 다. 이 질문은 새로운 기능 추가와 같은 소프트웨어 팽창의 다른 원인을 다루지 않습니다.

아마도 관련 :

• (거대한) 프로젝트에서 복잡한 코드를 다루는 방법
• 사람들은 어떻게 코드를 작성하는 것이 매우 복잡하고 읽기 어려운가요?

이것은 기술적 문제가 아닌 비즈니스 문제입니다.

때로는 연구원이나 프로토 타입으로 코딩하고 있기 때문에 견고성이 매우 낮은 무언가를 만들 것입니다. 그것이 깨지면, 우리는 그것을 고친다. 코드를 곧 폐기 할 경우 추가 마법에 투자 할 필요가 없습니다.

그러나 시스템 사용자가 강력해야한다면 그렇게 구축해야합니다. 또한 필요하지 않은 중복성 / 강건성을 무시하면서 장기적인 성공을 극대화해야하는 방식으로 구체적으로 강력해야합니다.

일반적으로 거칠게 시작한 다음 시간이 지남에 따라 견고성을 추가합니다. 나는 일반적인 계획 과정에서이 부분과 같은 질문을 자주합니다. 나는 일반적으로 익스트림 프로그래밍 스타일을 사용하여 원하는 기능을 길게 만들고 견고성 기능도 넣습니다. 예를 들어 "시스템은 단일 상자의 장애에도 불구하고"는 "사용자는 Facebook 자격 증명을 사용하여 가입 할 수 있습니다"와 혼동됩니다. 어느 것이 먼저 나올지라도 나는 먼저 빌드합니다.

복잡한 소프트웨어는 일반적 입니다 당신이 아마 알고 있지만, 분명히 그게 할 수있는 가장 좋은 방법은 아니에요 있기 때문에 개발자들이 기존의 코드보다는 시도 "에 압정"에 경향이 있기 때문에 훌륭한 세부 사항 어떻게 소프트웨어 작품을 이해하는 중복.

그러나 어느 정도의 중복성이 허용되어야하는지 물으면 아무 말도하지 않을 것입니다. 중복성은 복잡성의 여러 부작용 중 하나 인 단순성의 대명사입니다. 시간이 더 중요하다면 단순성이 뒷자리를 차지할 것이지만, 시간이 본질이라고 주장하는 사람들은 실제로 소프트웨어 개발을 돌보는 사람들은 거의 없다고 강조합니다. 일반적으로 프로젝트 관리자는 가능한 한 빨리 작업을 완료해야하므로 더 시급한 문제로 돌아갈 수 있지만 작업이 언제 완료되는지 아는 것은 프로그래머의 의무입니다. 나는 의도했던대로 프로그램에 성공적으로 통합 할 때까지 작업이 완료되지 않았다고 생각합니다. 아마도 프로그램이 복잡 할 것입니다.

그러나 그렇게 할 때 중복 코드를 생성해야 할 수도 있습니다. 프로젝트가 이미 중복되어 있다면, 실제로 보스가 몇 주 동안 죽일 필요가 없다고 가정하면 패턴을 계속 유지하는 것이 더 간단 할 수 있습니다. 전체 프로젝트를 재구성 할 수 있습니다.

편집 : 질문의 표현에 비추어 견고성에 대해 조금 추가하겠습니다. 제 생각에는 매개 변수 검사는 A) 날짜 값과 같은 매우 구체적인 형식을 문자열로 수락하거나 B) 다양한 매개 변수가 잠재적으로 서로 충돌하거나 상호 배타적 일 경우에만 수행해야합니다.

A)를 사용하면 매개 변수가 특정 형식과 일치해야하는 요구 사항은 일반적으로 메서드의 필요성 (예 : 문자열에서 날짜로 변환)에 중요합니다. 기술적으로 그것은 여전히 ​​필요하지 않고 프로그램에서 발생할 수 있지만 이러한 가능성을 제거하고 찾고있는 데이터 유형을 나타내는 것으로 알고있는 매개 변수 만 허용하는 것이 좋습니다. 예를 들어 포인트는 변환되지 않습니다. 변환도 수행해야하는 경우 유틸리티 메서드를 사용하여 문자열을 메서드에 전달하기 전에 변환하십시오.

B)에있어서, 상호 배타적 인 파라미터는 나쁜 구조를 나타낸다. 하나의 사례를 처리하는 클래스와 다른 방법으로 처리하는 클래스가 두 개 있어야합니다. 중복성을 피하기 위해 모든 공통 작업을 단일 기본 클래스에서 수행 할 수 있습니다.

메소드의 매개 변수 수가 10 이상이되는 상황에서 자주 변경되지 않는 모든 매개 변수가 포함 된 속성 파일을 고려하기 시작합니다. 변경되면 특성 파일에 기본값을 저장하고 런타임시 기본값을 대체 할 수있는 "setPropertyName ()"메소드를 추가 할 수 있습니다.

소프트웨어는 사용자 실수를 용서하고 프로그래머 실수를 완전히 용인해야합니다.

즉, 소프트웨어는 매우 강력해야하며 사용자 입력 오류 및 시스템 구성 오류와 같은 항목을 원활하게 복구 할 수 있어야합니다. 오류가 발생한 위치 (입력 상자, 구성 파일, 명령 줄 인수 등)와 어떤 제약 조건이 위반되었는지 ( "X 자 미만이어야 함", "유효한 옵션은 [X , Y, Z] "등 ...) 추가적인 견고성을 위해 소프트웨어는 대안을 제안하거나 합리적인 기본값을 사용할 수 있습니다 (그러나 사용자가 지정한 것을 정확하게 사용하고 있지 않다는 것을 항상 표시해야합니다).

다른 기본값으로 자동 재 시도가 필요한 많은 상황을 생각할 수 없지만 일부가 있습니다 (통신 링크를 설정하기 위해 자동 재 시도하는 것이 합리적입니다). 나는이 수준의 '중복성'이 비즈니스 결정이라는 @William에 동의합니다.

반면 프로그래머 오류에 대한 런타임 견고성이 없어야합니다. 함수 매개 변수에 대한 전제 조건이있는 경우 런타임 검사가 아닌 어설 션으로 검사해야합니다. 중복 된 errror 점검 및 호출 매개 변수에 동일한 매개 변수 3 ~ 4 레벨에 대한보고를 보는 것은 제 애완 동물입니다.

 int A(int x)
 {
   if (x==0) return -1
   ...
 }
 int B(int x)
 {
   if (x==0) return -1
   err = A(x)
   if (err) return err;
   ...
 }
 // and so on and so on....

이것은 불필요한 추가 복잡성 일뿐입니다. 한 함수가 다른 함수를 잘못 사용하여 발생한 오류를 처리하는 방법을 알아내는 데 시간을 소비해서는 안됩니다. 이것이 '견고성'유형 인 경우에는 필요하지 않습니다. asserts와 철저한 통합 테스트로 교체하십시오.

요구 사항입니다.

견고성에 대한 요구 사항이 있습니까?

"통신 링크가 실패하면 잘못된 패킷이 삭제됩니다." "링크가 다시 작동하면 트랜잭션이 두 번 처리되지 않습니다."

오류 복구에 대한 유스 케이스가 있어야합니다 (그렇지 않으면 어떻게되는지 알 수 있습니까?)

필요할 때 견고성을 발명하기 위해 프로그래머에게 맡기면 "마법의"시스템이됩니다.

모든 마법 시스템은 시간이지나면서 엉뚱한 마술이됩니다. 백그라운드의 오류 수정은 오류 발생을 숨기므로 오류가 수정되지 않으므로 시스템은 결국 엔트로피 상태가 더 크게 저하됩니다. 항상 오류를 수정하므로 쓰레기처럼 실행됩니다. 시스템이 영구적으로 저하 된 상태로 들어 가지 못하게하는 제한이 있어야합니다.

일부 작업은 특히 데이터베이스와 같은 외부 리소스에 의존하는 경우 "다시 시도"방식을 보증합니다. 예를 들어, 데이터베이스에 연결할 수 없거나 쿼리가 실패하면 작업을 특정 횟수만큼 재 시도하여 오류를 포기하고 더 높은 수준으로 던질 수 있습니다. 그러나 일부 논리에서 동일한 것을 여러 번 시도하는 것은 실제 문제를 숨기는 잘못된 코드와 마 법적 사고의 증상 인 경우가 많습니다.