Tag: 개발자

더 나은 프로그래밍을 위한 제언

제발 줄 좀 맞추자
프로그래밍을 잘 하는 사람과 그렇지 못한 사람의 차이는 바로 줄 간격을 맞춰서 프로그램을 짜느냐에 달려 있다고 나는 과감히 주장한다. 왜냐하면 그 동안 수많은 개발자를 보아왔지만 줄을 제대로 맞추지 않고 프로그램을 제대로 짜는 사람은 본 적이 없기 때문이다. 보기 좋은 코드가 디버깅하기 좋다. 제발 기본에 먼저 충실하자. 알고리즘과 자료구조에 대한 이해는 기본이다. 그런 다음에 기교를 발휘해도 늦지 않는다.

백문이 불여일타
“프로그래머가 되는 가장 좋은 방법은 프로그램을 작성해보고, 다른 사람이 작성한 훌륭한 프로그램을 공부하는 것이다.”
훌륭한 작가 중에서 책을 많이 읽지 않은 사람을 보았는가? 마찬가지로 좋은 프로그램을 만들기 위해서는 좋은 프로그램을 많이 보아야 한다. 무에서 만들어지는 것은 아무것도 없다. 책에 있는 소스나 공개 소스를 스스로 분석해보자. 그러나 이보다 더 좋은 방법은 직접 짜보는 것이다. 직접 짜보는 것만큼 훌륭하게 배우는 방법은 없다.

선설계 후코딩
항상 프로그래밍을 하기 전에 선설계 후코딩하는 습관을 들여야 한다. 생각하고 계획하는 프로그래밍을 하라는 말이다. 프로그래밍을 하다가 막히는 부분에 가서야 생각하는 것은 좋지 않은 습관이다. 프로그래밍 시간이 배로들뿐더러 수정에 의해 또 다른 문제가 야기될 개연성이 크다. 계획을 하되 머리속으로만 하지 말고 문서로 작성하여 기억이 유실되지 않도록 해야 한다.

친절한 주석씨
주석은 습관이다. 주석은 타인에 대한 배려다. 친절한 프로그래머가 되는 지름길은 주석을 잘 다는 것이다. 시간이 날 때 주석을 다는 것이 아니다. 주석은 프로그래밍의 일부분이라는 인식을 갖고 실천해야 한다. 주석을 달지 않으면 본인도 시간이 지나면 잘 기억이 나지 않는다.

3종 언어 세트
나의 경험으로 볼 때 프로그래밍 언어는 최소한 3가지는 익혀야 한다. 가급적이면 소프트웨어 프레임워크에 맞는 언어를 각각 익히는 것이 좋다. Client/Server, .NET, J2EE 프레임워크에 맞는 Powerbuilder, Java, C#을 예로 들 수 있다. 그렇지만 이 세가지 중에서 반드시 자신의 전공부야는 있어야 한다. 하나의 언어를 배우더라도 다른 언어에서 금세 응용할 수 있도록 충분히 이해해야 한다.

나만의 테크노트
자신만의 노하우를 반드시 정리하라. 가장 큰 재산이 된다. 일전에 프로젝트를 하면서 나만의 테크노트를 한 권씩 만들어 정리한 적이 있었는데 매우 유용했다. 그렇게 습득한 지식은 책에도 잘 나와 있지 않는다. 기록을 하지 않고 다시 복기하려면 엄청한 시간과 노력이 또 다시 요구된다. 테크 노트를 정리하는 일은 시행착오를 줄일 수 있도록 해 줄 뿐만 아니라 전문가로 가는 노하우를 하나씩 쌓아가는 기쁨도 느끼게 된다. Taeyo ASP & .NET 웹사이트가 성장한 배경을 살펴보라. 내일 당장 그대만의  테크노트를 한 권 장만하라.

코딩이 뭐길래
프로그래머는 절대 코딩만 하는 사람이 아니라고 누차 강조했다. 코딩 지상주의를 절대 경계하라. 어느 정도 코딩 실력이 올라가면 데이터베이스, 아키텍쳐 등의 유사분야의 영역에 대한 지식을 넓혀라. 때론 일반적인 지식도 필요하다. 큰 그림을 그릴 수 있어야 한다. 설상 프로그래머로 자신의 경력개발경로를 설계한다 하더라도 다른 분야에 대한 학습은 꼭 필요하다.

개발자들은 문제의 크고 작음에 상관없이 항상 컴퓨팅이 필요한 여러가지 문제에 직면해 있고, 문제를 해결하기 위한 다양한 솔루션들을 제시하고 검토하고 구현해야 한다.

그러나, 문제를 대하고 해결함에 있어 모든 개발자들이 다 동일한 방식과 태도를 가지는 것은 아니다. 주변의 몇몇 개발자분들만 봐도 실제적인 문제를 다룸에 있어 참으로 다양한 방법과 방식을 사용하고 있다는 것을 알 수 있었다.

[그림1] “몰개발”님 – 문제에 대한 지속적인 관심과 공통 이슈에 대한 현명한(?) 접근 방식의 소유자

폭주하는 정보와 요청들 속에서 자신과 관련된 문제에 대해 지속적으로 관심을 갖고 이를 재빨리 파악하여 신속히 영향도를 분석해낼 수 있는 능력은 실제 필드에서는 굉장히 유용한 방식이라고 생각한다.

대개는 자신과 관련없는 일이거니 생각하고는 놓치거나 잊어버려 뒤늦게 이를 수습하기 위해 두, 세 배 더 고생해야 하는 경우가 부지기수니까..

[그림2] “플랫폼”님 – 복잡한 문제에 대한 단순 명료(?)한 솔루션 프로바이더

복잡한 문제를 단순 명료하게 해결할 수 있는 솔루션을 찾을 수만 있다면 그것이야말로 최고의 솔루션이 아니고 무엇이겠는가?

“뛰어난 것은 단순하다”는 말은 진정 문제 해결을 위한 기본지침일 것이다. 다만, 문제를 단순화해야지…해결책만 단순화하는 우를 범해서는 OTL 이다.
(“플랫폼”님이 그렇다는 얘기는 아니고…^^;)

[그림3] “마베왕”님 – 각각의 문제를 가장 잘 처리할 수 있는 사람들을 매쉬업(?) 하라!

누군가가 특정 분야에 일가견이 있어 해당 문제에 대해 최적의 솔루션을 제시할 수 있다고 확신하면 그런 사람들을 매쉬업(?)해서 전체적인 문제를 해결하는 것도 훌륭한 방법이라고 생각한다.

얼마나 많은 개발자들이 그 알량한 자존심을 지키기 위해 다른 사람이 훨씬 더 잘 할 수 있는 일을 본인이 직접 개고생해서 구현하고는 형편없는 퀄리티에 좌절하고 깨지고 했었던가? -_ -;;;

선택과 집중.
다양하고 복잡하고 문제를 해결하기 위해서는 반드시 필요한 결정일 것이다.

최근의 개발 트렌드인 프레임워크와 라이브러리를 도입하여 개발 생산성을 높이는 방식도 결국 같은 맥락이라고 볼 수 있겠다.

다만, 매쉬업을 해야지 떠넘기기를 하면 역시 OTL…

(절대 “마베왕”님이 그렇다는 얘기는 아니다. 칼 맞을라…=_ =;;; )

[그림4] “삽질왕”군 – 문제와 해결을 위해 쌓인 스트레스…이렇게라도 풀어줘야지…

이렇게 다양한 접근 방식과 솔루션을 통해 문제를 해결했다고 하더라도… 결국 문제는 문제라는 생각이 든다.

문제는 골치 아프다. 해결됐다고 하더라도 그 사이에 쌓인 스트레스는 어쩌란 말인가?

그럴 땐 역시…궁시렁거리는 게 쵝오가 아닐까? ^^;
(실상은 쵝오가 아니라 유일한 위안거리라는 게 문제긴 하지만… 문제다, 문제야…=_ =;;;)