컴퓨터, 독서, 학습, 그리고 사람

모바일 시장이 발전하면서 개인도 모바일 App을 만들어서 돈을 벌 수 있게 되었습니다. 그러나 제대로 된 서비스를 만들려면 어떠한 역할들이 필요할 지 한번 정리해 봤습니다. 1. 기획 (Planning) - 새로운 서비스/시스템을 기획 - 일반적인 아이디어를 보다 실현 가능하도록 구체화 함 - 서비스 기획안, 화면 구성 방안 및 사용자 매뉴얼 등을 작성 독서량이 많아야 한다. (다양한 분야의 도서를 읽어야 함) 기존의 서비스를 많이 사용해 봐야 한다. 기획하려는 분야의 전문가가 되어야 한다. 좋은 아이디어를 선별할 수 있는 판단력이 있어야 한다. 기획하는 서비스에 대한 시장 조사 능력이 있어야 한다. 2. 디자인 (Design) - 디자인은 단순히 그림을 그리는 것이 아님 - 디자인은 해당 서비스의 이미..

지난 글에서 프로젝트 성공 요인 중 변경관리, 희의관리, 이해관계자, 변화관리에 대해서 살펴봤습니다. 이번에는 이슈화, 리스크관리, 인적자원, 현실과 지표의 괴리에 대해서 알아보겠습니다. 다시 한번 출처를 언급하면 2004년 월간 시사컴퓨터에 기고된 천장락 교수님의 글을 정리해서 옮겨놓은 것입니다. 5. 사소해 보이는 문제도 '이슈화' 하자 프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때 이슈가 발생했다고 합니다. 또 어떤 것이라도 일정에 차질을 주게 되면 이슈로 인식해야 한다고 합니다. 이러한 이슈를 관리하는 절차는 다음 6단계로 되어 있다고 합니다. 이슈 발생 인지 -> 이슈 분류 -> 대응 방안 수립 -> 대응 방안 실행 -> 실행..

2004년 5월 ~ 12월까지 월간 시사 컴퓨터에 연재된 천정락 교수님의 프로젝트 성공 요인 분석이란 자료가 있습니다. 4년여의 시간이 지났지만, 아직도 현재 진행하고 있는 IT 프로젝트에도 도움이 되는 이야기 인 듯 하여 정리해서 옮겨 봅니다. 1. 업무 변경 관리로 프로젝트 성공률을 높이자. 첫번째로 이야기 한 것은 변경 관리입니다. 프로젝트의 범위나 현업의 업무가 변경된 경우, 의사결정자들과 프로젝트 수행자들이 모여 업무 변경 관리 위원회를 만들고 체크해 나가야 한다는 이야기 입니다. 방법으로는 업무가 변경될 때마다, 단계별로, 프로젝트 막바지에 변경하는 방식이 있는데요 변경될 때마다 하는 것은 번거롭고 프로젝트 진행을 더디게 할 수 있구요. 단계별로 수행하는 것은 프로젝트가 잠시 멈추게 되므로 미..

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

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

리펙토링을 실제로 어떻게 수행하는지.. 마틴 파울러(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로 바꾸는 것도 설명되어 있습니다. 즉, 경우에 따라 적용하는 리펙토링이 다르다는 것인데.. 이건 경험이 필요한 것 같습니다.~ 끊임없이 생각해보고 변경하다보면 어떤 것이 올바른 리펙토링인지 알수 있지 않을까 합니다. 다음으로는 리펙토링을 하고 있으면, 윗분들은 아무것도 하지 않고 있다고 생..

요즘 테스트 코드와 관련해서... 테스트 코드를 먼저 만들고 난 후, 코딩을 진행하는 것이 좋다... 또는 프로그래밍 코딩을 하면, 테스트 코드를 만들어 확인해야 한다.. 리펙토링을 하기 전에는 반드시 테스트 코드가 있어야 한다.. 라는 이야기를 많이 합니다. 테스트 코드라는 것이 매우 중요한 개념이라는 것은 많이 들어서 알 것 같습니다. 그런데.. 실천이 매우 어렵다는 것을 한번 느낀 적이 있어 글을 써봅니다. 최근 프로젝트에서 JUnit이라는 테스트 프레임워크와 Ant 툴을 이용해서 프로젝트에서 테스트 프로그램을 구성해 보았습니다. 흔히 말하듯 빌드 한방에 테스트가 완료되구요.. 테스트 전후의 데이터도 변화가 없게 만들고... 나름 머리써가면서 잘 만들어 놨었죠~~ 하지만, 테스트 구현에 있어 약간의..