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
