| English | 의미 |
|---|---|
| modular/ˈmɒdjʊlə/ | 모듈화 |
두 가지 깔끔한 설계는 다른 평균을 보고할 수 있습니다
- 가상의 기록에는 점수 80, 결측 및 100이 포함됩니다. 결측을 0으로 처리하면
(80 + 0 + 100) / 3 = 60이 되며, 결측 결과를 생략하면(80 + 100) / 2 = 90이 됩니다. - 분리된 메서드는 두 결과 모두를 정확하게 계산할 수 있습니다. 조직은 보고 정책을 결정하지 않습니다: 결측의 의미를 무엇으로 정의할지, 누가 결정할지, 그리고 보고서에 어떤 분모를 표시할지를 결과를 사용하기 전에 명확히 하십시오.
점수는 80, 부재 중이며 100입니다. 사용 가능한 점수 정책에 따라 평균은 얼마입니까?
난이도 2/5 · 140 코인 + 오늘 첫 완료 시 소액 보너스
현재 점수의 합은 180이고, 현재 점수의 개수는 2이므로, 180/2 = 90입니다.
요구사항을 계약으로 전환하기
- 결측이 미시도 평가 과제, 배정되지 않은 과제, 또는 아직 입력되지 않은 데이터를 의미하는지 명시하십시오. 이러한 사례들이 동일한 규칙을 공유할 필요는 없으며, 가상의 예시는 결과와 Effects를 보여줄 뿐 학교 grading policy를 규정하지 않습니다.
- 수용되는 입력, 결측 값의 처리 방법, 결과를 명시하십시오. 규칙이 "사용 가능한 점수의 평균"이라면, 모든 값이 결측인 기록에는 평균이 없습니다. 0을 임의创造하거나 0으로 나누는 대신 이 경우를 명시적으로 보고하십시오.
검증에 대한 역할 분리
- 모듈러(Modular) 설계는
readScores,averageAvailable및printReport을 분리합니다. 평균 메서스는 파일을 읽거나 형식화된 출력을 캡처하지 않고도 알려진 값을 사용하여 검증할 수 있습니다. - 분리(separation)는 인터페이스가 명확하게 유지될 때 도움이 됩니다. 부재(absence)의 의미 변경은 여전히 계산, 보고 및 검증에 대한 변경을 필요할 수 있으며, 작은 메소드와 좋은 이름만으로는 이러한 의존성을 방지할 수 없습니다.
일반 사례 및 경계 사례 확인
- 사용 가능한 점수 정책에 대해, [80, 결격, 100]가 90를, 단일 80가 80를, [결격, 결격]이 합의된 "결과 없음" 결과를 생성함을 확인하십시오. 단순히 프로그램이 실행되는지만 확인하지 마십시오.
- 아래 계산은 누락된 값에
null을 사용합니다. 이는 이중 평균(double average)을 반환하고 모든 값이 누락된 경우를 거절합니다. 일반적인 점수의 비공/null이 아닌 배열을 가정하며, 입력 검증과 보고는 별도의 책임입니다.
public class AverageAvailable {
public static double averageAvailable(Integer[] scores) {
double total = 0;
int present = 0;
for (Integer score : scores) {
if (score != null) {
total += score;
present++;
}
}
if (present == 0) {
throw new IllegalArgumentException("No available scores");
}
return total / present;
}
}
모듈화된 설계(독립적이고 이름이 명확한 부분)는 주로 더 쉽게...
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
모듈화는 변경을 안전하게 만들고 부품을 재사용 가능하게 합니다.
여러 호출자가 하나의 메서드를 공유할 때, 해당 메서드를 수정하면 중복된 복사본을 편집하지 않고 모든 호출자에게 혜택을 줄 수 있습니다.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
참: 호출자는 구현을 재사용합니다. 이 변경 사항의 계약 및 영향은 여전히 검토해야 합니다.
데이터나 논리에 편향이 있으면 대규모에서 불공정한 결과가 발생할 수 있습니다.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
설계 선택은 실제 사람에게 영향을 미칩니다.谁的에 영향을 받는지를 고려하십시오.
입력 및 출력된 결과와 무관하게 평균 계산 자체를 독립적으로 검증하기 위해 어떤 설계가 해당 책임을 가장 잘 분리합니까?
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
계산을 입력 및 출력과 분리하면, 다른 연산 없이도 점수 확인을 수행할 수 있습니다. 단, 메소드가 작다고 해서 반드시 정확성을 보장하지는 않습니다.
프로그램 설계는 단순히 외관적이며 코드의 안전한 변경 가능성에는 영향을 주지 않습니다.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
설계는 프로그램이 안전하게 수정될 수 있는 방식을 결정합니다.
표시된 averageAvailable 메소드는 모든 값이 없는 배열에 대해 0을 반환합니다.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
거짓: 사용 가능한 점수가 없어 평균을 정의할 수 없으므로 IllegalArgumentException으로 이 경우를 거부합니다.
관련 사용자에게 결과(consequences) 보고
- 90의 보고는 세 건 중 두 개의 사용 가능한 점수를 평균화하고 하나의 부재 result를 제외했음을 명시해야 합니다. 단순히 90만 보고하면 독자가 outcomes를 비교하기 위해 필요한 정보를 숨기는 것입니다.
- 데이터와 정책으로 인해 영향을 받을 수 있는 사람을 검토하십시오. 일관된 계산임에도 불구하고 다양한 종류의 부재를 부적절하게 처리할 수 있으므로, 합의된 요구사항을 테스트하고 결과를 사용자가 이해할 수 있게 하십시오.
모듈러화는 정책을 점검하고 테스트하기 쉽게 하지만, 해당 정책이 공평하거나 적절함을 보장하지는 않습니다. 평균 60과 90은 서로 다른 분모(denominators)를 사용합니다. 더 나은 result처럼 보이는 것을 조용히 선택하기보다 규칙을 선택하고 공개하십시오.
좋은 설계인가, 나쁜 설계인가?
설계 선택은 실질적인 결과를 낳습니다. 각 결과를 분류하십시오.
설계 전반에 걸쳐 정책 변경 적용
- 승인된 요구사항이 미시도한 과제를 0으로 카운트하도록 변경되면, 분모, 관련 예제, 체크 및 보고 문구를 업데이트하십시오. 메소드를 재사용하는 것은 해당 메소드의 계약(contract)이 새로운 task와 일치할 때만 유용합니다.
- 가용성(testability), 정확성(correctness) 및 사용자 이해도를 별도로 검토하십시오. 명확한 경계(boundaries)는 일부 변경 리스크를 줄이지만, 메소드의 계약이 변경될 때는 호출자(callers)와 공유된 가정(assumptions)을 여전히 확인해야 합니다.
프로그램 설계는 유지보수성과 사람에 영향을 미칩니다. behavior를 검증할 수 있도록 책임을 분리하고, 누락된 데이터의 정책을 정의하며, 그 경계 사례를 테스트하고 분모를 공개하십시오. 정확한 산술 연산과 깔끔한 구조만으로는 적절한 정책을 자체적으로 확립할 수 없습니다.
Match the change to the issue it addresses.
난이도 2/5 · 140 코인 + 오늘 첫 완료 시 소액 보너스
A modular structure enables checking but cannot choose the right policy by itself.