Maintenance script: Repair MoniWiki formatting after migration

2026-03-29T00:34:31Z

Repair MoniWiki formatting after migration

← Older revision		Revision as of 00:34, 29 March 2026
Line 43:		Line 43:

	see also Seminar:가위바위보 , Wiki:SwitchStatement		see also Seminar:가위바위보 , Wiki:SwitchStatement
	--JuNe		--[[JuNe]]

Maintenance script: Repair batch-0003 pages from live compare

2026-03-27T00:29:11Z

Repair batch-0003 pages from live compare

← Older revision		Revision as of 00:29, 27 March 2026
Line 44:		Line 44:
	see also Seminar:가위바위보 , Wiki:SwitchStatement		see also Seminar:가위바위보 , Wiki:SwitchStatement
	--JuNe		--JuNe

imported>Unknown at 05:28, 7 February 2021

2021-02-07T05:28:09Z

New page

[[가위바위보]] 구현 코드들을 보면 케이스 문을 많이 쓰거나 혹은 비슷한 구조의 if 문이 중복된 경우가 많습니다.

케이스문이 줄줄이 나오는 것이나 비슷한 구조가 반복되는 것이나 모두 "나쁜 냄새"(Moa:BadSmell )입니다. 조금이라도 나쁜 냄새가 나면 바로바로 냄새 제거를 해야 합니다. 예컨대, 반복되는 케이스문은 테이블 프로그래밍(Table/Data Driven Programming)으로 해결할 수 있습니다.

그리고, 사고의 도구들을 적극적으로 활용하기 바랍니다. 스테이트 다이어그램이나, 심지어는 x,y 좌표계를 사용하는 것, 혹은 서브루틴을 통해 문제를 소문제(subproblem)로 나누는 것도 아주 훌륭한 사고의 도구가 됩니다 -- 문제의 복잡도를 낮춰주기 때문이죠.

예컨대, 다음과 같은 소문제가 있겠죠:
* 텍스트화일로부터 입력자료 읽고 해석하기
* 둘 중에 누가 이겼는지 판단하기
* 사람별로 이긴 횟수, 진 횟수 누적하기
* 결과 보여주기

이중에서 두번째 "판단하기"를 TDD와 리팩토링을 통해 다음과 같이 만들었습니다.

GAWI=1
BAWI=2
BO=3

def getWinner(p1,p2):
"""return 1 when p1 wins, 2 when p2 wins, 0 when a tie"""
if p1>=p2:
return p1-p2
else:
return p1-p2+3

여기서 한단계 더 리팩토링이 가능할까요?

def getWinner(p1,p2):
"""return 1 when p1 wins, 2 when p2 wins, 0 when a tie"""
return (p1+2*p2)%3

>>> getWinner(GAWI,BO)
1
>>> getWinner(BO,GAWI)
2
>>> getWinner(BAWI,GAWI)
1
>>> getWinner(BO,BO)
0

사실은 이런 종적 상태로서의 프로그램이 중요한 것이 아니고, 어떻게 이런 프로그램에 도달할 수 있었는지, 그 사고와 프로그래밍의 과정이 중요합니다.

see also Seminar:가위바위보 , Wiki:SwitchStatement
--JuNe

SwitchAndCaseAsBadSmell - Revision history

Maintenance script: Repair MoniWiki formatting after migration

Maintenance script: Repair batch-0003 pages from live compare

imported>Unknown at 05:28, 7 February 2021