루키의 보석함

프로젝트가 실패하는 가장 큰 요인은 바로 발생할 수 있는 문제점들을 드러내서 함께 논의하지 않고 나중에 해결하면 되겠지... 하는 안일한 생각으로 방치하기 때문이지 않을까 합니다. 그래서 이러한 문제점을 체계적으로 관리할 수 있는 위험관리에 대해서 정리해보려고 합니다. 위험관리를 포함한 품질관리와 관련된 규격으로는 TL 9000이 있습니다. ISO 9000이란 규격은 많이 들어 보셨을 텐데요.. TL 9000은 ISO 9000에 비해 IT 분야에 특화되어 있고, 품질기획/프로젝트계획/구성관리계획등 계획에 초점을 맞추고 있습니다. Telecommunication Leader 9000의 약어로 QuEST 포럼에서 ISO 9001을 기반으로 1999년 제정했으며, IT 분야의 특성에 따라 하드웨어/소프트웨어/..

Don't call me names! 언뜻 보면 "내 이름을 부르지 마라" 일 것 같지만, 실제 의미는 "욕하지 마라", "약올리지 마라" 라는 뜻으로 사용되는 문장입니다. names가 복수가 아닌 단수형인 name으로 사용되었다면 이름이라는 의미 그대로 쓰였겠지만, 복수가 되면서 여러개의 이름 즉, 별명으로 보기 때문에 위와 같은 뜻이 되었을 거라고 합니다. 이름이라는 것은 하나의 고유한 의미를 가져야 합니다. 그리고 이름을 지어준다는 것은 그 객체(물체이건 상황이건)에 생명력을 불어넣는 계기가 됩니다. 빅무(Big Moo)라는 책에 나오는 이야기 인데요.. 뉴턴이 중력을 발견해서 유명해진 것으로 알고 있지만, 실제로 뉴턴이 발견한 것은 미적분과 반사 망원경이라고 합니다. 뉴턴은 미적분과 연금술 연구에..

바라바시가 쓴 링크라는 책에서는 웹에서의 visibility에 대해 이야기 하고 있습니다. 웹에서의 visibility(가시성)의 척도는 바로 링크의 개수이다. 당신의 웹페이지로 들어오는 링크가 많으면 많을수록 그것은 가시적이다. 웹에서의 visibility는 매우 중요하죠.. 만약 내 페이지에 대한 링크가 전혀 없다면, 아무도 제 블로그를 찾아오지 않을 테니까요.. 다음으로 서점에 가서 책을 살 때 여러분은 어떤 것을 중점적으로 보나요? 물론 상품평이 좋고, 유명한 책을 고르겠죠.. ^^ 저의 경우는 글자 크기와 폰트를 봅니다. 책을 읽는데 부담이 없어야 하기 때문이죠.. 어떤 분은 그림이나 표가 많은 책을 산다고 합니다. 글로 주절주절 적어놓은 것보다 하나의 그림이 더 많은 이야기를 해주고 있으니까요..

요즘 애자일 방법론이나 XP(eXtreme Programming)가 프로젝트 관리에 있어 많은 관심을 받고 있습니다. 기존의 폭포수 모델 보다는 반복을 통해 보다 빠른 피드백이 가능하고.. 자동 배포, 자동 테스트를 통한 개발 생산성 향상.. 짝 프로그래밍을 통한 프로그래밍 효율성 증대.. 그리고 주 40시간에서 16시간 근무로의 변경.. 정말 매력적인 요소가 많습니다. 특히 야근에 찌들어있는 개발자들에게는 환상적인 요소지요. 그런데 제가 이런 부분들을 적용하면서 느끼는 점이 있는데요.. 개발자 스스로 입맛에 맞는 것만 취하고 나머지는 버린다는 점입니다. 대표적인 것이 주 16시간 근무와 같은 것인데요.. 이것의 기본 개념은 40시간에 일할 내용을 우리는 16시간이면 처리한다는 겁니다. 그리고 남는 시간..

언제부터인지 모르지만 평생 학습이란 말이 보편화되었습니다. 그만큼 이제 공부라는 것은 학창시절로 끝이 아니라, 사회생활을 하면서도 지속되어야 하는 것이 되어 버린 것이죠.. 오죽하면 일과 공부를 병행하는 셀러던트라는 신조어가 나오기도 했습니다. 지난번 포스팅인 변화해야 산다. 에서 이야기 했듯이 프로그래밍 분야에서도 끊임없는 자기개발이 중요한 요소인 것이 사실입니다. 그렇다면, 프로그래머들은 어떻게 평생 학습을 해 나가야 할까요? 1. 꾸준히 해야 한다. 일반 수험생들에게 항상 하는 이야기이지만, 벼락치기는 전혀 도움이 안됩니다. 프로그래밍과 같은 분야에서도 마찬가지입니다. 지금 하는 공부는 당장 필요할 수도 있지만, 향후 몇년 후에 더 가치가 있을 수도 있는 겁니다. 꾸준히 그리고 천천히 계획을 가지고..

개발자로서 살아가는 것은 정말 쉬운 일이 아닙니다. 왜냐하면 끊임없이 변해야만 하기 때문이니까요.. 보통의 직업은 한번 익힌 기술을 가지고 어느정도는 평생 먹고 살수가 있습니다. 물론 그들도 끊임없이 자기 발전을 위해 노력하는 면은 있을 겁니다. 그러나 우리 개발자만큼은 아닐거라고 생각합니다. 끊임없이 나오는 새로운 용어와 기술들, 발전하는 하드웨어, 진보하는 플랫폼, 여기에 새로운 언어들까지.. 새로운 것을 배워서 2~3년 써먹다 보면 어느덧 구석기 시대의 기술이 되어버리는 느낌이라고나 할까요? 변하기 위해서는 끊임없이 배워야 하지만, 의외로 개발자들은 변화에 익숙하지 않은 것 같습니다. 새로운 것을 받아들이는 것을 두려워하기보다는 귀찮아하는 면이 많은 것 같습니다. 지금 기술로도 충분한데.. 왜 그걸..

리펙토링을 실제로 어떻게 수행하는지.. 마틴 파울러(Martin Fowler)의 리펙토링 책에 나온 내용을 요약합니다. 여기에 정리한 내용은 인덱스 정도로 활용하시고.. 실제 리펙토링을 위한 예제나 자세한 설명은 책을 참고하시기 바랍니다. 1. 메소드 정리 (Composing Methods) Extract Method (136) 그룹으로 함께 묶을 수 있는 코드 조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다. Inline Method (144) 메소드 몸체가 메소드의 이름 만큼이나 명확할 때는, 호출하는 곳에 메소드의 몸체를 넣고 메소드를 삭제하라 Inline Temp (146) 간단한 수식의 결과값을 가지는 임시변수가 있고, 그 임시변수가 다른 리펙토링을 하..

리펙토링을 하려면 소스 코드 속의 나쁜 냄새를 맡을 수 있어야 한다고 합니다. "리펙토링"이란 책에서 켄트 벡(Kent Beck)과 마틴 파울러(Martin Fowler)가 이야기한 코드 속의 나쁜 냄새에 대해 정리해 보려고 합니다. 중복된 코드 (Duplicated Code) - 동일한 소스가 여기 저기 사용된다면 반드시 리펙토링을 해야 한다고 합니다. Extract Method (136), Extract Class (179), Pull Up Method (370), Form template Method (393) 긴 메소드 (Long Method) - C 프로그래밍부터 시작해서인지 절차적 프로그래밍에 익숙한 경우, 하나의 메소드에서 모든 일을 처리하는 경우가 종종 있습니다. 긴 메소드는 쪼개야 한다고..

프로그래머들은 한번쯤 리펙토링이라는 것을 들어봤을 겁니다. 리펙토링이 좋다는 것은 익히 들어 알겠는데 실제로 못하는 경우가 대부분입니다. 왜 그럴까요? 우선, 리펙토링이 무엇이고 어떻게 하는 것인지 모르기 때문인 것 같습니다. 솔직히 저도 리펙토링 관련 책을 이번에 읽어보기는 했지만, 아직도 어떤 경우에 리펙토링을 해야 하는지 느낌이 확 오지는 않습니다. -.- A->B로 변경하는 것이 설명되어 있으면, 바로 B->A로 바꾸는 것도 설명되어 있습니다. 즉, 경우에 따라 적용하는 리펙토링이 다르다는 것인데.. 이건 경험이 필요한 것 같습니다.~ 끊임없이 생각해보고 변경하다보면 어떤 것이 올바른 리펙토링인지 알수 있지 않을까 합니다. 다음으로는 리펙토링을 하고 있으면, 윗분들은 아무것도 하지 않고 있다고 생..

프로젝트를 진행할 때, 현업에서 사용하는 방법론은 여러가지가 있습니다. 방법론!! 몇몇 사람들 특히 개발자들은 방법론은 쓸데없는 것이고 개발에 전혀 도움이 되지 않는다고 이야기 합니다. 저 역시도 RUP, 마르미, 이노베이터 등의 방법론을 토대로 프로젝트를 진행해 본 경험이 있습니다만, 솔직히 방법론이 무용지물이라는 생각을 해본 적이 꽤 있습니다. 이유는 바로 방법론에 맞추어 개발하고 산출물을 만드는 것이 아니라, 프로젝트 완료 시점에 방법론의 산출물을 한꺼번에 작성하거나 초기에 대충 작성해 놓고 나중에 한꺼번에 변경하는 것이 문제가 되는 것이었습니다. 그러다보니 오히려 방법론이 개발팀에 있어서는 짐이 되는 것이죠.. 또, 방법론은 모든 프로젝트를 염두에 두고 만들어 놓은 것이므로.. 프로젝트의 특성에 ..