첫 번째 작업
코드 구조 분석
UML의 클래스 다이어그램은 다음과 같습니다 :
측정 및 분석 :
작품 내 생각은 출력 후 유도 및 저장 TreeSet의 다음 빈 공간과 다른 문자를 제거 각 항목을 읽어 정규 표현식을 사용하는 것입니다.
작업의 난 단지 두 개의 클래스, 마스터 클래스 및 항목 클래스를 사용했다. 나는 매우 높은 방법의 정도와 복잡성을 결합 프로세스 중심의 사고에서 여전히 그들을 볼 시험에 도움이되지 않으며 그 버그를 발견 할 수 있습니다.
분석 버그
재정의 compareTo 메소드 동안, 나는 심각한 실수를했다. TreeSet의 이진 트리이므로 compareTo와 함수가 반환되도록 값은 현재의 구성 요소는 좌우 서브 트리의 서브 트리를 판단한다. 같은 항목 인덱스가 병합됩니다 보장 할 수 있도록 compareTo와 기능, 난, 두 요소의 크기를 비교하기 위해 인덱스를 사용합니다. 그러나 문제는 인덱스가 나는 두 계수의 크기를 비교하기로 결정했습니다 동시에하지 않을 때 심각한 문제로, 리드 (편리하게 긍정적 인 첫번째 장소에있는 항목을)입니다. 동일한 개의 인덱스 경우 비정상 병합하는 것이 가능하다 동일한 계수 번이 손실 될 수있는 경우 상기.
찾을 상호 테스트 버그
나는 각각 다른의 조금 다른 학생들 코드를 읽어 비트 및 일부 학생들은 나중에 작업을 쓰기로 진행할 수 있음을 발견 측정하지만, 형식은 WF의 출력을 일으키는 원인이 주석 판사의 일부가 아닙니다.
객체 생성 모드
I 작성하는 데 사용되는 일이 본질적으로 판단 (또는 일정한 전력 기능)는 입력 문자열과 직접 복귀 Item 객체의 유도로의 getItem 방법 개체. 그러나 단점은 높은 복잡성, 버그를 찾기 어려운 나타나는 것입니다. 일반적으로 확장 성, 더 판단 조건을 추가해야합니다. 공장 모드는 더 나은 사용되어야한다.
경험
그들이 거기에 왜 이러한 노하우를 알고, 또는 다른 일부는 작업 중 일부는 더 위험 문제에 매우 경향이 모르는 사실, 이해가 충분하지 않습니다, 설명 할 수없는 버그를 보일있을 수 있습니다.
두 번째 작업
코드 구조 분석
UML의 클래스 다이어그램은 다음과 같습니다 :
측정 및 분석 :
이 작업은 내가 결정 방식의 단순함을 확장하기 위해 섹스를 포기. 직접 해시 맵 합병하여 다음 유도체의 각 수학 식을 사용한다. 읽기 프로세스가 기본적으로 한 번 생각 일반 용어 표현의 증가에 같은 일입니다 판단.
조금 진행,하지만 여전히 특히 복잡한 방법이 있습니다 본 과제의 복잡성을 개선 할 필요가있다.
분석 버그
작업 가이드 책은 WF으로 이어질하지 않습니다 공백 문자의 위치를 설명합니다. 하지만 실수로 공백 문자, WF를 이끌 때문에 제거 공백 문자의 모든 직접 이동하지 않습니다 생각했다. 가 발생했습니다 잘못된 문자가 출력 WF해야하며, 내 프로그램은 시험에 강한 실행되었다.
내 프로그램의 상호 시험 범위 예외의 첨자 아웃 나타났다. 그 이유는 내가 잘못 제거를 국경에있는 목록 리드의 길이의 변화로 이어질 것 목록을 통해 프로세스 루프의 요소임을이다. 내가 인터넷에서 배운 올바른 방법은 요소는 반복자를 사용하여 통과해야한다 제거하는 것입니다.
찾을 상호 테스트 버그
나는 데이터의 내 자신이 있었다 몇 가지 버그 제출을 사용하는 학생들이 세 개의 연속 문자, 직접 던져 예외를 처리하지 않은 것을 발견했다.
객체 생성 모드
생성 된 개체를 추가하는 것은 매우 쉬운 내가 객체 모델이 최적화 된 만드는 작업은, 공장 패턴을 사용하려고하고, 객체의 세부 사항은 사용하는 것이 더 편리하고, 또 다른 설치 방법을 생성합니다.
경험
이 작업은 나에게 지침을주의 깊게 읽기의 중요성을 깨닫게하고, 수요에 대한 명확한 이해가없는 경우, 만족스러운 프로그램을 작성하는 것은 불가능합니다.
세 번째 작동
코드 구조 분석
UML의 클래스 다이어그램은 다음과 같습니다 :
측정 및 분석 :
그래서 입력 과정뿐만 아니라 모든 재구성의 일부를 결정하는, 재귀 때문에이 작업을 수행합니다. 일반적인 생각은 각 항목을 구현의 도출 방법은, 최종적으로 하나의 부모에 의해 관리되며, 그 결과를 출력하는 클래스를 구축 할 수있다.
우리는 방법의 복잡성 중 일부는 다소 높은 여전히 볼 수 있지만 특히 높은 수준의 등장.
분석 버그
내 판단 문자의 일정 기간이 정규 표현식과 일치하지 않는 경우 잘못된 형식을 설명하는 것을 본 과제 WF의 방법으로. 그러나, 내 과실에 디지털이있는 경우 괄호 안에 전자 공간의 결과로 공간을 누락, 그들은 WF 버그를 형성 보도했다.
찾을 상호 테스트 버그
온라인으로 다른 사람의 코드를 학습 한 후, 나는 또한 학생들에게 몇 가지 버그를 식별하기 위해 평가 시스템을 사용, 평가 시스템의 미니어처를 구축, 학생들의 문제는 최적화 및 WF에서 주로 발생, 일부 급우, WF가 판단 학생들 나타난 결함의 최적화, 최적화 괄호 아무것도 상황에서 나타난 출력 결과를 초래 장소 밖으로 최적화는 안된다.
객체 생성 모드
기초의 작업은 여러 가지 새로운 클래스가 일반적으로 공장 모델 더 나은 확장 성을 나타내는의 getItem 방법을 사용할 수 있습니다 추가합니다.
경험
나는이 작업의 어려움이 상대적으로 높은, 또한 나에게 좋은 코드 구조 구축 및 디버그 할 프로그램이 효과를 높일 것을 깨닫게되는 사실이라고 생각합니다.