Maintenance script: Repair batch-0001 pages from live compare

2026-03-26T23:56:05Z

Repair batch-0001 pages from live compare

← Older revision		Revision as of 23:56, 26 March 2026
Line 8:		Line 8:

	Wiki:RefactorLowHangingFruit . 고쳐야 할 것이 많다면 오히려 조금씩 고치도록 한다(그리고 고치는 작업을 엔지니어링 태스크로 혹은 유저 스토리로 명시화해서 관리한다). 고치는 중에, 5분 정도의 단위로 테스트를 해봐서 하나도 문제가 없도록 고쳐 나가야 한다. 섬과 육지를 연결하는 다리가 있을 때, 이걸 새 다리로 교체하려면 헌 다리를 부수고 새 다리를 만드는 것이 아니고, 새 다리를 만든 다음 헌 다리를 부수어야 하는 것이다.		Wiki:RefactorLowHangingFruit . 고쳐야 할 것이 많다면 오히려 조금씩 고치도록 한다(그리고 고치는 작업을 엔지니어링 태스크로 혹은 유저 스토리로 명시화해서 관리한다). 고치는 중에, 5분 정도의 단위로 테스트를 해봐서 하나도 문제가 없도록 고쳐 나가야 한다. 섬과 육지를 연결하는 다리가 있을 때, 이걸 새 다리로 교체하려면 헌 다리를 부수고 새 다리를 만드는 것이 아니고, 새 다리를 만든 다음 헌 다리를 부수어야 하는 것이다.
	~~~cpp~~ formatText(String data)		<code>formatText(String data)</code>
	을 ~~{{{~cpp~~ formatText(String data,boolean shouldBeVeryFancy)~~}}}~~로 바꾸어야 한다면, ~~{{{~cpp~~ fancibleFormatText~~}}}~~를 만들고, 기존의 ~~{{{~cpp~~ formatText~~}}}~~를 호출하는 곳을 ~~{{{~cpp~~ fancibleFormatText(data,false)~~}}}~~로 하나씩 바꿔나가면서 계속 테스트를 돌려보면 된다. 이게 완전히 다 되었다고 생각이 들면 ~~{{{~cpp~~ formatText~~}}}~~ 정의를 지워본다. 문제가 없으면 ~~{{{~cpp~~ fancibleFormatText~~}}}~~를 ~~{{{~cpp~~ formatText~~}}}~~로 rename method 리팩토링을 해준다. 하지만 만약 이 작업이 너무 단순 반복적인 경우에, 충분히 용기가 생기고, 또 확신이 들면 이 작업을 자동화할 수 있다(OAOO). 예컨대 IDE에서 지원하는 자동 리팩토링을 사용하거나, 정규식을 통한 바꾸기(replace) 기능을 쓰거나, 해당 언어 파서를 이용하는 간단한 스크립트를 작성해서 쓰는 방법 등이 있다. 이렇게 큰 걸음을 디디는 경우에는 자동화 테스트가 필수적이다.		을 <code>formatText(String data,boolean shouldBeVeryFancy)</code>로 바꾸어야 한다면, <code>fancibleFormatText</code>를 만들고, 기존의 <code>formatText</code>를 호출하는 곳을 <code>fancibleFormatText(data,false)</code>로 하나씩 바꿔나가면서 계속 테스트를 돌려보면 된다. 이게 완전히 다 되었다고 생각이 들면 <code>formatText</code> 정의를 지워본다. 문제가 없으면 <code>fancibleFormatText</code>를 <code>formatText</code>로 rename method 리팩토링을 해준다. 하지만 만약 이 작업이 너무 단순 반복적인 경우에, 충분히 용기가 생기고, 또 확신이 들면 이 작업을 자동화할 수 있다(OAOO). 예컨대 IDE에서 지원하는 자동 리팩토링을 사용하거나, 정규식을 통한 바꾸기(replace) 기능을 쓰거나, 해당 언어 파서를 이용하는 간단한 스크립트를 작성해서 쓰는 방법 등이 있다. 이렇게 큰 걸음을 디디는 경우에는 자동화 테스트가 필수적이다.

	그런데 만약 테스트 주도적 개발을 제대로 못하고/안하고 있다면?		그런데 만약 테스트 주도적 개발을 제대로 못하고/안하고 있다면?
Line 18:		Line 18:
	----		----
	[[ExtremeProgramming]]		[[ExtremeProgramming]]

imported>Unknown at 05:22, 7 February 2021

2021-02-07T05:22:57Z

New page

코드 공동 소유

만약 누군가가 클래스의 인터페이스를 변경했으면 변경된 클래스를 사용하는 모든 클라이언트 코드에서 오류가 발생할 것이다. 그렇게되면 클래스를 변경한 사람이 모든 오류를 수정해야만 하는가, 아니면 먼저(컴파일 시간에 오류가 발생할꺼 같은데) 발견한 사람이 수정해야 하는가?

코드 커밋된 상태에서 하나라도 테스트 실패가 있다면 롤백하거나, 수정한다. 고로, 클래스를 변경한 사람이 모든 오류를 수정해야 한다. 만약 이후에 오류를 발견하게 된다면 누구든지 수정할 수 있고, 또 그래야 한다.

특히 이미 많이 코드가 작성된 시점에서 클래스의 인터페이스를 변경하는 것은 너무 많은 코드를 바꿔야하기 때문에 걱정(귀찮음?)이 앞설 수 있다.

Wiki:RefactorLowHangingFruit . 고쳐야 할 것이 많다면 오히려 조금씩 고치도록 한다(그리고 고치는 작업을 엔지니어링 태스크로 혹은 유저 스토리로 명시화해서 관리한다). 고치는 중에, 5분 정도의 단위로 테스트를 해봐서 하나도 문제가 없도록 고쳐 나가야 한다. 섬과 육지를 연결하는 다리가 있을 때, 이걸 새 다리로 교체하려면 헌 다리를 부수고 새 다리를 만드는 것이 아니고, 새 다리를 만든 다음 헌 다리를 부수어야 하는 것이다.
~cpp formatText(String data)
을 {{{~cpp formatText(String data,boolean shouldBeVeryFancy)}}}로 바꾸어야 한다면, {{{~cpp fancibleFormatText}}}를 만들고, 기존의 {{{~cpp formatText}}}를 호출하는 곳을 {{{~cpp fancibleFormatText(data,false)}}}로 하나씩 바꿔나가면서 계속 테스트를 돌려보면 된다. 이게 완전히 다 되었다고 생각이 들면 {{{~cpp formatText}}} 정의를 지워본다. 문제가 없으면 {{{~cpp fancibleFormatText}}}를 {{{~cpp formatText}}}로 rename method 리팩토링을 해준다. 하지만 만약 이 작업이 너무 단순 반복적인 경우에, 충분히 용기가 생기고, 또 확신이 들면 이 작업을 자동화할 수 있다(OAOO). 예컨대 IDE에서 지원하는 자동 리팩토링을 사용하거나, 정규식을 통한 바꾸기(replace) 기능을 쓰거나, 해당 언어 파서를 이용하는 간단한 스크립트를 작성해서 쓰는 방법 등이 있다. 이렇게 큰 걸음을 디디는 경우에는 자동화 테스트가 필수적이다.

그런데 만약 테스트 주도적 개발을 제대로 못하고/안하고 있다면?

일단 리팩토링을 필요로 하는 부분을 한정하고, 그 주위에 테스트 프로그램을 조금씩 붙여 나가야 한다. 그리고 리팩토링을 한다. 간혹 컴파일러를 테스트 프로그램으로 여기는 약간은 위험한 방법도 있다. see also Wiki:RefactoringLegacyCode

Contributors: JuNe, [[1002]], [[Benghun]], [[sun]]
----
[[ExtremeProgramming]]

CollectiveOwnership - Revision history

Maintenance script: Repair batch-0001 pages from live compare

imported>Unknown at 05:22, 7 February 2021