김용유닷컴

1. 정보모음에 소홀히 하지 말고 설명서를 읽음에 게을리 하지 말지어다. 오늘 필요 없는 정보는 내일 필요하리라. 가장 가치 있고도 저렴한 지식은 책 속에 있느니라. 서점과 동료의 책꽂이에 무엇이 꽂혀 있는지 때때로 살피어라. 무심코 흘렸던 종이 한 장이 너의 근심을 풀어 주었으리라. 설명서는 충분히, 꼼꼼히 읽을지어다. 모든 의문은 설명서를 안 보는데서 생기니라. 그렇더라도 모두 다 읽을 필요는 없느니라. 많은 정보가 능사는 아니니라. 정보의 가치를 찾는 법부터 배우라. 세상엔 너무나 많은 자료와 정보가 넘쳐난다.

알알이 모두 끌어 모을 생각을 하기 보단 정보를 하나로 꿰는 법부터 먼저 배우는것이 너의 근심에서 쉽게 벋어나게 하는 방법이 되리라. 일을 시작하기전에 필요한 정보를 꼼꼼히 먼저 챙기는 법부터 배워라. 너희는 먼저 개발 의뢰서를 꼼꼼히 읽을지어다. 만약 개발 의뢰서가 없다면 발주자에게 요구할 지어다. 개발 의뢰서 없는 프로그램은 존재하지 않으니라.


2. 너의 PC가 안전하다고 믿지 말지어다. 5분 후에 정전이 되고 내일 너의 하드가 맛이 가리라. 그러니 너의 소중한 소스코드는 정기적으로 여러 군데에 단계별로 백업해 두어라. PC는 평상시엔 안전하다. 그런 실수를 저지르는것은 네자신이거나 아니면 외부적인 요인에 기인한다. 항상 백업을 철저히 해두며 백업에 백업까지도 챙겨두라.그리고 백업을 했다면 리스트를 작성하라. 쓸데없는 백업은 백해 무익하나니 리스트를 항상 유지할 지어다. 너희는 노트를 옆에 끼고 살 지어다. 노트는 너의 생명이며, 너희가 기억하지 못하는 모든것을 상기시켜 줄지어다.

3. 변하는 수를 다룰 때에는 늘 조심할지어다. 정수가 절대로 그 한계를 넘지 않으리라 가정하는 것은 어리석음이라. 127 ,-128 ,255 ,32767 ,-32768 ,65535, 이 숫자들을 너의 골수에 새기어라. 0.0은 0이 아니니 실수는 원래부터 결코 정밀하지 않느니라. 부호 없는 것과 있는 것을 어울리거나 정수끼리 나눌 때에는 늘 조심하여라. 변수는 프로그램의 근원, 프로그램을 작성할때 가장 유의 할것이 바로 변수의 이름 짓기니라. 이름보고도 성격을 알 수 있게 해두라. 그러나 변수는 성질이 드러우니 변수에 성격을 부여할때는 조심스럽게 할지어다. 너희는 코딩하기 이전에 계획을 할 지어다. 이는 프로그래머가 코더가 아닌 것이니라.

4. 무슨 일을 반복시킬 때에는 처음과 끝에 유의할지어다. 너의 컴퓨터는 1보다는 0을 좋아 하니라. 배열의 첨자가 그 범위를 넘지 않을지 손 댈 때마다 따져 보아라. 수식에 1을 더하거나 뺄 때에는 늘 긴장하라. 너의 프로그램은 단지 한 번 덜해서 틀리고 한 번 더해서 다운되느니라. 프로그램을 작성할땐 계산, 판단, 비교를 그 모든걸 컴에게 되도록 맡기지말라. 네손으로 미리 계산하고 그 결과를 사용하는 방법이 최선이니라. 컴퓨터는 의지가 없나니 네가 잘못하든 잘하든 아무런 상관이 없느라. 너희는 머리가 악세사리가 아님을 기억하고 항상 생각하고 항상 노트에 적을 지어다.

5. 항상 모든 경우의 수를 고려하고 섣불리 생략하지 말지어다. 절대로 없어 나지 않을 일은 반드시 일어나고, 가장 드물게 일어날 일이 가장 너를 괴롭히리라. 그러하니 언제나 논리에 구멍이 없는지 꼼꼼히 따져 보고, if를 쓸때에는 else 부터 생각하라. 논리적인 오류는 성급함에서 생기나니 처음엔 항상 원리와 원칙을 지키라. 생각은 네가 하라 그리고 그 결과를 컴에게 시켜라. IF를 쓰기전에 규칙을 세우라. 먼저 IF의 결과에대한 규칙부터 세우고 따져라. 그리고 논리적인 계산을 IF문장안에서 하지 말라. 하나의 IF문장속에 수많은 논리연산은 버그의 원인이니라. 어느 정도의 프로그램에 대한 윤곽이 잡히면 프로토 타입을 만들지어다. 프로토타입은 프로그램에 대한 시뮬레이션이며 발주자의 요구를 빨리 수용 하는 방법이니라.

6. 함수 안에서 매개 변수값은 결코 믿지 말지어다. 지금 그 매개 변수가 결코 가질 수 없다는 값을 내일부터는 가지리라. 그러하니 매개 변수 값이 올바름을 항상 검사할지어다. 그렇더라도 처리 속도가 문제가 되는 경우는 예외이니라. 함수도 하나의 독립적인 프로그램이란것을 잊지말며, 네가 프로그램을 작성할땐 모든 함수가 돼도록이면 독립적으로 돌아가도록 할지어다. 함수의 매계변수는 항상 그옆에 작은 컴맨트와 초기화를 잊지말라. 처음부터 속도문제를 생각하지 말라. 모든 루틴을 최적화 할순 없다. 전체 프로그램중에 단 20%가 전체 실행시간에 80%를 점유한다. 프로토 타입에대한 발주자의 의견을 꼼꼼히 들을 지어다. 이는 발주자에 대한 신뢰도의 척도니라.

7. 오류를 알려 주는 기능은 있는 대로 모두 활용할지어다. 컴파일러의 경고는 모두 켜두어라. 경고는 곧 오류이니라. 오류를 알리는 함수의 결과를 확인하지 않는 우를 범하지 말지어다. 모든 파일 입출력과 모든 메모리 할당은 조만간 실패할 것이라. 컴파일러가 모든 경고기능을 동원해도 알려주지 않는 것은 많다. 중요한 건 오류가 생기기전에 규칙을 지켰는지 생각하라. 파일의 입출력과 메모리의 항당은 항상 쌍으로 생각해서 열었다면 닫아주고 활당받았다면 돌 려주라. 프로그램의 매인턴앤스를 게을리하지 말지어다. 이는 프로그램 만드는 일 보다 중요한 일이니라.

8. 한 번의 수정과 재컴파일만으로 연관된 모든 것이 저절로, 강제로 바뀌도록 할지어다. 어떠한 것을 수정했을 때에 연관된 것이 따라서 변하지 않는다면 그것이 곧 벌레이니라. 컴파일러로 하여금 매개 변수 리스트를 완전하게 검사하도록 하고 언젠가 손대야 하거나 따라서 변해야 하는 수치는 전부 매크로로 치환하며, 형 정의를 적극 활용하여라. 이미 완벽한 루틴을 손대지 말라. 프로그램이 무너지는 가장 첫번째이유는 도미노 현상 때문이나니 한번의 수정과 재컴파일로 쓸데없는것을 손대게 하지 말라. 컴파일러가 매개변수 리스트를 챙기지 말게 하라. 프로그램에 들어가기 전엔 미리 함수명과 매개변수 리스트를 만들어라. 너희는 프로그램의 도큐멘트를 만드는일에 게으르지말지어다. 이는 사용자가 너의 프로그램에 대해서는 바보이기 때문이니라.

9. 사용자가 알아서 잘 써 주리라고 희망하지 말지어다. 너의 프로그램은 항상 바보만이 쓰느니라. 사용 설명서를 쓸 때에는 결코 빠뜨리지 말아라. 빠뜨린 만큼 사용자는 너를 괴롭힐 것이니라. 사용자는 나쁜놈이다. 쓸데없는짓을 잘한다. 무식하다. 인간성도 더럽다. 대부분이 바보며 가끔 똑똑한 사람도 있는데 그 놈은 더 하다.모든것을 설명하지 말며 온갇기능을 가진 하나의 프로그램을 작성하려 들지 말라. 많은 기능이 필요한 프로그램은 나누어서 작게 따로 만들어주라. 너희는 공부하는데 게으르지 말지어다. 자고나면 새로운 하드웨어와 새로운 소프트 웨어가 나오기 때문이니라.

10. 매사에 겸손하고 항상 남을 생각할지어다. 가장 완벽한 프로그램일수록 가장 완벽하게 숨은 벌레가 있느니라. 네가 이 세상 최고의 프로그래머라고 떠들며 자만할 때, 옆집 곳간에서는 훨씬 더 뛰어난 것을 묵묵히 만들고 있느니라. 아무렴 프로그래밍은 혼자 잘나서 할 게 아니니, 너로 인해 다른 사람들도 더불어 잘 되면 그 얼마나 좋은 것이냐. 프로그래머는 논리적으 로 생각하여야 하지만 프로그램은 비논리적으로 작성하라. 프로그래머가 경지에 들면 누가 누가 잘하는지 알수가 없는 법, 또한 프로그래머로서의 '무지'에 대해서 잊지마라. 프로그래머의 '무지'는 생략하고, 선택하고, 단순화시키고, 명백하게하는 것이니라. 항상 새로운 아이디어와 새로운 생각으로 무장하라. 그리고 나누라 나누는곳에 기쁨있나니 너희는 모든 프로그램에 대해서 위의 프로시줘를 따를 지니라. 내용출처 : [기타] 인터넷 : http://www.beginninglinux.wo.to/

[개발자의 마음 가짐세]

항상 프로그래밍에 대해서 열린 마음(Open Mind)을 가져라. 새로운 아이디어를 거부하는 것은, 개발 능력 발전에 매우 유해한 행위이다.

자만심을 죽여라. 자만심은 어느 정도 경력이 있는 고참 개발자에게 가장 나쁜 것이다. 자만심은 자기 파괴적이며, 팀 이익을 위배한다. 당신이 어떤 개발 능력을 가지고 있던 간에, 당신보다 우수하지는 못할지라도, 당신만큼 뛰어난 다른 개발자들이 여럿 있다는 사실을 명심하라. 그런 개발자들은 자신만의 특수한 기술을 가지고 있지만, 당신의 개발 실력에 찬사를 표시할 것이다. 만일 당신이 자만심을 고수한다면, 다른 팀원(혹은 다른 개발자)들이 형편없다고 격하시키면서 그 자만심을 유지하려 할 것이다. 특히 당신이 팀장(Team Leader)이라면 더욱 그러할 것이다.

자만심이 강한 팀장은, 대부분, 팀원(혹은 다른 개발자)들을 교육하기를 꺼려하고, 팀원(Member)들을 도우려 하는데에도 인색하다. 단지 팀원들은 모조리 바보다라고 생각한다. 실력이 뛰어난 팀원들을 자신의 경쟁상대로만 간주하고, 거리를 멀리 하려 한다. 모든 팀에는 어느 정도 이런 유형의 행위가 발생한다. 팀장과 팀원간의 이런 특성을 깨닫는 것이, 좋은 팀을 만드는 첫걸음이다.

만일 그러하지 않았다면 다음과 같은 목표를 세워라.

1. 나의 팀을 더 뛰어나게 만들어라. 팀원들이 일을 잘하면, 결국 나도 잘하는 것이다.(팀장으로서의 능력이 뛰어남을 인정받게 되는 것이다)

2. 고참의 정도나 입사 기간이 아니라, 개발자들을 공로(성과)로 경쟁하게 하라.

[동료 코드 리뷰(Peer Review)]

동료들의 코드를 정기적으로 리뷰하라. 다른 팀원들이 당신의 코드를 리뷰하게 하는 것 뿐만 아니라, 당신 또한 다른 팀원의 코드를 리뷰해야 한다.

다른 사람의 코드를 봄(review)으로 해서, 더 나은 코딩 방법을 자주 찾을 수 있을 것이다. 당신이 비록 고참의 위치에 있다해도, 다른 사람들의 코드를 보는 것은, 다른 방법을 찾아내는 것만큼이나 유용하다.

다른 사람의 코드를 보는 것을 필수적으로 행하라. 종종 다른 사람의 시야가 당신이 잊은 무엇을 찾을 수 있으며, 다른 방법을 제시할 수 있고, 실수를 찾을 수도 있다. 때로 당신은 특별한 작업에 시달려서 매우 침체될 수 있으며, 이 때문에 다른 대안을 간과하는 경우가 발생한다.

그 작업과 거리가 먼 사람이 코드를 리뷰함으로써, 문제를 단순화하고 더 빠르고 좋은 방법을 찾을 수 있는 경우가 자주 있다.(이 말은 때로는 다른 사람의 시야가 나보다 더 해결책을 잘 찾아낼수도 있다는 것이다. 바둑이나 장기에서, 실제 대전자보다 관전하는 사람이 훈수를 더 잘 한다는 말과 비슷한 의미이다).

고참 개발자는 다른 사람에게, 심지어 신참 개발자에게라도, 자신의 코드 보여주기를 습관화할 필요가 있다. 다음과 같은 두가지 이유 때문에 그러하다.

1. 진행중인 작업과 다소 거리가 있는 다른 사람을 위해 코드 리뷰를 위해서
2. 코드 리뷰어 교육을 위해서

결국 모든 코드 리뷰어들은 팀원들이기 때문이다. 당신이 팀원들을 더 잘 교육할 수록, 당신 자신의 일에 더 몰두할 수 있으며, 더욱 고차원적인 일을 할 수 있는 여유가 생길 것이다.

[항상 배울게 있다]

매우 경력이 화려하고 뛰어난 개발자라해도, 다른 사람에게서 뭔가 배울 것이 항상 있다. 나는 모든 것을 다 알고 있다 혹은 나는 어떤 다른 개발자보다도 뛰어나다고 스스로 단정을 내려버리는 것 만큼, 당신의 경력과 개인적 발전에 저해되는 행위는 없을 것이다.