U E D R , A S I H C RSS

1thPCinCAUCSE/nullì „ëžµ

1회 경진대회 팀�였� null 팀 전략 (neocoin, 1002)

null 팀� 경우 B 문제 하나를 풀었고 (1시간 5분 정� 소요. 패�티 없�), A 번 문제를 계� 시�하�중 시간초과.

초기 5분

1002ê°€ 5ë¶„ ì§€ê°�ì�„ 했습니다.; 암튼, 35ë¶„ì—� 시작ì�„ 했고, ì�¼ë‹¨ 5ë¶„ì�˜ 시간ì�„ ë‘�ê³  neocoin ê³¼ 1002 는 문제들ì�„ ì�½ì–´ë‚˜ê°€ê¸° 시작했습니다. 한글 문서였기 때문ì—� 3ê°œì�˜ 문제를 훑는ë�°ì—�ë�„ 5ë¶„ì�´ë©´ 충분하ë�”êµ°ìš”. neocoin ì�€ B번ì�„, 1002 는 A번ì�„ ì�¼ë‹¨ ì�½ê³ , C 번ì—� 대해서는 ê°™ì�´ ì�½ì—ˆìŠµë‹ˆë‹¤. 그리고 미리 문제ìœì œìž�쪽ì—�서 난ì�´ë�„를 C > A > B ìž„ì�„ 언급했습니다. 문제를 ì�½ì–´ë‚˜ê°€ë©´ì„œë�„ ì�¼ë‹¨ Bì�˜ 경우가 바로 계산ì�´ 나올 것 같아서 B 를 먼저 해결하기로 ì„ íƒ�했습니다. ê·¸ 다ì�Œì—�는 문제ì—� 대한 ì�´í•´ë�„ê°€ ìƒ�대ì �으로 높았ë�˜ A번ì�„ 해결하기로 했습니다.

ì§„í–‰

�구는 연습장과 ��스 카드, assert 문� �용한 테스트 케�스 등� �용했습니다. 연습장과 ��스 카드는 주로 개개� 수�과 중요 변수들� �기 위해, �는 그림� 그리기 위해 �용했고 (� �구� 용�가 구분�어있진 않았�) 문제� 대해서 답� 나왔다하는 가정하� (문제지� Sample Input->Output � 나와있었기� 가능했습니다.) Backward 로 문제가 해결� �황� 가정하고, 그러기 위해 필요한 변수들� 찾아나가는 방법으로 진행했습니다. 프로그래� 스타�� Structured 스타�� Stepwise Refinement & PBI & assert 를 �용한 TDD 를 사용했습니다.


B 번 진행


한 20분정� 잘못진행했었는�, 첫번째는 1002 가 B 번문제를 제대로 �해하지 못했고 (앞부분만 �고, 문제� input-output � 거꾸로 �단), �번째는 input � 100 �때� output 예�치를 잘못계산한 �태�서 �를 근거로 Test Driven � 시�해서 추후 발견뒤 테스트를 수정하는�안 시간� 낭비했습니다.

Sample 로 제공한 ��터들� 만족시키는 코드는 작성하였으나, 여전히 변수들� 다 뽑아져지지 않아서, 임�� 결과��터 (100� 경우) � 대해 예��는 결과를 ��하고 코드를 작성한뒤, 코드와 결과들, 코드로부터 발견�는 변수들� 토대로 연습장� 기�� 했고, 그러�중 neocoin � �반화 공�� 찾아내었습니다.

ì �절히 중복코드를 삭제하고 난 ë’¤, 한 5ë¶„ì •ë�„ Input-Output 코드를 iostream ê³¼ STL/vector 를 사용하여 작성한 ë’¤ ì�´ë¥¼ ì œìœ, 통과했습니다.

A 번 진행


A 번 진행중 아쉬웠���, 만� � 문제를 바로 풀기전� OO 패러다임으로 해결할 것�가 Structured 패러다임으로 해결할 것�가� 대해 먼저 ��하는 여유를 가졌��면 문제 해결� � 쉽지 않았�까 하는 ��였습니다.

문제� 대해 역시 B 번� 진행하� 스타�대로 Structured 로 진행했는�, 초반� 너무 코드위주로 � 변수들� 뽑아내려고 접근한 것� 문제가 �었� 것 같습니다. 여유를 �고 페�� 프로그래�� 했어�. 바늘들� 대해서 OO 로 접근했으면 좀 � 쉽지 않았�까 ��.

마치며

지난번 IPSC 경험때는 맨땅� 해딩하는 �낌�였는�, �번�는 비� 입�하지 못했지만, ��� 과정들� ���으로 �어난 �� 대해서 개��으로는 �거웠고 명쾌했습니다. 급조�어 2주만� 만난 Pair 치고 �발� 잘 맞았습니다. (�건 방학 �달�안 ProjectPrometheus 때 하� 서로 싸워대어서. -_-;)

미리 예제문제로 제시� 5문제중 어려웠었� 뒤� 3문제들� �� 풀어보고 훈련했었다면 실전�서� � 여유있고 ���� 작업� 할 수 있었으리� ��하며. 그리고, 초반� 바로 TDD 로 나가는 것보다, 문제� 대한 여러 접근방법� 둔 뒤, 하나를 고르고 그� 대해 TDD 로 나가는 것� � 좋았� 것��고 ��. (TDD를 바로 문제 Approach 기법으로 �용하는것 보단, 해당 문제 접근방법� 대해 빨리 필요한 변수들� 발견해나가고, 명확하게 해주는� � 효과가 �다는 ��� 들어서)

문제를 풀때 우스개로 �야기했�것� '수학�� 접근�� 공학�� 접근��'(페르마� 마지막정리 책� 나왔� 예. 즉, 연역/귀납). �런문제� 경우 문제 풀기전 '어�쪽 접근� � 유용할까' �리를.; 개��으론 연역� 약해서 후�를..; --1002

1002가 사실� 모� �줘서 너무 �사합니다. 얼마나 기억� �듬었�까..

문제를 푸는 �안, 굉장히 여유롭다는 �낌� 들었습니다. �당히 달려나간다고 할까요. 위� 언급� 2가지� 실수가 없었다면, A를 넘어 C번� 노려 봄�한 �낌� 듭니다. �런 것들� 연습으로 체화�는 것�겠지요. 다� ipsc를 ��게 기다려 봅니다.

시간 지연� �유는, 성급한 방법론� 선�과 믿는 것� 가장 �심하� �는 디버깅 �칙� 시간� 쫓겨서 ��� 하지 못한�으로 ��합니다.

마지막으로, 2주만� 만난 팀� 전략� 쓴다니, 약간 사기죠 ^^; --neocoin

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:22:08
Processing time 0.0415 sec