프로그래머의 지혜

칼럼 2008. 12. 26. 17:29

제가 10여년 넘게 소프트웨어 업계에서 얻은 경험을  "세상의 지혜", 발라사르 그라시안 지음, 이동진 옮김 토대로 참고하여 패러프레이지(재구성) 한 것입니다.

 

프로그래머의 삶에 조금이라도 도움이 되는 한줄기 서광이 빛추었으면 합니다.

감사합니다.

1) 컴퓨터 프로그래머는 최고의 직업임을 알라.

2) 컴퓨터 프로그래머는 노가다 직업임을 인정하라.

3) 프로그래밍의 성공 열쇠는 자신감이다.

4) 산은 넘어봐야 안다.

5) 산을 넘지 않고 넘어봐야 안다는 말하는 사람들을 가까이 하지 마라.

6) 언제나 진실하게 행동하라.

7) 프로그래밍은 진실의 반영이다.

8) 프로그래밍은 고도의 논리적 사유를 요구한다.

9) 개발툴은 기술적이기보다는 기능적이다.

10) 완전한 프로그램을 만드는 것만큼 자신을 완전하게 만들어라.

11) 컴퓨터를 이해하고 프로그램 구조를 이해하는 것만큼 자신을 알고 이해하라.

12) 팀워크를 위해서 일하라.

13) 팀워크의 활성화를 위해서는 스터디 모임이 효과적이다.

14) 팀 내에서 나서는 사람이 되기보다는 없어서는 안될 사람이 되어라.

15) 프로그래밍 지식이 실체화되려면 용기가 있어야 한다.

16) 소프트웨어 기술과 소질을 잘 살려서 최대한 도로 자신의 능력을 완숙한 경지로 향상시켜라.

17) 팀원들이 당신을 존중하고 신뢰하도록 만들라.

18) 팀장에게 반항하거나 그를 능가하려고 하지 말라.

19) 팀 내에서의 불만을 자기 것으로만 생각하지도 말고 퍼뜨리지 말라.

20) 프로그램 개발 시 발생하는 고통은 누구에게나 있는 것이다.

21) 가능한 한 자신의 결점을 노출시키지 말라.

22) 항상 배우도록 하고 자신에게 멘토가 되어줄 사람을 찾아라.

23) 동료 팀원들을 스승으로 삼아라.

24) 재능은 누구에게나 주어지지만 그 재능이 숙련적인 기술로 발전하기 위해서는 노력이 필요하다.

25) 프로그램 완성을 위해서는 WHY 보다는 HOW가 더 중요하다.

26) 버그를 한 번에 잡으려고 하지마라. 긴장을 갖고 있으되 한편으로는 여유로움을 간직하라.

27) 프로그래밍이란 지성과 감성 그리고 용기와 박력의 결합이다.

28) 자신의 주변에 우수한 인재들이 모이도록 자신을 향상시켜라.

29) 프로그램 개발은 풍부한 기술지식과 풍요로운 마음가짐을 요구한다.

30) 팀 내에서 그리고 회사 내에서 그리고 어디에서든 적을 만들지 말라.

31) 적을 만들지 않기 위해서는 항상 자신을 새롭게 하라.

32) 근면은 프로그래머가 프로그래밍을 하는데 있어서 근간을 이룬다.

33) 자신이 작성한 프로그램에 자부심을 갖되 대단한 기대는 갖지 말라.

34) 직장에서 퇴출될 수 없는 자신만의 노하우를 가져라.

35) 운이 안 좋아도 배움을 늦추지 말라. 운이 안 좋을때 배우는 것이 더 많을 수 있다.

36) 장황한 지식이 아닌 실질적인 지식을 갖추어라.

37) 소프트웨어 기술 지식을 적시 적소에 사용하는 방법을 배워라.

38) 프로그래머는 소프트웨어 개발을 위한 마법사임을 깨달아라.

 

39) 자신의 결점을 숨기려고 하지 말고 결점을 고치려 하되 안 되면 무시하라. 가능한 한 떳떳하고 당당하게 살아가라.

40) 팀 내에서 다른 팀원의 결함을 찾아내려고 하지 마라.

41) 프로그램 개발에서부터 팀워크에 이르기까지 매사에 긍정적으로 생각하고 행동하라.

42) 사유와 상상은 다르다. 상상할 때와 사유할 때를 구별하라.

43) 팀 내의 전체적인 분위기를 읽을 줄 알아라. 회사가 돌아가는 분위기를 인식하라.

44) 경쟁 프로그래머가 있을 경우 그를 존중하고 그로부터 배우려고 노력하라.

45) 교만하고 자만해 있는 사람이 팀원으로 있다면 자신의 마음에 그러한 요인이나 인자가 없는지 잘 내면을 살펴라.

46) 소프트웨어 프로그래머의 실력은 소프트웨어가 얼마나 성능이 좋은가에 판가름난다.

47) 누구나 할 수 있는 프로그래밍 기술도 갖추되 자신만의 프로그래밍 기술도 갖추어라.

48) 프로그래밍에 대한 자신의 주관을 져버리지 말라. 자신의 철학을 지켜라.

49) 팀원으로부터 인기를 얻으려고 하지 말라.

50) 프로그램 상에 존재할 수 있는 미심쩍은 오류나 버그에 대해서는 즉각 조치를 취하라.

51) 운이 좋은 프로그래머와 실력이 좋은 프로그래머들을 주변에 많이 두어라.

52) 위기에 처했을 때는 마음으로 자신이 선망하는 고수들에게 기도하라.

53) 자신의 기술지식을 팀원에게 베풀거나 그들과 공유하라.

54) 자신의 능력을 20%~30%는 숨겨라.

55) 팀원이나 팀장의 요청을 무조건 받아들이려고 하지 말라. 거절할 줄도 알라.

56) 자신의 기술지식이나 기술소질에 있어서 가장 뛰어난 부분을 더욱 발전시켜라. 자신의 장점을 최대한 발전시켜라.

57) 프로그램의 구조와 설계 전반에 관하여 조용하고 맑은 정신으로 깊이 사유하는 시간을 가져라.

58) 구루나 마스터가 되기 전까지는 프로그래밍을 짜기 전에 3번 생각하고 한 줄의 코드를 작성하는 습관을 가져라.

59) 짠 코드를 다시 고치거나 지우는 것을 아깝게 생각하지 말라.

60) 프로그램이 완전히 완성되기에는 시간이 필요함을 알라. 모든 사사물물은 완성하는 데에는 시간이 요구된다.

61) 자신을 비난하는 자가 3번을 비난하면 두 번은 침묵으로 무시하나 한 번쯤은 진실한 말로 그렇지 않음을 이야기하라.

62) 운이 좋다고 느껴질 때 열심히 일하고 많은 것을 배워라.

63) 팀원들이 자신을 좋아하도록 해라. 팀원에게 친절하고 베풀어라.

64) 모자란 실력에 대해 자신이 실력 있다고 뻥 튀겨 부풀리지 말라.

65) 자신의 능력을 지나치게 믿지 말라.

66) 팀의 흐름을 따르라.

67) 행운이 자신에게 언제 찾아오는지 명리학자에게 자문을 구하라. 그러나 행운보다 노력과 배움이 더 중요함을 인지하라.

68) 원대한 포부와 야망 그리고 비전을 가진 사람이 어떻게 그것을 현실화시키는지를 알라.

69) 프로그래밍 기술지식이 풍부한 사람을 사귀라.

70) 교묘한 프로그래밍 기술 노하우(TIP)를 많이 습득하라.

71) 프로그램의 제어 흐름과 데이터 흐름을 잘 관찰하라.

72) 자신이 작성한 프로그램은 자신의 분신임을 깨달아라.

73) 프로그래밍을 통해서 일상생활에 대한 자신의 논리적 판단력을 증진시켜라.

74) 팀원을 미워하지 말고 자신을 사랑할 줄 알라. 애증을 버려라.

75) 팀 내에서 나서서 무엇을 하려고 하지 말라. 시키지 않은 일을 하지 말라.

76) 팀 내에서 알 수 없는 신비감과 심오함으로 자신을 포장하라.

77) 팀 내에서 자신과 타인의 자존심에 상처를 주지 않도록 주의하라.

78) 논쟁을 삼가되 논쟁을 하게 되면 서로를 존중하는 기반 하에서 논쟁을 하라.

79) 인생은 선택의 연속이다. 올바른 선택을 하라. 그러나 틀린 선택을 해도 후회하지는 마라.

80) 팀 내에서 누군가 자신을 비난해도 당황하거나 화를 내지 마라. 너그러운 마음으로 사태를 분석하고 진지하고 진솔하게 사실을 이야기 하라.

81) 프로그래밍은 빨리 한다고 능사가 아니다. 시간이 해결해 줄 수 있음도 인정할 줄 알라.

82) 진지함과 즐거움을 동시에 갖고 프로그래밍을 하라.

83) 팀 내에서 싸움은 가급적 피해 되 싸움에서 이기되 패배를 통해서 배우는 자세도 길러라.

84) 싸움은 배짱으로 하는 것이지 머리로 하는 것이 아니다. 머리를 텅비우고 배에 힘을 주어라.

85) 팀 내에서 자신을 나약하게 생각하거나 무시하는 사람에게는 자신이 힘이 있고 위엄이 있음을 보여주라.

86) 싸워서 질 경우 참고 견디는 인내의 마음을 길러라.

87) 프로그래밍할때는 항상 주의를 기울여서 실수와 오류가 프로그램 상에 들어가지 않도록 노력하라.

88) 항상 깨어있는 의식 상태로 프로그래밍을 하라.

89) 항상 버그가 언제 어디서든지 발생할 수 있음을 인식하고 있으라.

90) 팀워크를 원활하게 유지하려면 주변의 사람들의 수준과 자신의 수준을 일치시키도록 하라. 나서지도 말고 주눅들지도 말라.

91) 프로그램의 완성도는 바둑처럼 끝내기를 잘하는데 있다.

92) 프로그래밍을 통해서 지식과 지혜를 길러라.

93) 어려운 문제를 해결해 낼 수 있는 실력을 길러라. 소프트웨어 업계에서 장인이라고 호칭되려면 남들이 해결하지 못하는 프로그램 문제를 해결할 수 있어야 한다.

94) 어려운 문제가 발생할 경우 자신이 해결해야만 한다면 그 문제를 우회할 수 있는 길을 모색하라.

95) 자신의 능력을 100%활용해도 안 되면 휴먼 네트워크를 활용하라.

96) 팀 내의 팀원들에게 좋지 못한 소식은 전하지도 말고 들으려고 하지도 말라.

97) 프로그래밍은 판단력을 기르는데 매우 요긴한 도구이다.

98) 소프트웨어 개발은 결과로서 평가 받는다. 결과가 좋으면 과정도 좋은 것이다.

99) 자신만 잘하려고 하지 말고 팀 내의 팀원들이 판단을 잘하도록 도와주라.

100) 프로그램 개발 시에 모든 것을 혼자 다하려고 하지마라. 팀원들과 함께 일하라. 물론 부당한 요구는 거절할 줄 알아라.

101) 자신이 일에 대한 과부하를 받지 않도록 하라.

102) 자신에게 맡겨진 일만을 하면 평범한 직장인이다. 그러나 진실한 장인의 명성과 명망은 그 이상을 할 때 얻어진다. 벤자민 플랑클린의 자서전을 읽어보라.

103) 프로그래밍 로직을 설정하는데 있어서 확고한 주관을 가져라. 이리 저리 변덕을 부리거나 흔들리지 마라.

104) 팀원을 믿어라. 결단력도 팀원을 믿는 마음이 강할 때 가능하다.

105) 팀원의 부당한 요구는 거절할 줄도 알라. 거절할 때는 물론 기술적으로 거절하라.

106) 팀원들이 모두 주장하는 것이라고 해서 무작정 동의하고 믿으려 하지 마라. 자신의 주관과 입지를 확실히 하라.

107) 기분에 따라 행동하지 말고 마음 속의 변화를 내색하지 말라.

108) 어디서나 결단력이 성공의 열쇠라는 것을 잊지 말라.

109) 자신이 해야할 일과 할 필요 없는 일을 분명히 하라.

110) 많은 사람을 포용하고 너그럽게 대하라.

111) 비전(Vision)을 갖고 가슴뛰는 삶을 살아라.

112) 이상적 대상을 자신의 모델(Model)로 삼아라.

113) 항상 새로워지려고 노력하고 자신의 우수한 능력을 늘 새롭게 개선시켜라.

114) 사소한 버그는 종종 저지를 수 있음을 인정하라. 버그가 일어나는 것에 두려워하지 말라. 그러면 프로그래밍이 힘들어진다. 버그가 많이 일어나는 것에 두려워하라.

115) 팀을 이루는 구성원들에 따라 다르게 대해 주어라. 받는 것을 원하는 사람에게 그가 필요 한 것을 주고, 주기를 좋아하는 사람에게는 그가 주고자 하는 것을 받을 줄 알라.

116) 위험(Risk)을 최대한 줄이고 안전하게 일하는 법을 배우라. 가능한한 쓸데없는 일에 목숨을 걸거나 위험을 감수하려고 하지 마라.

117) 명랑할 줄도 알라. 재치와 유머가 필요할 때가 있다. 만화책도 즐겨 읽어라.

118) 팀원이 제공하거나 관리자가 제공하는 정보가 100% 옳다고 믿지는 말라. 의심할 줄도 알라.

119) 지나친 것은 부족한 것만 못하다. 무엇이든지 지나친 것은 해롭다. 극단적인 괴로움이나 극단적인 즐거움에서 벗어나라.

120) 적으로부터 배울 줄 알아라. 적을 통해서 자신을 성찰하라.

121) 소프트웨어 개발 프로젝트를 통해서 완성되는 프로그램에 자신의 전 재능을 바치지는 말라. 다 해결해 주면 유지보수 비용을 받지 못함을 인식하라.

122) 프로그램 개발에 완전무결함이란 없으며 온전함만이 존재한다는 점을 인정하고 개발일에 여유를 가져라. 온전함이란 버그가 존재해도 제대로 돌아가는 프로그램을 말한다.

123) 팀원에게 자신의 재능을 전부 보여주지 말라. 숨겨둔 재능이 있을때 팀원들은 자신을 존경해 준다.

124) 자신의 장인정신에 대한 명망을 잃지 않으려면 나쁜 소문이 일어나는 것을 예방하라. 나쁜 평판이 외부로 새어 나가는 것을 막아라.

125) 프로그래머라고 프로그래밍만 공부할게 아니라 각종 처세술, 대인관계, 리더쉽, 성공학 에서부터 동양고전 등 다양한 교양적 지식을 갖추어라.

126) 남이 불쾌해 하는 일에 대해서는 참견하거나 끼어들지 말라. 젊잖게 행동하고 고상하게 행동하라.

127) 매사에 자신을 성찰하고 자신을 탐구하라.

128) 프로젝트 수행시 프로젝트가 성공할 것임을 확신하고 프로젝트에 임하라. 자신감이 없다면 프로젝트 수행은 실패가 될 가능성이 높다.

129) 프로그래밍, 팀워크 그리고 프로젝트 수행을 통해서 지식을 초월하여 지혜를 배우도록 하라.

130) 프로그래밍만 잘하는 것을 넘어서 영어회화, 대인관계, 독서능력, 운동, 취미, 여가생활 등 다양한 분야에서의 재능을 길러라.

131) 지나친 자신감은 금물이지만 남에게 기대감을 불러일으킬 수 있는 자신감은 좋은 것이다.

132) 임베디드 프로그래밍과 같은 경우 사소한 버그가 치명적일 수 있으므로 프로그래밍 시 신중함을 기하라.

133) 프로그래머는 기술력으로 승부해야 한다. 기술력은 좋은 평판을 얻게 한다는 점을 명심하라.

134) 자신의 속 마음을 남에게 나누지 마라.

135) 겉모양만 보고 팀원이나 관리자 그리고 고객을 판단하지 마라.

136) 지루하고 반복적인 프로그램 작업일지라도 거기서 배울 것이 있음을 깨달아라.

137) 남들이 알아주지 않는다고 실망하거나 자조하지 말라. 대신 자신이 남들을 알아주지 못했는가를 자문해 보도록 하라. 주는데로 받는 법이다.

138) 운이 좋을때 그 운을 다 소화할 수 있는 큰 그릇이 되라.

139) 프로젝트마다 사용되는 언어와 개발툴이 다를 수 있음을 인정하라. 어떤 프로젝트에 어떤 언어를 사용해야 하는지를 알고 다양한 언어와 개발툴을 배우고 경험하는 것을 두려워하거나 거부하려고 하지 마라.

140) Less is More라고 덜 말하는 것이 더 많은 말을 의미한다. 말은 짧고 간단하게 할 줄 알라.

141) 프로그래머의 명예를 지킬 줄 알라. 프로그래머는 노동을 해주는 단순한 일개의 노역자가 아니라 기업의 문제를 해결해 주는 해결사임을 인식하라.

142) 지위의 높고 낮음에 얽매이지 말라. 지위보다 더 중요한 것은 고매한 인격과 훌륭한 기술력이라는 것을 상기하라.

143) 자신이 프로그램을 완성하면 자아도취에 빠지곤 한다. 하지만 그러한 자아도취를 남에게 내보이지 말도록 하라.

144) 다른 소프트웨어 장인이 어떻게 장인이 되었는가를 탐색하고 그들의 길을 걸어가도록 하라.

145) 남을 비난하지 말고 비난 받지 않도록 경계하라. 만약 남이 자신을 비난하더라도 대응하지 말고 참아라.

146) 일을 하고 일에서 물러날 때를 아는 것이 훌륭한 프로그래머이다.

147) 자신의 재능을 지나치게 믿지 말라.

148) 프로그래밍시 발생하는 문제를 해결해 줄 절친한 친구를 사귀어두라.

149) 프로그래머에게도 프로그래밍 실력만이 중요한 것이 아니라 인맥(휴먼 네트워크)이 중요함을 인식하라.

150) 시기, 질투가 난무하는 곳에 가지 말고 그런 사람들을 사귀도록 하지 마라. 오직 명예롭고 순수한 사람을 사귀도록 하라.

151) 일이 잘된다고 방심하지 말고 일이 안될때를 대비하라.

152) 자기를 칭찬하거나 교만해 하지 말라.

153) 시대의 흐름을 따르라. 변화에 적응하라. 변화에 거부하지 말라.

154) 때로는 모른 척 하고 넘어가야 할 때도 있음을 알라.

155) 팀원, 관리자, 고객의 마음을 사로잡을 수 있는 능력을 키워라.

156) 일반적으로 무결성있는 코드를 작성하려고 노력하면 버그가 최대한 줄어든다는 점은 상식이다. 이러한 상식을 얼마나 잘 지키느냐가 프로그래머로서의 자신을 고상하게 만들어 준다.

157) 남을 원망하기 전에 자신이 원망할 짓을 하지 않았는지를 살피라.

158) 남들이 도움을 기대할 수 있는 능력있는 사람이 되어라.

159) 자신의 잘못과 남의 잘못을 모두 잊어버릴 줄 알라.

160) 관대함과 정직함을 프로그래머의 생명으로 삶아라.

161) 불평을 한다고 해서 불평이 이루어지지는 않는다는 것을 깨달아라.

162) 자신의 능력을 과대포장해도 안되지만 PR을 하지 않는 것도 문제이다. 자신의 능력을 어느 정도 드러낼 줄도 알아야 한다. 중용이 중요하다.

163) 이미 결정내린 것에 대해서도 다시 숙고하는 자세를 길러라. 최종적인 국면에 치다르기 전에 취소할 수 있음을 알라.

164) 남과 다투거나 의견의 상치를 이끌려고 하지 말라. 남과 무조건 동의하려고 하는 것도 아첨이 될 수 있으므로 주의를 요하지만 남에 대해 트집을 잡거나 다투고자 하는 것은 어리석은 짓이다.

165) 항상 자신은 어리석다고 생각하라. 물론 마음속으로 말이다. 그래야 비울 줄 알고 더 배울 수 있는 것이다.

166) 소프트웨어 장인은 혼자서 전체의 프로그램을 개발할 수 있는 능력을 가진 존재이다. 이렇게 되도록 노력하고 또 노력하라.

167) 문제의 핵심으로 바로 들어가라. 주위를 서성이지 말라. 쓸데없는 말이나 쓸데없는 코드 작성으로 시간을 낭비하지 말라. 문제의 요체가 되는 코드를 작성하고 그에 대한 핵심 담론만을 나누어라.

168) 때로 일어나는 감정의 소용돌이 속에서 조용히 지켜보는 관조자가 되라.

169) 운이 없을때는 체념하지 말고 2배, 5배 그 이상을 노력하고 운이 좋을때를 기다려라.

170) 긍정적으로 생각하고 자신의 단점보다는 장점을 생각하라.

171) 관념을 타파하라. 관념은 고집불통을 낳게 된다. 그것은 위험하다. 관념을 녹여버릴 줄 알라.

172) 자신의 일한 댓가에 대해 정당한 보수를 받도록 하라.

173) 약점과 단점은 최대한 숨기도록 하라.

174) 사사물물과 사건들 속에서 숨겨져 있는 지혜를 발견하도록 하라.

175) 충고해 주는 팀원이나 관리자 그리고 고객을 존경하라.

176) 대화의 기술을 몸에 익히고 피드백 기술을 통해 일의 능률을 향상시켜라.

177) 책임을 혼자 뒤집어쓰려고 하지도 말고 남에게 전가하려고 하지도 말라. 책임은 공유하는 것이 좋다.

178) 팀원들 중의 어느 누가 좀 모자라게 보여도 눈감아 줄 수 있어야 한다. 인내심을 길러라.

179) 생각과 말 그리고 행동을 모두 조심하라.

180) 남들로부터 승리하는 법을 배우라. 경쟁자가 되었든 적이 되었든 승리하는 법을 배워라.

181) 지행일치가 되지 않는 사람은 경계하라.

182) 자신감을 갖고 자신을 의지할 줄 알라.

183) 프로젝트에서 되도록 성공하도록 하라. 실패보다는 성공할 때 배우는 것이 더 많다. 그 중 하나가 성취감이다.

184) 지나치게 서두르지 말라. 소프트웨어 개발은 서두른다고 해결되는 것이 아니다.

185) 내면에서 우러나오는 소리에 귀를 기울일 줄 알라.

186) 팀원들 간에 너무 친하지도 말고 너무 불친절하지도 말도록 환경을 조성하라. 가까우면 지나치게 의존하려고 하고 멀어지면 서로 협력이 안된다.

187) 사사물물에는 명암이 있음을 인지하라. 좋은 면이 있으면 나쁜 면이 있는 법이다.

188) 지혜의 명언은 실전에 사용되지 않으면 똥이나 다름없다는 성현의 가르침을 깨달으라.





출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=4&no=184&page=1

Posted by Sting!
,
제 2회 Meet The Architect : 아키텍트의 논리와 직관 이라는 세미나가 성공적으로 마쳤습니다.

 

장소가 멀어 많은 분이 참여하시지 않을까봐 걱정이 많았는데, 많이 와 주신것 같습니다.

 

장승운 이사님의 세미나는 개발자들의 편향적인 기술지향적인 사고에 일침을 가하고,  올바른 가치 추구와 세상의 흐름을 깨닫게 해주는 멋진 세미나였습니다.

 

많은 분들이 블로그에 좋은 후기를 남겨주셨고, 몇분의 열성팬들은 MindMap까지 만들어 공유하시는 군요. 지식 나눔의 좋은 예라고 생각이 듭니다.

 

저 역시 실제 아키텍트들을 만나기 이전에는 일반 서적에서와 같이 기술 지향적인 측면으로만 아키텍트를 보아왔습니다.

 

 

 

하지만 실제 많은 아키텍트 분들을 만나면서, 좋은 소프트웨어를 만들기 위해서는

단순히 기술적인 요소외에도 펀딩, 커뮤니케이션 제어, 고객과의 협상, 수학등 너무나 많은 요소들이 필요로 하다는 것을 깨닫는 좋은 시간이었습니다.

 

 세미나의 주제는 다음과 같았습니다.

  • 아키텍트로써 갖추어야 하는 역량
  • 논리의 중요성과 생존 능력
  • 메가 트랜드 (Mega Trend)
  • 아이스버그 (Iceberg)

특히 다윈의 "종의 기원"에서 가져온 사람의 본질과 특성에 대한 얘기들이 너무 신선했습니다.

 

TP를 보시면서 그 아쉬움을 달래시길 바랍니다.

 

 

 

Slideshare.net 를 통해서 PDF를 , 데브피아를 통해서 PPTX를 받으실수 있습니다.

 

그리고 약속한대로 제가 정리한 마인드 맵입니다.

 

(이미지를 클릭하시면 풀 화면을 다운 받으실수 있습니다.)

 

 

PDF 버젼             2ndmeetthearchitect

 

MindMap 버젼      아키텍트의 논리와 직관.mm  (FreeMind로 작성 되었습니다. )

 

많은 분에게 도움이 되었길 바라며,  세미나에 오시지 못한 분들에게 유익한 자료가 되었으면 좋겠습니다.

 

후배들을 위해 자신의 지식을 흔쾌히 나눠주신 장승운 아키텍트 (이사)님에게 다시한번 감사를 드리며 글을 맺습니다.



출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=4&no=196&page=1
Posted by Sting!
,

립싱크 하는 사람들을 가수라 칭하지 마라.
그들에게는 립싱커라는 신조어를 만들어 주어라
                                             - 맨발의가수 이은미 -

 

 

 

 

 

 

저를 비롯한 제 주위의 몇몇 소수를 보고 느낀 거지만...

그 소수에게서 100% 공통적인 특징은
개발 1~2년차가 됐을 때 쯤에...한없이 거만해 진다는 겁니다.


int i = 2; 라는 문장을
수학과, 프로그래밍 사이에서 고민하던 그들이

이제는 어려운 로직도 단숨에 짜내면서 스스로 아주 높은 수준의 프로그래머가 되었다 칭하기 때문일까요?


결과는 하나지만, 그 로직은 수백, 수천가지가 될 수 있음에도...
오직 내가 짠 코드만이 완벽한 것이다라고 외치는 그들......


10년, 20년을 해왔음에도 힘들어 하는 개발자들을 보며 스스로 그들을 한심해 합니다.

 

코어에서 돌아가는 원리를 파악하며, 메모리와 안정성을 고민하는 그들앞에서

인터넷서 검색한 소스로 결과만 나오면 된다는 그들이 말이죠.

 

완전 초보들은 검색도 할줄 모릅니다.
키워드가 뭔지...내가 궁금한 게 뭘 뜻하는건지도 모르기 때문이죠.

이제 1, 2년차는 딱 말하면, 아~ 뭐구나~ 라는건 알고 있기 때문에...

요즘같이 검색 잘되는 엔진 앞에서는 느려도 한두시간이면 소스를 구하게 되죠.

그리고 그들이 결정적으로 말하죠.

 


"그 기능 만드는 거 쉽다"

 

 

 


2년전에, 로직을 하나 짜게 됐습니다.
수많은 테스트와 디버깅을 거쳐 완성된 단 한줄의 로직이 있었습니다.
그 로직속에는 ( 변수 / 3 ) 이라는 부분이 있었죠

왜 3으로 나누는지 그 3이라는 값이 나오기 위해 내가 얼마나 많은 테스트를 거쳤는지도 모른체
사용하는 사람은

"잘되네~" 하고 끝내버립니다.

 

요즘들어 프로그래밍이 예전보다는 많이 친숙하게 바뀌고 간편해지면서
10년, 20년전보다는 훨씬 대중적이 됐습니다.

그래서 다양한 사람들이 다양한 분야에서 배우고, 일을 합니다.


공부를 시작한 초보들이여...
소스를 달라 하기전에 만드는 방법을 가르쳐 달라 하십시오.

이제 프로그래밍을 조금쯤 알게 된 이들이여...
복사, 붙이기 이전에 인텔리젼스라도 살펴보며 , MSDN이라도 뒤져보며 직접 만들어 보십시오.


오래된 개발자들이여...
초보시절의 초심을 되새기며,
현재 자신은 눈감고도 짤 수 있는 간단한 로직이라도, 초보에겐 몇날몇일 밤새도 이해할 수 없었음을 기억해 주십시오.
그리고 그들에게
고기를 주는게 아니라 고기를 낚는 방법을 가르쳐 주십시오.


옳게 배운 초보가
제대로된 프로그래머가 됩니다.

기초를 탄탄히 한 초보가
진정한 로직을 만들어 냅니다.


자, 지금 당신은 어느 길을 가고 있습니까?

혹 1,2년차에 접어들어 한참 프로그래밍이 쉽고, 재밌게 느껴지십니까?  
나는 정말 천재야... 5,6년 했다는 사람도 끙끙 대는걸 내가 이렇게 쉽게 만들고 있쟎아 라고 생각하며
대견해 하고 있습니까?

 

인터넷에서 떠다니는 소스가 여러분의 것이 아닙니다.
복사, 붙이기는 개발이 아닙니다.

 

 

복사 붙이기 하는 사람들을 개발자라 칭하지 마라.
그들에게는 프로그램 스크랩퍼라는 신조어를 만들어 주어라
                                             - 맨땅에 해딩 모정남 -

출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=4&no=178&page=1
Posted by Sting!
,

패턴으로 가는길

칼럼 2008. 12. 26. 17:16

어떻게 해야 패턴을 좀더 쉽게 공부하고 체득할 수 있을까요? 

제가 강의나  Online을 통해 많은 분들이 저에게 질문을 하십니다.

제가  집필중인 "미워도 다시 보는 패턴 이야기"라는 서적 안에 패턴서적의 빌드오더를 적어놓았지만, 

POSA2와  Framework Design Guideline  이 두 서적의 편역 작업이 급해 집필이 무한정 연기되었습니다.

 

이 책이 나올때 까지 기다리세요!! 라고 말하면 너무 장사치 같겠죠. ^^..

 

이번 컬럼을 통해  부족하지만 제가 걸어온 그리고 걸어갈 패턴의 길을 알려드리고자 합니다.

 

 

 

1. 패턴을 대하기 이전에 마음가짐 - 유연성, 확장성

 

많은 분들이 패턴에 대해 허상을 가지고 있는데요. 

왜 패턴을 공부해야 되는지에 하시나요?

 

종종 패턴을 이용하면 비약적인 성능 향상, 생산성이 증대 될거라 생각하시는 분도 있고 심하신 분은 Silver Bullet (은총알)로 생각하시는 분도 있습니다. 

 

물론  제한적인 도메인안에서 성능, 생산성 향상을 가져 올수 있는 패턴도 있지만,  패턴 자체의 목적은 유연성과 확장성에 좀더 초첨이 맞추어져 있습니다.

 

초창기 객체 지향(80년대)의 가장 중요시 여기는 패러다임은 "Reuse (재사용)" 였습니다.  그래서 Component와 같은 이상적인 패러다임이 나오기도 했습니다. 마치 Lego와 같이 조립만 하면 만들어지는 Legoware를 꿈꾸어 왔죠.

 

하지만 현재 소프트웨어는 어떠한 가요?  빈번하게 바뀌는 시장의 요구사항, 한두 명이서 만들수가 없을 정도로 거대해진 규모,  길어진 소프트웨어 생명주기를 가진 녀석들이 대부분입니다.  

 

그렇기 때문에 소프트웨어가 가져야 할 중요할 설계 방향이 재사용성 보다는 쉽게 변화를 받아 들일수 있는 유연성 (Reflexibility)과 뛰어난 확장성(Extensibility)을 가지는 것이 더욱 중요하게 되었습니다.

유연성과 확장성에 관심이 있는 분이라면 패턴은 좋은 도구가 됩니다.

하지만,  최적화나 성능 개선이 목적이시라면 패턴보다는 알고리즘을 공부하는 것이 더 나을 것입니다.

 

 

 

2. 패턴의 시작은 GoF 부터?

 

GoF 책이 명서이며,  패턴책에  큰 영향을 끼친 절대적인 서적임은 틀림없습니다.

하지만 여러분이 처음 패턴을 접한다면 GoF의 Design Pattern이라는 서적은 매우 어려운 서적이 될것입니다.

GoF 책을 보고 좌절하신 초보 개발자나 학생들을 많이 보아왔기 때문입니다. 

저역시도 초보시절 GoF 책을 이해하기 위해서 3번을 읽었고 읽을때마다 새로운 느낌을 주는 서적이었습니다. 

마치 성경을 읽는 느낌이라고 할까요? 그 만큼 깊이가 있는 책입니다.   

 

GoF 책은 1990년대 후반부에 쓰여있다 보니, 1990년 중반부에 사용되는 Application을 예로 들어 설명하였고, C++ 의 이해를 수반으로 하고 있기 때문에 초보 개발자에게는 난해할 수 밖에 없었습니다.

그래서 2000년대에 이슈인 Database 프로그래밍과 같이 누구나 쉽게 이해할수 있는 수준으로 설명한 책이 Design Pattern Explained 였고 국내에서는 알기 쉬운 디자인 패턴” 이라고 번역이 되었습니다. 불과 2년전만해도 초보자를 위한 디자인 패턴책은 이것 밖에 없었습니다.

 

하지만 현재는 뇌공학을 연계로 해서 쉽게 개념을 파악할수 있는 좋은 서적이 나왔습니다.

바로 “Head First Design Patterns” 입니다.

한빛 미디어에서 번역되었으며 국내 패턴 서적에서는 계속 1위를 고수하고 있으므로 보시길 권해드립니다.

하지만 정신 사납다고 하시는 분들도 계시네요 ^^ 그런 분들은 알기 쉬운 디자인 패턴을 읽길 권해드립니다.

 

다음 단계 서적으로는, 구체적으로 하나의 언어를 정해서 언어별 특성을 파악하며 패턴을 살펴볼 필요가 있습니다.

여러분이 Java에 관심이 많다면 "Java 언어로 배우는 디자인 패턴 입문" 을 추천 드리며,

C++에 관심있는 개발자라면 장세찬씨의 “GoF 디자인 패턴! 이렇게 활용한다.”를 보시길 권해드립니다. 

그 다음 GoF 서적을 보시면 한결 수월하게 읽으실수 있을 겁니다.

 

이것으로서 패턴의 가장 기본이 되는 Micro Pattern들을 터득하실수 있습니다. 

GoF Pattern은 단지 패턴의 시작일 뿐입니다.  

 

GoF 패턴을 이해하셨지만, 여러분에 프로그래밍에 바로 적용하시는 분은 매우 극소수일 겁니다.

왜 일까요? 결코 여러분의 능력이 떨어져서가 아닙니다. 

패턴을 올바로 이해하고 활용하기 위해서  작년에 마소에 기고 했던 "미워도 다시 보는 패턴 이야기" 라는 글을 다운 받아 읽어보시길 바랍니다. 

 

이부분까지 이 컬럼에 다 쓰다간 대하드라마가 될거 같네요 ^^.

 

 

3. POSA (Pattern-Oriented Software Architecture) 의 세계로 초대.

 

일명 POSA 라고 불리는 이 서적들은 GoF와 어깨를 나란히 하는 명서중에 명서이며,

GoF를 읽은 분이라면 패턴에 좀더 깊은 세계를 맛보기 위한 좋은 서적입니다.

 

GoF(1995년)가 나온 1년뒤에 볼륨 1권이 출간(1996년)되었지만, 

국내에는 2008년도에 역서가 나왔기 때문에 패턴 초보자들에게는 그리 알려져 있지 않은 서적입니다. 

 

GoF가 가벼운 Micro Pattern 이었다면, POSA는  좀더 세부적인 도메인을 다루고 있는데요. 

이 책을 탐독하면 자연스럽게 패턴 군 (Compound Pattern)들이 눈에 보이게 됩니다.  물론 GoF 패턴이 전제에 깔려 있습니다.

1,2권은 제가 마이크로 소프트웨어에 서평을 기고한 적이 있으니 링크를 통해 읽어보시고,

 3권 (Resource Pattern)에 대해서 간략히 언급하겠습니다.

 

자원 관리를 위한 패턴들의 집합으로, 리소스 획득, 반환, 생명주기에 관한 패턴으로 크게 카테고리가 나뉘어져 있습니다. 

기존의 리소스 관련 지식들을 패턴으로 잘 정형화했습니다.  1,2권에 비해 패턴 하나 하나에 깊이 있게 다루지 못하는 것이 흠이지만, 리소스 관리에 대한 지식을 정리하기에는 좋은 서적이라고 할수 있습니다.

 

물론 4,5 권도 나와 있지만 4권은 1,2,3군의 내용을 합쳐놓은 것이고, 5권은 Pattern을 만들기 위한 Meta Pattern에 가까운 것이기 때문에  구입을 안하셔도 될듯합니다.

 

^^ 참고로 1권의 번역서는 저희 스터팀이 감역하였으며, 지금 현재 2권을 편역중입니다. 

 

 

4. 도무지 끝이 없는 패턴 이야기 (PLOP와 다양한 패턴들)

 

이제 패턴 서적은 매년마다 무수히 쏟아져 나오고 있습니다.

그리고 PLOP 학회를 통해 무수히 쏟아내는 패턴들.  그야말로 패턴의 홍수시대가 왔습니다.

제가 소장하고 있는 괜찮은 패턴 서적들을 몇가지를 여러분에게 공유하고자 합니다.

 

 

PLoPD 시리즈

 

OOPSLA가 열린후 일주일후 같은 장소에서 PLOP라는 유명한 패턴 학회가 열립니다. 

저희 Paper Meeting도 여기서 아이디어를 그대로 가져왔습니다. 그야 말로 패턴의 보고이며, 시중에 나온 새로운 도메인의 패턴 서적들은 거의 다 이 학회를 한번 거쳤다고 해도 과언이 아닐정도로 패턴의 가장 큰 학회입니다. 

다양한 도메인을 폭 넓게 다루고 있고, 학회에 발표된 논문들을 예전 포스트를 통해 공유한 적이 있습니다.

이 학회에서 발표된 패턴중에 괜찮은 패턴들을 묶어 PLoPD (Program Language of Program Design)  라는 서적으로 출간됩니다.    

 

POAD (Pattern Oriented Anaysis Design)

그야 말로 Pattern Drvien Design이라고 불러도 좋을만큼, 패턴을 활용해 분석및 적합한 전략/전술을 선택하는 가이드라인을 제공하는 서적입니다. 아마존 별 5개이지만, 국내에서는 잘 소개되지 않는 서적입니다. 그리고 아쉽게 절판까지 되었습니다. 많은 분에게 도움이 되는 서적입니다.  구하실 수 있다면 꼭 읽어 보시길 바랍니다.

 

 

Remoting Patterns

POSA2가 Open Source CORBA인 TAO, ACE에 사용된 패턴을 소개한다면, 조금 더 최신  기술인 .NET Remoting, Web Service, CORBA , RealTime CORBA 에 사용된 분산 패턴들을 소개합니다.

겉보기에는 POSA2와 다른 패턴을 소개하고 잇는것 같지만 다시 한번 되짚어보면 POSA2에 소개된 패턴과는 내부 맥락이 같습니다. 

이 서적을 통해서 최신 분산 기술에 정리된 내용을 체계적으로 정리할수 있어서 무척 도움이 되었습니다. 특히 .NET Remoting은 WCF (Windows Communication Foundation)과 동일한 아키텍쳐를 가졌다고해도 과언이 아닐정도로 똑같습니다.

 

 

xUnit Test Patterns

TDD가 이슈가 되면서 Testing에 대한 관심이 요즘 매우 급증한 상태입니다.

VS.NET 과 Eclipse 역시 이러한 흐름이 발 맞춰 다양한 Testing 관련 기능을 제공하고 있습니다.

그중 여러분이 가장 자주 사용하시는 것이 xUnit (JUnit, NUnit, CUnit...) 일 것입니다. 

이 책은 Unit Testing을 하기 위해서 어떻게 Testing Code를 작성하고 Refactoring하는지 정수를 보여주는 서적입니다. 막대한 분량으로 인해 많은 분이 좌절하시지만, 꼭 도움이 될 서적입니다. 

저 역시 다 읽어 보진 않았지만 TDD에 관심이 있으신 분은 꼭 읽어보아야할 서적으로 추천드립니다.

 

 

Patterns For Fault Tolerant Software   (내(耐)고장성 소프트웨어를 위한 패턴)

Quality 검증의 TDD 와  방어적인 프로그래밍을 넘어서, 내부적인 고장에도 스스로 복구및 조치를 취할수 있는 한발 앞선 소프트웨어 입니다. Error Handling/ Mitigation , Fault를 Detection하는 다양한 패턴들을 소개합니다.  

뭐니 뭐니해도 핵심은 WatchDog 입니다. 

 

 

PEAA (Patterns for Enterprise Application Architecture)

Refactoring의 창시자인 Marting Fowler 아 저씨가 쓴 책으로, 출판 당시 굉장한 센세이션을 일으킨 서적입니다.  Enterprise Application을 설계하기 위한 다양한 패턴이 소개되어 있습니다. 물론 POSA나 PLOP에 나온 패턴을 현대적으로 바뀐 것이 대부분이지만, 이러한 것도 역시 기술이죠. Martin 아저씨는 과거의 기술, 용어, 개념들을 현대에 맞게  변형, 확장하는 능력은 알아줘야 할듯 합니다.  SI를 하시는 분이라면 역서도  꼭 읽어보세요

 

 

Enterprise Integration Patterns

EAI를 위한 Messaging 처리에 중점을 둔 서적입니다.  어떻게 메세징 시스템을 만드는지 조목 조목 설명이 되어 있습니다. BPM/EAI/Enterprise SOA에 관심이 있는 분이라면 읽어보셔야 될 서적입니다.

 

 

Real-Time Design Patterns

Real-Time 시스템을 구축할때 가장 고려해야 할 것이 에측성일 것입니다.  우선 순위를 고려하고 주어진 Deadline안에 Job이 Schedulable 하냐를 판단하는 것이 중요합니다. 하지 못한다면 차선책을 선택해야 되니깐요.  Embedded , Mission Critical한 시스템을 설계하시는 분에게는 도움이 될 서적입니다.

간략이 요약한 정도라, 방향을 잡는도 유용한 서적입니다. 실무에 쓰시기 위해서는 관련 논문을 찾아 읽으셔야 될듯합니다.

 

 

Refactorig to Patterns

Pattern을 활용하여 Refactoring을 하는 방법을 소개하는 서적입니다.

Martin Fowler아저씨의 Refactoring 읽으신 분이라면 그 다음 이 서적을 읽어 보시길 권해드립니다.

"패턴을 활용한 리펙토링" 이라는 제목으로 역서가 출간되었습니다.

 

 

Architecting Enterprise Solutions

고성능과 인터넷 기반의 시스템을 구축할때 사용하기 유용판 패턴 서적으로, 실제 실무에 Infra를 구축하시는 개발자에게는 좋은 동반자가 되는 서적입니다.   시스템을 제어, 성능 측정, 적절한 서버수 산정과 같은 유용한 가이드라인이 제공되므로 읽어 보시길 권해드립니다.

 

 

PLOP 학회 논문들

하지만 가장 여러분에게 소개 시키고 드리고 싶은 것은  PLOP 학회에서 몇년간 발표된 논문입니다.  매우 엄청난 양을 자랑합니다.    여러분을 좌절을 안겨드려서 죄송하지만, 아마 여기서 소개된 패턴들이 대부분 위 서적들에 소개되었습니다.  그리고 종종 책의 저자도 보이구요.   출/퇴근 시간에 간간히 읽어보시면 도움이 될듯 합니다.

 

 

 

5. 맺음 그리고 저희 스터디 팀의 결실 EvaCast  

 

너무나 많은 서적과 자료들을 소개시켜 드려 절망과 좌절에 빠진 분도 있을 겁니다.   ^^

사실상 이렇게 많은 패턴을 혼자 공부한다는 것은 거의 힘들거 같구요. 

지인을 통해 스터디 그룹을 만드시거나,  이미 활동중인 여러 스터디 모임이 생겼습니다.

이런 곳에 한번 참가해 보시는 것도 좋을듯 하네요.

 

현재 저희 스터디 그룹은 POSA2 번역에 올인하고 있어서, 아쉽지만 몇달간은 스터디가 중지되었습니다. 

 

하지만  그동안 저희 스터디 팀의 노력의 결정체들을  EvaCast를 통해 공유해 놓았습니다.

GoF, POSA1, POSA2 패턴들을 거진다 보시고, 다운 받을수 있을뿐만 아니라, 이번에 완전 새롭게 개펀 작업을 했습니다.    

EvaCast 을 통해 혼자라도 꾸준히 공부해 나가시길 권해드립니다. 

그럼 혹시 궁금하신 질문은 Comment로 남겨주시면 답변드리겠습니다.  감사합니다.


출처 : http://www.devpia.com/Maeul/Contents/Detail.aspx?BoardID=4246&MAEULNo=4&no=37819
Posted by Sting!
,

1. 프로개발자의 프로그래밍은 아마츄어와는 다르다.

 

  프로그래밍의 공정은, 설계 내용을 현실의 소프트웨어로 변환하는 작업이다. 결정할 수 있는 언어나 개발툴을 사용해, 사양서에 기술된 처리 내용의 프로그램을 작성한다. 발견된 버그를 해소할 때까지 작성 작업은 계속 된다. 일반적으로, 모듈 테스트만은 프로그램의 작성자가 실시하고, 그 이상의 테스트는 별도인 담당자가 실시한다. 테스트에서 버그가 발견되면, 프로그램의 작성자가 수정하고 이런 반복이 개발의 끝까지 계속 된다.


 업무로 작성하는 프로그램은 취미로 만드는 경우와 크게 다르다. 신뢰성은 물론이거니와 변경하기 쉬운 유연성을 필요로 하고 처리 내용을 알 수 있기 쉬게 파악성도 염두에 두어야 한다.  또, 대상이 되는 분야에 따라서는 처리 속도를 한계까지 향상시키지 않으면 안 된다.  이 중 어떤 것을 중시해야할 것인가는 설계 단계에서 고려되어 개개의 모듈 마다 명시한다.
 프로그램에 요구되는 특성 가운데 아마츄어와 가장 다른 것은 유연성과 파악성이다. 기능 변경에 따라 수정하면서 계속 사용하므로 유연성의 높은 프로그래밍이 반드시 필요하기 때문이다.  또, 시스템을 팀 단위로 개발하기 때문에 작성자와는 별도인 사람이 수정하는 경우도 꽤 많다. 그 때의 부하를 경감하는 의미로 누가 봐도 알수 있는 파악성이 높은 프로그램을 만들지 않으면 안 된다.


 실은 신뢰성을 높이는데도 유연성이나 파악성이 크게 영향을 준다. 프로개발자에 있어서의 신뢰성에는 시스템을 계속 수정한 상태에서도 높게 유지하는 것까지 포함된다. 유연성이나 파악성이 뒤떨어지면 수정에 의해서 신뢰성이 저하되 목표로 하는 품질을 유지할 수 없다. 진짜 신뢰성이란 계속 수정하는 도중 상태도 포함하고 있어 시스템의 사용 초반부터 다 사용할 때까지의 전기간에 평가되어야 한다.
 이상과 같은 요구에 만족할수 있도로 만들 수 있는 것이 진짜 프로개발자라고 할 수 있다.

 

2.유연성을 높이는 객체 지향은 높은 설계 능력을 요구한다.

 시스템이나 프로그램의 유연성을 높이는 노력은 이전부터 행해지고 있었다. 프로그램에 관계하는 방법에서는 적절한 기능으로 나눈 모듈 분할 구조화 프로그래밍등이 유명하다. 획기적인 개선은 할 수 없었지만 어느 정도의 성과는 얻을 수 있었다.


 최근의 주류가 되고 있는 것은 무엇보다도 객체 지향 기술이다. 개발 환경이나 개발툴의 성능이 향상되고 새로운 OS에서는 객체 지향의 API를 최초부터 탑재하고 있을 정도다.


 객체 지향 기술은 프로그래밍 뿐만이 아니라 시스템 설계에도 크게 도움이 된다. 양쪽 모두에 적용하면 최대의 효과를 얻을 수 있으므로 설계 단계로부터 이용한다. 더 본격적으로 활용하는 경우에는 분석의 공정으로부터 이용한다.


 객체 지향 기술의 최근 중심은 프레임워크와 디자인 패턴이다. 프레임워크는 GUI를 중심으로 한 개발툴에 장비해 프로그래밍 작업의 부하를 경감한다. 디자인 패턴은 클래스의 좋은 설계 예로서 참고해 프레임워크 이외의 클래스를 작성할 경우에 이용한다.


 프레임워크 쪽이 GUI 중심의 개발툴을 뒤따르고 있는 것이라면 꽤 간단하게 사용할 수 있다. 초보자로부터 베테랑까지 폭넓게 도움이 되는 기술이다. 유저 인터페이스 부분만큼이라면 프레임워크에 의해서 간단하게 만들 수 있다. 그런데 대상 분야마다의 독자 기능에 관해서는 클래스로부터 설계해야 한다. 이 때에 디자인 패턴을 이용한다. 큰 기능은 시스템 설계 레벨로 이용해 작은 기능은 프로그램 레벨로 이용한다. 그 때문에 프로그래머는 디자인 패턴을 이해하고 좋은 구조로 만들지 않으면 안 된다.


 디자인 패턴을 알고 있었다고 해도 클래스 설계는 높은 설계 능력을 요구한다. 이 점이 프레임워크와 크게 다른 점이다. 설계 능력이라고 하는 것보다 설계의 센스라고 하는 표현 쪽이 적절할지도 모르다. 여하튼 이런한 힘에서는 좋은 구조로 설계할 수 없는 것이다. 즉, 툴이 진보하고 유연성을 높일 수 있지만 그러기 위해서는 설계자에게도 프로그래머에도 높은 설계 능력이 필요하다.

 

3.파악성은 프로그램의 표준화로 향상시킨다.

 파악성을 높이는 연구는 유연성과 같이 시스템 설계에 크게 관련되는 것 과는 달리 프로그래밍 쪽에 크게 관계한다. 프로그램의 처리 내용을 이해하기 쉽게 만드는 것이 목적으로 변수명이나 코멘트등의 붙이는 방법을 표준화 하는 것으로 실현된다. 규정한 표준화 룰을 지키는 것으로 프로그램을 이해하기 쉽게 일정 레벨로 유지한다.
 무엇보다 기본적인 룰은 변수명의 붙이는 방법이다. 구조체를 포함한 데이터형, 데이터 자체인가 포인터인가 핸들인가, 글로벌인가 로컬인가등이, 변수명을 본 것만으로 알 수 있도록 한다. 변수명 뿐만이 아니라 클래스명, 메소드명, 함수명등도 같은 생각으로 룰화한다.


 표준화할 내용중에는 전체의 제어 구조를 명확하게 전하는 것, 클래스간이나 메소드간의 관련등도 포함해 어떤 구조가 되어 있는지 빠르게 읽어낼 수 있도록 만든다. 메소드명이나 변수명의 붙이는 방법에 가세해 화려한 코멘트를 능숙하게 이용한다. 또, 명령의 줄 순서를 공부하는 방법도 효과가 있다.
 코멘트을 붙이는 방법에서는, 설명 대상의 범위를 명확하게 나타내 보이도록 룰을 결정한다. 대상이 1행인가, 복수행인가, 1 블록인가로 코멘트의 서식을 바꾼다. 반대로, 1행의 명령에 복수의 코멘트를 붙이기도 하므로, 이 케이스도 룰에 포함한다.


 모듈마다의 기능이나 변경 이력등도 코멘트로서 선두에 명기한다.  또, 개발 도중의 단계를 구별하여 원시 코드의 관리를 돕는다. 최초의 프로그래밍 단계, 모듈 테스트를 종료한 단계, 개발을 종료한 단계등으로 구별할 수 있으면, 같은 이름의 원시 코드가 복수 나왔을 때 혼란이 생기기 마련이다.
 이것들 이외에도 아이디어 순서로 파악성을 향상할 수 있다. 어느 정도까지 할수 있는가는, 조직에 의해서 크게 다르지만 기본인 변수명의 표준화는, 많이 실시되고 있는 편에 들어간다. 반대로 가장 중요한 전체의 제어 구조의 명확한 표현은 좀처럼 룰화 되어 있지 않다.

 

4.프로개발자 레벨의 프로그래밍은 현재 상태로서는 소수파.

 실제의 개발 현장을 보면 업무로 작성하는 프로그램의 모든 것이 프로개발자의 레벨이 요구된다고는 할 수 없다. 그 뿐만 아니라 그러게 만드는 방법조차 모르고 프로그래밍 하고 있는 쪽이 현재 상태로서는 더 많다고 볼수 있다.

 

  그 원인을 몇가지 들어 보자.


 프로그래밍을 공부할 때 잡지나 단행본의 해설을 참고로 한다. 거기에 실려 있는 샘플에서는 매우 유감스러운 일이지만 프로개발자의 레벨로 만들어진 것으로 보이지 않는다. 기본중의 기본인 변수명의 붙이는 방법조차 전혀 신경쓰지 않고 만들어져 있다. 이런 상태이므로 프로개발자의 레벨에는 달하지 않았다. 유연성에 관한 기사나 책은 좋은 것을 이따금 보인다. 그러나 파악성에 관한 기사나 책은 전무에 가까워 어느 레벨이 꽤 낮다.


 또 하나 문제인 것은 OS나 개발툴을 만들고 있는 회사도 파악성에 관해서는 이해하고 있지 않는 점이다. OS가 제공하는 API, 개발툴이 제공하는 프레임워크 양자가 제공하는 샘플의 어떤 것을 봐도 파악성을 고려하고 있다고는 생각되지 않는 것뿐이다. 여기에서도 기본중의 기본인 변수명의 붙이는 방법조차, 프로개발자의 레벨에 이르지 않았다. 또, 코멘트의 붙이는 방법도 프로개발자의 레벨에는 멀다.


 이러한 예를 보면  많은 프로그래머는 똑같이 만드는 것이 당연하다. 프로개발자 레벨로 만드는 방법을 모르기 때문에 그렇게 만들지 않는 것이다. 만약 알고 있으면, 의식해 프로그래밍하는 사람은 확실히 증가 할 것이다. 반대로, 프로개발자 레벨로 프로그래밍 하는 방법을 채용하고 있는 조직으로 일한 경험이 있는 사람은 그방법을 강제적으로 마스터 당해 말하지 않아도 제대로 프로그래밍하는 방법을 염두에 두겠지만. 그러한 조직이 매우 적기 때문에 전체적으로는 소수파가 된다. 어쨌든 OS나 개발툴을 만들고 있는 기업에서조차, 프로개발자의 레벨을 채우지 않으니까. 즉, 진짜 문제는 파악성을 중시한 만드는 방법이 널리 알려지지 않은 점이다.



출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=8&no=195&page=1
Posted by Sting!
,