19081
7
7
분석하면서 학습하는 것이 중요
컴퓨터의 세계에서는, 새로운 기술이 차례차례로 등장한다. 개발에 종사하는 사람은, 자신이 필요한 기술을 계속 학습하지 않으면 안 된다. 또, 세상의 최신 기술이 아니어도, 자신에게 있어서 새로운 기술을 습득할 기회는 자주 있다. 기술 혁신이 격렬한 만큼, 습득에 걸리는 시간을 짧게 하는 것이 요구되고 있다.
모르는 기술을 배울 때는, 자신이 가지고 있는 기존의 지식을 최대한으로 이용해야 한다. 그러면, 학습의 효율이 향상할 뿐만 아니라, 습득 기술을 높은 레벨로 살릴 수 있는 기초가 완성된다. 깊게 생각하지 않고 공부한 것은 우선 사용할 수 있는 레벨 밖에 되지 않고, 그러면 설계의 질을 향상할 수 없다.
학습 시에 생각해야 할 것은, 그 기술을 이용하고 시스템을 만들 때, 어떠한 설계 룰을 적용시키면 좋은가다. 시스템 전체로의“파악성, 유연성, 신뢰성”를 향상시키기 위해서 필요한, 설계 가이드 라인의 규정을 최종 목적으로 한다. 이러한 목적이 있으면, 학습으로의 집중력은 꽤 높아진다. 또, 완성된 가이드 라인은, 실제로 설계할 경우에 역립 해, 학습이 끝나자 마자 이용하기 시작할 수 있다. 반대로, 기술을 단지 기억하는 것 만으로는 안된다. 그 기술이 가지는 기능을 분석해, 어떻게 설계해야 하는가 생각하면서 학습하는 편이 좋다.
학습의 교재로서 기술의 개발원이 제공하고 있는 자료를 이용하는 것이 많다. 그 내용이지만, 기술의 사양을 기술한 것으로부터, 사용법을 설명한 것까지 있다. 여기서 주의하고 싶은 것은, 사용법을 설명한 자료의 내용이, 좋은 설계에만큼 먼 것 바보 리나점이다. 소개되고 있는 샘플에서는, 시스템의“파악성, 유연성, 신뢰성” 등, 전혀 생각하지 않았다. 이해하기 위한 예이며, 설계의 예가 아닌 점을 인식해 두자. 설계로서는 나쁜 예가 거의이므로 참고로 하지 않고, 스스로 좋은 설계를 요구할 필요가 있다. 유명한 대기업 메이커라고, 자료가 좋은 것은 우선 없다. 기대하는 것은 금물이다.
파악성등을 고려해 설계 가이드 라인을 이끈다
여기까지의 이야기라고, 꽤 추상적 지나 이해 받을 수 없다고 생각한다. 간단한 예를 들어 설명하자. 많은 사람에게 관계가 있는 대상이 좋기 때문에, 새로운 프로그램 언어의 습득을 생각한다. 프로그램 언어(이어)여도, 고려해야 할 중심은“파악성, 유연성, 신뢰성”의 3. 이러한 종합점이 높아지도록(듯이), 설계 가이드 라인을 규정해야 한다.
우선은 최초의「파악성」로, 원시 코드를 본 것만으로 처리 내용을 알 수 있도록(듯이) 한다. 우선 생각해 떠오르는 것은, 세세하게 코멘트를 붙일 것이다. 그러나, 코멘트를 자세하게 붙이는 것 만으로는 불충분하고, 효과는 작다. 처리 내용이나 제어의 흐름을 알 수 있도록(듯이) 프로그래밍 하는 것이 중요하다. 예를 들어, 중심이 되는 제어 구조를 나타내도록(듯이) 메인 루틴을 만든다, 라고 하는 룰이다. 포함되는 분기 부분에서는, 어느 값이 관계하고 있는지를 명확하게 나타내 보인다. 같이 써브루틴의 제어 구조도 알기 쉽게 만든다. 해선 안 되는 것이, 루틴을 부르는 계층을 깊게 하는 것. 몇 겹이나 불리면, 처리를 파악하기 어려워지기 때문이다. 더하고, 다수 있는 분기 명령중에서, 가장 보기 쉬운 것을 선택한다.
변수나 루틴의 명명 룰을, 파악하기 쉽게 규정하는 일도 도움이 된다. 예를 들어, 함수나 메소드등의 이름은「처리＋목적어： 동사＋명사」로, 변수나 오브젝트의 이름은「목적어： 명사」라고 한다든가다. 목적어에는, 복수의 단어를 조합하기도 하므로, 말의 줄 순서도 결정해 둔다. 파악성을 향상하는 궁리는 아직도 있지만, 이 근처에 멈추어 두자.
2번째의「유연성」에서는, 기능의 변경이 가능한 한 하기 쉽게 고려한다. 무엇보다 중요한 것은, 기능적인 단락으로 루틴을 나누는 것이다. 게다가, 서로에의 영향이 최소한이 되도록(듯이), 변수의 주고 받는 방법 등을 규정한다. 프로그램중의 변경할 것 같은 값은, 루틴의 밖에 내 정의해, 자세한 코멘트를 붙이는 것이 중요. 값의 의미 뿐만이 아니라, 적정한 범위등도 기술하도록(듯이), 룰을 결정한다.
3번째의「신뢰성」에서는, 버그가 나오기 어렵게 만드는 것으로, 엄격한 환경에서의 안정성을 향상시키는 것의 2점을 고려한다. 버그를 줄이려면 , 우선「파악성」이 매우 중요하다. 예를 들어, 글로벌 변수의 이름이라면, 절대로 중복 하지 않는 듯한 명명 룰을 규정한다. 그 밖에, 문제가 일어나기 어려운 제어 구조를 만드는 방법, 이용해서는 안되는 명령이나 표기 방법등도 규정한다. 엄격한 환경에의 고려에서는, 메모리 부족등에의 처리 방법을, 미리 결정하는 것으로 대응한다. 생각할 수 있는 상황은 지금까지의 경험으로부터 생각나므로, 우선 전부를 들어 본다. 그 중에 중요한 것을 선택해, 구체적인 프로그래밍 방법을 규정하면 좋다.
이상과 같이 해 모은 룰을 정리해, 최종적인 가이드 라인으로서 통합한다. 경우에 따라서는, 일부의 룰이 서로 모순되기도 할 것이다. 그 때에는, 제1에「신뢰성」을, 다음에「파악성」을 중시해 선택한다. 다만, 어떤 것을 중시해야할 것인가는, 대상이 되는 기술에 따라서 다르므로, 스스로 판단해 상관없다.
설계 가이드 라인을 사양으로 해 정리한다
가이드 라인의 내용이 정해지면, 이용하기 쉽게 사양으로 해 정리하는 것이 중요하다. 항목 마다 분류하고 룰을 늘어놓는다. 가이드 라인을 적용한 샘플을, 몇개나 첨부하는 일도 잊지 않고. 만약 여유가 있다면, 설계 시에 호출해 사용하는 템플릿도 작성하고 싶다. 목적 마다 최적인 형태로 준비하는 것으로, 상당한 효율화를 실현할 수 있다.
가이드 라인을 정리해 버리면, 그 기술을 이용하는 것이 라크가 되고, 곧바로 실천으로 사용하기 시작할 수 있다. 학습의 개시부터 응용까지의 시간은, 가장 짧아질 것이다. 템플릿을 능숙하게 만들면, 세세한 것을 기억하지 않아도, 그 기술을 사용할 수 있다. 반대로 말한다면, 그것이 가능하게 되도록(듯이) 템플릿을 만들어야 한다. 기술 혁신이 빠른 상황에서는, 암기 하는 것을 최소한으로 억제하는 일도 중요라고 할 수 있다.
가이드 라인을 최초로 만드는 것은, 꽤 큰 일이다. 그러나, 비슷한 기술이면, 전의 가이드 라인을 이용할 수 있으므로, 그만큼 귀찮지 않다. 예를 들어, 1개의 프로그램 언어의 가이드 라인이 있으면, 다른 언어의 가이드 라인을 만드는 것이 용이하게 된다. 재산이라고 생각해 만들면 좋을 것이다.
이상이, 모르는 기술의 높은 수준의 습득 방법이다. 이러한 방법은, 지금까지 가지고 있는 기술력을 이용하기 위해(때문에), 그것이 어느 정도 없으면 어렵다. 그러나, 별로 가지고 있지 않은 사람이라도, 이러한 생각으로 공부하는 것은 중요하다. 또, 가이드 라인을 만든 사람은, 그것을 동료에게 공개하고 싶다. 모두가 이용하는 것으로, 설계의 질을 전체적으로 향상할 수 있기 때문이다.
출처 : 데브피아 컬럼 게시판
http://www.devpia.com/maeul/contents/de ··· page%3D1
(0) 
(0)
댓글을 달아 주세요