지난 44년 동안 ‘끊임없이 우물을 파는 사람이 성공하고 승리한다’는 확실한 교훈을 얻었다. 어리석게 들릴지 모른다. 그러나 놀랍게도 석유나 가스를 찾고자 한다면 유전을 파야 한다는 사실을 정확하게 이해하는 사람은 드물다. 아무리 훌륭한 유전지도가 있다고 해도, 그리고 유전지역을 연구하더라도 석유를 얻으려면 일단 시추를 해야 한다. -존 마스터스(유명한 캐나다 유전 개발업자)
그렇습니다. 실행 없이 저절로 얻어지는 것은 없습니다. 석유를 얻으려면 일단 땅을 파야합니다. 필요한 것을 얻어내려면 비가 내리거나 해가 뜨거나 어떤 위협이 있더라도 석유를 얻기 위해 유전을 파야 하는 것처럼 꾸준하게 실행을 해야 합니다.
책소개 Object-C 혹은 Cocoa 없이 앱스토어 애플리케이션 만들기『HTML, CSS, JavaScript로 iPhone Apps 개발하기』. 이 책은 웹 개발자라면 누구라도 쉽게 아이폰 애플리케이션 개발자가 될 수 있도록 도와주는 안내서다. Objective-C나 Cocoa를 사용하지 않고 플랫폼 위에서 아이폰과 아이팟 터치를 위한 애플리케이션을 디자인하고 작성할 수 있는 오픈 소스 웹 기술들을 사용하는 방법을 배울 수 있다.
목 차
1장 시작하기 Web Apps VS. Native Apps Web Programming 특강
2장 기본 아이폰 스타일링 첫 번째 단계 아이폰 CSS 추가하기 아이폰에 모양과 느낌 추가하기 jQuery와 기본적인 동작 추가하기 이 장을 마치며
3장 향상된 아이폰 스타일링 Ajax의 터치 추가하기 교통경찰 역할을 하는 iphone.html 작성하기 간단한 부가기능 추가하기 ‘back' 버튼으로 되돌리기 Home Screen에 Icon 추가하기 Full Screen Mode 이 장을 마치며
4장 Animation 친구로부터 약간의 도움을 얻다. Dates 패널 추가하기 Date 패널 추가하기 New Entry 패널 추가하기 Settings 패널 추가하기 하나의 HTML로 완성하기 jQTouch 사용자 정의에 맞추기 이 장을 마치며
5장 Client-Side 데이터 기억장치 localStorage와 sessionStorage 사용자 설정을 localStorage에 저장하기 Client-Side Database 이 장을 마치며
6장 Offline Offline Application Cache의 기본 Online Whitelist와 Fallback 옵션 동적 Manifest 파일 생성하기 Debugging 이 장을 마치며
7장 Native PhoneGap 소개 아이폰에 우리가 만든 애플리케이션 인스톨하기 JavaScript로 아이폰 제어하기 이 장을 마치며
8장 iTunes에 애플리케이션 올리기 아이폰 Distribution Provisioning Profile 만들기 아이폰 Distribution Provisioning Profile 인스톨하기 프로젝트명 변경하기 애플리케이션 바이너리 준비하기 애플리케이션 올리기 기다리는 동안 참고할 사이트
테스트 주도 개발 저자 켄트 벡 | 역자 김창준 외 | 출판사 인사이트
책소개
최근 주목받고 있는 프로그래밍 방법인 테스트 주도 개발, 즉 TDD를 설명한 최초의 책이자, 가장 권위적인 책. 테스트 주도 개발을 퍼뜨린 장본인이며 객체 지향 프로그래밍의 선구자 중 한 사람인 켄트 벡이 직접 썼다.
'테스트 주도 개발(Test-Driven Development)'은 테스트가 개발을 주도하는 방법이다. 테스트가 개발을 주도한다는 것은 테스트가 코딩의 방향을 이끌어 간다는 말이다. 테스트를 실패하는 코드가 없으면 코딩을 하지 않고, 코드 상에 중복이 있으면 제거한다는 간단한 규칙을 지켜나가면 자연스레 아름다운 코드가 천변만화 펼쳐진다. 덤으로 회귀 테스트도 생기고, 개발 과정 자체가 즐거워지는 보너스도 있다.
1부에서는 자바 언어를 사용해서 다중 화폐 코드를 작성하고, 2부에서는 파이썬 언어를 사용해서 단위 테스팅 프레임웍을 작성한다. 3부에는 이런 개발을 할 때 자주 등장하는 패턴들을 정리해 놓았다. 100여 개의 역주로 내용을 알기 쉽고 풍부하게 해설하고 있다. TDD를 국내에 처음 소개한 역자의 'TDD 수련법', '실전 TDD' 원고 추가했으며, 부록으로 TDD 시연 동영상 CD를 준다. 또한 한국어판 발간에 즈음한 켄트 벡 인터뷰를 수록했다.
저자 소개
<지은이> 켄트 벡(Kent Beck) 켄트 벡(Kent Beck)은 소프트웨어 패턴 운동의 선구자 중 한 명이며, CRC 카드와 HotDraw 드로잉 에디터 프레임워크, xUnit 유닛 테스팅 프레임워크를 개발했고, 리팩토링과 테스트 주도 개발을 소개했다. 또한 기민한 방법론(Agile Methodology) 중 가장 널리 알려진 익스트림 프로그래밍(Extreme Programming, XP)의 아버지다. 피플웨어로 유명한 톰 디마르코(Tom DeMarco)는 2001년 OOPSLA 컨퍼런스에서 "켄트 벡은 CMM 개발을 지휘한 와츠 험프리가 지난 10년 간 중요했던 것보다 더 중요해질 것"이라고 말했다. 켄트 벡은 현재 Three Rivers Institute 소속이다. 저술한 책으로는 Smalltalk Best Practice Patterns와 Kent Beck's Guide to Better Smalltalk 같은 스몰토크 패턴에 관련된 책들과 Extreme Programming Explained, Planning Extreme Programming(공저), Refactoring(공저), Contributing to Eclipse(공저) 등이 있고 현재도 여러 책을 집필 중에 있다.
< 옮긴이 > 김창준 현재 월간 마이크로소프트웨어 자문위원, 한국 XP 사용자 모임 설립자 및 코어그룹 멤버, XP 코치 팀 수석 코치. 다음커뮤니케이션, NHN, 한미 연합사령부, SKT, 삼성전자/전기 등에 XP 코칭, 교육, 컨설팅 등을 제공한 바 있다. 한국 XP 사용자 모임 http://xper.org 를 운영하고 있다.
강규영 현재 다음커뮤니케이션 R&D 센터에서 근무중. 한국 XP 사용자 모임 코어그룹 및 XP 코치 팀으로 활동하고 있으며 김창준씨를 도와 여러 XP 컨설팅에 참여. 개인위키 http://jania.pe.kr 을 운영하고 있다.
목 차
TDD 수련법 (by 김창준) 한국어판 인터뷰
1부 화폐(돈) 예제
1장 다중 통화를 지원하는 Money 객체 2장 타락한 객체 3장 모두를 위한 평등 4장 프라이버시 5장 솔직히 말하자면 6장 돌아온 ‘모두를 위한 평등’ 7장 사과와 오렌지 8장 객체 만들기 9장 우리가 사는 시간(times) 10장 흥미로운 시간 11장 모든 악의 근원 12장 드디어, 더하기 13장 진짜로 만들기 14장 바꾸기 15장 서로 다른 통화끼리 더하기 16장 드디어, 추상화 17장 Money 회고
2부 XUnit 예시
18장 xUnit으로 가는 첫걸음 19장 테이블 차리기 20장 뒷정리하기 21장 셈하기 22장 실패 처리하기 23장 얼마나 달콤한지 24장 xUnit 회고
3부 테스트 주도 개발의 패턴
25장 테스트 주도 개발 패턴 26장 빨간 막대 패턴 27장 테스팅 패턴 28장 초록 막대 패턴 29장 xUnit 패턴 30장 디자인 패턴 31장 리팩토링 32장 TDD 마스터하기
부록 A 영향도 부록 B 피보나치 마치는 글 (by 마틴 파울러) 실전 TDD (by 김창준, 강석천)
가진 것 하나를 열로 나누면 우리가 가진 것이 십 분의 일로 줄어드는 속세의 수학과는 달리 가진 것 하나를 열로 나누었기에 그것이 ‘천’이나 ‘만’으로 부푼다는 하늘나라의 참된 수학, 끊임없는 나눔만이 행복의 원천이 될 수 있다는 행복 정석을 그들과의 만남을 통해서 배우게 된다. -이태석 신부, ‘친구가 되어 주실래요?’에서
‘울지마 톤즈’로 세상을 울린 故 이태석 신부님 글입니다. 이태석 신부는 부족한 것들 때문에 불편한 점도 있지만 부족한 것들 덕분에 깨달음도 많이 얻는다고 말했습니다. 무엇보다도 작은 것들에 대해 감사하는 마음을 덤으로 얻게 되어 기쁨이 크다고 말합니다.
낙타는
위기를 맞으면
술수를 쓰지 않고 도전한다.
정공법으로 승부수를 던지는 것이다.
땡볕에 쉴 그늘도 없을 때 낙타는 오히려
얼굴을 햇볕 쪽으로 마주 향한다. 햇볕을 피하려
등을 돌리면 몸통의 넓은 부위가 뜨거워지지만
마주 보면 얼굴은 햇볕을 받더라도 몸통
부위에는 그늘이 만들어져서 어려움은
오히려 줄어들기 때문이다.
- 최형선의《낙타는 왜 사막으로 갔을까》중에서 -
* 우리도 이따금 사막을 헤맵니다.
모래는 뜨겁고 땡볕은 더 뜨겁습니다.
몸을 돌려 땡볕을 피하느냐, 아니면 낙타처럼
정면으로 땡볕에 맞서느냐, 선택의 기로입니다.
정면으로 도전하면 새로운 길이 열립니다.
사막도 아름답습니다.
2011.03.26~03.27 강원도 속초 대포항을 다녀왔다. 토요일 슈슈가 근무여서 아침에 박물관에 출근시키고, 집에서 쉬다가 올초부터 생각했던 동해에 대한 열망에 속초행을 결심하게 됐다. 오전에 국립민속박물관에서 지난번에 복원한 "오촌댁"도 구경하고. 국립민속박물관의 오전은 외국인을 발디딜곳이 없구나. 외국같아.
오후 6시 민속박물관에서 슈슈를 픽업하여, 종로 2가에서 버거킹 햄버거 구매. 참고로 난 네비게이션이 없다. 덕분에 을지로를 돌아 왕십리를 지나서 강변북로타고 천호대교로. 토요일 저녁이라 차 엄청 막힌다. 천호대교에서 서울춘천간 고속도로로 이동. 이제 미시령 터널도 개통이 되어 서울에서 속초까지 엄청 빨라졌다. 12년 전에 속초를 갔었는데, 머구리들과 함께. 춘천고속도로를 진입하니 엄청 어둡다. 아니나 다를까 견인차가 막 달리더니 얼마 지나지않아 로드킬을 목격했다. 뭔가 큰 동물을 치어서 차가 한대 서있고 그 옆에 견인차들이 있었는데, 얼핏 봤지만 뭔가 큰 노루같은... 에고~ 밤에 어두운 고속도로를 달리는건 쉽지 않은 일이다. 특히 산간도로는 더욱더~ 새 도로라서인가 금방 동홍천(춘천간고속도로 종점, 곧 양양까지 개통예정)을 지났다. 동홍천을 나오니 국도 분위기의 고속도로 46번 도로를 타고 가는데, 중간중간 신호가 있어서 나름 시간이 걸린다. 12선녀탕 인근을 지나 한계령과 미시령 사이. 한계령은 양양가는길이고, 속초는 미시령이다. 옛 미시령 도로는 폐쇄됐고, 미시령 터널을 통과한다. 통행료 3000원,. 현금 준비하자. 긴 미시령 터널을 지나면 울산바위전망대 근처인데, 속초의 야경이 한눈에 들어온다. 감탄의 아우성을 지를 준비 하시고 미시령 터널을 나가시기 바란다. 우린 밤 9시 10분경 통과했는데, 아이폰 사진으로는 담을 수 없었다. 한참을 내리막을 가야 하기때문에 기어를 1단에 놓고 내려갔다. 그렇게 속초외곽을 달려 대포항에 도착하는가 했는데, 외옹치항으로 돌아들어가는 길을 네이버지도가 알려준다. 그냥 대포항으로 직진할껄. 외옹치항으로 들어가는 길 진입로에 펜션및 모텔이 있어서 여기에서 숙박을 해결해야 겠다는생각. 대포항과 얼마 멀지 않아서 방을 잡고 걸어서 가도 될 정도이다. 다음엔 꼭 그렇게. 외옹치에서 대포항으로 진입하는데, 길이 좁아서 바로 나와버렸다. 대포항 끝방향이었는데, 뭔가 생선과 조개를 구워먹는 포장마차가 좋아보였다. 다음엔 꼭 먹으리. 예전 대포항 1주차장은 공사중이었는데, 그 옆에 1주차장이 새로 있으니 일단 파킹. 대포항으로 들어가는 입구에 새우튀김집이 즐비하다. 조금들어가면 줄서서 기다리는 새우튀김집이 있는데, 아마 이집이 맛집인가보다. 튀김은 조명아래에서 더욱 맛있어 보인다. 포장을하면 종이컵하나와 포장간장을 주기때문에 일단 들어갈때 작은 새우튀김으로 한봉지 사서 먹으면서 다니는것도 좋을거 같다. 차 때문에 회집은 들어가지 않고 구경만 쭉 하고, 비단멍게, 새우튀김 큰거, 오징어 순대 하나를 사서 숙소를 찾아서 출발. 1 주차장 맡은편에 편의점이 있어서 미리 먹을거 좀 사갔다. 외옹치항 입구쯤에 있는 숙소에 여정을 풀고 속초에서의 하루를 마쳤다.
다음날 아침(2011.03.27). 일어나자마자 씻고 나서는데, 설악의 설경이 눈에 들어오는 것이 아닌가. 병풍을 두른것 처럼 속초를 감싸안고 있는 설악이 저 멀리 보이는데, 지난 밤 지나올때는 몰랐다.
일단 인근의 속초 해수욕장을 들러 푸른바다와 모래사장 한번 밟아 주시고. 인증샷! 인근의 진전사지3층석탑과 진전사부도를 보러 가기로 했다. 각각 국보, 보물로 지정. 물치항인근을 지나 올라가는데, 군부대가 엄청 크게 있었다. 신기하다. 한참을 올라가다보니 진전사지3층석탑을 볼수 있었다. 역시 다녀보면 옛 절터는 정말 풍수지리가 좋다. 지금은 차로 올수 있지만 에전은 오솔길이지 않았을까? 여기 터를 잡은 걸보면 옛선인들의 능력이 참 대단함을 느낀다. 그리고, 조금 더 올라가면 전진서부도가 있는데, 진전사를 복원하고 있는 중이더라. 왠 하얀개가 와서 반기는 바람에 옷은 흙으로 범범. ㅋㅋ 아직 어린 개같던데 심심한가보다.
다시 미시령으로 향하는 중 대포항 입구의 대게사랑에서 대게해장국과 물회를 먹고. 미시령터널로 이동. 중간에 종합관광안내소에서 안내지도물을 챙겼다.
역시나 가는길은 그렇게 멀게 느껴지지않았다. 미시령을 지나, 백담사 인근을 지나고. 함참을 다가보니 큰 강이 나오면서 38선휴개소라는게 있길래 쉬었더니, 소양강이란다. 정말 크구나하는 생각과 소양강 처녀는 이제 어딨나?
인제를 지나고, 춘천서울간 고속도로 진입. 서울까지는 쭉쭉 가더라. 서울도착 2시. 속초가는게 남해가는것 보다 훨씬 가깝다. 이제 남해를 가야할 차례이다.
소프트웨어 개발의 모든 것(김익환,전규현 지음. 페가수스)를 읽고 나서 중요한 몇 구절을 남겨본다.
요구사항의 중요성 소프트웨어 시스템 구축에서 가장 여려운 부분은 무엇을 구축할 것인지를 정확하게 판단하는 것이다. 그러나. 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이 불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이 허락하는 한 최대한 많은 정보를 파악하는 것이 좋다. 잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발 비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며 많은 추가 비용을 발생시킨다. 완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다. 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수 있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다. 요구사항 오류는 개발 단계가 지나가면 지나갈수록 그 수정비용이 기하급수로 증가한다. 유지보수 단계에서 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는 요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.
코딩자세 : 소프트웨어를 잘 구현하기 위해서는 코딩을 함에 있어 반드시 지켜야 할 것들이 있다. * 회사의 코딩표준을 철저히 지켜야 한다. * 버그가 발견되면 그 즉시 버그를 고쳐라. * 발견된 버그가 재현이 안 된다고 해서 버그가 사라진 것이 아니다. * 문제 없이 작동하고 있는 코드를 괜히 정리하려고 하지 마라. * 문제가 해결될 때까지 이렇게 저렇게 마구 고치지 마라. * 코딩 작업을 작게 나누어서 코딩, 빌드, 테스트를 자주 반복하라. * 중요하지 않은 버그는 하나도 없다.
회사의 코딩표준을 지켜야 하는 이유. * 소스코드의 작성법을 통일하여 개발자들끼리 서로 코드를 더 쉽게 이해할 수 있게 한다. * 개발자가 바뀌어도 빠른 시간 안에 소스코드를 파악 할 수 있게 한다. * 흔히 저지르기 쉬운 사소한 실수를 방지하여 제품의 품질을 높인다.
품질관리 소프트웨어프로젝트에서 품질은 소프트웨어가 얼마나 요구사항을 잘 만족시키고 있는가의 정도이다. 품질은 전적으로 테스트에만 의존하는 것이 아니다. 잘 만들어진 프로젝트 계획, 잘 분석된 요구사항, 각 단계의 철저한 리뷰, 체계적인 테스트 등 프로젝트 전 과정에 걸친 일련의 활동들이 모여서 제품의 품질을 보장하게 된다. 많은 개발자들이 소프트웨어의 품질에 큰 관심을 두지 않는다. 현재 프로젝트를 끝내고 빨리 새로운 프로젝트를 하고 싶어한다. 현재의 문제는 유지보수에서 해결할 수 있을 것으로 생각하기도 한다. 이러한 생각은 제품의 품질을 떨어뜨리고, 제품을 제 때에 출시하지 못하게 만들기도 한다. 품질을 포기하고 제때 출시된 제품은 정시 출시에 대한 의미조차 없다. 고객들은 제품의 품질을 계속 기억할 것이고, 추후 더 나은 제품에 대한 기억이 사라지지 않을 것이다. 일반적으로 소프트웨어의 유지보수에 개발 지용의 2~5배가 지불된다고 알려져 있다. 최초에 낮은 품질로 출시된 제품은 유지보수 비용을 지속적으로 증가시킨다. 유지보수 비용을 간과하면 장기적으로 제품의 수익성에 심각한 저하를 가져올 수 있다. 그럼에도 불구하고 소프트웨어 개발 시에 유지보수에 대해 신경을 쓰지 못하는 경우로 다음과 같은 것들이 있다.
* 당장 프로젝트가 발등에 떨어진 불이라서 유지보수에 대해서는 신경 쓸 겨를이 없다. * 유지보수는 다른 개발팀이 맡을 것이므로 신경 쓰지 않는다. * 경험이 별로 없어서 유지보수에 많은 비용이 드는지 몰랐다. * 유지보수에 비용이 얼마나 드는지 정확하게 따져본 적이 없다.
제품의 품질을 유지보수 기간으로 넘길 것이 아니고, 지금 바로 품질에 대해서 신경을 쓰는 것이 경제적으로 더 바람직하다.
리스크 관리 리스크 계획 중 개발자가 퇴사할 징후가 보일때 다음과 같은 대응책을 마련할 수있다. * 개발자가 퇴사하지 않도록 노력한다. * 개발자가 퇴사하더라도 보충할 개발자를 미리 사내에서 물색해 놓는다. * 사내에서 보충할 개발자를 찾지 못하면, 외부 채용 활동의 준비 단계를 해 놓는다. 즉, 채용공지를 하고 이력서를 분석하여 채용자 후보를 미리 물색해 놓는다. * 해당 개발자이 모듈을 다른 개발자와 많은 부분 공유하도록 계획한다. * 아예 해당 개발자를 프로젝트에서 제외하고 진행한다.
동기 유발 요인 : 프로젝트에서 개발자의 동기를 유발하는 요인에는 다음과 같은 것들이 있다. * 목표설정, 성취감, 성장가능성, 개인생활의 보장, 포상.
프로젝트 팀이 하는 작업 리스트 * SRS 작성 및 검토 * 소프트웨어 아키텍처 설계 논의 * 소프트웨어 컴포넌트와 인터페이스 논의 * 소프트웨어 설계 리뷰 * 소스코드 리뷰 * 결함 추척 및 해결 * 중요 이슈 논의 * 유지보수
성공하는 팀의 특징 * 훌륭한 기술리더가 있다. * 도전적이고 실천가능한 목표와 비전을 공유하고 있다. * 실력 있고 헌신적인 팀원들로 구성되어 있다. * 팀원들간에 서로 신뢰한다. * 팀원들간에 의사소통이 원활하다. * 팀이 적절한 권한과 자율성이 있다. * 팀워크를 유지하기에 알맞은 팀이다.
실패하는 팀 * 비전이 공유되어 있지 않다. * 팀원들간에 서로 신뢰하지 않는다. * 팀원들 간 의사소통이 원활하지 않다. * 문제 팀원 방치.
필자의 경험에 의하면 프로젝트를 망치는 길은 지뢰밭과 같이 많아도 성공하기 위한 비법은 없다. 기본에 충실하고 기초와 문화가 각각 개발자들 몸에 배어서앞에서 언급된 여러 활동들이 종합적으로 자연스럽게 이루어 질 때 소프트웨어 프로젝트 성공이 좀더 가까워 질 것이다.
개발자들은 가장 먼저 * SRS를 작성해야 한다고 생각하고, * SRS를 작성하면서 모든 관련자와 철저히 리뷰를 하고, * 프로젝트 관리자는 개발자들과 함께 1,2일 단위의 상세 일정을 작성하고, * 테스트팀은 SRS를 보고 테스트 Suite를 만들기 시작하고, * 개발 리더들은 화이트보드나 종이를 펼쳐놓고 아키텍처에 대해 토론을 하며, * 구현 시 모든 소스코드는 당연히 리뷰를 하고, * 개발자는 매일 스스로 일정을 업데이트하고, * 소스코드 작성은 일일빌드가 깨지지 않으면서 이루어지며, * 소스코드관리시스템과 버그관리시스템을 효과적으로 사용하며, * 알파, 베타 단계 별로 모든 프로젝트 관련자들이 유기적으로 움직이며, * 일정에 맞춰 완성도 있는 품질의 제품을 출시한다.
위와 같은 활동들이 당연하다고 생각되고 몸에 배어야 한다. 이러한 것들을 규칙만으로 통제를 해서는 달성하기 어렵고 한꺼번에 모두 다 습득하기도 어렵다. 하나씩 익혀서 몸에 배었을 때 소프트웨어 프로젝트를 성공하는 원리가 보이기 시작하고, 좋은 제품을 만들 수 있을 것이다.
(0) 
(0)
