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

ㅡ,.ㅡ;;의 이미지

당신의 프로그래밍 철학은 무엇인가..

댓글

서지훈의 이미지

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

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

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

ㅡ,.ㅡ;;의 이미지

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

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


음.. 그건... 생활철학?..인생철학?..쪽 안닌가요..ㅡ,.ㅡ;


----------------------------------------------------------------------------

octo16의 이미지

코드가 곧 문서!!!

sjpark의 이미지

fender의 이미지

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

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

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

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

chadr의 이미지

코드를 자연어같이..

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

elflord의 이미지

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


===== ===== ===== ===== =====
그럼 이만 총총...[竹]
http://elflord.egloos.com

sunyzero의 이미지

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

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

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

========================================
* The truth will set you free.

서지훈의 이미지

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

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


음.. 그건... 생활철학?..인생철학?..쪽 안닌가요..ㅡ,.ㅡ;

ㅎㅎ
이런 내용을 원하는게 아닐줄은 알았지만...^^

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

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

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

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

hados의 이미지

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

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

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

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

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

advanced의 이미지

fender wrote:

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

XP 에 빠질 수 없는게 있죠.

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

수수깡의 이미지

상콤한데? ㅋㅋ

THe World is just awesome~!!
http://susukang.tistory.com

버그소년의 이미지

심플이가 베스트여~

가끔은 밥을 굶어도 살 수 있다.

temper의 이미지

Anyway, working exactly.

수수깡의 이미지

Perfect~

THe World is just awesome~!!
http://susukang.tistory.com

redbaron의 이미지

Advanced wrote:
fender wrote:

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

XP 에 빠질 수 없는게 있죠.

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


남의 여자일때는..(남성과 동일취급..)
corba의 이미지

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

입니다.... -_ㅜ

ㅡ,.ㅡ;;의 이미지

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

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


----------------------------------------------------------------------------

ysch0i의 이미지

KISS

서명없어요.

ㅡ,.ㅡ;;의 이미지

corba wrote:
굶어 죽는 일은 없어야 겠다.

입니다.... -_ㅜ

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


----------------------------------------------------------------------------

madhatter의 이미지

'만들면 다가 아니다.'

입니다.

shyxu의 이미지

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

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

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

Since 2003.
지금은 맥유저...
---
http://jtjoo.com

kwon37xi의 이미지

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

Quote:

컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러
로모뉴스의 이미지

ㅡ,.ㅡ;; wrote:
당신의 프로그래밍 철학은 무엇인가..

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

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

Just for fun..

OPEN MIND!

neobug의 이미지

보안적 취약성 Zero 지향

ㅡ,.ㅡ;;의 이미지

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

Quote:

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

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


----------------------------------------------------------------------------

hanbak의 이미지

Simple & Quick
입니당~

gsong의 이미지

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

creativeidler의 이미지

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

fender의 이미지

ㅡ,.ㅡ;; wrote:
저는 저말이 정반대라고 생각되는데요..
정말 컴퓨터가 이해할수 있는코드를 어느바보나 다 짤수 있을까요?
그렇다면 리눅스커널과 같은기능을 하는 코드를 어느바보나 다짤수 있다는뜻인가..

최소한 리눅스 커널 소스가 리누스 아니면 아무도 이해 못할 정도로 유지보수가 어려웠다면 설사 성능이 지금 보다 훨씬 뛰어나다고 해도, 학창시절 리누스의 취미 프로젝트로 사장되어 버렸을 겁니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

purespace의 이미지

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

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

남을 의식하지 않고 언제나 한결같은 모습으로 살고싶다...

ㅡ,.ㅡ;;의 이미지

fender wrote:
ㅡ,.ㅡ;; wrote:
저는 저말이 정반대라고 생각되는데요..
정말 컴퓨터가 이해할수 있는코드를 어느바보나 다 짤수 있을까요?
그렇다면 리눅스커널과 같은기능을 하는 코드를 어느바보나 다짤수 있다는뜻인가..

최소한 리눅스 커널 소스가 리누스 아니면 아무도 이해 못할 정도로 유지보수가 어려웠다면 설사 성능이 지금 보다 훨씬 뛰어나다고 해도, 학창시절 리누스의 취미 프로젝트로 사장되어 버렸을 겁니다.

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


----------------------------------------------------------------------------

fender의 이미지

ㅡ,.ㅡ;; wrote:
fender wrote:
ㅡ,.ㅡ;; wrote:
저는 저말이 정반대라고 생각되는데요..
정말 컴퓨터가 이해할수 있는코드를 어느바보나 다 짤수 있을까요?
그렇다면 리눅스커널과 같은기능을 하는 코드를 어느바보나 다짤수 있다는뜻인가..

최소한 리눅스 커널 소스가 리누스 아니면 아무도 이해 못할 정도로 유지보수가 어려웠다면 설사 성능이 지금 보다 훨씬 뛰어나다고 해도, 학창시절 리누스의 취미 프로젝트로 사장되어 버렸을 겁니다.

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


리팩토링은 돌지도 않는 프로그램을 짜라는 말이 아님은 잘 아시리라 믿습니다만... 그리고 원래 반박하신 내용 - "컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다"라는 말은 리팩터링과 직접적인 관련이 없습니다.

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

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

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

자룡의 이미지

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

입니다. (=..=ㆀ)

-----
이글을 읽는 모든 이에게 평화가 함께 하기를... ^^;

dalekang의 이미지

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

ed.netdiver의 이미지

돌면 장땡!

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

angpoo의 이미지

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

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

faye의 이미지

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

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

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

hook의 이미지

농담식으로 그러더군요

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

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

fender의 이미지

hook wrote:
농담식으로 그러더군요

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

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


그런 작업도 체계적이고 이론적으로 접근해야 성공할 수 있습니다. 아래 주소를 참조하세요 (꼭 자세히 읽어 보시기를... -ㅅ-; ):

http://mindprod.com/unmain.html

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

dansepo의 이미지

fender wrote:
hook wrote:
농담식으로 그러더군요

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

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


그런 작업도 체계적이고 이론적으로 접근해야 성공할 수 있습니다. 아래 주소를 참조하세요 (꼭 자세히 읽어 보시기를... -ㅅ-; ):

http://mindprod.com/unmain.html

오늘 또한번 감동.....

세포분열중......

dondek의 이미지

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

진리를 나의 수준으로 끌어내리지 마라.
나를 진리의 수준으로 끌어올려라. - 배꼽 중에서

leilei의 이미지

fender wrote:
hook wrote:
농담식으로 그러더군요

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

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


그런 작업도 체계적이고 이론적으로 접근해야 성공할 수 있습니다. 아래 주소를 참조하세요 (꼭 자세히 읽어 보시기를... -ㅅ-; ):

http://mindprod.com/unmain.html

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

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

ssoo76의 이미지

프로그래밍은 노가다다.

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

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

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

세상은 하나..........

barbarianmonk의 이미지

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

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

youngminny의 이미지

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

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

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

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

buffmail의 이미지

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

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

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

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

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

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

gurugio의 이미지

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

코딩했으면 좋겠습니다.

wildkuz의 이미지

:twisted:

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

You may say I'm a dreamer.
But I'm not the only one.

송지석의 이미지

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

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

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

jachin의 이미지

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

bluemoon의 이미지

쉽게 만들자.

irondog의 이미지

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

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

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

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

M.W.Park의 이미지

ysch0i wrote:
KISS

한표 더~~
제 자신과 동료들에게 항상 강조하는 부분입니다.

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

saxboy의 이미지

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

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

oedalpha의 이미지

제 친구는 generalize or generate..

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

youlsa의 이미지

Keep It Simple Stupid입니다. ^_^

=-=-=-=-=-=-=-=-=
http://youlsa.com

JCastle의 이미지

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

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

안녕하세요 ^^

pey의 이미지

Clean code that works!!

항상 노력합니다.

jj의 이미지

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

--
Life is short. damn short...

chaeso의 이미지

없는데요..

그냥 짜는 거죠..

musik의 이미지

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

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

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

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

atie의 이미지

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

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

----
I paint objects as I think them, not as I see them.
atie's minipage

elfs의 이미지

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

제 프로그래밍 철학은

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

crichton의 이미지

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

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

911ssam~tong!의 이미지

:roll:
Copy & Paste !

Ooryll Qrygg의 이미지

Share and Enjoy!

신승한의 이미지

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

futari의 이미지

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

-------------------------
The universe is run by the complex interweaving of three elements: matter, energy, and enlightened self-interest.
- G'kar, Babylon 5

purple의 이미지

Quote:
(설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다. - 생떽쥐베리의 말을 에릭 레이몬드가 인용한 것을 인용

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

dude7853의 이미지

futari wrote:
"좋은게 좋은거다."

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

dangsan49의 이미지

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

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

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

VENI, VIDI, VICI - Caesar, Gaius Julius -

dangsan49의 이미지

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

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

VENI, VIDI, VICI - Caesar, Gaius Julius -

doraq의 이미지

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

park의 이미지

폼나게

청춘

youlsa의 이미지

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

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

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

=-=-=-=-=-=-=-=-=
http://youlsa.com

ㅡ,.ㅡ;;의 이미지

purple wrote:
Quote:
(설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다. - 생떽쥐베리의 말을 에릭 레이몬드가 인용한 것을 인용

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

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


----------------------------------------------------------------------------

jcly2의 이미지

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

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

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

yong27의 이미지

프로그래머는 神이다.

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

좀더 다이나믹하게~

행복한고니의 이미지

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

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

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

__________________________________
나는 세상에서 가장 중요한 사람이다.

김경태의 이미지

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

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

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

2. 성능, 안정성

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

3. 코드의 유연성

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

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

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

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

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

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

도움 되셨기를 바랍니다.

moonzoo의 이미지

직관적으로

유연하게.

전체 설계 => 각 부품 설계 => 짜맞추기 순서로..

가장기본은 input , ouput이 명확하게..

LispM의 이미지

Abstraction, Engineering, Discipline

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

dangsan49의 이미지

앗..다시 새로운 페이지가 열렸군요.

개발자만의 "디버깅 정보를 볼수 있는 접근 통로"를 만들어 놓는 것입니다.
이럼 나중에 버그 발견시 대처도 쉽고
유지보수도 쉬울거란 생각이 드는군요.

VENI, VIDI, VICI - Caesar, Gaius Julius -

batmi의 이미지

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

.
마음을 가꾸는 방법은??

zeroness의 이미지

fender wrote:
hook wrote:
농담식으로 그러더군요

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

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


그런 작업도 체계적이고 이론적으로 접근해야 성공할 수 있습니다. 아래 주소를 참조하세요 (꼭 자세히 읽어 보시기를... -ㅅ-; ):

http://mindprod.com/unmain.html

오오오~~~ 베리굿!!!
ㅠㅠㅠㅠㅠㅠ

인간에게 있어 열정은 둘도없이 소중한 것이다. 경력이나 학력보다도... - 월리엄 록펠러 1세 -

kwon37xi의 이미지

hook wrote:
농담식으로 그러더군요

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

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

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

mindengine의 이미지

그런것은 없다.

rainmen747의 이미지

15년전이었나...

그래픽카드를 공부한 끝에

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

turbo-c를 열었다.

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

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

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

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

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

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

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

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

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

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

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

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

이제는 프로그렘은 커녕

나의 머리를 맴도는 기술은

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

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

내 과거 돌려도...

lnsium의 이미지

프로그래밍이 내 삶의 부분이라면 바로 내 삶의 철학에 부합해야한다.
고로 절대고독!

의사소통에의 노력과 약간의 환희와 마침내 다가오는 절대고독...
자기만족과 자괴를 방황하는...

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.