No older revisions available
No older revisions available
SPEC : http://icpc.baylor.edu/past/icpc2001/Finals/problems.pdf 중 Problem A
----
Requirement 수정 예상궁리 (일단은 떠오르는대로. Testability 를 고려하지 않은 상태로)
----
문제분류
- http://zeropage.org/pds/200272883050/VonNeuman_NoComment.zip - 주석없는 가장 초기 버전
- http://zeropage.org/pds/20027281074/VonNeuman_Comment.zip - 주석 달던중인 버전 (아직 주석없애기 시도 못함)
- TDD접근 방법의 미숙
- 1002 의 개인적으로 생각되는 '미숙' 했다고 생각한 점을 든다면, 평소에 프로그래밍을 하는 리듬이 아니였다는 점. 이전 스타일이라면 일단 문제를 보고 문제를 나누면서 시나리오를 어느정도 만들어 놓은 뒤, 그걸 검증해나간다는 느낌으로 테스트코드를 작성했었는데, 이번의 경우 정말 Extreme 하게 작업한 것 같다. (중반에 CRC 라도 한번 하고 싶었는데, 형에게 물어보고 왠지 '아 내가 알던 방법이 틀린걸꺼야' 하며 그냥 Test 만 생각하게 되었다.) 작업하는 중간 뭔가 석연치 않은 느낌이 들었다면, 아마 대강 이런 느낌이였던 것 같다. 전반적 시각을 한번정도 중간에 정리를 할 필요가 있을건데, 그런 시간을 두지 못한것.
- 1002 의 개인적으로 생각되는 '미숙' 했다고 생각한 점을 든다면, 평소에 프로그래밍을 하는 리듬이 아니였다는 점. 이전 스타일이라면 일단 문제를 보고 문제를 나누면서 시나리오를 어느정도 만들어 놓은 뒤, 그걸 검증해나간다는 느낌으로 테스트코드를 작성했었는데, 이번의 경우 정말 Extreme 하게 작업한 것 같다. (중반에 CRC 라도 한번 하고 싶었는데, 형에게 물어보고 왠지 '아 내가 알던 방법이 틀린걸꺼야' 하며 그냥 Test 만 생각하게 되었다.) 작업하는 중간 뭔가 석연치 않은 느낌이 들었다면, 아마 대강 이런 느낌이였던 것 같다. 전반적 시각을 한번정도 중간에 정리를 할 필요가 있을건데, 그런 시간을 두지 못한것.
- 자료형 배경 지식의 미숙 (처음 STL미사용 접근, 중반부터 STL사용으로 자료형의 일관성문제)
- 중간에 창준이형이 "너희는 C++ 로 프로그래밍을 하면서 STL를 안사용하네?" 라고 했을때, 그냥 막연하게 Java 에서의 Collection Class 정도로만 STL을 생각하고, 사용을 잘 안했다. 그러다가 중반부로 들어서면서 Vector를 이용하게 되었는데, 처음 한두번 이용한 Vector 가 후반으로 가면서 전체의 디자인을 뒤집었다; (물론 거기에는 디미터 법칙을 지키지 않은 소스도 한몫했지만 -_-;) 그걸 떠나서라도 Vector를 써 나가면서 백터 비교 assert 문 등도 만들어 놓고 하는 식으로 점차 이용하다보니 상당히 편리했다. 그러다가 Refactoring Time 때 서로 다른 자료형 (앞에서 array 로 썼던 것들) 에 대해 vector 로 통일을 하다 보니 시간이 비교적 꽤 지연이 되었다.
- 중간에 창준이형이 "너희는 C++ 로 프로그래밍을 하면서 STL를 안사용하네?" 라고 했을때, 그냥 막연하게 Java 에서의 Collection Class 정도로만 STL을 생각하고, 사용을 잘 안했다. 그러다가 중반부로 들어서면서 Vector를 이용하게 되었는데, 처음 한두번 이용한 Vector 가 후반으로 가면서 전체의 디자인을 뒤집었다; (물론 거기에는 디미터 법칙을 지키지 않은 소스도 한몫했지만 -_-;) 그걸 떠나서라도 Vector를 써 나가면서 백터 비교 assert 문 등도 만들어 놓고 하는 식으로 점차 이용하다보니 상당히 편리했다. 그러다가 Refactoring Time 때 서로 다른 자료형 (앞에서 array 로 썼던 것들) 에 대해 vector 로 통일을 하다 보니 시간이 비교적 꽤 지연이 되었다.
- Refactoring Bad Smell 을 제대로 맡지 못함 - 간과하기 쉽지만 중요한 것중 하나로 naming이 있다. 주석을 다는 중간에 느낀점이 있다면, naming 에 대해서 소홀히 했다란 느낌이 들었다. 그리고 주석을 달아가면서 이미 구식이 되어버린 예전의 테스트들 (로직이 많이 바뀌면서 테스트들이 많이 깨져나갔다) 를 보면 디미터 법칙이라던가 일관된 자료형의 사용 (InformationHiding) 의 문제가 있었음을 느낀다.
Requirement 수정 예상궁리 (일단은 떠오르는대로. Testability 를 고려하지 않은 상태로)
- load 를 발생시키는 예를 Passenger 뿐만 아니라 다른 여러가지를 둔다. ex) 여행객 가방, 컨테이너의 경우 traffic load 2, 4 를 발생시킨다.
- PassengerSet Case가 여러개이고 Configuration 은 1개인 경우에 대해서. Configuration 1 : 여러 Case 에 대해 각각 출력하는 경우.
-> 역시 PassengerSet 이 따로 있어서 Configuration 과 같이 협동할 경우엔 쉽게 구현 가능. 그렇지 않은 경우 고생 예상.
- 가장 트래픽이 많이 발생하는 길을 알아낸다. - 복도에 대해서 InformationHiding.
- 복도중에서 일자형 에스컬레이터를 두어본다. - 상동.
- 지금 만든 모듈의 소스 수정없이 GUI 버전으로 재작성하기 - Input / Output 먼저 작성하는 사람들은 가장 고생.
- 출력 Output 의 Sorting 을 2가지로 둔다면?
-> Output 쪽이 따로 나누어진 경우 금방.
| VonNeumannAirport/1002 | 1002 | VonNeumannAirport TDD 재시도중. |
| VonNeumannAirport/인수 | ["Lovelyboy^_^"] | |
| VonNeumannAirport/Leonardong | 한 번 실패 후 재도전한 Python버전 | |
| VonNeumannAirport/남상협 | (namsang) |
문제분류
