// ... 중간 생략 ... //
int main() { return MainUI(); } ...
// ... 중간 생략 ... //
Quote:
철학 1.
main은 한 줄로, MainUI 함수의 반환 값을 반환하게...
MainUI에서 모든 짓을 알아서 하도록...
철학 2.
무조건 시각적으로 출력한다.
맨 위 1줄, 맨 왼쪽 1줄, 맨 아래 1줄, 맨 오른쪽 1줄 사용 금지
제목을 출력할 땐 gotoxy()
줄을 바꿀 때도 gotoxy()
gotoxy() 로 여백을 만들자
cprintf() 에서 \n 을 사용해서
캐리지 리턴 하지 않고
라인 피드 하는 것도 방법
철학 3.
(실용 면에서는) C++이 최고다.
str struct;
printf("Structure Output : %d %d", struct.a, struct.b)
는 당장 friend str operator<<(ostream &o, str x)
오버로딩을 해서 cout << struct 로 바꾼다.
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
KISS입니다. 복잡한 코드는 완성시키기도 힘들고
디버깅하기도 힘들고 수정하기도 힘듭니다.
2. 욕심을 부리지 않는다.
한 함수에 너무 많은 기능을 넣는다던지
너무 General한 기능을 구현하려 한다던지
지나치게 코드를 간략화 한더던지
필요 이상으로 빠르게 동작하도록 한다던지
이런 일은 삼가합니다.
3. 스타일을 지킨다.
들여쓰기, 띄어쓰기, 변수/함수/상수/클래스
이름붙이기의 (나름대로의) 규칙을 칼같이 지킨다.
나중에 보기도 편하겠고..
이렇게 하면 나중에 검색 기능으로 코드 중에서
찾고자 하는 부분을 찾을 때도 좋습니다.
"x = " 이런식으로 빈칸 갯수까지 맞추어두면요.
4. 결과를 확인할 수 있는 단위로 개발한다.
대개 Bottom-Up식 개발이 되겠고, 좀 무식해
보이겠지만, 최대한 빠르게(되도록이면 시각적으로?)
결과를 확인할 수 있는 부분부터 개발합니다.
이렇게 몇가지 붙여서 Prototype을 만들어 봅니다.
결과가 가시적이면 테스트도 쉽고 개발의욕이
높아지더라구요. 그리고 단위 단위로 테스트하면서
진행할 수 있어 버그를 초기에 잡기 좋습니다.
5. 자신이 작성한 프로그램을 너무 믿지 않는다.
항상 자신이 작성한 코드에 결함이 있을 수 있다는
생각을 갖고 주의를 기울입니다. 다른 사람이 작성한
것과 같이 사용될 경우, 자기 코드의 결함을 확인하기
위해 노력하다보면(자기 코드의 결함이 없음을 증명
하기 위해 노력하는 것과 결과적으로 같습니다),
다른 모듈의 문제도 쉽게 발견되는 경우가 많습니다.
6. 예외 처리를 뒤로 미루지 않는다.
함수나 모듈 단위로 예외처리가 가능한 것은 처음
작성시에 되도록 모든 가능한 경우를 포함시킵니다.
이것은 단위 테스트에 기초하여 개발을 진행시키는
것과 관련이 있습니다. 나중에 예외처리를 추가해야지
하고 진행해버리면 결국 일정에 쫓기던지 귀찮아서던지
나중에도 안해버리는 경우가 많더라구요.
7. 자기가 무엇을 개발하는지 알고 개발한다.
개발 결과물/사용방식/사용목적/사용자에 대해서
이해가 부족한 상태에서 개발하면 결국 전면수정,
재개발, 버그지옥, 일정지연 등의 부작용이
생깁니다.
전에 정리해 둔 게 아니라 생각나는 대로 쓴거라
주제에 잘 안맞거나 주관적인 내용이 많을거라
생각합니다만.. ^^
1. 전체적이면서도 상당히 세부적인 내용까지 이해가 될때까지
그림을 디립따 그립니다. 실제로 전체적인 시스템 layout,
case, data-flow 등을 다그리면 상당히 두꺼운 량의 그림이 나옵니다.
시작할때, 같은 시스템을 여러 각도에서 그림을 그려보면서
코드의 대략적인 layout 과 디자인 패턴을 생각합니다.
( 일단 상사가 그림을 좋아합니다. )
2. 프로그램 스펙을 Test script 로 항상 maintain 합니다.
즉, 이 프로그램이 잘못되었는지를 'tst.sh all' 한방으로 알아냅니다.
아니면, 스펙에 문제가 있는지도 모릅니다. 어쨌거나, 사람에게서
들은 스펙들을 싸그리 모아서 test script 들을 만듭니다.
( python 이 참 좋습니다. )
생각하지 못한 스펙이 있다면, test case 를 추가합니다.
3. 에러가 나면 로그를 분석한후, 코드상의 문제이면 고치지만,
좀 문제가 크다싶으면 일단 그림을 참조하고, 그림부터 그립니다.
즉, 계획이 없으면 실행을 안하는 소심형 입니다.
아직 실력이 미미한 관계로, 믿을수 있는 코드를 만들겠다는 주의로 살고있습니다.
자신의 머리에 들은 것을 작가는 글로 쓰고, 화가는 그림을 그리고, 감독은 영화를 만들고, 작곡가는 음악을 만드는 것처럼 나는 프로그램을 만든다.
가 맞는 말이겠네요.
(실제로 위에 나오는 것 중에서 그래도 자신있는게 프로그래밍이니...-_-;;;)
c'est un des orgueils de notre pauvre humanit?, que chaque homme se croie plus malheureux qu'un autre malheureux qui pleure et qui g?mit ? c?t? de lui
- Le Comte de Monte-Cristo
-----------------------------------------------------------------------
2. 최근에 익힌 최신 기술을 최대한 이용하지 않는다.
최근에 익힌 기술을 남발하면 같이 개발하는 사람들이 어려워 합니다.
고로, 남들이 이해하기 좋도록, 새로운 기술은 최대한 자재한다.
3. 코드 백업은, 쳬계적인 check-in으로..
머 회사에서 SourceSafe를 사용하고 있으니 특별히 백업할 필요가 없습니다.
백업은 의도적으로 하지 않는다. 다만 습관적으로 관련있는것들을 묶어서 check-in 하자.
4. 필요한놈만 주석과 문서로.
자잘한 코드의 주석은 별로 필요가 없습니다.
다만 복잡한 처리과정은 주석으로 처리가 되지 않습니다.
주석은 필요한놈만 단다, 그리고 필요한놈만 문서화 한다.
5. 밑그림은 간략하게, 가능한 빠르게 실 작업에 들어간다.
어느 방법이든 디자인시와, 실 개발시에 완벽하게 맞아떨어지는 것은 없습니다.
밑그림 정도만 디자인으로, 실제로 적용할때에는 가능한한 컴퓨터로 빠르게 trial-and-error 로 적응합니다.
아. 모니터는 가능하면 LCD로...
이중.. 개발철학 이라면...
1번이겠군요...
WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
저는 저말이 정반대라고 생각되는데요..
정말 컴퓨터가 이해할수 있는코드를 어느바보나 다 짤수 있을까요?
그렇다면 리눅스커널과 같은기능을 하는 코드를 어느바보나 다짤수 있다는뜻인가..
최소한 리눅스 커널 소스가 리누스 아니면 아무도 이해 못할 정도로 유지보수가 어려웠다면 설사 성능이 지금 보다 훨씬 뛰어나다고 해도, 학창시절 리누스의 취미 프로젝트로 사장되어 버렸을 겁니다.
리누스 외에 이해하는사람들이 있기는 했으나.. 아예 돌지조차 않는걸짜두었다면. 리누스는 아예 사람들한테 보여주지도 않았을겁니다.
리팩토링은 돌지도 않는 프로그램을 짜라는 말이 아님은 잘 아시리라 믿습니다만... 그리고 원래 반박하신 내용 - "컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다"라는 말은 리팩터링과 직접적인 관련이 없습니다.
사람만 이해하고 컴퓨터에서 돌지 않는 코드를 짜라는게 아니라 제대로 동작하는 건 프로그래머로서의 '기본'이고 '제대로된' 프로그래머라면 거기에 덧붙여 유지보수도 용이한 프로그램을 짠다는 뜻입니다.
그걸 왜 굳이 '사람이 이해할수 있는코드인데 컴퓨터가 이해못할코드도 좋다'라고 곡해해서 반박을 하셨는지 이해가 안가는군요.
재밌는 의문이 드는군요.
1. 컴퓨터는 똑똑하다.
2. 사람은 컴퓨터보다 똑똑하다.
3. 사람은 컴퓨터보다 똑똑하므로 컴퓨터가 이해하는 정도는 충분히 (눈 감고도) 이해할 수 있다.
4. 컴퓨터가 이해하는 코드는 사람이면 당연히 이해할 수 있다. (물론 프로그래머라는 전제겠죠..?)
5. 사람이 이해하지 못하는 코드는, 컴퓨터는 당연히 이해하지 못한다.
(컴퓨터 이해 -> 사람 이해) => (사람이 이해못함 -> 컴퓨터가 이해못함)
그럼 컴퓨터로는 돌아가는데, 사람이 이해하지 못하는 코드는 머죠???
사람이 컴퓨터보다 못하다는 건가...
아님 언어가 틀려서인가.. (컴퓨터:어셈블러, 사람:씨)
WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
저는 저말이 정반대라고 생각되는데요..
정말 컴퓨터가 이해할수 있는코드를 어느바보나 다 짤수 있을까요?
그렇다면 리눅스커널과 같은기능을 하는 코드를 어느바보나 다짤수 있다는뜻인가..
최소한 리눅스 커널 소스가 리누스 아니면 아무도 이해 못할 정도로 유지보수가 어려웠다면 설사 성능이 지금 보다 훨씬 뛰어나다고 해도, 학창시절 리누스의 취미 프로젝트로 사장되어 버렸을 겁니다.
리누스 외에 이해하는사람들이 있기는 했으나.. 아예 돌지조차 않는걸짜두었다면. 리누스는 아예 사람들한테 보여주지도 않았을겁니다.
리팩토링은 돌지도 않는 프로그램을 짜라는 말이 아님은 잘 아시리라 믿습니다만... 그리고 원래 반박하신 내용 - "컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다"라는 말은 리팩터링과 직접적인 관련이 없습니다.
사람만 이해하고 컴퓨터에서 돌지 않는 코드를 짜라는게 아니라 제대로 동작하는 건 프로그래머로서의 '기본'이고 '제대로된' 프로그래머라면 거기에 덧붙여 유지보수도 용이한 프로그램을 짠다는 뜻입니다.
그걸 왜 굳이 '사람이 이해할수 있는코드인데 컴퓨터가 이해못할코드도 좋다'라고 곡해해서 반박을 하셨는지 이해가 안가는군요.
재밌는 의문이 드는군요.
1. 컴퓨터는 똑똑하다.
2. 사람은 컴퓨터보다 똑똑하다.
3. 사람은 컴퓨터보다 똑똑하므로 컴퓨터가 이해하는 정도는 충분히 (눈 감고도) 이해할 수 있다.
4. 컴퓨터가 이해하는 코드는 사람이면 당연히 이해할 수 있다. (물론 프로그래머라는 전제겠죠..?)
5. 사람이 이해하지 못하는 코드는, 컴퓨터는 당연히 이해하지 못한다.
(컴퓨터 이해 -> 사람 이해) => (사람이 이해못함 -> 컴퓨터가 이해못함)
그럼 컴퓨터로는 돌아가는데, 사람이 이해하지 못하는 코드는 머죠???
사람이 컴퓨터보다 못하다는 건가...
아님 언어가 틀려서인가.. (컴퓨터:어셈블러, 사람:씨)
사람이 컴퓨터보다 더 똑똑하기 때문에 컴퓨터라면 닥치고 돌릴뿐인 코드를 보고 화를 내며 고치려고 애쓰는거죠. 컴퓨터는 주어진 코드를 묵묵히 수행할 뿐 해당 코드를 고치거나 다른 곳에다 가져다 쓰려고 하진 않습니다.
일단 문제를 이해하고 이것저것 생각을 많이 해둡니다.
디자인은 그림 그려가면서 꼼꼼히 하고, 최대한 모듈러 하게...
그리고 어느정도 클래스/메소드 시그내쳐도 디자인에 집어넣습니다... 이 부분은 물론 나중에 바뀌지요.
일단 최대한 유연하고 independent 한 모듈들을 추구하구요, Inversion Of Control이라는 개념을 머리에 두려고 노력합니다.
그리고 나서 코딩 들어갑니다.
ㅇ ㅏ 그리고 최대한 Unit Testing 을 하려고 하기는 합니다만...
뭐, 아직도 초짜라 제대로 지켜지는건 별로 없긴 하지만요... ㅋ
무작정 코딩만 하는 걸 최대한 피하기 위해 "코딩 전에 최대한 많이 디자인" 이 목표긴 합니다만 지키기는 힘들더군요.
개발중 요구 기능이 추가/변경되는 일도 있고... 이래저래 초반 디자인이 그대로 남아 있는 경우는 없었습니다.
개발이 끝난 후에도 변하지 않은 디자인을 하는게 요즘 목표 입니다.
개발자라면 만드는 프로그램이 사용되는 domain 도 어느정도는 이해하고, 추가/변경되는 요구 사항도 어느정도는 예측할줄 알아야 한다고 생각합니다.
=================================
Structure I
Public Name As String = "RSH"
Public Age As Integer = 29
Private Wife As Boolean = TRUE
Private Daughter As Integer = 1
Private Son As Integer = 0
Private Unknown_Children As Integer = 2
EN
1. 제발 돌아라...돌아만 가라..
2. 디버깅은 printf가 전부다.
3. 한 줄 넣고 make 오류 안나면 다음 작업
4. 런타임 에러는 최대한 나중에 잡는다.
5. 컴파일 에러만 안나면 일단 성공(?)
6. 시키는 것만 구현한다.
7. 명확히 지시하지 않은 건 설사 나중에 필요할지 모르더라도 우선 뺀다. 8. 코딩은 엉덩이가 하지 않는다. 구글이 한다.
컴퓨터는 마법지팡이고
프로그래밍은 스펠을 외우는것이고 (복잡한.. 마법어들.. 젠장..)
프로그래머는 마법사이고(복잡한 스펠을 머리속으로 빠르게 연산하는 마법사는 대마법사(구루))
코드는 마법스크롤이다 (찢어버리면 바로 주문이 나가듯, 컴파일하면 실행되는)
프로그램은 마법이다
... 참고로 운동이나, 음악연주 같은것들은 무공에 가깝습니다
연습을 하면할수록 내공이 쌓이고 (침착하게 해야 정순한(?)내공이 쌓인담니다:습관)
처음에는 초식을 따라 연습을 시작하지만
진정한 고수가 되면 초식을 잊어버리게 되는 경지에 오르고
그렇게 되면 몸이 알아서 반응하고 (고수는 아무생각없이 노래를 들으며 바로 똑같이 연주를 '- ')
생각이 초보보다 많지 않다는거지 감정이나 열정이 없다는 것은 아니고;;
아무튼..뭐 이런식.. ^^;;
댓글
가져다가 붙이는 길만이 일찍 퇴근하기 위한 희망을 이끌어 낼수 있다.
가져다가 붙이는 길만이 일찍 퇴근하기 위한 희망을 이끌어 낼수 있다.
그러나 희망에 대한 성공률은 낮다. :)
그나저나 백수 언제 탈출하냐... ㅡㅡ; 배고파라.
'내가 아는 프로그래밍을 하자'아직 아는게 없으니... 프로그래밍
'내가 아는 프로그래밍을 하자'
아직 아는게 없으니... 프로그래밍한게 없지만 서도... (중얼중얼...)
(시무룩..)
=3
예전에는 프로그래밍 철학이 있었따~~~~
1. 예외처리가 필요한 모든 구멍을 막는다. 예를 들면 파일오픈 시키고 데이터 읽어올때 안읽히는 경우를 예상하여 print 문이라도 하나 맹글고 exit 시킨다.
2. 일단 골격을 짜서 화면을 보여주고 살을 갖다 붙인다.
3. 코멘트는 최대한 많이... 완벽한 해결책이 없이 프로그램해야할경우 나중에 이러저러한 문제가 있을 경우 동작이 안될수 있다. 내일의 나에게 해결하도록 생각해 보라고 메세지를 보내는 마음으로...
4. 골격이 잘못되었다고 판단되면, 왕창무너뜨리고 다시... (분당 400타의 키보드 실력믿고 하는것 일수도...)
5. 프로그램의 기능적인 부분을 한번쓰면 그냥 프로그램내에 소설을 쓰지만 같은 프로그램내에서 두번째 사용할것 같으면 서브프로그램으로, 다른 프로그램에서도 쓸것같으면 서브모듈로 또는 라이브러리로...
이런 철학으로 프로그래밍해왔는데 비주얼 프로그램이 유행이 되면서 모다 물건너 갔다. 이제는 그냥 되는대로... 버그가 안 나타나기를 기도하면서 짠다...
- 겨울아찌 -
- 겨울아찌 -
winchild@gmail.com
소스공유...
소스 공유를 항상 맘에 품고 코딩을한다.
이게 내가 느낀 전부...
공유를 생각한다면 눈에 띄게 코드가 깔끔해지고 각종 패턴들이 적절히 적용된다.
아니한 생각을 하지않게 된다. 프로그래머는 코드로 말하지 주석으로 말하지 않는다.. 잘짜여진 코드는 아무리 잘 설명한 주석보다 낫다.
위와같이 하기위해선 소스공유를 생각한다.
*그럼에도 불고하고 윈도우 개발자이다. 밥줄이니.. 언젠가 리눅서가 되리니..
예술 , 기술 , 건축!!
예술 , 기술 , 건축!!
결벽증 환자 양성과정 ㅡㅛ-);; - 완벽하지 않으면 프로그램도 아니
결벽증 환자 양성과정 ㅡㅛ-);;
- 완벽하지 않으면 프로그램도 아니다 -_-
동의 안할래야 안할 수가 없는 . . . ㅡ_-);;
이와 반대의 시각으로 보자면 . . .
말장난~!
- 프로그래밍 언어도 문자로 표현하는 "말"이다 -_-
말씀 언(言), 말씀 어(語) 니까 . . . -_-/
---------------------------------------------------------------
폐인이 되자 (/ㅂ/)
될수 있는 한 기능별로 묶어서 따로 만들자 입니다.급하면 기능별로
될수 있는 한 기능별로 묶어서 따로 만들자 입니다.
급하면 기능별로 묶지 않고 누더기 코딩을 하는데...
종국엔 이것이 시간만 더 잡아 먹더라구요
그래서 요즘은 아무리 급해도... 컴포넌트화 클래스화 모듈화를 할려고 합니다.
프로그래밍 철학이라면...
프로그래머가 아닌 사람의 눈으로, 글들을 재미있게 보았는데요..
글쎄.. '코딩철학', '작업철학' 이라고 할까요? 음 그런 생각이 드네요..
만일 시인이나 소설가에게 당신의 철학이 뭐냐고 물으면
조금은 다른 답들이 나오지 않나요?
음,
내가 만든 프로그램이 전쟁무기에 사용되지 않게 한다.
세상에서 가장 아름답고 이로운 프로그램을 만드는 것이 꿈이다.
예술적 프로그래밍, 코드, 구조, 결과물.. 등등.
^^; 프로그래머 세계에선 이런 류의 답은 엉뚱한 건가요?
게으름 극대화.....생각은 많이 타이핑은 적게....코드는 두고두고 우
게으름 극대화.....생각은 많이 타이핑은 적게....코드는 두고두고 우려먹을수 있게.
목표를 이루는법
일반적 기능을 가질수 있도록 하면서. 코드는 최대한 짧고 간결하게 작성하면 됩니다.. :shock:
아 또한가지 있군요
호랑이는 죽어서 가죽을 남기고, 사람은 죽어서 이름을 남기고, 프로그래머는 죽어서 주석을 남긴다....
내일 할 수 있는 오늘 하지말자
내일 할 수 있는 오늘 하지말자
Life rushes on, we are distracted
9 to 5
9 to 5
이게 뭐예요?
잘몰라서 ^^a(긁적긁적)
Generalize or Generatehttp://mithrandi
Generalize or Generate
http://mithrandir.xcool.net/~kyagrd/?page=_500_Writings&show=GeneralizeOrGenerate
--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/
어영부영. 뚝딱뚝딱.
어영부영. 뚝딱뚝딱.
그나마 XP느낌의 CVS 문화가 정립되어 있을 때는
개발자끼리 코드로 대화를 하니까
더 심사숙고하게 됩니다만..
또는, 나만의 거시기를 보이고자 할 때는 탭 하나라도 흐트러짐이 없지만..
아무래도 프로젝트에 들어가면 어영부영, 뚝딱뚝딱이 되곤 하네요.
근데..
어영부영, 뚝딱뚝딱에 대해서도 변명할 것은 많은데요 ㅠ.ㅠ
고수님들 많은 이 곳에서 딱히 이야기 하긴 그렇고.. 샤샥 도망가렵니다. ㅡ.ㅡ;
main은 한줄로...
// ... 중간 생략 ... // int main() { return MainUI(); } ... // ... 중간 생략 ... //Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
그냥 이런거죠...
간단하게. 무조건...
절대로 쓸데없는 루틴 넣지 않는다.
printf 가 없으면 디버깅 어떻게 하시렵니까!?
(puts,putchar 모두포함)
printf 부터 만들어보세요. 어렵긴 하지만... 보람있습니다^^
FeeL받으면 갈아 엎는다...ㅡㅡ;
FeeL받으면 전부 갈아 엎어 버린다. ㅡㅡ;
소스가 만줄이상이라면 내심 다시 생각해보기도 하지요...ㅡㅡ;
설령 약간 비효율적이라도 최대한 함수를 직접 만들어서 쓴다. 단, 술술 풀릴때...
닙따 함수만 왕창왕창 찾아 쓰는 타입들을 많이봐서리...
ANSI C 표준함수자체에도 결함이 있는데. 어찌 여타함수에 결함이 없겠는가? 가끔 어떤 이들은 빡빡 우긴다.
분명 이 함수가 맞는데 왜 에러가 나나..ㅡㅡ;
태어나서 본 모든 책과 웹을 바탕으로 최대한 스타일리쉬하게 짠다.
ANSI C도 따르고, 충성MS의 헝가리안 표긱법, OpenGL의 표기법, kernighan & ritchie C도 따르고, 맥코웰도 따르고...
암튼 몸에 좋고, 정신에 좋은건 모든지 따른다...ㅡㅡ;
VC++을 이용할때...계속 디버깅해도 에러나면 한번 부팅한다.
VC++자체 버그땜시. 10시간 이상 FeeL받은 적이 있어서...ㅡㅡ;
Hello World.
모르면 모르는데로 아는만큼만 만들지 말자.제가 가장 싫어하는 것이
모르면 모르는데로 아는만큼만 만들지 말자.
제가 가장 싫어하는 것이 잘 모르면 물어보고 찾아서 배울 생각은 않고
어떻게든 그 상황을 모면해보자라는 안일한 생각으로 개발에 임하는 자세입니다.
그런데... 현실은 어쩔수가 없습니다.
프로젝트 기간은 짧고 요구사항은 추상적이고 자꾸 변화하지요.
머리에 떠도는대로 그냥 타이핑칠수밖에 없고 그래도 빠듯합니다.
그래서 요즘은 현실을 직시하자 입니다. :(
어차피 리펙토링이 있으니까요.
제 철학이랄 건 없구 몇가지 생각나는 것을 정리해 보았습니다.
제 입장에서 생각나는 것을 적어보겠습니다.
1. 가능한한 단순하게 구현한다.
KISS입니다. 복잡한 코드는 완성시키기도 힘들고
디버깅하기도 힘들고 수정하기도 힘듭니다.
2. 욕심을 부리지 않는다.
한 함수에 너무 많은 기능을 넣는다던지
너무 General한 기능을 구현하려 한다던지
지나치게 코드를 간략화 한더던지
필요 이상으로 빠르게 동작하도록 한다던지
이런 일은 삼가합니다.
3. 스타일을 지킨다.
들여쓰기, 띄어쓰기, 변수/함수/상수/클래스
이름붙이기의 (나름대로의) 규칙을 칼같이 지킨다.
나중에 보기도 편하겠고..
이렇게 하면 나중에 검색 기능으로 코드 중에서
찾고자 하는 부분을 찾을 때도 좋습니다.
"x = " 이런식으로 빈칸 갯수까지 맞추어두면요.
4. 결과를 확인할 수 있는 단위로 개발한다.
대개 Bottom-Up식 개발이 되겠고, 좀 무식해
보이겠지만, 최대한 빠르게(되도록이면 시각적으로?)
결과를 확인할 수 있는 부분부터 개발합니다.
이렇게 몇가지 붙여서 Prototype을 만들어 봅니다.
결과가 가시적이면 테스트도 쉽고 개발의욕이
높아지더라구요. 그리고 단위 단위로 테스트하면서
진행할 수 있어 버그를 초기에 잡기 좋습니다.
5. 자신이 작성한 프로그램을 너무 믿지 않는다.
항상 자신이 작성한 코드에 결함이 있을 수 있다는
생각을 갖고 주의를 기울입니다. 다른 사람이 작성한
것과 같이 사용될 경우, 자기 코드의 결함을 확인하기
위해 노력하다보면(자기 코드의 결함이 없음을 증명
하기 위해 노력하는 것과 결과적으로 같습니다),
다른 모듈의 문제도 쉽게 발견되는 경우가 많습니다.
6. 예외 처리를 뒤로 미루지 않는다.
함수나 모듈 단위로 예외처리가 가능한 것은 처음
작성시에 되도록 모든 가능한 경우를 포함시킵니다.
이것은 단위 테스트에 기초하여 개발을 진행시키는
것과 관련이 있습니다. 나중에 예외처리를 추가해야지
하고 진행해버리면 결국 일정에 쫓기던지 귀찮아서던지
나중에도 안해버리는 경우가 많더라구요.
7. 자기가 무엇을 개발하는지 알고 개발한다.
개발 결과물/사용방식/사용목적/사용자에 대해서
이해가 부족한 상태에서 개발하면 결국 전면수정,
재개발, 버그지옥, 일정지연 등의 부작용이
생깁니다.
전에 정리해 둔 게 아니라 생각나는 대로 쓴거라
주제에 잘 안맞거나 주관적인 내용이 많을거라
생각합니다만.. ^^
http://blog.dreamwiz.com/shjii
1. 전체적이면서도 상당히 세부적인 내용까지 이해가 될때까지 그림
1. 전체적이면서도 상당히 세부적인 내용까지 이해가 될때까지
그림을 디립따 그립니다. 실제로 전체적인 시스템 layout,
case, data-flow 등을 다그리면 상당히 두꺼운 량의 그림이 나옵니다.
시작할때, 같은 시스템을 여러 각도에서 그림을 그려보면서
코드의 대략적인 layout 과 디자인 패턴을 생각합니다.
( 일단 상사가 그림을 좋아합니다. )
2. 프로그램 스펙을 Test script 로 항상 maintain 합니다.
즉, 이 프로그램이 잘못되었는지를 'tst.sh all' 한방으로 알아냅니다.
아니면, 스펙에 문제가 있는지도 모릅니다. 어쨌거나, 사람에게서
들은 스펙들을 싸그리 모아서 test script 들을 만듭니다.
( python 이 참 좋습니다. )
생각하지 못한 스펙이 있다면, test case 를 추가합니다.
3. 에러가 나면 로그를 분석한후, 코드상의 문제이면 고치지만,
좀 문제가 크다싶으면 일단 그림을 참조하고, 그림부터 그립니다.
즉, 계획이 없으면 실행을 안하는 소심형 입니다.
아직 실력이 미미한 관계로, 믿을수 있는 코드를 만들겠다는 주의로 살고있습니다.
삽질의 대마왕...
프로그래밍이 인생의 전부는 아니다.
프로그래밍 설계와 코딩의 방법론이 많이 등장했네요.
많이 배우고 여러가지를 느끼게 해주었습니다.
저의 프로그래밍 철학은 "프로그래밍이 인생의 전부는 아니다." 입니다.
나를 위해 프로그래밍을 할 뿐, 프로그래밍을 위해 내가 살아야하는 것은
아닙니다. 더 가치있는 일이 있다면, 그것이 먼저입니다.
내 블로그: http://unipro.tistory.com
Re: 프로그래밍이 인생의 전부는 아니다.
전 "프로그래밍하지 않은 삶은 무가치하다" 인데..:oops:
제 삶도 프로그래밍의 한 과정이라 생각하고 열심히 하고 있습니다.
[quote="hook"]농담식으로 그러더군요 가늘고 길게 회사에
마음에 와 닿네요....
추가로... 손이 너무 빠르면 안된다는것..
항상 감사하는 마음으로...
6개월동안 데몬프로그램이 돌다 죽는 버그를 잡지 못했습니다...그
6개월동안 데몬프로그램이 돌다 죽는 버그를 잡지 못했습니다...
그래서 저는...
변강쇠처럼 튼튼하게 돌아라~~
알고보니 vc++의 컴파일 옵션중에 multithreaded 옵션을 안줘서 그랬더군요...어처구니없게 :roll:
http://oksystem.pe.kr
>.<
1. 무조건 테스트케이스 먼저.... 디자인은 테스트케이스로 한다.2
1. 무조건 테스트케이스 먼저.... 디자인은 테스트케이스로 한다.
2. google first. 누군가 비슷한 일을 했을 것이다.. 참고하라..
3. 내 코드에 대해서 최대한 객관적으로 접근하라... 1주일만 지나면 내가한 코드도 못알아 본다..
What do you want to eat?
[quote="temper"][size=24][b]Anyway, work
가장 많이 공감이 가네요.
개인적으로 하나 더 붙이면, 일정 준수
흐~ 너무 직업병 걸린 것처럼 보이나~~
총총..
나중에 요구사항이 바뀌어도조금만 수정하면 되도록 ^^
나중에 요구사항이 바뀌어도
조금만 수정하면 되도록 ^^
Re: 당신의 프로그래밍 철학은..?
========== 모델링 ===========
자연언어가 그렇듯이
프로그램 또한
생각과 현실의 모델링.
모델링을 잘하면 프로그램의 50%는 끝.
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
단순하게...
시스템을 고려하여 가장 단순하게...
예쁘게.... -ㅅ-;
예쁘게.... -ㅅ-;
shai-hulud가 되고 싶은 sandworm.
철학이라고 말하긴 머하지만...
오타 치지 말자...;;;
Simple, Thin, Elegant.and... Just fo
Simple, Thin, Elegant.
and... Just for fun.
───────────────────────
yaourt -S gothick elegant
khris'log
한가지 일을 잘하자. 사람이든 프로그램이든. from taoup
한가지 일을 잘하자. 사람이든 프로그램이든. from taoup
그것은 또다른 세상의 신이 되는 일
프로그래밍이란 신. 조물주의 일이라 생각합니다.
제가 코드를 짜는 동안 전 조물주가 되는 것이지요^^
내 자신이 더욱 완벽한 코드.. 결과물
더욱 완벽한 신이 되기위해....
왜... copy & paste 가 없는거죠
왜... copy & paste 가 없는거죠
황혼보다 어두운 자여
내 몸에 흐르는 피보다 더 붉은 자여
시간의 흐름 속에 파뭍힌 위대한 그대의 이름을 걸고 나 여기서 어둠에 맹세하노라
우리 앞을 가로막고 있는 모든 어리석은 자 들에게
나와 그대의 힘을
위대한 파멸의 힘을 보여줄 것을
여기 글들을 읽고 생긴 생각
프로그래밍은 컴퓨터속에서 살아가는 새 생명을 창조하는 작업..
새 생명을 창조한다는데 이리끼우고 저리끼우고 뒤죽박죽
만든다는건 말이 안되겠죠
프로그래밍은 새 생명의 설계
어떤 일이든 두번 이상 생각하고 시작하자
저는 코드를 읽기 쉽게 하는 걸 많이 신경씁니다.나중에 알아보기도 쉽
저는 코드를 읽기 쉽게 하는 걸 많이 신경씁니다.
나중에 알아보기도 쉽고, 다른 사람이 코드를 볼 때 어떤 동작을 하는지 단번에 알아챌 수 있도록 말이죠.
그리고 되도록이면 작동 코드를 작성한 후에 구현을 합니다.
구현 때문에 실제 코드가 복잡해지는 걸 막기 위해서죠.
[quote="soyoyoo"]오타 치지 말자...;;;[/quote]
철학일지는 모르겠지만,
확실히 맞는 말....
오타 조심, 예외 처리 철저
이거 무시 했다가는 괜한 삽질로 아까운 시간 날리더군요.
그리고 만약 누군가가
저에게 프로그램을 왜 만드느냐라고 묻는다면,
자신의 머리에 들은 것을 작가는 글로 쓰고, 화가는 그림을 그리고, 감독은 영화를 만들고, 작곡가는 음악을 만드는 것처럼 나는 프로그램을 만든다.
가 맞는 말이겠네요.
(실제로 위에 나오는 것 중에서 그래도 자신있는게 프로그래밍이니...-_-;;;)
c'est un des orgueils de notre pauvre humanit?, que chaque homme se croie plus malheureux qu'un autre malheureux qui pleure et qui g?mit ? c?t? de lui
- Le Comte de Monte-Cristo
-----------------------------------------------------------------------
요새 modifiability 가 가장 중요하다고 느끼고 있습니다.당
요새 modifiability 가 가장 중요하다고 느끼고 있습니다.
당장은 일정에 쫒기더라도 나중을 위해서...
복잡하고 결과값 예상이 힘든 부분은
디자인에 구애받지 않고 돌아가는 작은 코드를 만들고
성공하면 refactoring을 통해 코드를 다듬어 나갑니다.
그리고, TDD 까지는 아니더라도
Test case를 만들어 관리하고 있습니다.
관리... 사소한 것이라도 기록에 남지죠.
같은 실수 두번 하지 말자.
성공했던 것 다시 찾느라고 시간 소모하지 말자...
등등...
프로그래밍은 즐거워야 합니다! :lol:
프로그래밍은 즐거워야 합니다! :lol:
종종 자신을 돌아보아요!~
하루 1% 릴리즈~~
내 자신이 만족할만한 코드를 짜는 것.1년 5년 10년이 지난뒤에 내
내 자신이 만족할만한 코드를 짜는 것.
1년 5년 10년이 지난뒤에 내가 봐도 부끄럽지 않을 코드를 짜는 거겠죠.
물론 -_-;; 지금의 코드는 지금 봐도 부끄럽다는.... :oops:
------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!
Reasonably ... ;-)
Reasonably ... ;-)
--
http://www.deisys.net
1. 선개발후최적화 먼저 개발하고, 최적화는 나중에 한다.
1. 선개발후최적화
먼저 개발하고, 최적화는 나중에 한다.
2. 최근에 익힌 최신 기술을 최대한 이용한다.
선개발시 최신 지식 및 기술을 이용하여 작성하여,
실습을 통해 자기학습효과를 극대화시킨다.
어차피 비효율적인 코드는 후최적화 과정에서 걸러지니깐...
3. 코드는 항상 백업하여 관리한다.
급작스런 사고로 이미작성된 코드를 날려본 사람만이
백업의 중요성을 알 수 있다 --;
4. 주석을 달고, 문서화한다.
나중을 위해...
5. 알고리즘 작성은 종이와 볼펜을 사용해 한다.
가급적 모니터를 보지 말자는...소중한 나의 눈을 위해 --;
1. [b]선개발후딴짓[/b]먼저 개발하고, 남는시간에 딴짓한다.
1. 선개발후딴짓
먼저 개발하고, 남는시간에 딴짓한다.
(이거 젤 중요한것 같아요.. 딴짓이 뭘지는 여러분들의 상상력에...)
2. 최근에 익힌 최신 기술을 최대한 이용하지 않는다.
최근에 익힌 기술을 남발하면 같이 개발하는 사람들이 어려워 합니다.
고로, 남들이 이해하기 좋도록, 새로운 기술은 최대한 자재한다.
3. 코드 백업은, 쳬계적인 check-in으로..
머 회사에서 SourceSafe를 사용하고 있으니 특별히 백업할 필요가 없습니다.
백업은 의도적으로 하지 않는다. 다만 습관적으로 관련있는것들을 묶어서 check-in 하자.
4. 필요한놈만 주석과 문서로.
자잘한 코드의 주석은 별로 필요가 없습니다.
다만 복잡한 처리과정은 주석으로 처리가 되지 않습니다.
주석은 필요한놈만 단다, 그리고 필요한놈만 문서화 한다.
5. 밑그림은 간략하게, 가능한 빠르게 실 작업에 들어간다.
어느 방법이든 디자인시와, 실 개발시에 완벽하게 맞아떨어지는 것은 없습니다.
밑그림 정도만 디자인으로, 실제로 적용할때에는 가능한한 컴퓨터로 빠르게 trial-and-error 로 적응합니다.
아. 모니터는 가능하면 LCD로...
이중.. 개발철학 이라면...
1번이겠군요...
WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
[quote="fender"][quote="ㅡ,.ㅡ;;"][quote="
재밌는 의문이 드는군요.
1. 컴퓨터는 똑똑하다.
2. 사람은 컴퓨터보다 똑똑하다.
3. 사람은 컴퓨터보다 똑똑하므로 컴퓨터가 이해하는 정도는 충분히 (눈 감고도) 이해할 수 있다.
4. 컴퓨터가 이해하는 코드는 사람이면 당연히 이해할 수 있다. (물론 프로그래머라는 전제겠죠..?)
5. 사람이 이해하지 못하는 코드는, 컴퓨터는 당연히 이해하지 못한다.
(컴퓨터 이해 -> 사람 이해) => (사람이 이해못함 -> 컴퓨터가 이해못함)
그럼 컴퓨터로는 돌아가는데, 사람이 이해하지 못하는 코드는 머죠???
사람이 컴퓨터보다 못하다는 건가...
아님 언어가 틀려서인가.. (컴퓨터:어셈블러, 사람:씨)
WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
[quote="htna"][quote="fender"][quote="ㅡ,
사람이 컴퓨터보다 더 똑똑하기 때문에 컴퓨터라면 닥치고 돌릴뿐인 코드를 보고 화를 내며 고치려고 애쓰는거죠. 컴퓨터는 주어진 코드를 묵묵히 수행할 뿐 해당 코드를 고치거나 다른 곳에다 가져다 쓰려고 하진 않습니다.
[quote="haijun"]3. 코드는 항상 백업하여 관리한다.
CVS나 SubVersion을 사용하심이???
의외로 버전 관리 프로그램을 안쓰시는 분들이 많던데, 버전관리 프로그램 사용으로 인한 개발 효율성 향상은 정말 눈에 띕니다.
그렇다고 사용법이 어렵냐 하면 요즘 나온 버전 관리 프로그램 클라이언트들이 워낙 좋아서 그렇지도 않거등요... 또 오픈소스구요.
저라면, 앞으로 회사 옮길때 버전관리 프로그램 안쓰는 회사는 안 갈것 같습니다. 아니면 회사 가서 제일 처음 하는일이 버전 관리 프로그램 사용하게 만드는 것이거나.
http://kwon37xi.egloos.com
Re: 그것은 또다른 세상의 신이 되는 일
저의 요새 철학과 정확히 일치합니다^^
물론 신 뿐 아니라, 못된 사장이 되서, 객체들을 마구 부려먹지요 --
'역지사지(易地思之)'
'역지사지(易地思之)'
......
'나'
또는 only ME
를 위한 소스, 문서가 아니라,
other,
또는 최소한 같은 팀내 동료
들을 위한 소스와 문서가 되도록 만들어야 겠다고 생각하고 있습니다
그러나! ...여전히 아직은 소원한 ...쿨럭;;;;;;
"For God so loved the world that he gave his one and only Son, that whoever believes in him shall not perish but have eternal life"-John 3:16
안되면 대기 하라~안되는건 안되는 거다.즐기수 없다면 피하라..
안되면 대기 하라~
안되는건 안되는 거다.
즐기수 없다면 피하라..
ㅠ.ㅠ 회사 짤리 겠는걸...
언제나 먼저 고려해야할 대상은 사람이 아니던가?
안되면 대기하라.
즐길 수 없다면 피하라.
메인은 서술형으로 구술하는 함수로 최대한 간결히 만든다.세부함수는 수
메인은 서술형으로 구술하는 함수로 최대한 간결히 만든다.
세부함수는 수학적으로 만들어준다.
너는 누구냐?
1 . 가독력이 높은 코드를 짜는것 tab 과 space 를 많이 두
1 . 가독력이 높은 코드를 짜는것
tab 과 space 를 많이 두고 bit operation 같은 경우 주석 철저히 달기
2 . Logic 이 완성되기 전에는 키보드에 손대지 않기 . 정도?
Dig it.
-_ -
최소노력, 최고성과
http://powereyes.egloos.com
철학이라면...
5k 넘는 소스파일은 쓰레기다.
-진-
좀 과격한가요? ;)
esolang(난해한
esolang(난해한 프로그래밍 언어)은 어떻게 쓰라구요 :cry:
-명예의전당자료발굴단-
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
"잘 ~ 해야
"잘 ~ 해야 한다."
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
거창한거 없이..
... 알맞은 모듈화와...
누구나 보아도 이해가 가능하도록 최대한 배려하는 코드... 입니다.
물론.. 그렇다고 코드상으로 말도안되는 괴상한 짓은 안합니다 :)
저는 더 나은
저는 더 나은 추상화를 위해서는 가독성은 희생되어도 된다고 생각합니다. 이쁘게 한 줄로 정렬된 어셈블리 코드 보다는 함축적인 지저분한 괄호와 <>가 더 낫습니다. 물론 둘다 잡을 수 있다면 둘다 잡아야 겠지요.
- CN의 낙서장 / HanIRC:#CN
- 죠커's blog / HanIRC:#CN
저는 좀 더
저는 좀 더 사회경험이 쌓이면서 새로운 프로그래밍 철학이 생기더군요.
* 프로그래밍을 하고 싶으면 빨리 은퇴부터 할지어다.
* 진정한 코드를 일 속에서 찾으려 하지 말지어다.
이 스레드...
오랫만에 부활하였군요 ㅎㅎ
요즘은 대충짜서 잘 돌고 테스트 데이터 대충 넣어봐서 돌아가면 장땡이다... 는게 주된 사상입니다...
코드 이쁘게 짠다고 실험데이터 이쁘게 나오는것도 아니니 ...
물론 외부 프로젝트는 주석은 달아줍니다 >_<
음...철학이라고 하면
쉽고 간결하고 단순하게?...랄까요 하핫
전국정보올림피아드
전국정보올림피아드대비 특별지도(학원 아닙니다... 시교육청관할 대전교육정보원)때 친구가 그러더군요.
"프로그램은 99%의 노가다와 1%의 알고리즘으로 만들어진다"
------------------------------------------------------
In simplexitate est opportunitas. --cppig1995
"x86-64 운영체제를 만들자" 강좌: http://kldp.org/taxonomy/term/3663
2007학년도 대전월평중학교 1학년 3반 학급카페: http://cafe.naver.com/djwp0713
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
일단은...
쪽팔리지 않는 코드를 짜자... 가 저한테는
첫번째인거 같군요-_-
=================================================
Do the python !
=================================================
=================================================
Do the python !
=================================================
개발은
개발은 서비스업이다. (남을 위해 무언가를 만드는 것이다.)
전산에 안 되는건 없다.(다만 시간이 무진장 걸릴수는 있다.)
몇가지..
- 퇴근은 칼같이
- 내일할 코딩을 오늘하지 말자.
- 내 후임자에게 코드를 알리지마라
- 단순한게 최고다
- 최고의 개발도구는 연습장이다.
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
아직은 학생이라...
"간단"하더라도 "유용"한 프로그램을 "매일" 작성하자.
- 워드 커닝햄
뭐, 원문과는 약간의 차이가 있습니다.^^;
---
Make Better Life.
---
Make Better Life.
환경을 먼저
환경을 먼저 프로그래밍하고, 환경을 프로그래밍하는 환경을 먼저 프로그래밍하고, 환경을 프로그래밍하는 환경을 프로그래밍하는 환경을 먼저 프로그래밍하자. (메타프로그래밍.)
DRY
DRY(Don't Repeat Yourself)
/***************************************
Being the one is just like being in love.
***************************************/
/***************************************
Being the one is just like being in love.
***************************************/
코딩은 최대한 나중에
일단 문제를 이해하고 이것저것 생각을 많이 해둡니다.
디자인은 그림 그려가면서 꼼꼼히 하고, 최대한 모듈러 하게...
그리고 어느정도 클래스/메소드 시그내쳐도 디자인에 집어넣습니다... 이 부분은 물론 나중에 바뀌지요.
일단 최대한 유연하고 independent 한 모듈들을 추구하구요, Inversion Of Control이라는 개념을 머리에 두려고 노력합니다.
그리고 나서 코딩 들어갑니다.
ㅇ ㅏ 그리고 최대한 Unit Testing 을 하려고 하기는 합니다만...
뭐, 아직도 초짜라 제대로 지켜지는건 별로 없긴 하지만요... ㅋ
무작정 코딩만 하는 걸 최대한 피하기 위해 "코딩 전에 최대한 많이 디자인" 이 목표긴 합니다만 지키기는 힘들더군요.
개발중 요구 기능이 추가/변경되는 일도 있고... 이래저래 초반 디자인이 그대로 남아 있는 경우는 없었습니다.
개발이 끝난 후에도 변하지 않은 디자인을 하는게 요즘 목표 입니다.
개발자라면 만드는 프로그램이 사용되는 domain 도 어느정도는 이해하고, 추가/변경되는 요구 사항도 어느정도는 예측할줄 알아야 한다고 생각합니다.
수학은 기호의
수학은 기호의 학문이요, 프로그래밍은 Naming의 학문이다.
수학은 기호의 학문이요, 프로그래밍은 네이밍(Naming)의 학문이다.
수학은 기호로 표현을 하여 의사소통을 하듯
프로그래밍도 누구나 알아볼 수 있어야 한다는 내용입니다.
짧고
짧고 가늘게...
최소의 코드로 메모리를 줄이며 소모전류를 적게 먹도록 연산을 줄이는 코드...
코드철학도 직업에 따라 변하는군요. ㅡㅡ;
짧고
짧고 가늘게...
최소의 코드로 메모리를 줄이며 소모전류를 적게 먹도록 연산을 줄이는 코드...
코드철학도 직업에 따라 변하는군요. ㅡㅡ;
짧고
짧고 가늘게...
코드는 메모리 적게 잡아 먹도록 최소화해서 짜고 소모전류를 줄이기 위해 연산은 최소화 하도록 합니다.
예전에는 이게 아니었는데 하는 일에 따라 철학도 바뀌는 것 같군요. ㅡㅡ;
저는 아직...
자랑은 아니지만, 개발자가 아니라서 철학 따위를 지니고 있지 않은..ㅡ,.ㅡ;;
그저 다른분들이 만들어 놓은 것에 감사를 표하고 쓸줄만 하는 엔드유저...
---------------------------------------------------
1t의 생각보다 1g의 실천이 낫다.
간결하게,정확하게,아
간결하게,정확하게,아름답게... ^^
개발자들의 궁극적 비전은 ?
인생은 짧고 코드는 길다.
인생은 짧고 코드는 길다.
=================================
Structure I
Public Name As String = "RSH"
Public Age As Integer = 29
Private Wife As Boolean = TRUE
Private Daughter As Integer = 1
Private Son As Integer = 0
Private Unknown_Children As Integer = 2
EN
백업!
한 게 없어도 일주일에 세 번씩 백업하기!
우워우엉어어ㅓㅓ어어어어엉워!!!!
(특히 저번주에 코드 패키지 하나 다 날려먹은 이후로 -_-)
----------------
agidari.wordpress.com
제 철학은..
누구에게나 심플'
땀나는 맛이 있기에 세상은 살맛나는 것이지
땀나는 맛이 있기에 세상은 살맛나는 것이지
제발...
1. 제발 돌아라...돌아만 가라..
2. 디버깅은 printf가 전부다.
3. 한 줄 넣고 make 오류 안나면 다음 작업
4. 런타임 에러는 최대한 나중에 잡는다.
5. 컴파일 에러만 안나면 일단 성공(?)
6. 시키는 것만 구현한다.
7. 명확히 지시하지 않은 건 설사 나중에 필요할지 모르더라도 우선 뺀다.
8. 코딩은 엉덩이가 하지 않는다. 구글이 한다.
머리를 굴려라! 그래야 먹고 산다.
잘난척!!
철학적으로 생각해 봤는데...
아무래도 프로그래밍 철학은 잘난척인거 같네요. ^^
한마디로
폼생폼사
짧거나 길거나 먼가 폼나게 남들이 감탄하게
근대 영 잘안되네요 ㅋ
nEW
nEW
..
베낄 코드가 있으면 철저하게 베낀다.
커맨트를 열심히 한다.
테스트 해본다.
입니다.
A rose is a rose is a rose..
철학은
철학은 아니지만..
판타지 소설을 많이 읽어보신분이라면 공감할지도 모르겠네요
컴퓨터는 마법지팡이고
프로그래밍은 스펠을 외우는것이고 (복잡한.. 마법어들.. 젠장..)
프로그래머는 마법사이고(복잡한 스펠을 머리속으로 빠르게 연산하는 마법사는 대마법사(구루))
코드는 마법스크롤이다 (찢어버리면 바로 주문이 나가듯, 컴파일하면 실행되는)
프로그램은 마법이다
... 참고로 운동이나, 음악연주 같은것들은 무공에 가깝습니다
연습을 하면할수록 내공이 쌓이고 (침착하게 해야 정순한(?)내공이 쌓인담니다:습관)
처음에는 초식을 따라 연습을 시작하지만
진정한 고수가 되면 초식을 잊어버리게 되는 경지에 오르고
그렇게 되면 몸이 알아서 반응하고 (고수는 아무생각없이 노래를 들으며 바로 똑같이 연주를 '- ')
생각이 초보보다 많지 않다는거지 감정이나 열정이 없다는 것은 아니고;;
아무튼..뭐 이런식.. ^^;;
고객고객
1. 고객만족!
2. 고객감동!!
3. 고객흥분!!!
니즈가 없는 프로그래밍은 없다!
고통이 지천에 있다한들 어이해 멈출수있더냐
그냥
원할때 원하는 것을 창조할수 있도록
/*********************************
*모든것을 방관하고 지켜보며
*모든것을 창조하고 파괴할수
* 있는 '권한'을 가진 자
*
* 루트 == 신 같은 뜻 아닌가?
*********************************/
/*********************************
*모든것을 방관하고 지켜보며
*모든것을 창조하고 파괴할수
* 있는 '권한'을 가진 자
*
* 루트 == 신 같은 뜻 아닌가?
*********************************/
테스트코드 있는 더러운 코드가 테스트코드 없는 깔끔한 코드보다 훨 낫다
테스트 코드 있는 더러운 코드는 언제든지 깔끔하게 다시 짜고 테스트만 패스하면 원래 코드를 대체할 수 있다는걸 보장할 수 있기 때문에 깔끔한 코드나 다름이 없다.
반면, 테스트 코드 없이 보기만 깔끔한 코드는 시한폭탄이나 다름없다.
내 손가락은 나만의 참을 수 없는 매직 스틱
저도 일단 돌게 만들고
지속적인 리팩토링입니다.
깨끗하게, 맑게,
깨끗하게, 맑게, 자신있게~
emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/
https://xenosi.de/
.....
내 손을 떠난 프로그램은 절대 다시 돌아오지 않는다. :)
하지만 실상은 온갖 버그들로 고생한다는 ㅠㅠ
페이지
댓글 달기