제가 적은 글이 아닙니다.
그냥 맘에 들어서 아는 지인들끼리 공유나 해볼까 하고 번역한 겁니다. 따라서 오역이 있을 수도 있어요.
원 저자에게 허락도 안받고 했어요.
그냥 맘에 들어서 아는 지인들끼리 공유나 해볼까 하고 번역한 겁니다. 따라서 오역이 있을 수도 있어요.
원 저자에게 허락도 안받고 했어요.
11살때부터 프로그래밍을 시작해서 지금까지 프로그래밍과 기술들을 사랑해온 나. 이제 그동안 내가 배웠던 어렵고 쉬운 몇가지 교훈들을 적어본다. 여러분이 학교에서 프로그래머가 되기 위해 공부중이라면 이런 경험이 없을 수 있다. 그러나 여러분이 이 글을 통해 내 경험에서 더 많을 것을 배울 수 있었으면 하는 마음에 글을 쓴다.
아마도 시간이 지나면 내용을 바꿀 것이다. 아마도 더 많은 교훈이 있을 지 모르겠다. 20년동안 느낀 규칙들중 여기에 포함되지 않은 다른 규칙은 없다고 생각한다. :-)
지금까지 가장 내 기억에 남는 교훈들이다.
문제를 해결하는데 얼마나 오래 걸릴지 그 한계를 설정하라 - - 여기로 와라. 용서를 빈다. 나도 마찬가지로 이런 죄를 지은 적이 있다. 언젠가 한번은 어떤 문제를 플려고 8시간동안 모니터앞에 죽치고 앉아있는 개발자를 본적도 있다. 1시간, 30분 또는 15분 단위의 자신만의 시간표를 작성하라. 미리 정해둔 시간내에 문제에 대한 해결책을 알아내지 못했다면 그 문제를 풀어서 슈퍼코더가 되려고 하지 말고 다른 이에게 도움을 요청하거나 인터넷에서 비슷한 문제가 있는지를 살펴보라.
언어는 언어이고, 언어이다. - 시간이 지날수록 한 언어가 어떻게 동작하는지를 알게되고, 다른 언어들과 비슷한 점들을 알게될 것이다. 여러분이 선택한 언어를 사용해서 적정수준의 "편안한 수준"을 제공해야 하고, 효율적(이고 깔끔한) 코드를 만들 수 있어야 하고, 무엇보다도 프로젝트 등등에 적합한 언어여야 한다.
"디자인 패턴"을 적용한 애플리케이션에 지나치게 목매달지 마라. - 때로는 싱글톤 패턴이나 페시드(facade)패턴을 사용하는 것보다 간단하게 알고리즘 작성하는게 더 쉬울 수 있다. 오히려 대부분의 경우 깔끔하고 남들이 쉽게 이해할 수 있는 코드를 짜는 것이 좋다. :-)
항상 코드를 백업하라. - 나도 어렸을 적에 하드디스크가 완전히 망가지는 바람에 코드를 날려먹고, 어떤 일이 눈앞에서 벌여졌는지를 알고 경악을 금치 못했던 적이 있다. 한번은 마감시한을 정해둔 까탈스러운 고객을 위한 프로그램을 개발하는데 데이터를 백업하지 않았고, 그 데이터가 내일 필요하다고 한다면...이럴 경우에 소스코드/버전 관리 시스템을 잘 적용할 수 있다.
여러분은 프로그래밍에서 최상이 아니다. 프로그래밍과 함께 살아가자. - 나는 언제나 프로그래밍에 대해 제법 많은 것을 알고 있다고 생각한다. 그러나 언제나 여러분보다 더 나은 사람이 있다. 항상... 그들로 부터 배우자.
더 많이 배우는 것을 배워라 - 앞에서 이야기했지만, 나는 늘 손에 컴퓨터나 프로그래밍에 관한 책이나 잡지를 가지고 있다.(내 친구들에게 물어보면 확인해 줄 것이다.) 정말로 수많은 기술들이 존재하고, 어떤 기술이 있는지를 살펴보는 것만으로도 충분히 직업이 될만큼의 작업이다. 그러나 여러분이 새소식을 받을 수 있는 똑똑한 방법이 있다면 매일매일 새로운 기술에 대하여 배울 수 있다.
변화는 늘 존재한다. - 여러분이 가진 기술지식 또는 프로그래밍 지식을 주식처럼 다루어야 한다.: 다각화하라. 특정 기술에 지나치게 안주하지 마라. 특정 언어나 기술의 지원이 충분하지 않다면 그 순간이 바로 여러분이 공부를 시작해야 하는 시점이며, 여러분의 이력서를 갱신해야 하는 출발점이기도 하다. 나를 계속 이끌어준 어떤 경험 규칙이 있냐고? 적어도 두세개 정도 언어를 알아두어라. 그래야 한 언어가 사장되어버리더라도 다른 새로운 기술을 익힐 동안 다른 언어가 대비책이 될 수 있다.
신입을 지원해 줘라. - 신입/초급 개발자에게 좋은 프로그래밍 가이드라인과 기법들을 교육시켜보라. 여러분도 모른다... 혹시 여러분이 승진될 수 있고, 개인적으로 신입들을 다음 역할에 맞게 교육시키고 준비시켰다는 자신감을 더 느낄 수도 있다.
알고리즘을 단순화하라. - 미치광이처럼 코드를 작성하라. 그러나 일단 일을 마쳤다면 코드로 다시 돌아와서 최적화하라. 이곳 저곳에서 코드를 개선하면 오랫동안 더욱 더 행복하게 만들어줄 것이다.
코드를 문서화 하라. - 웹 서비스 API를 문서화하든 간단한 클래스를 문서화하든지 간에 여러분이 문서화를 진행해 보라. 내가 작성한 코드에 너무 주석이 많다는 이야기를 들은적도 있지만, 사실 나는 자랑스럽게 생각한다. 코드 3중마다 주석한 줄 추가하는데에는 1초면 된다. 금방 이해하기 어려운 기법을 사용했다면 거침없이 주석을 많이 달아야 한다. 주석이 없으면 대부분의 아키텍트나 백업 개발자, 지원팀들이 여러분의 작업이 적절하게 되었는지를 이야기하지 못하게 되는 원인중 하나가 된다.
테스트, 테스트, 테스트 - 나는 블랙박스 테스트를 무지 좋아하는 사람이다. 일상적인 업무를 끝냈다면 이제 "확인 도장"을 찍을 시간이 되었다. 품질 보증팀이 있다면 여러분의 코드에 있는 오류들에 대하여 프로젝트 관리자들보다 QA팀과 더 많은 이야기를 나눌 수도 있다. 코드를 꼼꼼히 테스트하지 않았다면 작성했던 코드보다 더 많은 수정작업을 해야할 수도 있다. 아마도 평판에도 나쁜 영향을 미칠 것이다.
매번 성공을 자축하라. - 골치아픈 문제를 엄청난 프로그래밍 기법으로 처치해 버린 다음 악수를 하거나, 하이파이브를 하거나 심지어 행복에 겨운 춤을 추면서 자축하는 많은 개발자들을 보아왔다. 모든 이들은 인생에서 찬란한 시기가 있다. 어떤 개발자가 행복한 표정을 지으면서 여러분에게 와서 그가 작성한 특별한 코드를 보여줬다고 하자. 여러분이 이미 100번넘게 그런 코드를 보아왔더라도 101번째로 그 개발자의 성공을 축하해주라.
자주 코드 리뷰 시간을 가져라.- 프로젝트별로나 개인별로 진행하라. 회사에서는 무엇인가를 작성하고나면 어떻게 잘 작성했는지 코드를 살펴보아야 한다. 리뷰하는 것을 사람들이 여러분의 코딩 스타일을 호되게 비판하는 것처럼 바라보지 마라. 건설적인 비판으로 받아들여라. 개인적으로는 코드를 리뷰하면서 항상 "어떻게 하면 더 잘할 수 있었을까?"라는 질문을 한다. 이렇게 하다보면 학습 속도도 점점 더 빨라지고, 여러분은 더 나은 프로그래머가 될 것이다.
여러분이 작성한 코드를 회고해보라. - 예전 코드를 바라보는 두가지 방식은 "이런 코드를 진정 내가 작성했단 말인가"와 "이런 코드를 진정 내가 작성했단 말인가"이다. 첫째는 여러분이 더 좋게 작성할 수 있었는데 하는 아쉬움의 표현이다. 예전 코드를 훨씬 더 좋고 깔끔하게 고칠 수 있었는데 하면서 놀랄지도 모르겠다. 아마 아예 제품 전체를 더 좋게 만들수 있을지도 모르겠다. 두번째는 성취와 감탄이다. 개발자들은 남들이 정말 좋았다고 인지하는 자신이 작성한 코드 성과를 한두개 정도는 가지고 있다. 다시한번 말하지만 여러분의 뛰어난 코딩 능력에 바탕을 두고 앞으로 더 나은 제품이나 아이디어를 끌어낼 수 있는 예전 코드나 프로젝트에서 취할 것은 취하는 온고지신의 자세를 가져라.
유머는 필수요소 - 20년동안 개발해오면서 적절한 유머 센스를 가지고 있지 않은 개발자를 만나본 적이 없다. 실제로 이 바닥에서 유머는 필수요소이다.
모든 것을 다 알고 있는, 소유욕이 강한, 경험이 없는 개발자를 주의하라. - 이런 유형의 개발자들을 만난다면 괴로울 것이다. 모든것을 다 알고 있다고 생각하는 개발자들은 팀원으로 함께 일하는 것이 아니라 여러분의 일을 가로챌것이다. 방어적 코더는 작성한 코드를 다른 사람과 공유하려하지 않을 것이고, 경험이 없는 코드는 10분마다 여러분에게 개발이 완료된 코드인지 아닌지를 물어볼 것이다.
결코 간단한 프로젝트는 없다. - 친구들이나 가족들이 나에게 '나를 위해 이런거 금방 좀 만들어줘봐'라고 이야기한다. 프로그램이나 웹사이트를 빨리 만들려면 이해 당사자들이 모두 인정할 수 있는 어떤 것을 완성하기 위하여 쌍방이 수립한 계획이 있어야한다. 어떤 사람이 시작시점에 마이크로소프트 엑세스로 된 3페이지짜리 웹사이트를 요구했다면 어느순간 SQL서버에 게시판에 맞춤형 CMS(콘텐츠 관리 시스템)까지 갖춘 15페이지짜리 웹사이트가 될 수 있다.
그 어떤 것도 당연하다고 생각하지 마라. - 간단한 프로젝트를 하고 있다면 어떤 부분은 쉽게 끝낼 수 있을 것이라 생각할 수 있다. 결코 한순간도 그렇게 생각하지 마라. 이미 여러분에게 클래스나 콤포넌트 또는 이미 작성된 코드가 있고...그것이 꼼꼼히 테스트되었고...기존 프로젝트에 사용된 제품이라면 몰라도, 그렇지 않다면 쉬울 것이라고 생각하지 마라.
소프트웨어는 영원히 끝나지 않는다. - 견습 프로그래머중 한사람이 나에게 소프트웨어는 절때 끝나지 않고, 다만 '임시로 완료되었을 뿐'이라고 이야기를 한 적이 있다. 지당한 말이다. 여러분이 작성한 프로그램을 고객이 여전히 건재하게 사용있고, 변경사항이 있다면 이를 여전히 수정해야 한다. 이런건 안좋은 일이 아니다. 여러분이 계속 일을 할 수 있게 되는 것이다. :-)
인내는 궁극의 미덕이다. - 고객, 친구, 가족이 컴퓨터를 사용하는 것을 보면 짜증을 내면서 컴퓨터를 손으로 치거나 성을 내면서 나가버리는 것을 보았다. 나는 언제나 "컴퓨터가 마음대로 동작한게 아니고 당신이 제어하는데로 움직인거라고"라고 이야기했었다. 여러분은 컴퓨터 프로그램을 개발하면서 어느 수준정도의 인내를 가져야 한다. 프로그래머가 무엇을 잘못하고있는지를 빨리 이해하면 할수록 컴퓨터의 관점에서 떨어져서 보면서 "아~ 왜 이렇게 되는지 알겠다"라고 말할 수 있게 될 것이다.
아무쪼록 몇사람들에게 내가 느꼈던 배움들이 어떤이에게 영감을 주었거나 기쁨을 주었으면 좋겠다.
'2.1 기본' 카테고리의 다른 글
| 20/20: 20년동안 배운 20가지 프로그래밍 배움 (2) | 2010/11/19 |
|---|---|
| [정리] 류한석님 - 소셜미디어와 클라우드 (0) | 2010/11/15 |
| 우씨...알약.... (2) | 2010/11/12 |
| 다음 로드 뷰 360도 회전 구현. (0) | 2010/01/15 |
| 미국 InfoWorld가 선정한 2010 엔터프라이즈 신기술 Top 10 (0) | 2010/01/13 |
| 투철한 보안의식, LinkedIn (0) | 2009/07/28 |
