당신의 프로그래밍 철학은..?

코드가 곧 문서!!!

(1) POP(뽀대 오리엔티드 프로그래밍)
- 프레임워크, 아키텍쳐는 일반인(특히 직장 상사;)가 이해할 수 없는 뭔가 심오하고 뽀대나는 걸로...

(2) SDA(스크린샷 드리븐 아키텍쳐)
- 릴리즈는 안해도 스샷은 나온다.

(3) XP
- 주 40시간 근무!

최대한 쉽게...
(내가 중간에 현프로젝트를 바톤터치했을때 후임자가 최대한 나에게 질문안하게끔...)

전 최대한 주석이 필요 없을 정도의 간결한 코드를 지양은 합니다.
함수이름, 변수이름, 파일 이름을 통해서...
그래도 각 함수의 input/output과 역활은 기본적으로 주석을...

주석 긴거 사람들이 좋아 할순 있지만...
역시 귀찮은 관계로...

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

XP 에 빠질 수 없는게 있죠.

이쁜 여동료와의 짝 프로그래밍 :oops:

심플이가 베스트여~

굶어 죽는 일은 없어야 겠다.

입니다.... -_ㅜ

KISS

'만들면 다가 아니다.'

입니다.

KLDP어딘가 구석에서 본 말인데요...
그 글을 본뒤로 걍 뻑 갔습니다.
그래서 철학이라면 철학으로 삼고 있습니다.

보안적 취약성 Zero 지향

Simple & Quick
입니당~

헉, 리팩토링을 그런 식으로 말하는 사람은 처음 봤습니다. 제가 보기엔 어떻게 프로그래밍을 해야할 것인가를 다루는 책 중에서 베스트에 꼽힐 수 있는 책입니다. 다시 한 번 읽어보시는 것이 어떨까요? 그리고, 마틴 파울러는 세계의 프로그래밍 패러다임을 이끌어가는 사람 중 한 명이라고도 할 수 있습니다. 비록 자기가 뭘 만들어낸 것보다 남이 만든 것을 정리를 잘하는 사람이라는 평가도 있긴 하지만, 내실 없이 명성을 얻은 사람이 결코 아닙니다.

나중에 발생한 문제나 요구사항 해결 시에는 수정이 아니라 추가하는 것만으로 가능하게...

생각만큼 그렇게 잘 되지는 않습니다만...

사람만 이해하고 컴퓨터에서 돌지 않는 코드를 짜라는게 아니라 제대로 동작하는 건 프로그래머로서의 '기본'이고 '제대로된' 프로그래머라면 거기에 덧붙여 유지보수도 용이한 프로그램을 짠다는 뜻입니다.

그걸 왜 굳이 '사람이 이해할수 있는코드인데 컴퓨터가 이해못할코드도 좋다'라고 곡해해서 반박을 하셨는지 이해가 안가는군요.

고객(내부 직원일 수도 있음)이 OK하거나
감동하게 하는 것입니다.

첫째 - 코딩량을 최소화 한다.
매크로를 적극활용합니다. #define뿐 아니라 에디터의 매크로도 총동원합니다.
필요에 따라서는 반복적인 코딩을 대신해줄 간단한 프로그램을 짜기도 합니다.
코딩량 늘어나면 결국 실수도 늘어나고 나중에 살펴봐야 할 양도 많아집니다.

둘째 - 하룻밤에 끝낼 수 없는 일은 하지 않는다.
보통 남들 일주일 작업할것을 일주일 고민하고 사전작업을 해서 하룻밤에 끝낼 방법을 찾아내죠.
도저히 하룻밤에 끝낼 수 없는 일이라면 하룻밤에 끝낼 수 있게 일을 나눕니다.
어찌됐건 시작한 일은 무리를 해서라도 끝내고 잡니다.

농담식으로 그러더군요

가늘고 길게 회사에서 남는 코딩법

최대한 소스는 보기 어렵게 짜라 여기저기 변수 숨겨놓고
주석은 최대한 아끼고 코드는 최대한 길게
버전업하면서 필요없는 코드들 그냥 남겨두고
이소스 전체를 팔아도 남들이 소스분석하는데 최대한 오래걸리도록
노력하라 문서는 대충 대충

How To Write Unmaintainable Code !!!!
아주 감동적으로 읽은 문서입니다.. :) :twisted:

저는... 가능한.. 최대한.. 쉽게 만들자 ! 입니다.. ㅋㅋ

아는 분이 예기하시길 .. 바둑같은거다 라고 예기 하셨지요..

초보와 고수의 차이는 수를 읽는 능력이 다른것 처럼 하나 하나 경우의 수를 읽어 내는것이 중요하다고 하시더군요

푸핫!! 최고입니다!!!!

저는, 무조건 잘게 쪼개기..

TDD 하면서 리팩토링이랍시고 코드를 잘근잘근 잘라서 이곳저곳에서 쓰는데 재미들렸어요 8)

:twisted:

뭐~ 대단한 일 한다고......... <늘메 버전> ㅋㅋㅋ

주석을 소스같이, 소스를 주석같이... -_-a

코드는 가장 정확하고 상세한 설계도.

1. 읽기 쉽게 - 나중에 다른 사람에게 넘기거나 내가 다시 볼때 고생 안한다.

2. 디버깅 하기 편하게 - 재작 후 디버깅하기 여려우면 시간 잡아먹기 좋다.
( 코드를 심하게 꼬지 말자. -.-; )

3. 유연하게 - 훗날 수정 및 확장을 고려해야 한다.

좋은 말씀 많이들 해주셨으니... 저는... 굉장히 C스럽기는 하지만.

리턴값과 널포인터와 변수 range는 꼭 체크하자. aka 가능하면 엄밀하게 코드를 만들자. :-)

Keep It Simple Stupid입니다. ^_^

Clean code that works!!

항상 노력합니다.

없는데요..

그냥 짜는 거죠..

구체적으로 이야기 한다면, 하나의 클래스나 프로그램의 변경이 다른 클래스나 프로그램에 미치는 영향을 최소화 할 수 있도록 설계하고 interface나 black-box function들 위주로 프로그램을 작성 합니다.

철학이라면..., 동작이 되게, 버릴 것 없게, 쉽게 유지보수 할 수 있게, 빠르게 돌게 그리고 미래의 변경에 대처되게 순으로 넓은 흰 도화지에 보기 좋은 작품을 그리듯이 만들려고 합니다. (잘 돌아가는 프로그램도 지저분하다 싶으면 아예 처음부터 다시 만들어 버리고 싶죠... 십수년을 해오는 일이지만 아직까지도, 잠 자다가 용도가 생각이 안나는 변수 이름이, 뱅뱅 꼬이는 코드가 머리 속에 돌아다니면 벌떡 일어나게 되서요.) 이래서인지 회사용 프로그램에 created by 누구라고 comment를 다는게 부끄러울 때가 많습니다.

벌거는 아니지만.. 설계보다는 구현에 초점을 맞추려고 합니다.
구현에 초점을 맞추는 거죠.. 구현에 필요없는 디자인은 배제하려는..

제가 XP는 모르지만 SimpleDesign은 XP에 나오는 말입니다~

"좋은게 좋은거다." :wink:

동감입니다. 제 프로그래밍 철학도 이걸로 해야겠습니다. :wink:

The art of Unix Programming에 보면 앞부분에 잘 나와있더군요.

그런데 항상 그렇지만,
이런것을 글로 읽는다고 해서 아는 것은 절대 아니겠조 ?

폼나게

프로그래머는 神이다.

내맘대로 만드는 또다른 세상~

뭐 그정도는 아니라도 최소한 몇가지 원칙은 지킨다.

1. 설계 70, 구현 20, 디버깅 10

딱 이 비율로 가면 이상적이다 보통은 거꾸로 가는 경우가 많지만...
적어도 내가 짠 프로그램은 완성된 순간 사소한 버그 이외에는 문제가 되지
않도록 짠다.

2. 성능, 안정성

기능 위주로 손대고 보는 것은 초보나 하는 짓.
성능, 안정성을 최대한 고려해서 설계단계부터 디버깅까지 일관되게 구현한
다.

3. 코드의 유연성

별로 그럴필요 없는 상황에서도 나는 되도록 유연한 프로그램이 되도록 노력
한다. 그래서 void *, 함수 포인터, pure virtual function이 자주 등장한다
물론 이 와중에 속도가 문제가 될수도 있지만 요즘의 하드웨어로는 아주 작
은 속도 향상보다는 간략하고 심플하며 확장성있는 코드가 더 우선이다.

4. 핵심 코드, 로직이 복잡한 코드만 한다.

이렇게 하는 것이 실력도 늘고, 나중에는 큰소리 칠수 있는 거리가 된다. 만약
남들이 다하는 코드, 남들이 다하는 구현을 맞게 되면 처음에는 편하지만 나
중까지 일하는 티가 나지 않는다. 심플하게 끝내버리고 시원스럽게 놀려면 비
록 힘들어 보이지만 어려운 코드에 접근하는게 지름길이다.

5. 구현은 단계적으로 한다.

설계와 구현을 병행하되 설계할때는 작은 sample code부터 하나 하나 구현
및 테스트를 한다. 이렇게 되면 구현과 test가 동시에 되므로 debugging 시
간이 획기적으로 줄어들고 설계에 있어서도 구현과 밀접하게 하게 되므로 가
장 현실적이면서도 강력한 코드를 만들 수 있다.

이상이 저의 설계, 구현, 디버깅 방법입니다.

도움 되셨기를 바랍니다.

Abstraction, Engineering, Discipline

최소한 나중에 나라도 알아볼 수 있게..ㅡ,.ㅡ

그러다가 자기가 짠 프로그램 유지보수하는데 지쳐서 제풀에 회사 때려치울껄요...
그런 사람들 꽤 있는 거 같은데...
자기가 짠 프로그램 유지 보수 하기 싫어갖구 프로젝트 끝나자마자 이직하고 그러는거...

15년전이었나...

그래픽카드를 공부한 끝에

나만의 gui 환경을 만들기 위하여

turbo-c를 열었다.

그래픽 모드를 선정하기위하여 2-3일..

그리고 즉시 모눈종이를 펴놓고

마우스 커서와 알파벹 폰트를 점을 찍어 만든후

hex 에 계산한후,font table 에 등록..

그다음 각종 버튼 이미지와 쉐도우,팝업 메뉴를 만들었지..

그리고 처음 프로그램을 판곳이

지금은 없어 졌지만,만도기술 연구소 초음파 해석 실험실...

지금이야 있을수 없는 일이지만...

그당시로는 시간도 널널 했고..

bios와 도스의 파일 시스템만 있는 상태에서

진정한 바닥부터 쌓아 올렸던 나의 프로그램..

아..그런 초심으로 다시 돌아갈수 있었다면..

이제는 프로그렘은 커녕

나의 머리를 맴도는 기술은

RPC,RMI,Corba,SOAP.. 한마디로 말하자면

손안대고 코를 풀려고 작정한것이다.

내 과거 돌려도...