숫자표현
프로그래밍/C/C++ 2007. 4. 4. 17:47 |8 진 정수 - 숫자 앞에 0
10 진 정수
16 진 정수 - 숫자 앞에 0x 또는 0X
7e2 - 7 x 10^2
05E-2 - 0.5 x 10^-2
8 진 정수 - 숫자 앞에 0
10 진 정수
16 진 정수 - 숫자 앞에 0x 또는 0X
7e2 - 7 x 10^2
05E-2 - 0.5 x 10^-2
Quick-Kill Project Management
출처 : http://www.ddj.com/dept/architect/189401902
실현 불가능한 스케쥴 하에서 소프트웨어 개발 프로젝트를 제대로 진행하기 위한….
Andrew Stellman and Jennifer Greene, Dr. Dobb’s Journal
6/30/2006
이글의 저자인 Andrew와 Jennifer는 O’Reilly 출판사에서 발간된 Applied Software Project Management의 저자이며 공식 홈페이지는 www.stellman-greene.com 이다.
—-
당신이 다섯명으로 구성된 프로젝트 팀을 이끄는 프로젝트 리드 개발자라고 해보자. 당신의 팀은 몇주간 프로젝트를 진행해 왔고 팀의 분위기는 다소 싸늘하게 맛이 가는 상황이다. 팀의 구성원들은 화려한 경력의 아키텍트로부터 갓 대학을 졸업한 초보 개발자까지 다양한 인원으로 구성되어 있다. 당신의 상사가 프로젝트 리드인 당신을 불러놓고 경영진으로부터 압박이 너무 강해 못살겠다고 죽는 소리를 해댄다. 프로젝트가 어제까지 끝이 났어야 했다는 것이다. 실상 이 프로젝트는 어제 끝내기로 아주 오래전에 약속이 된 상태였고 고객이 이 소프트웨어를 제때 사용하지 못하면 어마어마한 손실이 발생하기 때문에 이 프로젝트가 실패하면 아마도 당신과 당신의 상사는 새 직장을 알아봐야 할지도 모르는 상황이 될 것 같다.
이런 고도의 스트레스가 가해지는 프로젝트를 수행하는 팀에게는 프로젝트가 악몽 그 자체이다. 제대로 방향을 잡지 못한 팀원들은 이래저래 잘못된 판단을 하여 일을 망치기 마련이고 책임감 넘치는 프로젝트 리드인 당신은 심각한 디자인 상의 오류를 수정하기 위해 주말동안 40시간을 일해야 했을 것이다. 싸늘한 표정의 경영진과의 미팅이 계속 되게 마련이고 절대 사라지지 않는 버그들이 여기저기 산재해 있으며 너무 많은 밤을 커피/피자와 보내게 되었을 것이다. 더우기 그런 고생 끝에 결국 뭔가 완성해서 납품을 하면 이번에는 고객이 그 소프트웨어를 싫어한다. 버튼을 누를 때마다 새로운 버그들이 나타나기 때문에 고객들은 자신들이 원했던 기능들이 결국에는 거의 구현되지 않았다고 느끼게 될 것이다.
Quick Kill 프로젝트 관리법
많은 팀들이 자신들이 위와 같은 상황에 처해있음을 깨닫게 되고 리드 개발자는 많은 심각한 문제들에 직면하게 될 것이다. 물론 리드 개발자는 직접 팀을 관리할 책임은 없지만 결국 그는 소프트웨어가 완성되도록 할 책임이 있다. 보통 팀 구성원들은 그를 존중하며 그가 결정을 내리면 모두 잘 따를 것이다. 하지만 리드 개발자의 임무는 팀 관리가 아니라 개발이다. 그의 대부분의 시간은 문제의 해결 방법을 찾아내고, 소프트웨어를 설계하고, 코드를 빌딩하는 곳에 써야만 마땅하다.
이상적인 상황이라면 프로젝트의 관리를 위해서 별도의 프로젝트 매니저가 존재하던가 아니면 프로젝트 리드에게 많은 시간이 주어져야 한다. 하지만 대부분의 경우 그러하듯 충분한 시간이나 예산이 주어지지 않았다면? 대부분의 사람들에게 이런 경우에 도대체 무엇부터 시작해야 할지 난감하기는 마찬가지일 것이다. 이 글의 주된 아이디어는 바로 이런 경우를 해쳐나가기 위한 방법에 집중한다. “Quick Kill 프로젝트 관리법”이라고 부르자. 프로젝트의 가장 중요한 문제점들만 집어내어 순식간에 죽여(kill)버리자는 컨셉이다. 다시 말하면 프로젝트 리드가 가장 적은 노력을 기울여 가장 많은 이득을 얻을 수 있는 trade-off 지점을 찾도록 해주자는 것이다.
Quick-kill 프로젝트 관리법에는 프로젝트 리드가 상사와 고객이 원하는 것을 만들어 낼 수 있는 아래와 같은 테크닉으로 이루어진다:
각각의 테크닉들을 실제 수행하는데에는 많은 시간이 소요되지 않는다. 그러면서도 프로젝트 진행에서 빠지기 쉬운 함정들을 손쉽게 피할 수 있도록 해준다. 이 방법들을 사용하면 프로젝트 리드들은 그럭저럭 괜찮은 결과를 낼 수 있게 된다.
목표/범위 정의 문서(Vision and Scope Document) : 6시간 이내
만약 소프트웨어 팀이 자신들이 작업중인 소프트웨어가 어느 맥락에서 만들어지고 있는지 잘 모르는 경우에는 프로젝트 진행 과정 중에 매우 안좋은 결정을 내리게 되는 경우가 많다. 이런 잘못된 결정은 나중에 바로 잡는데 귀중한 시간들을 소모하게 되고, 바로 잡지 않는다면 고객들의 요구사항을 무시한 것이 될수도 있어 상당한 신뢰를 잃게 되기도 한다. 프로젝트의 범위를 이해하지 않은채 프로젝트에 투입되면 긴급상황이 거듭되는 동안 목표를 잊어버리고 더 안좋은 길로 들어서게 되는 첩경이다. 프로그래머들이 자기 눈 앞에 놓인 문제들은 잘 볼지 몰라도 프로젝트 전체의 맥락은 놓쳐버리게 되는 것이다. 이것은 프로젝트 지연과 프로젝트 실패의 가장 큰 원인이다.
운좋게도 이 문제는 아주 손쉬운 방법으로 해결될 수 있다. 프로젝트의 목표(vision)와 범위(scope)를 문서에 적는 일은 채 하루도 걸리지 않지만 위의 문제들로 인한 프로젝트의 지체 시간을 엄청나게 절약해준다.
이 목표/범위 문서를 작성하는 가장 첫번째 단계는 프로젝트의 직접적인 이해 당사자(stakeholder)들을 만나 이야기를 하는 것이다. 보통 직접적인 이해 당사자가 누구인지 분명하지 않은 경우가 많다. 프로젝트 리드는 먼저 프로젝트에 의해 가장 큰 영향을 받는 사람을 찾아야 한다. 프로젝트를 입안했거나 그 개발 경과에 영향이 있는 사람들을 찾아야 한다. 아니면 가장 쉬운 방법으로 프로젝트가 엉망이 되어 버렸을 때 치명타를 입는 사람들을 찾으면 손쉽다. 대부분의 이해당사자들은 그들이 원하는 요구사항이나 프로젝트의 목표에 대해 프로젝트 리드와 기꺼이 이야기를 나눌 것이다. 그리고, 그것이 당연히 리드 개발자와 그 개발팀이 해야할 일이기도 하다. 보통의 경우 각 이해당사자들이 원하는 요구사항을 취합하는데 한사람당 한시간도 걸리지 않을 것이다.
목표/범위 정의 문서는 간단해야 한다. 한두 페이지를 넘어가서는 안된다. (테이블 1 참조) 프로젝트 이해 당사자들과의 면담을 거쳐 얻어진 요구사항들은 이 문서의 “문제점들” 섹션에 추가한다.
- 요구사항들 (Problem Statement)
- 프로젝트의 배경(Project Background)
- 이해 당사자들(Stakeholders)
- 고객들(Users)
- 목표(Vision of the Solution)
- 목표 명세(Vision Statement)
- 기능 명세(List of Features)
- 개발하지 않을 기능들(Features That Will Not Be Developed)
테이블 1: 목표/범위 정의 문서 개요.
“프로젝트의 배경” 섹션에는 프로젝트가 해결해야 하는 문제점(problem)의 요약이 들어간다. 그 문제의 간단한 배경 역사에 대한 설명이 있어야 하고 회사가 그 문제점을 해결하기 위한 소프트웨어를 만들게된 이유에 대해 간략히 쓰도록 한다. 이 섹션은 문제점이 왜 존재해왔고 회사에서의 그 문제점의 위상, 이전에 이 문제를 해결하기 위해 있어왔던 프로젝트들과 어느 정도 해결했는지 여부 등을 알 수 있어야 한다.
“이해 당사자들” 섹션은 이해 당사자들을 나열해서 목록을 작성하도록 한다. 이름을 쓸 수도 있고 직책이나 역할을 써도 된다. (”기획팀장”, “대표이사”, “홍길동” 등) 각 이해 당사자에 대해 몇줄 이내로 그들의 요구사항을 적어 두도록 하자. “고객들” 섹션에 대해서도 마찬가지로 작성을 하도록 한다. 고객들도 역시 이름이나 직책 또는 역할로 대신 써도 된다. (”지원팀”, “일반 가정 사용자”, “금성전자” 등등) 고객이 너무 많다면 일일히 모두 적는 것이 비효율적일 수도 있다.
이 문서의 가장 중요한 부분은 고객들과 이해 당사자들의 요구사항 부분이다. 프로젝트의 구성원들이 그 프로젝트를 이끄는 원동력이 무엇인지 이해하지 못한다면 매우 편협한 시각만들 가지고 고객이나 이해당사자들은 별로 중요하지 않게 여기는 일들에 지나치게 많은 시간을 투자하거나 할 가능성이 높다. 좋은 소프트웨어를 만드는 것은 오히려 쉽다. 하지만 “알맞는” 소프트웨어를 만들기 위한 방법은 프로젝트 팀의 모든 구성원들이 자신이 만들어야 하는 소프트웨어를 만드는 이유와 방법을 사전에 이해해야만 하기 때문에 어려운 것이다. 물론 그것이 바로 프로젝트 기회의 목적이기도 하다.
문서의 “목표” 부분은 소프트웨어의 목표를 적는 곳이다. 모든 소프트웨어는 고객이나 프로젝트 이해 당사자의 문제를 해결하기 위해 작성된다. 프로젝트 팀은 이 점을 염두에 두고 목표 명세를 적어 나간다. (요구사항들을 어떻게 해결해줄건지를 적으면 된다) 목표 명세 부분은 프로젝트를 어떻게 완수하는지를 적는 것이 목표다. 프로젝트의 목적에 대해서도 설명이 있어야 한다. 프로젝트에 투여되는 시간과 돈, 리소스에 대한 엄격한 이유가 있어야만 한다.
“기능 명세”와 “프로젝트에서 개발하지 않을 기능들” 섹션은 프로젝트 팀이 무엇을 만들고 무엇을 만들지 않을 것인가에 대한 명세이다. 이 섹션을 쓰기 전에 문서를 모두 작성해 놓고 이 부분에 대하여 허심탄회한 논의를 해야만 한다. 각각의 기능들은 “문제점들” 섹션의 문제점들을 해결하기 위한 것이어야만 한다. 프로젝트 팀들은 종종 ‘당연히 있어야 할 것 같은 기능’이지만 정작 문제의 해결에는 별 도움이 되지 않는 기능들을 추가하는 실수를 범한다. 이런 기능들은 “프로젝트에서 개발하지 않을 기능들” 섹션으로 과감하게 옮겨야 한다.
업무 분할: 2시간
기능 구현을 시작하기 전에 프로젝트 리드는 팀의 구성원들과 함께 각각의 기능에 대한 소요 시간을 추산해야 한다. 많은 개발자들은 일정 추산을 어려워한다. 하지만, 몇가지 방법만 따르면 일정 추산이 상당히 손쉽고 믿을만하게 된다.
일정 추산은 각 프로젝트 구성원들은 프로젝트의 여러가지 측면을 고려해볼수 있는 기회가 되기 때문에 매우 중요하다. 대부분의 프로그래머들은 간단한 작업으로 예상하고 일정을 추산했던 작업이 실은 매우 복잡한 것으로 밝혀져 엄청나게 많은 추가 시간이 소요될 것이란걸 깨닫고 절망했던 기억이 있을 것이다. 게다가 팀 구성원 중 다른 사람이 그 작업이 완료된 후 어떤 작업을 해야 하는 상황이라면 자칫 프로젝트 전체가 혼란에 빠지게 될수도 있다. 일정 추산의 요령은 이런 일반적인 프로젝트 진행상의 재해상황을 피할 수 있게 해준다. 프로젝트의 일정을 추산하기 위해서는 팀이 프로젝트를 완수하기 위한 단계를 미리 파악해놓고 각각의 단계들을 완수하는데 몇일 정도가 소요되는지 추산해야 한다. 정확한 일정을 파악하기 위한 유일한 방법은 팀 구성원 모두가 둘러 앉아 프로젝트의 모든 요소들(특히나 빼먹고 나중에 당황할만한 요소들)을 겁듭 함께 생각해 보는 것이다.
일정 추산을 위한 첫번째 단계는 프로젝트를 여러개의 작업들로 분산하는 것이다. 이것을 업무 분할(work breakdown structure, WBS)라고 부른다. 프로젝트를 작업들로 분산하는데에는 아주 많은 방법들이 있다. 리드 개발자는 팀 구성원들을 모아 적당한 수의 작업들로 프로젝트를 분할해야 한다.
경험적으로 가장 좋은 작업의 수는 프로젝트 당 대략 10-20개 정도의 작업으로 분할하는 것이다. 큰 규모의 프로젝트들(스페이스 셔틀 등)에서는 이 각각의 작업들이 엄청나게 큰 일(유도시스템 테스트 처럼)이 되겠지만 일반적인 소프트웨어 프로젝트에서는 비교적 작은 단위로 떨어지기 마련이다. 이 작업 분할은 보통 한시간 내에 완료할 수 있을 것이다.
팀 멤버들이 이 WBS에 동의했다면 이제 각각의 작업에 대해 일정 추산이 가능해진다. 물론 팀 구성원들이 모두 일정 추산에 필요한 모든 필요한 정보들을 가지고 있는 것은 아닐 것이지만 어쨌든 모두들 구체적인 수치로 일정 추산을 해야만 한다. 일정 추산에 필요하지만 누락된 정보들이 있다면 어느 정도 추정을 해야만 한다. 이렇게 추정에 의한 부분들에는 옆에 빈칸을 함께 남겨두고 나중에 정보들이 보강되면 이 빈칸들이 채워주게 되면 프로젝트의 진행에 따라 일정 추산이 갈수록 더 정확하게 변해갈 것이다.
일정 추산에 있어 추정은 매우 중요한 역할을 한다. 두명의 구성원이 어떤 작업의 소요 시간에 대해 의견을 달리 할 때를 보면 이 두명의 일정 추산이 다른 이유 중 가장 큰 부분이추정의 정도가 다르기 때문인 경우가 대부분이다. 예를 들어, 동일한 목표/범위 정의 문서를 기반으로 작업하고 있는 두 개발자에게 컴퓨터의 시계를 맞추는 모듈의 작성에 있어 일정 추산이 완전히 다르다고 한다면 그 이유는 보통 두 사람의 “추정” 부분이 완전히 다를 수 있다는 것이다. 한 사람은 키보드 커맨드로 시간을 맞추는 커맨드라인 버전의 모듈을 생각했고, 다른 한 사람은 윈도우 제어판에 플러그인 되는 GUI 프로그램 모듈로 추정하고 있었다든지 하는 경우가 될 수 있겠다.
프로젝트 리드는 팀 구성원들 간의 이런 “추정” 부분의 차이를 해소하도록 도우면서 각각의 작업들의 추정시간을 픽스해 나갈수 있을 것이다. 리드는 각각의 작업들을 하나씩 내놓아 팀원들이 각각의 작업들에 대해 추산을 하도록 하자. 이견이 있는 경우는 팀원들의 “추정”이 일치하지 않는 것이므로 프로젝트 리드가 이들을 일치하도록 조정하여 해당 작업의 아래에 “추정”을 적어두도록 한다. 더 많은 “추정”들이 쓰여질수록 팀 구성원들이 프로젝트에 대해 많은 것을 알게 되는 것이다. 이것이 거듭될수록 팀 구성원들의 일정 추산은 갈수록 정확해지게 된다.
결국 최종적으로 WBS는 작업 목록과 각각의 작업의 일정 추산, 작업별 “추정”들로 이루어지게 된다. 10-20개의 작업들에 대해 이런 일정 추산과 “추정”을 집계하는 데에는 대략 1시간 정도가 소요될 것이다. WBS를 작성하고 추정을 하는데 2시간 정도 소요된다. 대부분의 다섯명짜리 프로젝트에서는 이 정도면 충분할 것이다. 프로젝트의 규모가 이보다 훨씬 크다면 프로젝트를 각각 두시간 분량으로 쪼개어 한 조각에 두시간씩 추정을 해나가면 된다.
코드 리뷰: 리뷰당 2.5시간
팀 구성원들은 코드의 샘플을 리뷰하며 결점들을 고쳐 나가게 된다. “결점”이란 프로그래머가 의도한대로 동작하지 않거나 동작하지만 개선되어야만 하는 프로그램의 블럭을 말한다. (예를 들자면 좀 더 보기 좋게 수정되어야 하는 부분이나 좀 더 빠르게 동작해야 하는 부분등)
코드 리뷰를 시행하는 것은 팀이 더 좋은 소프트웨어를 만들도록 하는 효과적인 방법이다. 팀이 버그를 찾아서 수정하도록 하기도 하지만 그보다 초급 프로그래머들이 더 좋은 기술을 연마하도록 하는 기회가 된다. 대부분 프로그래머들은 다른 사람들이 나중에 자신의 코드를 읽을 것이라는 것을 알고 있으면 좀 더 나은 코드를 작성하게 되는 경향이 있다.
코드 리뷰를 하기 위한 첫번째 단계는 리뷰할 코드의 샘플을 선택하는 것이다. 전체 코드를 모두 리뷰하는 것은 불가능하기 때문에 어느 부분을 리뷰할 것인지 골라야만 한다. 리뷰할 코드를 잘 선택해야 코드 리뷰가 효율적이 된다. 상당수의 프로젝트들에 있어 많은 수의 결점들이 특정 핵심 부분에 몰려있는 경우가 대부분이다. 그렇기 때문에 리뷰할 코드를 잘 선택하면 팀 전체의 많은 시간을 절약하게 된다.
보통 프로젝트 리드가 리뷰에 사용할 알맞은 코드를 선택하는 일은 그리 어렵지 않다. 보통 트리키한 알고리즘을 구현한 부분이라던가 복잡한 API나 오브젝트 인터페이스를 사용한 부분, 새로운 기술을 응용한 부분등이 대상이 되는 경우가 많을 것이다. 이런 핵심적인 부분을 리뷰하는 것은 소프트웨어의 동작에 안정성을 위협하는 결점들을 제거할 수 일기 때문에 유용하기도 하지만 결국 그 부분을 유지/보수할 수 있는 인력을 늘린다는 측면에서도 바람직하다.
리뷰를 준비하기 위해서 프로젝트 리뷰는 선택된 코드 블럭을 라인 넘버와 함께 프린트하여 각 프로젝트 구성원들에게 배포한다. 각 구성원들은 각자 30분 정도의 시간을 투자해서 이를 읽어보고 (실행해보면 더 좋고) 검토해보는 시간을 갖도록 하자. 각자 이 코드가 작성자의 의도대로 동작할지에 대한 고찰을 하도록 하자. 코드 동작의 정확성/유지보수성/신뢰성/보안/확장성/재활용성/효율성에 문제가 없는지 염두에 두고 살펴보도록 한다. 이런 각각의 문제점들은 “결점”으로 간주하도록 한다. 모든 팀 구성원들은 가능한 많은 “결점”들을 찾아내어 프린트된 소스에 표시를 하도록 한다.
각자 준비가 끝나면 코드 리뷰 미팅을 개최한다. 코드 리뷰의 시작은 프로젝트 리드가 코드 샘플의 첫번째 블럭을 읽는 것으로 시작한다. 물론 소스를 다 읽는다기 보다는 개략적인 설명과 코드의 작성 목적 등을 설명하는 것이다. 이 설명에 동의하지 않는 구성원이 있다면 코드의 원 작성자가 코드의 작성 목적 등을 자세히 설명하는 시간을 갖도록 하자. 어떤 때에는 다른 구성원이 더 좋은 방법을 내놓을 수도 있다. 작성 목적의 설명을 듣는 것만으로도 많은 문제의 해결책들이 쏟아져 나올 수 있다.
팀 구성원들은 코드 블럭에서 발견한 “결점”에 대해 논의하도록 한다. 이때 프로젝트 리드는 미팅의 중재자 역할을 해야 한다. 누군가 “결점”을 발견하면 리드는 그 것을 즉시 고칠 수 있는지 없는지를 판단한다. 고칠 수 있으면 그 자리에서 고치면 된다. 즉시 고칠 수 없다면 이슈로 열어놓고 나중에 수정하도록 할수도 있다. 각각의 경우에 있어 리드는 스프레드쉬트에 한줄씩 추가하여 리뷰 로그를 작성하도록 한다. 각각의 “결점”에 대해 한줄을 추가하는 것이다. 라인 넘버, 발견자, 해결 방법, 해결 여부 등을 적어 넣으면 된다. 로그의 상단에는 리뷰 미팅이 언제 어떤 코드 블럭을 가지고 행해졌는지 적어 넣도록 하자.
코드 리뷰 미팅은 2시간 이상 소요되어서는 안된다. 만약 그 이상이 소요되었다면 다음번에는 좀 더 짧은 소스를 선택하도록 하자. 코드 리뷰 미팅이 끝나고 나면 프로젝트 리드는 리뷰 로그를 모두에게 보내고 그 수정 작업을 필요한 사람에게 할당하도록 한다. 수정 작업이 끝나고 나면 수정 사항이 제대로 코드에 반영되었는지 리드가 확인하도록 하자
프로그래머로 살아남기라는 제목부터가 심상치 않다. 느낌이 좋지 않을 수도 있다. 도데체 프로그래머란 직업이 어떻길래? 라는 의문이 강하게 와닿을 것 같다. 사실 현직 프로그래머에게는 가장 민감한 주제라고 볼 수 있다. 적어도 필자에게는 그랬었다. 그래서 그것을 다루기가 매우 조심스럽다. 왜냐하면, 정답이 없이, 보편적인 결론을 내릴 수 밖에 없기 때문이다. |
수영하다가 우연히 발견한재밌고 알찬 내용이네요.
마치 실연이후 길거리에 들리는 유행가 가사가 마치 내맘을 대변해주는 듯 착각과 같은 느낌.
챙파가 11년동안 키보드 두둥기면서(이젠 기획이나 PM역할을 하지만) 공감하는주요 내용에 밑줄긋습니다. 근데 다 밑줄 그을듯.ㅎㅎ
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. 매사에 겸손하고 항상 남을 생각할지어다. 가장 완벽한 프로그램일수록 가장 완벽하게 숨은 벌레가 있느니라. 네가 이 세상 최고의 프로그래머라고 떠들며 자만할 때, 옆집 곳간에서는 훨씬 더 뛰어난 것을 묵묵히 만들고 있느니라. 아무렴 프로그래밍은 혼자 잘나서 할 게 아니니, 너로 인해 다른 사람들도 더불어 잘 되면 그 얼마나 좋은 것이냐. 프로그래머는 논리적으로 생각하여야 하지만 프로그램은 비논리적으로 작성하라. 프로그래머가 경지에 들면 누가 누가 잘하는지 알수가 없는 법, 또한 프로그래머로서의 '무지'에 대해서 잊지마라. 프로그래머의 '무지'는 생략하고, 선택하고, 단순화시키고, 명백하게하는 것이니라. 항상 새로운 아이디어와 새로운 생각으로 무장하라. 그리고 나누라 나누는곳에 기쁨있나니 너희는 모든 프로그램에 대해서 위의 프로시줘를 따를 지니라.
직접 뚜드려서 변환도 가능(단, 10진수 → 문자 only)
=> ALT 를 누른상태에서 10진수(키패드 only)를 입력한뒤 ALT를 떼면 문자로 바뀌게된다.
//================================================================
//12-5
//================================================================
#include
#include
/*
int main(int argc, char *argv[])
{
int i;
//
printf("nThe following arguments were passed to main(): ");
printf("nARGC: %dn", argc);
for(i=1;i
printf("n");
//
printf("nParameter test: ");
printf(" of argc: %dn", argc);
for(i = 0; i< argc; i++){
printf("%s", argv[i]);
}
printf("n");
return 0;
}
*/
//===============================================================
//cd Microsoft vi*: 알아서 찾아 들어가준다..신기신기~
//test.exe도 argc에 포함이 된다 그래서 초기 카운터는 1
//===============================================================
int main(int argc, char* argv[])
{
int i;
int value;
int sum = 0;
printf("nThe following numerical data of the arguments passed to main(): ");
for(i=1;i
value = atoi(argv[i]);
sum += value;
printf("%d", value);
}
printf("nThe sum of the numerical data is %dn", sum);
return 0;
}