| - ================================================================================<br> |
| - For a computer guru |
| + \TableOfContents1 |
| = |
| - 개성있는 프로그래머가 되는길(1) |
| + ! 개성있는 프로그래머가 되는길(1) |
| = |
| - 저자 : 이만용(프로그램 세계 기사) |
| - ================================================================================ |
| + \right 저자 : 이만용(프로그램 세계 기사) |
| = |
| + |
| = 모든 사람이 컴퓨터를 좋아하는 것은 아니다. 더 나아가 컴퓨터를 유용하게 |
| = 사용할 수 있도록 해주는 프로그래밍을 좋아하는 것도 아니다. 일반적으로 |
| = 프로그래밍을 좋아하거나 프로그래밍이 왠지 자기에게 맞을 것 같은 사람들은 |
| = 그렇지 않은 사람들과 분명히 다른 개성을 가지고 있다. 그 차이가 그렇게 크지는 |
| = 않다 하더라도 결과물은 다르다. 한 사람은 프로그래머이거나 프로그래머라고 |
| = 부를 수 있는 사람이고 다른 사람은 프로그래머가 전혀 아니다. |
| = |
| - ================================================================================<br> |
| - 프로그래밍은 다음과 같은 몇가지 마음의 작용이 일어날 때 좋아지고 시도하게 만든다. |
| - ================================================================================ |
| + ! 프로그래밍은 다음과 같은 몇가지 마음의 작용이 일어날 때 좋아지고 시도하게 만든다. |
| = |
| = 정말 훌륭한 소프트웨어를 사용해 보았으며 “언젠가는...” 자신도 그 정도 또는 |
| = 그에 가까운 수준의 소프트웨어를 만들고 싶다는 존경심으로부터 나온 욕구 |
| = |
| = 지금 현재하고 있는 작업이 불만스럽고 더욱 단순화시키고 싶다는 매우 현실적인 욕구 |
| = |
| = 예전에는 이 둘 중 하나였으나 직업적인 말단 프로그래머가 되어 상부 팀장의 지시에 |
| = 따라 어쩔 수 없이 해야 하는 의무 |
| = |
| = 처음 자신을 프로그래밍하게 또는 프로그래밍 공부를 하게 만든 요인에 따라 앞으로의 |
| = 선택 방법이 크게 달라진다. |
| = |
| = 참고로 필자는 겔로그와 제비우스(Xevious)와 같은 오락이 나오던 시절, 험상궂은 |
| = 아저씨들이 담배를 피워대던 오락실에서 우두커니 서서 그 오락들에 매료되어 |
| = 프로그래밍을 시작했다. 당연히 그 시절에는 베이직(BASIC)... |
| = |
| = 프로그래밍을 한다고 해서 모두가 똑같은 프로그래밍을 하는 것은 아닌 듯 하다. |
| = 사람이 다르면 프로그래밍 방식도 다르고 프로그래밍 방식이 다르면 나오는 작품도 |
| = 천차만별이다. 소프트웨어는 크든 적든 어느 정도 프로그래머의 개성을 반영한다. |
| = |
| = |
| = !! 1. 프로그래밍이 좋아서 하는 사람 |
| = |
| = 이 부류에 드는 사람들은 “대책이 없는(?)” 사람들이며 어느 누구도 말릴 수 없다. |
| = 누가 간섭하지 않아도 혼자서 바람도 안 부는데도 잘 도는 바람개비인 사람들이다. |
| = 이 사람들은 종종 “특별히 아무도 위하지 않는 자신만을 위한 프로그램”을 만들기 |
| = 좋아한다. 그 사람의 개인적인 취향을 닮은 프로그램이 많으며 그 프로그램에는 |
| = 프로그램을 만든 사람의 “인격(Character)”이 들어있다 해도 과언이 아니다. |
| = |
| = 프로그래밍이 원래 좋아서 코딩하는 사람은 아니라 하더라도, 이 세상에 태어나 자기 |
| = 인격을 가지고 있으며 자기와 동일시 할 수 있는 프로그램 하나 만들어 보는 것이 |
| = 프로그래머의 간절한 소원이 아닐까? 여러분은 어떠한가? 프로그래밍하는데 그런 희망 |
| = 내지는 야망 하나 없다면 얼마나 밋밋하겠는가? 오늘도 버거운 프로그래밍 과제를 |
| = 부여받는 말단 프로그래머의 마음 한 구석에는 자기를 표현해주는 프로그래밍 과제가 |
| = 조용히 끓고 있을 것이다. |
| = |
| = 요즘 전세계적인 열풍을 몰고 있는 리눅스(Linux)는 “프로그래밍이 좋아서” 만들어진 |
| = 대표적인 작품 중 하나다. |
| = |
| = 일반 응용 프로그램과 달리 운영체계 커널이라는 것은 사람들에게 화려하게 보이지도 |
| = 않으며 관심을 많이 끌지 않는다. 리누스(Linus)가 현재와 같은 성공을 예견하고 리눅스를 |
| = 코딩하기 시작했다고 신화화시킬 수 있을까?(리누스 그 자신이 거세게 항의하고 나올 |
| = 것이다. 리누스는 항상 리눅스 디자인의 핵심은 재미(fun)여야 한다고 강조한다). |
| = |
| = 예를 들어 인텔(Intel) 플랫폼이 아닌 알파(Alpha) 플랫폼과 같은 이 기종에 리눅스가 |
| = 돌아갈 수 있을 것이라고는 리누스 자신도 생각하지 못했다고 한다. 신(God)은 |
| = 예견했는지 몰라도, 신이 리누스나 다른 커널 개발자들의 손을 빌렸다고 말할 수 |
| = 있을 지는 몰라도, 직접 손을 사용하여 코딩을 한 사람은 모르고 한 일이며 그 |
| = 주위에 있는 사람들은 더더욱 모르고 한 일이다. 우리 중 예언자가 있으면 모를까…… |
| = |
| = 리눅스는 리누스가 가지고 있던 386PC를 위한 개인 취미 프로젝트라는 사실을 |
| = 많은 사람이 알고 있다. |
| = |
| = 그 후 지금까지 성장하기 위해서는 “단지 좋아서 자발적으로 열심히”라는 조건 |
| = 이상의 것이 있었다는 게 분명하다(조금 뒤에 다룰 것이다). 그러다 다음 사실은 분명하다. |
| = |
| = “단지 좋아서”, “자기의 인격을 닮은” 무엇인가를 만들어서 “자기 자신을 즐겁게“ |
| = 하기 위해 만들어진 프로그램에는 임시 땜질과 같은 거짓 요소가 없고 오히려 순도와 |
| = 완성도가 높을 때가 많다. 이는 기본적으로 자기 좋아서 하는 일에 대하여 프로그래머가 |
| = 자기를 속이는 일은 없으며 무엇보다 데드라인(dead line)이 없기 때문에 미봉책을 |
| = 쓸 이유조차 없기 때문이다. 문제에 봉착하면 포기하거나 자기 에너지를 모두 소비할 |
| = 때까지 붙어있으면 그만이지 대충 마무리 지을 이유는 없다. |
| = |
| = 좋아서 만드는 프로그램이 장난감 수준의 소프트웨어라고 말하고 싶은 사람도 있을 |
| = 지 모른다. 이미 전문가적인 수준의 프로그래머들이 그렇게 볼 지 모르지만 실상은 |
| = 그렇지 않다! |
| = |
| = |
| = 감히 리차드 스톨맨(Richard M. Stall man, 줄여서 rms라고 많이 부른다. FSF 회장이며 |
| = GNU 프로젝트의 창시자)씨의 이맥스(Emacs)는 “좋아서” 만든 소프트웨어라고 생각하며 |
| = 여러분도 알다시피 순도높고 리차드 스톨맨씨의 인격을 닮은 프로그램이라 말하고자 한다. |
| = 리눅스도 기본적으로 그러하다. |
| = |
| = 좋아서 만드는 프로그램은 둘 중 하나가 된다. 정말로 원래 의도했던 그대로 자기 |
| = 자신만을 위한 무명의 소프트웨어가 되거나 컴퓨터 역사상 길이 남을 명작이 되거나…… |
| = |
| = 어디에서 들은 말인지 기억이 가물가물하지만 필자는 이런 말하기를 좋아한다. |
| = |
| = “못하는 사람이 잘하는 사람 이기지 못한다. 이는 원래 당연하다. |
| = 그러나 잘하는 사람이라도 좋아하는 사람 이기기 어렵고 |
| = 좋아하는 사람이 미친 사람 절대 못 이긴다!” |
| = |
| = 필요는 발명의 어머니이다. 그러나 좋아하고 미칠 때에만 명작을 낳는다. |
| = |
| = |
| = |
| = !! 2. 자연스럽게 프로그래밍을 하게 된 사람 |
| = |
| = 프로그래밍과 별 연관이 없는 사람인데 프로그래밍을 하기 시작할 때가 있다. |
| = 이런 종류의 사람들이 요즘 많아지는데 이는 바로 리눅스(Linux)를 통해 |
| = 유닉스적인 사용 전통이 부활했기(원래 죽지는 않았다. 단지 많은 PC 사용자에 |
| = 의해 가려졌을 뿐이지) 때문이다. |
| = |
| = 이들은 대부분 시스템 관리자나 네트웍 관리자로서 실전적인 일에 종사하고 |
| = 있는 사람들이다. 그리고 절대적으로 리눅스, FreeBSD와 같이 개방적인 |
| = 운영체계에서 작업하는 사람들이 많다. 이들에게는 매우 기본적인 것만 주어져 |
| = 있으나 그와 동시에 기본적인 것들을 묶어 사용할 수 있게 해주는 환경이 함께 |
| = 제공되고 있다. 많은 기본 유닉스 명령을 이용하여 시스템과 네트워크 관리 작업을 |
| = 할 수 있으며 쉘(Shell), 펄(Perl), Tcl /Tk의 관리/통합 환경이 주어져 있다. |
| = |
| = 상대적으로 윈도우즈NT 관리자 중에서 “필요에 의해 자연스럽게 프로그래밍에 |
| = 빠져드는” 관리자가 거의 없는 이유는 분명한 듯 하다. 짜맞춰져 있는 메뉴와 |
| = 버튼 이외 별다른 선택이 없는 유연하지 않은 시스템이며 새로운 조합을 만들고 |
| = 싶어도 원래부터 조합도 힘들고 거의 모든 개발 환경이 돈을 주고 구입해야 |
| = 하기 때문이다(게다가 불법 복사를 조장할 만큼 비싸기까지 하다.) |
| = |
| = 이들에게는 일상의 작업이 많고 반복적이다. 따라서 무기력한 사람이 아니고서야 |
| = “조금 더 편하고 게으르게“ 일을 할 수는 없을까라는 생각을 자연스럽게 하게 된다. |
| = |
| = 가장 기본적인 인터페이스인 유닉스 쉘은 윈도우즈에서의 그래픽한 쉘 환경, |
| = 탐색기 또는 파일 관리자에 비교할 수 없을 만큼 초라해 보이고 구석기 시대의 |
| = 유물처럼 보이지만 풍부한 자체 스크립트 언어를 가지고 아직도 유용성을 |
| = 가지고 살아있다는 점을 인정해야 한다. |
| = |
| = 예를 들어 쉘 스크립트 언어는 뭔가 거대한 응용 프로그램을 만드는 언어가 |
| = 아니다. 원래 그런 목적을 가지고 만든 것이 아니기 때문에 그런 일을 하지 |
| = 못한다고 비난할 필요조차 없다. 쉘 스크립트 언어는 유닉스/리눅스 관리 |
| = 사용자의 둘도 없는 친구이다. |
| = |
| = 처음부터 모든 것을 다 알고 시작할 필요는 없다. 원하는 작업 패턴에 따라 |
| = 하나씩 익혀 가는 것이 순리이다. |
| = |
| = 이럴 때에는 이렇게 하고 싶다! (if, case) |
| = |
| = 반복해서 하고 싶다. (while) |
| = |
| = 순차적으로 하고 싶다. (for 또는 foreach) |
| = |
| = 우선 몰라도 쉘에 관련된 것을 처음부터 끝까지 읽어나가는 것이 중요하다. 한 번 |
| = 읽어서 모두 이해가 되길 바라는 도둑님같은 심보는 버리도록 하자(이 말은 어디에나 |
| = 적용된다). 쉘에 관한 한 if, while, for를 잘 익혀두자. 사실 모든 언어가 각자의 |
| = 특성을 가지고 있다 하더라도 조건/반복은 모든 컴퓨터 프로그래밍 언어의 핵심 구조이다. |
| = |
| = 필자 자신은 “절대로 한 번에 이해할 리 없다”라는 확신을 가지고 첫번째 독서는 |
| = 마음 편하게 (그러나 빠른 속도로) 읽어 내려가는 편이다. 그리고 나면 충분히 |
| = 이해하지는 못해도 대충 각 제목에서 “이런 것은 할 수 있다. 이런 것은 못한다”라는 |
| = 윤곽 정도는 잡게 된다. |
| = |
| = 이것만으로 큰 수확이지 않은가? |
| = 무엇이 가능한지 아닌지 대략 짐작은 할 수 있으므로 헛수고를 피할 수 있다. |
| = |
| = 이 부류의 사람들은 거의 대부분 계속 “자연스럽게 프로그래밍하는 사람”으로 |
| = 남는 경향이 많다. |
| = |
| = 대부분 간단한 쉘 스크립트, 펄 스크립트를 만드는데 그치지만 때로는 현실 경험에 |
| = 의거하여 정말 쓸모 있는 종류의 소프트웨어(자족적인 소프트웨어가 아니라)를 |
| = 만들어 내는 경향이 있다. 핵심 프로그램은 아니지만 이들의 기여가 없으면 컴퓨터 |
| = 세계는 매우 밋밋할 것이 분명하다. |
| = |
| = 특히나 리눅스에서는 이들의 기여가 엄청나다. 이 부류의 사람들은 전문 프로그래머라고 |
| = 생각하는 사람보다 오히려 훨씬 개방적이어서 자신의 필요를 빠르고 효율적으로 |
| = 완성시켜 줄 수 있는 도구, 즉 언어의 새로운 출현에 항상 호기심을 갖고 배운다. |
| = 이런 관점에서 전문 프로그래머보다 더 박식하고 행복하게 프로그래밍한다. |
| = |
| = |
| = !!! 책 구입, 프린팅에 인색하지 말자 |
| = |
| = |
| = 개인적으로 책을 모으는 취미가 있기도 하지만 다음과 같은 생각은 매우 위험하다고 |
| = 생각하며 하나의 주제에 대해서도 최소 2개 이상의 책이나 문서를 가지고 있어야 |
| = 한다고 주장한다. |
| = |
| = 적지 않은 사람들이 어떤 한 주제에 대한 훌륭한 책 한 권에 만족하려는 듯 하다. |
| = 그러나 어떠한 훌륭한 책도 모든 것을 담을 수 없다. 예를 들어 펄(Perl)이라는 |
| = 언어에 관한 한 펄의 원저자인 래리 월(Larry Wall)씨의 책은 당연히 |
| = 뛰어난 내용과 설명, 재치가 들어있다. 그러나 경험적으로 원저자보다 조금은 |
| = 다른 관점에서 더 잘 설명하는 저자들이 많으며 그들로부터 실전적인 경험을 |
| = 더 많이 얻을 수 있다. 어떤 때에는 원저자가 아닌 저자의 글을 읽고 나서 |
| = 원저자의 글을 잘 이해할 수 있게 되는 경우도 있다. |
| = |
| = 풍부한 지식을 얻고 실전적인 지식을 얻으려면 여러 권의 책 또는 웹 상의 |
| = 문서를 경험하는 방법 이외에는 없다. |
| = |
| = 리눅스를 사용하면서 질 좋은 내용은 문서 또한 프리 매뉴얼(Free Manual)의 |
| = 형태로 풍부하다는데 놀라지 않을 수 없었다. LDP |
| = (국내에서는 KLDP, http://kldp.org)와 같은 노력이 그러하다. PS(포스트스크립트) |
| = 문서로 되어 있는 매뉴얼들을 포스트스크립트 프린터가 없다 하더라도 |
| = 리눅스에서 고스트스크립트(ghostscript)라는 것을 이용하여 일반 프린터에서도 |
| = 예쁘게 찍어 놓을 수 있어 좋다. |
| = |
| = 물론 초보자에게는 별로 적합하지 않은 실전적인 매뉴얼들이다. 따라서 여러분이 |
| = 감당할 수 있는 문서만 출력한다. (지금은 상당히 많이 개선되었지만) 필자처럼 |
| = 출력광(print mania)이 되어 좋은 문서만 발견하면 “일단 찍어놓고 보자”는 |
| = 식의 사람들도 적지 않다. 사무실 한 쪽에 쌓여만 가는 깨끗한 출력 문서를 |
| = 보면 부담스러워진다. 이에 대해서는 여러분의 판단에 맡긴다. |
| = |
| = |
| = !! 3. 프로그래밍을 해야 하는 사람 |
| = |
| = 프로그래밍이 마냥 좋아서 시작하던 사람들은 언젠가 자연스레 |
| = “프로그래밍을 해야하는 사람”으로 지위 변신을 하게 된다. 학생에서 사회인이 |
| = 되었다는 말이다. 이제부터는 본격적으로 “지배받는” 프로그래밍이 시작된다. |
| = |
| = 어느 프로젝트 팀원에 속해 있다면 프로젝트 설계자가 아닌 이상 전체를 위한 |
| = 일부가 되어 유기적으로 움직여야 한다. 이 때 가장 중요한 것은 당연히 여러분 |
| = 자신의 개성과 창의성보다 서로 간의 교류와 협력이다. 프로그래밍 규칙이 완전히 |
| = 바뀌게 되었음을 의미한다. 재미있어 보이는가? |
| = |
| = 만약 주문에 따라 프로그래밍을 하는 경우라면, 기존 프로그래밍 성과에 대한 |
| = 고객의 신뢰, 신속, 약속 이행이 무엇보다 중요하다. 그 중 고객이 제일 중요하게 |
| = 생각하는 것은 약속 이행일 것이다. 약속한 시간과 구현하겠다고 하는 기능에 대한 |
| = 약속을 지켜야 한다. |
| = |
| = 이러한 부담 아래서 코딩해야 할 때에는 주어진 작업에 대하여 프로그래머로서의 |
| = 능력을 “준비해 둔 상태인가”가 중요하다. 코딩을 시작하면서 새로운 것을 배운다는 |
| = 것은 이미 실패(절반의 실패 또는 완전한 실패, 어찌 되었든 실패)를 예견한다. |
| = 데드라인까지 새로운 것을 배울 시간은 없다. |
| = |
| = 중간중간 기발한 아이디어와 디자인이 떠오를지는 몰라도 그것을 실현할 무기는 |
| = “이미 배워둔 언어와 현실 팁”뿐이다. “프로그래밍을 좋아하는” 단계에서 |
| = 충분히 배우고 실습하지 않았다면 고통의 나날이 시작될 것이다. |
| = |
| = |
| = !! 4. 가장 완벽한 상황 |
| = |
| = 가장 완벽한 상황은 프로그래밍을 좋아해서 시작했는데 공교롭게도 자기 주변 |
| = 작업에서 프로그래밍의 필요성이 있고 따라서 필요한 소프트웨어를 좋아서 |
| = 추진하는 상황이다. |
| = |
| = 어느 정도 언어도 충분히 많이 익히고 실전의 경험(코딩하고 디버깅하고 |
| = 코딩하고 디버깅하고……)을 쌓아 인간이라면 누구나 빈번하게 저지를 수밖에 |
| = 없는 문제를 피해 가거나 금방 눈치챌 수 있는 상태가 되기 바로 직전에 본업 |
| = 프로그래머로 뛰어든다. |
| = |
| = 좋아하는 일이 있고 좋아하는 일을 잘 하며 좋아하는 일을 통해 삶을 꾸려 |
| = 나갈 수 있을 때 가장 완벽하다고 생각한다. 그렇지 않을 사람이 있을까? |
| = |
| = 그러나 이런 완벽한 상황을 누리고 있는 프로그래머가 전 세계적을 얼마나 될까? |
| = 열악하다고 말하는 국내에는 도대체 이렇게 행복한 프로그래머가 있기는 있는 것일까? |
| = |
| = 현실 세계에서는 행복해지려는 찰나에 방해하는 요소들이 적지 않다. 따라서 |
| = 전투에서처럼 교두보를 하나씩 점령해나가는 것이 필요하다. |
| = |
| = 젊고 유능한 프로그래머가 되기 위해 그리고 행복한 프로그래머가 되기 위해 어떤 |
| = 것부터 시작해야 할까? |
| = |
| - ================================================================================<br> |
| - 프로그래머가 되고 싶다! |
| - ================================================================================ |
| = |
| + |
| + ! 프로그래머가 되고 싶다! |
| + |
| + |
| = 필자도 그러했지만 여전히 많은 젊은 친구들(필자가 어른이라서 내려 부르는 의미로 |
| = 부르는 것이 아니다. 우리 나이 또래는 친구다!)은 몇몇 매스컴과 사업상의 성공 |
| = 모델을 보고 그렇게 “성공적인 프로그래머”를 어렴풋하게 꿈꾸는 듯 하다. |
| = |
| = 만약 마이크로소프트 사의 빌 게이츠(Bill Gates)와 같은 사람을 모델로 선정했다면 |
| = 필자는 약간의 코멘트를 달지 않을 수 없다. |
| = |
| = 빌 게이츠는 “프로그래머”였겠지만 “프로그래머로서 성공”한 것은 아니다. |
| = 이 말이 프로그래머로서의 빌 게이츠를 깍아 내리는 것은 아니다. 하지만 동시에 |
| = 뛰어난 프로그래밍 능력을 갖추었기 때문에 성공했다고 “위험하게“ 말할 수 |
| = 없다는 것이다. 현실 세계에서 프로그래밍만 잘해서 금전적인 성공을 거둔 사례가 |
| = 있는지 의심스럽다. |
| = |
| = 성공적인 프로그래머, 따라서 더 이상은 프로그래머가 아닌(왜냐하면 프로그래밍할 |
| = 시간도 없는 비즈니스맨이 되어버리기 때문에) 성공적 인간이 되기 위해서는 |
| = 빌 게이츠나 기타 다른 사람처럼 프로그래머로서의 자질 이외의 알파 요인이 |
| = 있어야 한다. |
| = |
| = 예를 들어 사업 수완, 용병술 등은 다른 비즈니스 수업이나 비즈니스맨에게 들어야 |
| = 할 내용이다. |
| = |
| = 이 글은 “성공적인” 프로그래머가 되기 위해 프로그래밍 기술과 자신감 이외의 다른 |
| = 요소를 강조하기 위해 쓰고 있지 않다. 필자는 아직 그런 말을 할 경험과 자격을 |
| = 갖추지 않았다. |
| = |
| = 앞으로 “프로그래머로서 성공적”이라는 의미는 원하는 일을 잘 설계하고 가장 |
| = 효율적으로 그리고 즐겁게 프로그래밍 기술을 이용하여 원하는 소프트웨어를 만들 수 |
| = 있는 능력과 개성을 갖추었다는 사실을 뜻한다. |
| = |
| = |
| = |
| = !! 그래도 나는 프로그래머가 되고 싶다! |
| = |
| = 훌륭한 선택이다. 왜냐? 이 세상에는 재미있는 일로 가득차 있는데 그 중에서 다른 |
| = 것 못지 않게 재미있는 것이 프로그래밍이기 때문이다. 그리고 현실 세계보다 훨씬 |
| = 정직한 세계라는 사실에 매료되기도 한다. |
| = |
| = 글 뒤에서 안내하겠지만 화가가 그림을 그리기 위해서는 주체할 수 없는 창작의 |
| = 욕구를 받쳐 줄만한 그리기 기술(캔버스, 붓, 물감 사용법)이 필요한데 프로그래밍에서는 |
| = 프로그래밍 설계, 프로그래밍 언어가 그에 해당된다. 이 기본 기술을 익히지 |
| = 않으면(정확히 말해서 항상 익혀나가지 않으면) 창작 욕구는 표현될 수 없다. |
| = |
| = 여러분의 머릿속에 있는 아이디어는 어떤 식으로든 프로그램 소스 코드의 형태로 |
| = 표현되어야만 의미를 갖는다. 그냥 머릿속이나 또는 광고를 위해 있지도 않은 것을 |
| = 나올 것처럼 얘기할 때 그 소프트웨어를 Vaporware 또는 Dreamware라고 부른다. |
| = |
| = 프로그래머는 구체적인 결과물을 내야 하는 구체적인 활동의 인간이다. |
| = 따라서 프로그래머가 되겠다는 마음을 계속 간직하면서 다음 내용들을 잘 |
| = 익혀나가야 한다. |
| = |
| = |
| = !! 프로그래머는 정신적인 디자이너다 |
| = |
| = 필자가 단순 코딩을 해가면서 뼈저리게 느끼는 것이 바로 이 말이다. |
| = 프로그래머는 디자이너(designer)이기 때문에 디자이너여야 한다. |
| = 디자이너가 아닌 프로그래머는 단순 코드 입력 인력일 뿐이다. |
| = |
| = 프로그래밍의 시작은 항상 두뇌에서 시작하며 어떤 일인가를 어떤 논리적인 |
| = 순서대로 해야 한다는 가장 간단한 수준의 구상부터 확실하게 시작해야 한다. |
| = 아이디어를 떠올리는 방법은 특별히 배우지 않아도 누구나 만들어낼 수 있지만 |
| = 아이디어를 유지하는 일은 누구나 할 수 있는 일이 아니다. |
| = |
| = 아이디어가 나오면 필자는 적어둔다. 필자의 두뇌는 약간의 휘발성을 가진 |
| = 메모리이기 때문이다. 항상 가지고 다니는 아이디어 수첩에 적어도 좋다. |
| = 필자는 요즘 커다란 스케치북을 구입하여 그 안에 시원스럽게 도표를 그리곤 한다. |
| = 작업간의 관계를 그림으로 표현해도 좋다. 프로그램의 목표를 구체적인 표현으로 만든 |
| = 다음, 그 일을 해내기 위해 필요한 작업을 세분한다. 원도 그리고 화살표로 |
| = 원들을 잇기도 하고 옆에 부연 설명을 적기도 한다. |
| = |
| = 생각을 덜 하고 코딩에 달려들면 몸이 고생한다. 때로 풀리지 않은 문제는 |
| = 키보드 앞을 떠나 다시 디자인 수준에서 해결해야 할 때가 있다. |
| = |
| = |
| = !! 남의 코드를 많이 읽어봐야 한다 |
| = |
| = 베스트셀러를 내는 작가들중 책을 많이 읽지 않은 사람이 있을까? |
| = 좋은 프로그램을 만들기 위해서는 좋은 프로그램을 많이 사용해 보아야 한다. 인간의 |
| = 아이디어라는 것은 무(無)에서 만들어지지 않는다. 아이디어는 경험한 것 안에서 맴도는 |
| = 경향을 갖는다. 많은 경험의 축적만으로도 자동적으로 아이디어가 떠오르기도 한다. |
| = |
| = 전통적으로 프로그램의 소스 코드는 볼 수 없었으므로 프로그램의 외형만 경험할 수 |
| = 있었으나 리눅스를 비롯하여 오픈 소스 소프트웨어들이 많이 나오면서 풍부한 |
| = 소스 코드를 읽을 수 있는 훌륭한 여건이 만들어졌다. 이는 얼마나 다행인지 모른다. |
| = 이제 코드를 읽어 배우는 직접 경험이 많아져서 좀 더 다양하고 질 높은 소프트웨어들이 |
| = 나올 것이라 기대하고 있다. |
| = |
| = 아무리 짧고 어색한 코드라도 중요하다. 여러분의 해결책에 앞서 어떤 문제를 풀기 |
| = 위한 코드가 있을 때 그 코드를 우선 존경할 필요가 있다. 이 세상 그 누군가가 적어도 |
| = 나보다는 먼저 어떤 문제에 대한 해결책을 고민했고 최소한 나보다 먼저 실제 코딩에 |
| = 나섰기 때문이다. 항상 어려운 것은 개척 또는 선두주자이다. 중세 전쟁 영화를 보면 |
| = 병사들이 성벽에 사다리를 놓고 기어올라가는 장면을 볼 수 있다. 얼마나 많은 |
| = 병사들이 희생되는가? 난공불락의 요새처럼 보이던 성도 한두 명의 병사가 올라가기만 |
| = 하면 금방 함락된다. |
| = |
| = 남의 코드를 존경하며 마음에 들지 않은 부분이 있다면 개선해서 이용하면 된다. |
| = 이유를 막론하고 남이 보여주는 소스 코드 보기를 게을리하지 말자. |
| = |
| = 다음 호에는 가장 중요한 부분인 |
| = 프로그래밍 언어를 배우는 방법을 중심으로 보다 구체적인 이야기를 |
| = 하고자 한다. |
