프로그래밍은 저의 밥줄이자, 취미인 삶의 동반자 중 하나겠지요.
-_-ㅋ

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

코드가 곧 문서!!!

소설쓰기

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

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

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

코드를 자연어같이..

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

성능이 나쁜 코드와 읽기 힘든 코드는 더이상 표현을 잘못한 것이다. 라고 가지고 있습니다.

누군가 그러더군요. 좋은 강사는 10개를 알고 하나를 가르치기 때문에 사람들이 쉽게 이해한다고, 아무리 뛰어난 사람도 그 자신이 설명을 잘 못하는 것은 정확한 이해를 못한거라고요. 코드도 마찬가지로 직관적이여야 한다고 생각합니다. 괜히 이리저리 꼬아놓은거 오히려 성능도 나쁜 경우가 대다수입니다.

그리고 두분째로는 성능이 나쁜 코드는 꼭 시스템을 해치는 요소로 나중에 등장하죠. 시스템이 커질수록 성능이 나쁘면 비용이나 유지가 힘들어지죠. 가치가 없다고 해야 하나요?

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

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

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

fender 님 재미있으십니다. :lol:

진지하게 쓰신 것이겠지만, 유머 넘치는 철학이 부럽습니다..... :D

XP 에 빠질 수 없는게 있죠.

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

심플이가 베스트여~

Anyway, working exactly.

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

입니다.... -_ㅜ

1. 작은것이 아름답다.
2. 프로그래머의 가장좋은문서는 코드여야한다
- 제가 생각하는것과 다른사람들이 생각하는것이 다를수도 있겠는데..
따라서저는 주석을 거의 안답니다.. 코드만 보고 할수 있어야하기때문에
네이밍을 주석처럼 하지 않습니다.. 로직을보고 기능을 파악할수 있어야하기에.

제일싫어하는건-긴것, 감추어둔것, 없는것 - 소스자체도 없고 그렇다고 사용법도 없는것.

KISS

그렇다면.. 굶어죽지 않기 위해 수단과 방법, 스타일을 가리지 않는다는 말씀인가요? 굶어죽지 않기 위할뿐이지 프로그래밍 철학은 없다는 뜻으로 해석되는데...

'만들면 다가 아니다.'

입니다.

"안되는건 억지로 안한다." 입니다. ㅡ,.ㅡ

아..아닌가.. 이건 직업 철학(?)인가..

흠.. 그러면...
"없으면 만든다" 뭐 이정도면..;;;

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

조금 다른 얘길수도 있지만
직업으로 계속 가져가긴 어렵다는 생각을 늘 한답니다.

얼마전 사무실에서 개발동아리 하나 만들면서 나눈얘기들인데..
목적이 뭐냐는 얘기에 의견이 분분하더군요. 돈, 스킬업, 사업성 등..
제가 '재미로 하는건 어때?' 라고 얘기했다가 욕(?) 얻어 먹었죠. --;

Just for fun..

보안적 취약성 Zero 지향

저는 저말이 정반대라고 생각되는데요..
정말 컴퓨터가 이해할수 있는코드를 어느바보나 다 짤수 있을까요?
그렇다면 리눅스커널과 같은기능을 하는 코드를 어느바보나 다짤수 있다는뜻인가..
두번째 사람이 이해할수 있는코드인데 컴퓨터가 이해못할코드도 좋단말인가..
마틴 파울러란사람이 리픽토링 이란책쓴걸로 아는데 작년에 회사 있길래 한번쓱훑어 보다가 걍덮었습니다. 솔찍히 별로라고 생각했거든요.ㅡ,.ㅡ; 그런생각도 했습니다. 사람들이 이책을보고 이렇게 프로그래밍하면 어쩌나..ㅡ,.ㅡ;;

Simple & Quick
입니당~

처리한 에러도 다시 보자. ^^;

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

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

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

리누스 외에 이해하는사람들이 있기는 했으나.. 아예 돌지조차 않는걸짜두었다면. 리누스는 아예 사람들한테 보여주지도 않았을겁니다.

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

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

이 창조물을 내가 인정할 수 있는가

입니다. (=..=ㆀ)

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

돌면 장땡!

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

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

초보라.. 철학일것까진 없지만..

회사에 들어와서.. 대충 강요되는 철학은....

구현 가능한 추가 기능의 옵션처리!! 더군요..

농담식으로 그러더군요

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

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

http://mindprod.com/unmain.html

"내가 만든 프로그램을 사용할 사용자를 위해서 난 프로그램을 짠다" 입니다.

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

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

프로그래밍은 노가다다.

노가다를 싫어하면 프로그래밍할 자격이 없다.

저의 프로그래밍 철학입니다.

물론 프로그래밍에 노가다가 전부는 아니지만 포함되어 있다고 봅니다. 결국 흥미로운 아이템을 찾고 설계한 후, 구현하기 위해서는 코딩이란 노가다를 건너뛸 수는 없기때문입니다.

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

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

전 일단 짜고 봅니다.. 좀 이상하게 여기실지 모르지만,
나중에 보면.. 완전히 삼류소설이지만.. *^^*
생각을 먼저하고 나중에 코딩하는 스타일은 아니라서..

어쨌든, 제가 개발하는데 있어서 가장 중요하게 여기는 것은 "일단 껍데기는 만들자" 입니다.. 좀 어리숙하죠 !!
위 어떤분처럼 프로그램은 없어도 scan은 나오죠..ㅋㅋ

코딩 자체에 있어서 중요하게 여기는 것은 역시.. "변수명" 입니다.
주석을 많이 다는 편인데, 빨리 나갈때는 주석보단 변수명에 신경써서 작업을 합니다.

각자 자기 나름대로의 철학이 있겠지만, 전...무대뽀거든요..

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

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

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

그냥 제 스스로 만족스럽고 재밌게만

코딩했으면 좋겠습니다.

:twisted:

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

배열, 포인터를 최대한 쉽게.. 입니다.

많이 길어져도 매크로 등으로 나누고, 보기 쉽게 만들려고 하고..

되도록 이중배열 안쓰고..

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

쉽게 만들자.

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

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

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

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

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

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

제 친구는 generalize or generate..

저는 아무래도 이거 인 듯..
내가 짜려고 하는 건 이미 누가 해놓았을 것이다

Keep It Simple Stupid입니다. ^_^

"가까운 미래에 발생가능할 변화를 예측하고 구조를 잡으라"

아니면 결국 노가다로 나에게 돌아오더라구염 ㅡㅡ;;

Clean code that works!!

항상 노력합니다.

기본적으론 KISS
assertion 사용에 후하고, 미래에 대한 투자에는 인색한 방향으로... :)

없는데요..

그냥 짜는 거죠..

'일단 돌게한 후, 지속적인 리팩토링.'

간단한 설계를 거쳐 일단 작동하는 놈을 손에 얻고 나서...
시간이 허용하는 한 리팩토링에 들어갑니다.

사용자 및 관리자가 원하는 것은 결국 예술코드가 아닌 '기능'이며,
품질향상에 대한 요구는 지속적인 리팩토링을 통해 개선해 나갈 수 있습니다.

아무리 설계를 공들여 해봤자.. 이 업무 저 업무 막 껴들어오고 추가되다보면
구조의 변경은 필연적이더군요. 저는 프로그램을 소용돌이치는 변신괴물이라
생각합니다 -_- 그도 그럴것이 프로그램을 사용하는 주체, 즉 사람의 본성이
워낙에 변덕스러운 것이기 때문이죠.

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

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

대부분의 분들이 자기위주의 철학을 가지고 계셔서 보다가 조금 놀랬습니다.-,.-

제 프로그래밍 철학은

"사용자가 사용하기 쉽도록 하자" 거든요..-.-a...

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

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

:roll:
Copy & Paste !

최대한 생각없어 보이게..

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

요구 사항 분석 단계에서 최대한 기능을 줄이려고 애씁니다. 기능 하나가 추가되면 일의 양은 팩토리얼로 커질테니까요. 그래서 종종 싸움이 벌어지기도 합니다만...

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

일단 봐서 만만하다 싶으면
바로 코딩 해서 실행 하게 만든다음...
점점 refinement해 나갑니다.

만약 만만하지 않다면,
고민을 좀 하조.
모듈별로 잘 쪼갠후 모듈간에 최소한의 약속만으로도
서로 돌아갈수 있도록 interface를 정합니다.

어떤식으로 접근을 하든
KISS가 최고조.

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

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

변수와 함수이름짓는데 아주 공을 들입니다.
값들도 가능한 한 DEFINE이나 enum 으로 정의해서
프로그램 읽는거 자체를 comment읽는거 처럼 할 수 있게 합니다.

폼나게

깜빡 잊고 위에 댓글을 썼는데.... 빼먹은게 있어서요... ^_^

프로그래밍 철학은..
Keep It Simple Stupid

방법론은...
1. Make it work.
2. Make it work right.
3. Make it work fast.

저도 인용부분에 절대 공감합니다..
그런데 저부분과 전혀 반대인사람도 종종있더군요..완전히 생각하는게 반대라고 해야할가요..
2년전인가 C만 십몇년을 해온사람이이라고 하더군요..무엇무엇을 해내고..
제가짠소스를 봤던모양입니다. 그러더군요.. 이곳에 더욱추가기능을 넣으면 좋지 않겠냐..
"제가 그런것은 함수의 분업화측면에서 이후함수에 포함이 되어야한다 사용자는 사용룰만 엄격히 지키면 아무런 이상이 없다."
"사용자(함수사용자즉프로그래머)가 혹시모를실수를 할수도 있다.그러니 여기서도 채크하고 저기서도 채크하고 많이할수록좋다.."ㅡ,.ㅡ;;
상당한 의견대립이 있었다는.. 끝까지 안했다는..ㅎㅎ
"어떤기능이 어디에 어디까지 포함하고 있어야할까라고 한번이라도 고민해보세요...."라고 말하고 싶었다는...

최대한 simple하면서 이해하기 편하게..

가끔 이해하기 편하게 한다는 이유만으로 변수명을 황당하게 길게 사용하기도
하지만서도..^^;

그리고 나서 변수명 기억해내려고 (혹은 기억할려고) 시간을 허비하게 되는 경우도 더러 발생..^^;

프로그래머는 神이다.

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

나의 귀차니즘을 만족시킨다.

... 상당한 귀차니즘의 소유자이기 때문에 제가 만족할만한 프로그램이 나온다면 아마 엄청 편리한 프로그램일겁니다. :D

P.S//사실 프로그램 시작하게 된 계기도 했던일 또 하는게 싫어서 그런거 안해도 되겠다 싶어 시작했는데... 어째 매일 같은 삽질만 하는 것 같아요. T_T