코딩/설계 철학.

pchero의 이미지

요즘 프로그래밍을 하면서 느끼는 것이...

제가 만든 프로그램 조차도 이해하기가 힘들다는 것입니다..

새로운 아이디어, 생각 및 버그패치, 오류 수정등을 할때마다 소스는 나날이 지저분해지는 느낌이고

구조의 이해는 점점 더 알수 없게끔 꼬여만 가는 느낌입니다.

더 큰 부분을 보고 처음의 구조를 정할 때 안정성있고, 유연한 구조를 생각하여 설계를 해야하는데, 쉽지가 않네요.

책에서 나오는 예제코드처럼 깔끔하고 한번에 이해가 가능한 코드를 만들고 싶은데 마음만큼 머리가 따라와주지 않습니다.

전체 적인 구조를 보며 이해하기 쉬운 코드보다도 부분적인 재치와 어떻게든 일을 줄여보고 싶은 마음에 꼼수(?)를 남발하기도 하죠.

여러분들의 현업에 일하시면서 가지고 계신 코딩 및 설계에 대한 철학 및 지침들에 대해 귀 기울여보고 싶습니다.

여러분의 코딩/설계 철학은 어떤것입니까?

empty2fill의 이미지

"Make it run, then make it right, then make it fast"

The Art of Unix Programming(http://www.faqs.org/docs/artu/) 책의

Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

에서 나오는 문구입니다.

최적화와 관련된 규칙이지만 설계까지 확장한다면

이 말을 추가하고 싶군요.

", then make it beautiful"

나날이 코드만 고치지 말고 구조 또한 고치면 갈수록 '깨끗해'지지 않을까 싶습니다.

——
———
Life is a tragedy when seen in close-up, but a comedy in long-shot. - Chaplin, Charlie -

pchero의 이미지


make it beautiful!

정말 멋진 말입니다..! :)

---------------------------------
제일 왼쪽이 저입니다 :)

---------------------------------
제일 왼쪽이 저입니다 :)

pajaebeo의 이미지

저는 요즘 지난 1년간 했던 일을 reverse engineering 을 하고 있습니다.
코딩으로 어찌어찌 돌아가게 만들었던 것을, UML로 다시 만들어보고 있는데,
제가 봐도 참 막막하군요 ^^
하지만, 이런 과정을 통해서 굉장히 많은 것을 배울 수 있는 것 같네요 :)

.... 물론 reverse engineering을 할 시간을 회사에서 받아내는게 쉽지 않겠지만요...
(이것이 젤 큰 문제 ^^)

nthroot의 이미지

그래서 디자인패턴 같은 것이 생겨나지 않았나 생각합니다.

예전에는 설계에 대해서 신경을 많이 썼던거 같은데 요즘엔 그냥...

돌아가면 기적이다..라는 생각으로...

------식은이 처------
길이 끝나는 저기엔 아무 것도 없어요. 희망이고 나발이고 아무 것도 없어.

munhoney의 이미지

마틴파울러가 예기한 말 중 가장 인상깊은 말이 있습니다.

"컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다."

이 말을 전해드리고 싶네요..

참 저는 이상적으로는 프로그램 개발 때

UML Tool(Rhapsody) + Project Management(TRAC) + Code Management (SVN)

을 추천합니다.

목표는 문서 최소화 및 쉬운 코드 이해 입니다.

---------------------------------
http://blog.naver.com/munhoney
---------------------------------

---------------------------------
http://blog.naver.com/munhoney
---------------------------------

jeongheumjo의 이미지

좋은 UML 툴이 있다면 알고 싶네요... 저는 StarUML 만 사용하고 있습니다. 물론 아주 가끔 코드설명 문서 만들 때만...

munhoney의 이미지

지금까지 썼던 UML 툴 중 (물론 몇개 안써봤지만요.. ㅡㅡ) 가장 베스트는 랩소디 인것 같습니다. 물론 IBM 의 로즈와 합쳐지는 것 같지만요..

좋은 점은 코드와 UML 및 문서가 통합된다는 것입니다. 코드를 수정하면 UML 내용이 업데이트 되고 UML을 수정하면 코드가 업데이트됩니다.

Java, C++ 모두 사용이 가능했습니다.

---------------------------------
http://blog.naver.com/munhoney
---------------------------------

---------------------------------
http://blog.naver.com/munhoney
---------------------------------

creativeidler의 이미지

좋은 코드의 조건은 다양한 방식으로 이야기할 수 있지만, 제가 가장 유용하다고 생각하는 조건은 다음 두 가지입니다.

1. 중복이 없어야 한다.
2. 프로그래머의 설계 의도가 코드에 드러나야 한다.

이 두 가지만 잘 지키면 어려운 디자인 패턴이나 아키텍처 같은 거 몰라도 됩니다. 처음부터 세련된 코드를 작성할 수는 없겠지만, 점점 엔트로피가 높아져서 개발 속도가 떨어지는 현상은 충분히 막을 수 있습니다.

단, 코딩할 때 좋은 코드부터 만들려고 하면 어렵습니다. 일단 돌아가게 만들고, 그 다음에 리팩토링해서 좋은 코드로 고쳐나가는 것이 결과적으로 더 좋은 설계를 만듭니다.

그리고, 코드를 깔끔하게 만드는 목적을 오해하면 안됩니다. 좋은 코드는 그 자체가 목적이 아니고 높은 생산성과 높은 품질을 이루기 위한 수단입니다. 코드 다듬느라 개발이 한없이 늦어진다면 주객이 전도되는 것이고, 빨리 개발하고 싶어서 좋은 코드를 등한시한다면 반대로 원했던 높은 생산성을 달성할 수 없습니다. 적절한 선을 잘 찾아야 합니다.

ssif의 이미지

creativeidler 님의 의견에 동의합니다.
프로젝트를 진행하면서 돌아가는 프로그램을 작성하고, 리펙토링하는 작업을 반복했을때(나무와 숲을 번갈아가며 보기) 좀더 유연한 결과물이 나왔습니다.
프로젝트는 납기일이 정해져있기에

"좋은 코드는 그 자체가 목적이 아니고 높은 생산성과 높은 품질을 이루기 위한 수단입니다. 코드 다듬느라 개발이 한없이 늦어진다면 주객이 전도되는 것이고, 빨리 개발하고 싶어서 좋은 코드를 등한시한다면 반대로 원했던 높은 생산성을 달성할 수 없습니다. 적절한 선을 잘 찾아야 합니다."

이 부분은 상황에 맞게 대처했습니다.
어쭙잔은 UML 지식대로 하려고 했을때 오히려 시간만 낭비했던 경험도 있었습니다.

봄들판에서다

jeongheumjo의 이미지

헤드퍼스트 디자인패턴 이라는 책을 보면 나오는 용어예요.
저는 워낙 디자인패턴에 문외한이라 이 용어를 보고 깜짝 놀랐습니다.
다양한 디자인의 패턴들이 의도하는 바가 이 하나의 말에 들어있다고 느껴졌기 때문입니다. 디자인패턴까지 가지 않더라도 고전적인 방식의프로그램에서 데이타와 코드를 분리하려는 시도들도 모두 OCP로 설명이 되니까요...
내용인 즉슨 기능 확장에 최대한 Open 되어있고 코드 수정에는 최대한 Closed 되어있도록 프로그램을 작성하도록 하자는 것입니다. 이렇게 할 때 작업 효율성 면에서나 유지보수 측면에서 견고한 코딩이 되게 됩니다.

그리고 저도 요즘 이런 고민들에 눈을 떠가는 데요,
디자인패턴을 먼저 익히고 리팩토링을 그 다음 익히고 그 다음에 익스트림 프로그래밍 이라는 개발 방법론을 공부하면 원하시는 고민의 해답이 되지 않을까 싶어요...(익스트림 프로그래밍이 정확히 뭔지 저도 잘 모르지만요...)

in1n4의 이미지

제가 생각하는 좋은 코드 습관을 말씀드리자면....

1. 코드가 짧다고 해서 처리 속도가 빠르지 않다
--> 누구나 알고 있지만 항상 코드 라인을 줄이는 것이 빠를 것이라는 본능에 맡긴 행동(예전 오락실 축구 게임에서 역할이 없는 버튼을 갈기(?)면서 뛰면 빨리 뛰는 것 같은..에헴)

2. 몇줄 안되는 코드에 쉬프트(>>, <<) 나 *,& 가 많이 들어가거나 할 때, 즉, 글 읽듯이 코드 해석이 안될 때 주석으로 간단한 소스를 짜두고 최적화 때문에 이런처리를 했다라는 약간의 변명과 같은 내용을 달아주는 것입니다.
--> 개인적으로 맘에 안드는 코드는 욕도 적어둡니다. 그럼 다음 사람이 소스를 받으면 웃습니다.ㅋㅋㅋㅋ(당시 상황을 90% 정도는 이해하죠. 이건 상당한 커뮤니케이션입니다.ㄷㄷ)

3. 디자인 패턴은 공부하되 남용하면 더 유지보수비용(시간)이 많이 소모됩니다
--> virtual를 많이 사용하여 해석하기 어려운 문제보다는 전체 시스템 디자인을 잘못 이해하여 virtual을 남용해 놓은 코드를 보면 C가 그리워질 것입니다 ㅋㅋ

4. namespace 와 같은 것으로 묶어 두십시오.
--> namespace는 방청소한 뒤(소스정리한 뒤)에 물건들이 자기의 자리에 있는 상황으로 만들기 때문에 util과 같은 자주 사용되는 것들은 정리하세요.

5. 전반적인 프로그램의 방향을 확실하게 이해하면 멋진 스케치가 나옵니다
--> 이면지에 수도 없이 그리고 난 뒤에 키보드에 손을 올리는 것이 좋습니다

jos77의 이미지

Code Complete , Professional 소프트웨어 개발 읽어보시거나
코딩 가이드 Code Convention 으로 검색해서 공부해보시길 권장드립니다

-----
안녕하세요 소프트웨어 공학센터 장원석 책임입니다.
http://www.software.kr

rgbi3307의 이미지

"입출력(I/O)과 반복(Loop)을 줄이는 방향으로 설계 및 코딩 해야 한다." 입니다.

From:
*알지비 (메일: rgbi3307(at)nate.com)
*학창시절 마이크로마우스를 만들었고, 10년동안 IT관련 개발자로 일하고 있음.
*틈틈히 커널연구회(http://www.kernel.bz/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

From:
*알지비 (메일: rgbi3307(at)nate.com)
*커널연구회(http://www.kernel.bz/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

magingax의 이미지


매크로로 대동단결

LISP 사용자모임
http://cafe.naver.com/lisper

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

pchero의 이미지

주옥과 같은 말씀 감사합니다.

정확한 길은 모르겠지만 방향은 알 것 같습니다.

이제 차분히, 꾸준하게 하나씩 지침을 따르려고 노력만 하면 되겠지요. :) ㅎㅎㅎ

---------------------------------
제일 왼쪽이 저입니다 :)

hungbob의 이미지

도 방법인 것 같습니다. DRY 원칙만 지켜도 상당히 깔끔한 코드가 나오더라는..