데이비스 (Alan M. Davis) 의 “201가지 소프트웨어 개발 원칙” 의 목차를 부분적인 요약 설명과 함께 정리하였다. 대부분 개발원칙으로
유효하고, 여러분도 알고 있는 내용일 수 있다. 상세한 내용이
필요하면 원서와 번역서를 참고하기 바란다.
일반적으로
도구의 사용을 선호하는 경향이 있는데, 도구의 성공적인 사용을 위해서는 조직 차원의 원칙하에서 기법을
확보하고, 필요한 언어로 구현할 수 있는 역량을 갖추어야 한다.
I. 일반원칙 (general principles)
1. 품질이 가장 중요 (#1) 하다.
품질은 측정 가능해야 하며, 측정할 수 있는 방안을 마련한다.
2. 품질 기준은 사람마다 다르다,
3. 생산성과 품질은 분리할 수
없다.
생산성을 높이면 품질이 떨어지고, 품질을 높이면 생산성이 떨어진다.
4. 고품질의 소프트웨어를 개발할
수 있다.
고객참여, 프로토타이핑, 설계 단순화, 인스펙션, 우수한 인력확보 등 품질을 높이기 위한 기법을 사용한다.
5. 개발 후에 품질을 높이려고
하지 마라.
개발 중에도 어려운데 나중에 품질을 높이는 것은 더 어렵다. 애자일의 리팩토링과 상충하는 원칙이며, 윈칙11과도 연관된다.
6. 낮은 신뢰성이 낮은 성능보다
더 나쁘다.
7. 시제품을 고객에게 빨리 제공한다.
고객의 진짜 요구를 파악하는
가장 효과적인 방법은 사용자에게 제품을 제공하여 사용하게 하는 것이다.
8. 고객, 사용자와 의사 소통한다.
9. 고객의 우선순위에 따라 개발자의
인센티브 (incentive) 기준을 정한다.
고객의 우선순위를 이해하라. 고객은 90%의 기능이 늦게 제공되어도 참을 수 있으나, 10% 기능은 제 시간에 필요할 수도 있다. 고객 이외의 다른 이해관계자의
요구와도 균형을 이룬다.
10. 본격적으로 개발하기 전에
시도하는 것 (throw one away) 은 버릴 계획으로 개발한다.
11. 적절한 유형의 시제품을 개발한다.
12. 시제품에서 이해가 잘 안되는
요구 기능을 개발한다.
13. 일회용 시제품은 빨리 개발한다.
14. 점증적으로 (incrementally) 시스템을 개발한다.
15. 고객은 많이 보면 더 많이
원한다.
사용자가 많이 보면 더 잘
이해한다. 피하지 말고 가능하면 빨리 현명하게 맞서라. 나중에
바꾸는 것 보다 낫다.
16. 개발 중 변경은 피할 수
없다.
17. 가능하면 개발하지 말고 구매한다.
18. 사용자 매뉴얼이 간단하도록
소프트웨어를 개발한다.
고객은 복잡하지 않고 단순하고 말끔하고 명확한 인터페이스 (simple, clean, clear interfaces)를 원한다.
19. 모든 복잡한 문제에 대한
해결책이 없을 수도 있다.
20. 가정 (assumption)을 기록한다.
21. 단계마다 다른 언어를 사용한다.
22. 도구보다 기법이 우선이다.
도구를 가진 원칙이 없는
엔지니어는 위험하다.
23. 도구를 사용하라. 그러나 도움이 되게 현실적으로 사용한다.
24. 소프트웨어 도구는 자질을
갖춘 개발자에게 제공한다.
25. CASE (Computer
Aided Software Engineering) 도구는 비싸다.
26. 언제 할지를 아는 것 (know-when) 이 어떻게 할지를 아는 것 (know-how) 만큼
중요하다.
27. 목적을 달성하면 멈춘다.
28. 정형적 방법을 이해한다.
프로젝트에 적어도 한 명 정도가 알고 있다면 도움이 될 수도 있다.
29. 조직의 문화와 평판 (reputation with organization) 를 고려한다.
30. 주의하면서 대세를 따른다.
5천만명이 바보 같은 말을
하더라도, 그것은 여전히 바보 같은 말이다. Anatole
France
모든 사람이 사용했다고 해서 당신에게는 맞지 않을 수도 있다. 당신의 환경에 적용 가능한지를 신중하게 평가하라. 새로운 기술이나
솔루션은 과장되어, 기대되는 효과를 얻지 못할 수도 있고, 일반적이지
않을 수도 있다.
31. 기술 변화를 무시하지 마라.
오랫동안 사용하고 관심을 끌고 있더라도 아직 거품일 수도 있다. 잡지를 구독하고, 컨퍼런스에 참여한다. 발표 내용보다 복도에서의 대화가 더 도움이 될 수도 있다.
32. 문서 표준을 사용한다.
33. 모든 문서에 용어 (glossary)를 정의 한다.
34. 모든 문서에 색인을 부여한다.
35. 같은 개념에 같은 명칭 (naming)을 사용한다.
36. 연구결과를 적용되는 것은
시간이 걸린다.
37. 책임져라. 제대로 하고, 제대로 못할 거면 하지 마라.
II.
요구공학 원칙 (requirements engineering principles)
38. 요구사항이 잘못되면 비용
견적도 잘못된다.
잦은 요구사항 변경, 요구사항 누락, 사용자와 불충분한 의사소통, 부실한 요구사항 명세, 불충분한 분석 5가지가 잘 못된 비용 견적의 원인이다.
39. 요구사항을 기록하기 전에
문제를 확실하게 이해한다.
40. 요구사항을 가능하면 바로
결정한다.
바로 알 수 없으면 시제품을 만들고, 고객과
의사 소통하면서, 필요한 모든 조치를 취한다.
41. 요구사항 오류는 즉시 수정한다.
42. 본 개발 전에 시제품으로
사용자 인터페이스를 결정하여 위험을 줄인다.
43. 요구사항 선정근거를 기록한다.
44. 세부 요구사항 (subsets, minimal subset) 을 식별한다.
45. 요구사항을 검토한다.
46. 요구사항 분석단계에서 설계하지
않는다.
47. 올바른 기법을 사용한다.
48. 여러 관점에서 요구사항을
분석한다.
49. 요구사항을 사용하기 좋게
구조화한다.
50. 요구사항의 우선순위를 정한다.
51. 간결하게 기록한다.
52. 요구사항에 유일한 식별번호를
부여한다.
53. 요구사항의 모호성을 줄인다.
54. 자연어를 보완하더라도 자연어를
대체하지 마라.
55. 더 정형적인 모델을 작성하기
전에 자연어로 기록한다.
56. 일기 쉽게 요구사항명세서를
작성한다.
57. 신뢰성에 대하여 구체적으로
기술한다.
58. 수용 불가능한 환경을 기술한다.
59. 미결정항목 (TBD to be determined) 은 누가 언제까지 해결할 것인지 각주를 작성한다.
60. 데이터베이스에 요구사항명세서를
저장한다.
III.
설계 원칙 (design principles)
61. 요구사항을 설계로 전환하는
것은 쉽지 않다.
62. 요구사항에 대한 설계 산출물을
추적한다.
63. 대안을 평가한다.
64. 문서가 없는 설계는 설계가
아니다.
65. 캡슐화 한다.
정보은닉은 테스트하기 쉽고, 유지보수하기 쉬운 소프트웨어를 만드는 검증된 방법이다.
66. 가능하면 재사용한다 (don’t reinvent the wheel).
67. 단순하게 개발한다.
68. 예외 상황에 대한 특별한
경우 (special cases) 를 많이 만들지 않는다.
69. 가능하면 실세계와 유사하게
소프트웨어를 개발하여 지적인 거리 (intelligent distance) 를 최소화 한다.
70. 설계자와 유지보수자가 설계를
완전히 이해하도록 문서화하여 설계를 지적으로 통제 (intelligent control) 한다.
71. 개념적 무결성 (conceptual integrity) 을 유지한다.
72. 개념적 오류는 문법적 오류 (syntactic errors) 보다 심각하다.
73. 결합도는 낮추고 응집도는
높인다.
74. 변경이 쉽게 설계한다.
아키텍처와 설계서는 변경될
수 있다는 것을 받아 들인다.
75. 유지보수를 고려하여 설계한다.
76. 오류를 고려하여 설계한다.
77. 일반성을 갖도록 소프트웨어를
개발한다.
78. 유연성있는 소프트웨어를 개발한다.
79. 효율적인 알고리즘을 사용한다.
80. 사용자가 필요로 하는 모든
정보는 모듈 명세서가 제공한다.
81. 설계는 다차원적이다. 패키징, 계층구조, 호출관계, 프로세스를 포함한다.
82. 뛰어난 설계자가 좋은 설계를
한다.
83. 어플리케이션을 이해한다.
84. 큰 투자 없이도 재사용할
수 있다.
레포지토리에서 찾아서 재사용하는
것을 쉽지 않고, 비효율적일 수 있지만 동료에게 물어서
(salvaging) 쉽게 재사용할 수도 있다.
85. 오류 값을 입력하면 해당
오류 메세지를 출력하게 처리한다.
86. 소프트웨어 신뢰성은 중복성을
통해 얻을 수 있다.
IV.
코딩원칙 (coding principles)
87. 트릭을 사용하지 않는다.
프로그래머의 개성을 프로그램에
반영하지 못하게 한다.
88. 광역변수를 사용하지 않는다.
89. 하향식으로 읽을 수 있도록
작성한다.
90. 파급효과를 없앤다.
91. 의미 있는 명칭을 사용한다.
92. 사람을 우선적으로 고려하여
프로그램을 작성한다.
93. 최적의 자료구조를 사용한다.
94. 빠른 소프트웨어 개발보다
먼저 올바르게 개발한다.
빠른 소프트웨어를 만들기
전에 먼저 소프트웨어를 완성하라. 성능이 좋은 프로그램이 실행하도록 하는 것 보다 실행되는 프로그램의
성능을 개선 하는 것이 훨씬 쉽다. 초기 코딩 시에는 최적화에 대하여 걱정하지 마라.
95. 코드를 완성하기 전에 주석을
작성한다.
96. 코딩을 시작하기 전에 문서화한다.
97. 모든 구성요소를 수작업으로
실행한다.
98. 코드를 검토한다..
상세 설계와 코드를 검토하는
것이 테스팅보다 훨씬 좋은 방법이다. 그러나 너무 지나치면 안 된다.
99. 비구조적 언어 (예, goto) 도 사용할 수 있다.
100. 구조화된 코드가 반드시 좋은
코드는 아니다.
101. 너무 깊게 중첩 (nested)하지 않는다.
102. 적절한 언어를 사용한다.
103. 프로그래밍 언어를 핑계대지
마라.
104. 언어 지식은 중요하지 않다. 유능한 개발자는 새로운 언어도 쉽게 익힌다.
105. 프로그램 체계 (coding conventions – program format) 를 정한다.
106. 너무 빨리 코딩하지 마라.
V.
테스팅 원칙 (testing principals)
107. 요구사항에 대하여 테스트를
추적한다.
108. 테스트하기 훨씬 이전에 테스트
계획을 수립한다.
109. 자신이 개발한 소프트웨어를
테스트하지 않는다.
110. 자신이 개발한 소프트웨어의
테스트 계획을 세우지 않는다.
111. 테스팅은 결함을 드러나게
한다.
112. 오류의 많고 적음과 소프트웨어
가치는 직접적인 관계가 없다.
113. 성공적인 테스트는 오류를
찾는 것이다.
114. 15% 모듈에서 50%의 오류가 발생한다.
115. 블랙박스 (blackbox)와 화이트박스 (whitebox) 테스팅을 실시한다.
116. 테스트 케이스는 예상결과를
포함한다.
117. 무효 값 (invalid value) 을 테스트한다.
118. 항상 스트레스 테스트 (stress test)를 실시한다.
119. 일괄이행 이론 (big bang theory)을 적용하지 마라.
120. McCabe의 복잡도 척도 (complexity measure)를 사용한다.
121. 효과적인 테스트 종료 척도 (testing completion measures)를 적용한다.
122. 효과적인 테스트 커버리지를
달성한다.
완벽한 커버리지 (statement
coverage, branch coverage, path coverage) 테스트하는 것은 불가능하다. 모든 경로 커버리지 (path coverage)는 매우 어렵고 현실적이지 않다.
123. 단위 테스팅이 끝나기 전에
통합하지 않는다.
124. 소프트웨어 테스팅에 필요한
테스팅용 코드 (imbed special instructions) 를 포함한다.
125. 결함의 원인을 파악하여 제거한다.
예방을 통하여 결함 발생을
막는 것이 결함을 발견하고 고치는 것보다 훨씬 경제적이다. 결함이 발생하면 결함의 원인을 분석하여 결함의
원인을 제거한다.
126. 오류를 개인적인 차원으로
생각하지 않는다.
소프트웨어는 완벽이 아닌 끊임없는 개선이 필요하다. 오류가 발생하면 잘못을 따지지 말고 공유하여 서로 배우는 기회로 활용한다.
VI.
관리원칙 (management principles)
127. 관리를 잘 하는 것 (good)은 좋은 (good) 기술보다 중요하다.
관리를 잘 하면 자원이 부족하더라도 좋은 결과를 얻을 수 있으나, 관리를 잘 못하면 좋은 기술을 가지고도 성공적인 결과를 얻을 수 없다.
128. 적절한 해결책 (solutions)을 사용한다.
129. 읽은 것을 모두 믿지 마라.
130. 고객의 우선순위를 이해한다.
지속적으로 접촉하여 요구사항 우선순위의 변화를 이해하고, 요구사항을 필수적 (desirable), 바람직한 (desirable), 선택적 (optional)으로 분리하여 관리한다.
131. 사람이 성공의 열쇠이다.
적절한 경험, 재능, 교육을 받은 숙련된 전문가가 핵심이다. 불충분한 도구, 언어, 프로세스를
가진 역량이 있는 전문가는 성공할 수 있으나, 아무리 좋은 도구, 언어, 프로세스를 가지고 역량이 없는 전문가는 실패한다.
132. 많은 비전문가 (many less skilled people) 보다는 소수정예 (few
good people) 가 더 좋다.
프로젝트에서는 어느 한 쪽으로 치우치지 말고, 적절한
전문가와 비전문가의 혼합이 바람직하다. 전문가는 이직 가능성이 높고,
비전문가는 낮은 생산성과 품질이 문제이다.
133. 구성원의 말을 경청한다.
134. 구성원을 신뢰한다.
135. 우수함 (excellence) 를 추구한다.
더 높은 기대를 하면 더 많은 결과를 얻는다.
136. 팀워크와 함께 의사소통 기술이
필수적이다.
137. 개발자와 함께 한다 (carry the water).
개발자가 잔업이나 휴일 근무할 경우 옆에 있어라.
기술적인 도움이 안되더라도 항상 옆에서 지원할 준비가 되어있다는 것을 보여 준다,
138. 개발자는 서로 다른 것으로부터
동기부여 받는다.
항상 보상이 가장 중요하지는 않다.
139. 사무실을 조용하게 유지한다.
140. 인력과 시간은 대체할 수
없다 (mythical man-month).
지연된 프로젝트에 인력을
더 투입하면 일정이 더 지연될 수도 있고, 인력을 더 투입한다고 해서 일정이 비례해서 단축되지는 않는다.
141. 소프트웨어 개발자의 생산성
차이는 크다.
월 LOC 기준으로 생산성은 25배, 1,000 LOC당 결함 기준으로 품질은 8배 정도 차이가 발생할 수 있다.
142. 원하는 것은 최적화 할 수
있다.
하나를 최적화 하면 다른 것은 품질이 떨어진다.
모든 것이 중요하다고 강조하면 아무 것도 최적화되지 않는다.
143. 자연스럽게 (unobtrusively) 데이터를 수집한다.
데이터 수집은 가능하면 개발자의 참여 없이 자동화 하는 것이 가장 좋다. 그러나 모든 것을 자동화할 수는 없다.
144. 코드 1라인 당 비용은 중요하지 않다.
145. 생산성을 완벽하게 측정하는
방법은 없다.
LOC나 기능점수 (function point)는 각기 장단점을 가지고 있다. 완벽한
생산성 측정을 불가능하다. 직관과 경험을 확인하기 위하여 측정 모델을 사용하지만, 전적으로 믿지는 말아라.
146. 비용추정 모델 (cost measurement models) 을 조정한다.
147. 비현실적인 납기를 정하지
마라.
개발자의 사기를 떨어드리고, 낮은 품질, 납기 지연, 비용 초과를 가져오고 결과적으로는 신뢰를 떨어뜨린다. 이것은 개발자나 관리자가 생산성이 낮거나 일을 잘못했기 때문은 아닐 수도 있다.
148. 불가능한 납기를 계획하지
마라.
프로젝트 기간 > 2.15*
대부분의 프로젝트가 이 법칙을 따른다.
Boehm은 계산된 기간의 25% (2.15가 아닌 2.5를 적용했을 때) 까지는 조정할 수는 있으나 자원의 추가 투입이 필요하고, 그 이상일
경우에는 범위를 조정할 것을 제안하다.
M/M
|
2.15
|
2.5
|
||
100%
|
75%
|
100%
|
75%
|
|
500
|
17
|
12
|
19
|
14
|
1,000
|
21
|
15
|
25
|
18
|
2,000
|
27
|
20
|
31
|
23
|
3,000
|
31
|
23
|
36
|
27
|
4,000
|
34
|
25
|
39
|
29
|
149. 측정하기 전에 왜 측정하는지
이해한다.
150. 생산성 데이터를 수집한다.
151. 팀 생산성을 고려한다.
개인의 생산성 최적화가 팀 생산성 최적화를 가져오지는 않는다. Lehman 보고에 의하면 개인 생산성은 3배 증가하였는데 회사
생산성은 낮아진 경우도 있다.
152. 개발자가 한 달에 개발하는
소스코드 라인수 (LOC/person-month)는 언어 독립적이다.
Higher 레벨 언어를 사용하면 Higher 레벨 언어는 한 라인이 더 많은 기능을 수행하므로 더 높은 생산성을 가져 올 수 있다. 그러나 이 원칙은 재검토가 필요하다.
153. 일정을 믿어라.
가능한 일정과 자원을 할당하면 모든 프로젝트 참가자는 일정을 믿어야 한다. 믿지 않으면 일정을 맞출 수 없다. 현실성보다 믿는 것이 더 중요하다. 개발자가 일정 계획을 세우는 것이 가장 좋다.
154. 정확하게 산정한 비용견적이라도
맞지 않을 수 있다.
155. 일정을 정기적으로 조정한다.
156. 사소하게 낮은 견적은 항상
나쁘지는 않다.
팀워크가 유지되고 있다면 별 문제가 없이 납기를 맞출 수 있다. 반면에 약간 여유있는 일정은 휴가, 적게 일하기 등을 통하여 생산성을
낮춘다. 그러나 이해할 수 없는 무리한 일정은 사기와 생산성에 부정적인 영향을 미친다.
157. 자원을 적절히 할당한다.
158. 프로젝트 계획을 상세하게
수립한다.
159. 계획을 최신 상태로 유지한다.
160. 계획변경의 파급효과에 주의한다.
계획 변경에 따라 필요한 조치를 취한다. 모든
실패한 프로젝트는 “한번에 하루씩 일정이 늦어졌다.”.
161. 상위 10개 위험을 파악한다.
Boehm의 일반적인 위험 목록
§ 인력 부족 (원칙 131)
§ 비현실적 일정 (원칙 148)
§ 요구사항 이해 부족 (원칙 40)
§ 미흡한 사용자 인터페이스 (원칙 42)
§ 불필요한기능 (goldplate) 추가 (원칙
179, 189)
§ 재사용 또는 인터페이스 컴포넌트
부족
§ 외부 수행 활동의 부족
§ 늦은 응답속도
§ 현재 기술 역량을 벗어난
적용
162. 직면한 위험을 이해한다.
163. 적절한 프로세스 모델을 사용한다.
기업 문화, 위험에 대한 대응 (risk willingness), 업무 영역, 요구사항 가변성, 요구사항 이해도를 고려하여 프로세스 모델을 선택한다. 프로세스 모델은
폭포수, 버리는 프로토타이핑, 점진적 개발, 나선형 모델, 애자일 등이 있다.
164. 방법론이 당신을 구하지는
못한다.
방법론 이전에 조직의 문제를 해결한다. 방법론이
조직의 문제를 해결하지 않는다.
165. 기적적인 생산성 향상 비법은
없다.
어떠한 도구 도입을 통한 50% ~ 100% 정도의
생산성 향상을 믿지 말아라. 소프트웨어 산업은 1년에 3% ~ 5% 정도의 생산성 향상을 달성할 수는 있다.
166. 진척도의 의미를 이해한다.
167. 계획과의 차이 나는 타스크 (manage by variance) 를 관리한다.
168. 메모리나 CPU 등 하드웨어에 과중한 부하를 주지 않는다.
169. 하드웨어 진화를 낙관적으로
받아 들인다.
실제로는 속도, 처리 용량, 표준화, 가격 대비 성능 등 모든 예측을 초과하였다.
170. 소프트웨어 발전에는 비관적으로
대응한다.
대부분의 소프트웨어 개발에 대한 예측은 실현되지 않았다.
171. 발생하지 않을 것이라고 확신한
것이 자주 재난 (disaster) 으로 발전한다.
예상되는 모든 재난을 분석하고, 사전에
비상계획을 수립하고, 지속적으로 위험을 평가한다. 위험은
실제로 발생한다고 예상하고 대응한다.
172. 프로젝트 사후 검토회의를
실시한다.
과거를 기억하지 못하는 사람은 그것을 되풀이 한다. – George Santayana, 1908
프르젝트 종료 후 핵심인력이 3~4일
간 프로젝트에서 발생한 모든 문제를 분석하여 정리하게 한다. 잘 못한 것을 문서화하고, 분석하여 배우고 나중에 그러한 실패를 되풀이하지 않기 위하여 어떻게 하여야 하는지를 기록한다.
그리고 도움이 되는 베스트 프랙티스도 함께 정리한다.
VII.
제품보증 원칙 (product assurance principles)
173. 제품보증 수준을 프로젝트에
맞게 조정한다.
제품 보증은 형상관리, 품질 보증, 검증과 확인 (V&V - verification and
validation), 테스트 4가지로 구성한다.
174. 소프트웨어 형상관리 절차를
조기에 확립한다.
소프트웨어 변경관리를 소프트웨어 형상관리 계획에 포함하여 작성한다.
175. 소프트웨어 프로세스에 형상관리를
포함시켜 적용한다.
프로젝트 규모, 가변성, 개발 프로세스, 고객 참여 정도 등을 고려하여 형상관리 프로세스를
조정하여 적용한다.
176. 형상관리는 프로젝트 관리와
독립적으로 조직을 구성한다.
177. 개발과 제품보증 업무를 순환보직으로
전환한다.
많은 조직이 첫 업무로서 또는 기술역량이 뒤진 개발자를 제품보증 업무를 수행하게
한다. 제품 보증은 개발과 동일하거나 더 뛰어난 역량을 필요로 한다.
회사 정책으로 우수한 엔지니어가 2~3년에 6개월 정도 제품 보증 업무를 보상 차원에서 수행하게 한다.
178. 모든 중간 산출물에 이름과
버전을 부여한다.
179. 기준선 (baselines) 을 통제한다.
180. 모든 것을 보관한다.
개발한 모든 사항을 보관하여 필요하면 바로 가져다 쓸 수 있게 한다. 소프트에어 개발 작업이 끊임없는 짜집기 작업이므로 이전 자료로 되돌릴
(undo) 수 있다.
181. 모든 변경을 지속적으로 추적한다.
182. 모든 구성원이 변경관리를
준수한다.
일반적으로 고객이 개발자를 직접 접촉하여 변경관리를 거치지 않고 요구사항 변경을
요청하는데, 비용상승 및 납기 지연의 원인이 된다.
183. 변경요청에 우선순위를 부여하고
일정계획을 세운다.
운영과 개발도 동일하며, 변경위원회를
운영한다.
184. 대규모 개발 프로젝트에서는
검증과 확인(V&V) 작업을 수행한다.
검증과 확인팀은 개발팀과 독립하여 구성하고, 프로젝트
계획서에 포함한다.
VIII.
진화 원칙 (evolution principles – 유지보수)
185. 소프트웨어는 계속 변화한다.
186. 소프트웨어의 엔트로피는 증가한다.
소프트웨어는 변경되면 복잡도가 증가하고, 구조화가
나빠진다. 안정성이 떨어지고, 신뢰성과 유지보수성이 악화된다. 이것을 Manny Lehman의 “엔트로피
증가의 법칙” 이라고 한다.
187. 고장나지 않았으면 변경하지
않는다.
188. 증상이 아닌 근본 문제 (problems – root causes)를 수정한다.
189. 요구사항을 먼저 변경한다.
190. 릴리즈 전 오류가 많은 컴포넌트는
릴리즈 후에도 많은 오류를 발생시킨다
실증 데이터에 의하여 증명된 사항으로, 최선의
방법은 이러한 컴포넌트를 버리고 새로 개발하는 것이 최선이다. 의미없는 일에 돈을 버리지 마라 (Don’t throw good money after bad.).
191. 프로그램이 오래될수록 유지보수하기가
더 어려워진다.
192. 언어는 유지보수성에 영향을
미친다.
193. 때로는 처음부터 개발 (start over) 하는 방법이 더 좋다.
재공학, 역공학이 반드시 좋은 것은
아니다. 경우에 따라서는 바로 설계하고 개발하는 것이 더 효율적일 수도 있으므로 신중하게 고려한다.
194. 가장 문제가 있는 컴포넌트는
다시 개발한다.
195. 유지보수는 개발보다 많은
오류를 발생시킨다.
196. 모든 변경에 대하여 회기
테스트 (regression test)를 실시한다.
197. 변경이 쉽다고 믿으면 잘못
변경하기 쉽다.
198. 비구조적 코드는 구조화해도
개선되지 않는다.
199. 최적화하기 전에 프로파일러를
사용하여 CPU와 메모리를 많이 사용하는 대상을 고른다.
200. 시스템의 친밀감을 유지한다
(Lehman’s “Law of Conservation of Familiarity.”)
201. 시스템을 환경 변화에 따라
계속 변경한다.
댓글 없음:
댓글 쓰기