1. 더 나은 코드 작성을 위한
리팩토링
1

2. 학습목표
-

3. 응용

4. 애플리케이션

5. 작성시

6. 만들어지는

7. 나쁜

8. 코드들을

9. 구별할

10. 수

11. 있다.

12.
-

13. 나쁜

14. 코드를

15. 객체지향

16. 설계가

17. 적용된

18. 코드로

19. 변경하는

20. 기법을

21. 배우고

22. 적용할

23. 수

25. 있다.
-

26. 실제

27. 코드에서

28. 잘못된

29. 부분을

30. 찾아내

31. 이해하기

32. 쉬운

33. 구조로

34. 변경할

35. 수

36. 있다.

37.
2
디자인패턴

38.
1. 코드개선
1. 객체지향 특징
2. 코드 개선 [실습]
3
디자인패턴

39. 1.객체지향 특징
4

40. 추상화 Abstraction

41. 객체지향 특징
주어진 문제나 시스템 중에서
중요하고 관계 있는 부분만
을 분리하여 간결하고
이해하기 쉽게 만드는 작업
5

42. 상속 Inheritance

43. 객체지향 특징
직접 구현하지 않고 부모 클
래스로부터 물려받은 기능
이나 데이터를 말하며 재사
용을 위한 보편적인 기법
6

44. 캡슐화 Capsulation

45. 객체지향 특징
외부와 통신할 때의 복잡도를
줄이고, 내부 상태를 보호
하기 위해 만들어 놓은 구조
7

46. 다형성 Polymorphism

47. 객체지향 특징
polymorphism

48. 하나의 선언으로 여러 개의
多形性

49. 타입을 가질 수 있는 것. 혹은
자신이 여러 타입을 가지는
것을 지칭
TYPE

50.
8

51. 2. 코드 개선
[실습]
9

52.
2. 리팩터링이란?
1. 프로젝트

53. 인

54. 더

55. 월드

56.
2. 리팩터링이란?

57.
3. 테스트

58. 코드

59.
4. 리팩터링과

60. 설계

61.
5. 코드

62. 속의

63. 나쁜

64. 냄새

65.
10
리팩터링

67. 1. 프로젝트 인 더 월드
Project in the world
11

68. 프로젝트 In IDEAL Project

69. in

70. the

71. world

72.
§

73. 확정되어

74. 변경되지

75. 않는

76. 고객의

77. 요구

78. 사항

79.
§

80. 빈틈없는

81. 시스템

82. 설계

83.
§

84. 숙련되고

85. 표준을

86. 따르기를

87. 즐기는

88. 개발자

89.
§

90. 하나의

91. 버그도

92. 빠져나갈

93. 수

94. 없는

95. 완벽한

96. 테스트

97.
§

98. 정확히

99. 산정된

100. 스케줄과

101. 여유

102. 있는

103. 납기

104. 일자

105.
12

106. 프로젝트 In REAL Project

107. in

108. the

109. world

110.
§ 파트리더

111. 고미화의

112. 고민

113.
­– 개발자가

114. 모두

115. 동일한

116. 수준의

117. Skill을

118. 가지고

119. 있지

120. 않다.

121.
­–

122. 고객의

123. 요구는

124. 계속

125. 변화된다.

126.
­–

127. 개발

128. 초기의

129. 디자인이

130. 완벽하지

131. 않는

132. 경우가

133. 많으며,

134.
­–

135. 실제로

136. 설계가

137. 잘못된

138. 경우도

139. 많다.

140.
­–

141. 테스트에

142. 나타나지

143. 않는

144. 버그들이

145. 존재한다

146.
­– 개발

147. 완료로

148. 끝나지

149. 않는다.

150. 유지보수가

151. 뒤

152. 따른다.

153.
13

154. 프로젝트 In REAL Project

155. in

156. the

157. world

158.
§ 개발자

159. 최고수의

160. 고민

161.
14

162. 프로젝트 In REAL Project

163. in

164. the

165. world

166.
§ 개발자

167. 최고수의

168. 고민

169.
­– 코드

170. 이해에

171. 많은

172. 시간이

173. 필요(복잡,다양한

174. 개발자의

175. 취향)

176.
­–

177. 어려운

178. 업무

179. 용어가

180. 많이

181. 들어간

182. 장황한

183. 주석

184. 또는

185. 주석

186. 부재

187.
­–

188. 수정으로

189. 인한

190. 파급

191. 효과에

192. 대한

193. 불안

194.
­–

195. Copy

197. Paste

198. 로

199. 신규

200. 기능

201. 작성

202.
­–

203. 고치면

204. 고칠수록

205. 수정이

206. 어려워짐

207. (땜빵식

208. 코드)

209.
15

210. Normal Dejavu Project

211. in

212. the

213. world

214.
•

215. (어쨌든)

216. 요구사항에

217. 맞춰

218. 동작하는

219. 코드

220. 완성

221.
•

222. 추가

223. 요구사항을

224. 계속

225. 반영,

226. 반영,

227. 반영

229.
•

230. 많은

231. 부분에

232. 있어

233. 수정이

234. 가해지고,

235. 개발

236. 속도가

237. 느려지기

238. 시작

239.
•

240. 가끔은

241. 수정해야

242. 할

243. 부분을

244. 잊어서

245. 에러도

246. 발생

247. (Iterative)

248.
•

249. 후임

250. 등장

251.
•

252. 소스를

253. 보고

254. 기겁,

255. 어떻게

256. 어딜

257. 고쳐야

258. 하나?

259.
•

260. 언제

261. 시간

262. 내서

263. 통째로

264. 다시

265. 재

266. 작성해야

267. 한다고

268. 믿음

269.
•

270. 그러나

271. 여전히

272. 부분

273. 부분

274. 수정하며,

275. 필요

276. 시에는

277. 선임자를

278. 전화로

279. 찾음

280.
•

281. (어쨌든)

282. 요구사항에

283. 맞춰

284. 동작하는

285. 코드

286. 완성

287.
•

288. and

289. Looping…⋯

290.
16

291. ….

292.
17

293. 2. 리팩터링이란?
18

294. 리팩터링이란? 리팩터링이란?

295.
§ 리팩터링

296.
­– 외견상

297. 보이는

298. 기능

299. 동작은

300. 바뀌지

301. 않는

302. 상태에서

304.
­– 이해하기

305. 쉽고,

307.
­– 수정하기

308. 쉽도록

310.
­– 소프트웨어의

311. 내부적인

312. 구조를

313. 변경하는

314. 것

315.
19

316. Example #1 리팩터링이란?

317.
void

318. f()

319. {

320.
void

321. f()

322. {

327. …⋯.

332. …⋯.

337. computeScore();

342. //

343. Compute

344. score

345. }

350. score

351. =

352. a

353. *

354. b

355. +

356. c;

362. score

363. -=

364. discount;

365. void

366. computeScore()

367. {

368.
}

374. score

375. =

376. a

377. *

378. b

379. +

380. c;

385. score

386. -=

387. discount;

388.
}

390.
20

391. Example #2 리팩터링이란?

392.
public

393. String

394. name;

395.
private

396. String

397. name;

399.
public

400. String

401. getName(){

406. return

407. name;

408.
}

410.
public

411. String

412. setName

413. (String

414. newName)

415. {

420. name

421. =

422. newName;

423.
}

425.
21

426. Example #3 리팩터링이란?

429. if

430. (user

431. ==

432. null)

439. plan

440. =

442. Plan.basic();

444. else

451. plan

452. =

453. user.getPlan();

455.
plan

456. =

457. user.getPlan();

459.
i nt er f ace

460.
User
+get Pl an( )
Nu l l Us e r
+get Pl an() r et ur n Pl an. basi c();
22

461. 왜 리팩터링을 하는가? 리팩터링이란?

462.
§ 설계를

463. 개선

464. 하기

465. 위해

466.
§ 코드를

467. 이해하기

468. 쉽게

469. 만들기

470. 위해

471.
§ 버그를

472. 찾아내기

473. 위해

474.
§ 좀

475. 더

476. 빠르게

477. 프로그래밍

478. 할

479. 수

480. 있도록

481.
개발자와

482. 관리자에게

483. 어떤

484. 하나의

485. 대안

486. 될

487. 수

488. 있는가?

489.
23

490. 구성요소 리팩터링이란?

491.
§ 나쁜냄새(Smells)

492.
§ 카탈로그(Catalogue)

493.
§ 자동화된

494. 단위

495. 테스트(Automated

496. Unit

497. Test)

498.
24

499. 문제점 리팩터링이란?

500.
§ 데이터

501. 베이스

502.
§ 인터페이스

503. 변경

504.
§ 프로젝트

505. 데드라인

506.
25

507. 언제 리팩터링할 것인가? 리팩터링이란?

508.
§ The

509. Rule

510. of

511. Three

512. ­–

513. DRY(Don’t

514. Repeat

515. Yourself)원칙

516.
§ 기능을

517. 추가할

518. 때

519.
§ 버그를

520. 수정

521. 할

522. 때

523.
§ 코드

524. 리뷰를

525. 할

526. 때

527.
26

528. 성능의 문제 리팩터링이란?

529.
§ 소프트웨어를

530. 더

531. 이해하기

532. 쉽게

533. 만들기

534. 위해

535. 수정을

536. 하는데,

537. 이
때

538. 종종

539. 프로그램을

540. 더

541. 느리게

542. 작동하도록

543. 하는

544. 원인이

545. 될

546. 수

547. 있
다.

548.
§

549. 잘

550. 분해된

551. 코드와

552. 프로그램이

553. 주는

554. 이점

555.
­– 새로운

556. 기능

557. 추가가

558. 쉬워

559. 퍼포먼스

560. 튜닝에만

561. 집중하는

562. 것이

563. 가능하다.

564.
­– 세밀한

565. 분석이

566. 가능하다.

567.
27

568. 안전한 리팩터링의 3대 요소 리팩터링이란?

569.
§ 백업을

570. 만들어

571. 놓거나

572. 형상
관리를

573. 사용한다.

574.
§ 검증된

575. 리팩터링

576. 도구를

577. 사
용한다.

578.
§ 자동화된

579. 단위

580. 테스트

581. 케이
스를

582. 만들어

583. 놓는다.

584.
28

585. 리팩터링 도구 리팩터링이란?

586.
§ 이클립스의

587. 리팩터링

588. 도구

589.
29

590. 3.테스트 코드
30

591. 단위 테스트 Automated

592. Unit

593. Test 테스트

594. 코드

595.
§ “리팩터링

596. 작업의

597. 필수

598. 조건은

599. 사전에

600. 탄탄한

601. 테스트를

602. 만들어

603.
놓는

604. 것이다.”

605. ­–

606. 마틴

607. 파울러

608.
§ 가장

609. 대표적인

610. 자동화된

611. 단위

612. 테스트

613. 프레임워크

615.
=

616. JUnit

617.
31

618. 테스트 주도 개발 Test-Driven

619. Development 테스트

620. 코드

621.
§ 자동화된

622. 단위

623. 테스트

624. 케이스를

625. 만들어

626. 내는

627. 가장

628. 훌륭한

629. 방식

630.
§ “프로그램을

631. 작성하기

632. 전에

633. 자동화된

634. 테스트

635. 코드를

636. 먼저

637. 작성한다.”

638.
§ 간결한

639. 설계와

640. 고품질

641. 모듈을

642. 만들어

643. 내는

644. 기법

645.
32

646. TDD 절차 테스트

647. 코드

649.
질문

650. Ask

651.
테스트를 작성함으로써 시스템에 질문한다. (FAIL)
응답

652. Respond

653.
테스트를 통과하는 코드를 작성해서 질문에 대답한다. (PASS
)
정련

654. Refine

655.
아이디어를 통합하고, 불필요한 것은 제거하고, 모호한 것은
명확히 해서 대답을 정제한다. (REFACTORING)
반복

656. Repeat

657.
다음 질문을 통해 대화를 계속 진행한다.
33

658. 4.리팩터링과 설계
Refactoring and Design
34

659. 소프트웨어 비용 리팩터링과

660. 설계

661.
§ 전체

662. 비용

663. =

664. 개발

665. 비용

666. +

667. 유지

668. 비용

669.
§ 유지

670. 비용

671. =

672. 이해

673. 비용

674. +

675. 수정

676. 비용

677. +

678. 테스트

679. 비용

681.
+

682. 설치

683. 비용

684.
35

685. 사전 설계 Upfront

686. Design 리팩터링과

687. 설계

688.
§ 사전

689. 설계

690.
­– 재

691. 작업

692. 비용을

693. 줄이기

694. 위해서

695. SW구조에

696. 대해

697. 사전에

698. 고민을

699. 하는

700. 방식

701.
­– 요구사항

702. 변경이

703. 일어날

704. 부분에

705. 대해서

706. 미리

707. 예측한다.

708.
­– 좀

709. 더

710. 유연한

711. 구조의

712. 설계를

713. 지향한다.

714.
§ 유연한

715. 구조로

716. 솔루션을

717. 구축할

718. 때의

719. 문제점

720.
­– 다양한

721. 유연성을

722. 가진다는

723. 건

724. 다른

725. 의미의

726. 비용으로

727. 이어진다.

728.
­– 좀

729. 더

730. 복잡한

731. 구조가

732. 되기

733. 쉽고,

734. 일반적으로

735. 유지관리하기

736. 더

737. 어려워진다.

738.
­– 그리고

739. 미래를

740. 정확히

741. 예측하기는

742. 것은

743. 대부분의

744. 경우

745. 불가능하다.

746.
36

747. 리팩터링과 설계 리팩터링과

748. 설계

750.
§ 리팩터링은

751. 일부

752. 관점이

753. 사전설계(upfront

754. design)와

755. 충돌하
지만

756. 결과적으로

757. 리팩터링은

758. 디자인을

759. 보완한다.

761.
­– 리팩터링과

762. 사전

763. 설계는

764. 강조점이

765. 다르다.

766. 완벽한

767. 솔루션을

768. 찾는

769. 것이

770.
아니라

771. 납득할만한

772. 수준(reasonable)의

773. 솔루션을

774. 찾는다.

775.
­– 유연성

776. 강조보다

777. 설계를

778. 간결하게

779. 만드는

780. 쪽에

781. 좀

782. 더

783. 관심을

784. 둔다.

785.
­– 간결한

786. 시스템을

787. 좀

788. 더

789. 복잡한

790. 유연한

791. 시스템으로

792. 만드는

793. 것은

794. 매우

795. 쉽지
만,

796. 그

797. 반대는

798. 훨씬

799. 어렵기

800. 때문이다.

801.
37

802. 5.코드 속의 나쁜 냄새
Smells
38

803. 직관 Intuition Smells

804.
1997년 5월 11일
뉴욕의 에퀴터블 센터에서는 IBM이 개발한 수퍼 컴퓨터 딥 블루(Deep
blue)와 세계 체스 챔피언 ‘게리 카스파로프(Kasparov)’간의 6 차전 마지
막 경기가 진행되고 있었다.
『딥 블루』는 2m가 채 안되는 키에 1.4 톤이나 나가는 몸무게를 가지
고 있으며 중국인 과학자 츄펑슝 박사 외에 6명의 IBM사 최고 과학자들
이 지난 8년 동안 32개의 마이크로 프로세서와 512개의 특수 체스 칩을
장착해서 만들은 2백만 달러 상당의 대형 병렬 수퍼 컴퓨터다. 『딥』은
오로지 『인간을 이겨라』는 특명을 받고 태어난 역사상 최고의 기계로써
1초당 2억번의 행마(行馬)를 검토해가며 장기를 둘 수 있는 능력이 있으
며, 지난 백 년 동안에 개최되었던 주요 체스 대국의 기보가 모두 입력되
어 있다. 더욱이 슈 박사 팀은 지난번의 패배를 설욕하기 위해 연산 능력
을 2배로 보강했으며 미국의 체스 챔피언 조엘 벤저민과 세계 유명 체스
선수들의 조언을 추가로 저장하였다. 특히 슈 박사 팀은 어떠한 경우에도
상대수의 변화에 따라 새로운 수를 개발하여 대처할 수 있는 자기 조정기
능의 유연성을 강화시키는데 초점을 두었다고 한다. 따라서『딥』은 그야
말로 체스에 있어서는 『살아있는 지능을 가지고 있는 컴퓨터』라고 할
수 있다
지난 5차전까지 이 두 대국자간의 전적은 1승 3무 1패로 무승부.
- New York Times 1997.5
39

805. 코드 속의 나쁜 냄새 #1 Smells

806.
“나쁜 냄새가 난다면, 고쳐라!” – 켄트벡
­– 중복코드(Duplicate

807. code)

808.
­– 긴

809. 메소드(Long

810. Method)

811.
­– 거대한

812. 클래스(Large

813. class)

814.
­– 긴

815. 파라미터

816. 리스트(Long

817. Parameter

818. List)

819.
­– 확산적

820. 변경(Divergent

821. Change)

822.
­– 산탄총

823. 수술(Shotgun

824. Surgery)

825.
­– 기능

826. 욕심(Feature

827. Envy)

828.
­– 데이터

829. 덩어리(Data

830. Clumps)

831.
­– 기본형에

832. 대한

833. 강박(Primitive

834. Obsession)

835.
­– 스위치

836. 구문(Switch

837. Statements)

838.
­– 병렬

839. 상속

840. 구조(Parallel

841. Inheritance

842. Hierarchies)

843.
40

844. 코드 속의 나쁜 냄새 #2 Smells

845.
“컴퓨터가 이해할 수 있는 코드는 바보도 작성할
수 있다. 사람이 이해할 수 있는 코드를 작성해
­– 게으른

846. 클래스(Lazy

847. Class)

848. 라” – 마틴 파울러
­– 추측성

849. 일반화(Speculative

850. Generality)

851.
­– 임시

852. 필드(Temporary

853. Field)

854.
­– 메시지

855. 연쇄(Message

856. Chains)

857.
­– 미들맨(Middle

858. Man)

859.
­– 부적절한

860. 친밀관계(Inappropriate

861. Intimacy)

862.
­– 인터페이스가

863. 다른

864. 대체

865. 클래스(Alternative

866. Classes

867. with

868. Different

869. Interfaces)

870.
­– 불완전한

871. 라이브러리

872. 클래스(Incomplete