우리는 정석을 지키고 있는가..

대학교 수업시간에 프로그래밍의 기초를 보면 프로그래밍 순서가 나온다.

요구분석 -> 설계 …….. 등등의 순서가 맞는지 지금은 가물하지만 대략 이렇다한다면 우리는 지키고 있는지 의문이다.

많은 프로그래밍을 해보았지만 대부분의 혹은 일부분의 사람들(소심해졌다.) 은 일단 프로그래밍을 시작한다.

워낙 바쁘고 프로젝트 기간도 별로 없는데다고 요즘같은때에는 요구, 설계가 같이 진행되면서 바뀌는 부분이 너무 많아서 솔직히 힘들다가 정답일듯 하다.

하지만 그렇지 않은 프로젝트를 진행할때에는 한번쯤 해보는 것도 나쁘지 않으리라 생각된다.

설계를 해본다는 것은 전체적인 시나리오를 이해할수 있어야만 가능하고. 설계를 하면서 실제 클래스, 함수(메소드)등을 써가면서 할경우에는 더욱더 설계가 빛을 바란다.

또한 여기에다가 시쿼스 다이어그램까지 들어가면 아놔 이거 정말 멋진 프로젝트가 될수 있다.  문서정리 또한 깔끔하게 진행되지 않겠는가…

이렇게 당연한것을 안하고 있다는 것이다.

이런부분을 크게 느낀것이 최근에 한 프로젝트에서 내가 80%정도 이해할수 없는 분야의 프로그래밍을 급하게 진행해야하는데 정말 머가 먼지 모르겠더라.

설계고 모고 전체가 머리에 안그려져서 너무 힘들었던 경우가 있는데 전체가 안되어서 부분부분으로 해서 설계를 맞추다 보니 나중에 정말

몇번을 엎었는지 모를정도로 코드를 수정했다. 나중에 이해다 되고 코드가 안정화 되었을때는 기존 코드의 2/1 ~ 3/2정도가 빠졌다.

이런것이 설계의 중요성이다.  초보 프로그래머한테 꼭 말해주고 싶다. 일단 설계를 해보라고 꼼꼼히 내가 쓸 함수(메소드) 네이밍까지 해가면서 설계를 완성했을때

코드는 덤으로 따라온다.

모바일 프로그래머는 소심해야한다.

모든 프로그래머에 대해서 그렇다고는 말할수 없지만 프로그래밍을 할때는 소심해야한다.  지금은 예전과 같지 않지만 예전에는 힙사이즈가 128~300k 이던 시절이 있었다.

정말 어떻게든 적게 사용하고 최소한으르 프로그래밍해야하기 때문에 최적화가 정말 많이 필요하던 시절이였다. 그러다 보니 변수, 함수(메소드), 클래스, 이미지 등등 용량이 나가는 것은 무엇이든지 재보고 전체 메모리를 얼마나 차지 하는지 꼼꼼히 계산하던 시절이였다. 지금도 컴퓨터에 비하면 많지는 않지만 이런시절을 프로그래밍을 하던 나에게는 지금 모바일 프로그래밍을 하는 사람들과는 사뭇다르게 프로그래밍을 한다. 1픽셀의 오차, 이미지의 용량 등등을 고려하지 않을수가 없는 것이다.

소심 내가 만든 함수(메소드) 에 예외처리가 되어있는지 버그가 생기지 않을런지 등등의 걱정은 누구나다 한다. 하지만 걱정만 하고 코드에 실천은 실제 해당 버그가 생기고 나서야 들어간다는 것이다. 우리는 프로그래밍에 대한 많은 책들을 보면 언제나 내가 만든 함수에 대한 확실한 예외처리가 되어있다.

아래와 같은 코드가 있다고 하자 완벽해 보인다. 하지만 a, b의 변수값에 의해서 int형을 초과할수도 있고 a, b의 길이에 대한 요구 사항도 없다.

그러므로 버그가 발생할 확율이 올라가는 것이다.

int add(int a, int b)

{

    return a + b;

}

프로그래밍을 하다보면 함수길이가 길어지면 불안해지기 시작한다.  소심하기 때문이다. 그런데 보통 이런경우 100% 버그가 있기 마련이다.

책에는 함수하나에는 하나의 기능을 넣도록 되어있다. 여러가지 기능이 들어가면 분명 버그가 생길 확율이 높아지기 때문이다.

솔직히 함수(메소드)가 잘 정리되어서 소스가 작성되면 보기도 좋고 이해도도 높아진다. 정리가 되어있다면 긴 함수도 그렇지 아니한가? 맞다 하지만

조금더 깔끔하게 정리된다고 할수 있다. 속도에 대해서는 당연히 0.00001초 정도 긴소스가 유리하지만 지금 시대의 프로그래밍 기법은 내가 코딩한 내용을

주석없이 누구에게 오픈하더라도 이해할 수 있는 코드를 작성하는게 정석이라는 것이다. 이름하나하나 소심하게 지어야한다.

일상생활은 대범하게 프로그래밍은 소심하게…