C 에서 문자열의 문제점 널 문자를 찾아서 문자열 끝까지 가보기 전에는 끝을 알아내는 방법이 없다. 문자열 내부에는 어떤 0값도 포함할 수 없으므로, JPEG 그림과 같은 비정형 이진 자료 Binary Large OBject(BLOB)를 C 문자열 내부에 저장할 수 없다. C 문자열이 이런 방삭을 채택한 이유 유닉스와 C 언어를 고안했을 무렵 사용한 PDP-7 마이크로프로세서 때문이다. PDP-7은 ASCIZ 문자열 타입을 지원하는데, ASCIZ에는 ‘끝이 Z(ero)인 ASCII’라는 의미를 가진다. ASCIZ의 문제점 strcat을 구현하는 과정이 러시아 페인트공 알고리즘을 사용하고 있다....
누구도 일정을 짜지 않는 이유 일정을 짜는 작업 자체가 고통스럽다. 아무도 일정을 짜는 작업에 의미가 있다고 생각하지 않는다. 일정은 항상 틀린다는 선입견이 있다. 일정을 손쉽게 잘 짜는 방법 마이크로소프트 엑셀을 사용합시다 단순하게 만듭니다 각 기능은 과업 여러 개를 포함해야만 합니다 담당 프로그래머만이 제대로 일정을 짤 수 있습니다 과업을 세부적으로 나누십시오 과업을 세부적으로 쪼개다보면, 어떻게 진행할지 구체적인 단계를 생각하게 된다. 세부적으로 과업을 나누다보면 기능을 설계하지 않을 수 없게된다. 경험적인 규칙에 따르면, 각 과업은 적게는 2시간에서 많게는 16시간 이내에 처리할 수 있어야한다....
명세 작성자는 개발자가 명세를 읽도록 유도할 필요가 있다. 명세서를 읽도록 사람을 유인하는 방법은 일반적으로 글쓰기 실력과 밀접환 관련이 있다. 규칙1: 재밌게 씁시다 명세를 읽게 유도하는 규칙 1번은 즐거운 경험을 누리게 만드는 것이다. 규칙2: 명세를 쓰는 작업은 머리가 돌아가도록 코드를 쓰는 작업과 유사하다 명세를 쓸 때 놓치기 쉬운 점은, 올바른 작성을 물론이거니와 이해하기 쉽도록 작성해야 한다는 점이다. 사람은 우선 동기부여가 되지 않으면 타인이 말하려는 내용을 이해하려 하지 않는다. 무언가를 해석하기 보다는 단지 순서대로 읽고 이해하기를 원한다....
누가 명세를 작성합니까? 팀 내에 프로그래머가 n명 있다면, 상호 대화 경로는 결국 O(n^2)이 된다. 마이크로소프트 사에서는 마스터 프로그래머 개념을 사용했다. 마스터 프로그래머가 모든 코드를 작성하는 책임이 있으며, 부하 프로그래머로 이뤄진 팀은 단순히 ‘코드 조력자’로 이용한다. 모든 개발자가 서로 이야기할 필요가 없으며, 모든 부하 프로그래머는 상간인 프로그램 관리자 한 명과 이야기하면 되기 때문이다. 상호 대화 복잡성은 O(n)으로 줄어들 것이다. 하지만 누구도 단순한 코드 조력자로만 남기를 원하지 않았다. 프로그램 관리자를 어떻게 뽑을까요? 코드 개발자를 프로그램 관리자로 승급시키지 마세요....
기능 명세 vs 기술 명세 5장에서 이야기 했던 명세는 기능 명세에 해당한다. 기능 명세(functional specification) 사용자 관점에서 젶무이 어떻게 동작할지를 기술 구현은 신경 쓰지 않는다. 화면, 메뉴, 대화 상자 등 기술 명세(technical specification) 프로그램 내부 구현을 기술한다. 자료 구조와 관계 형 데이터베이스 모델과 프로그래밍 언어, 도구, 알고리즘 선택과 같은 항목을 다룬다. 명세서에 넣는 단골 항목 면책 조항: 현재 명세가 완벽하지 않다는 것을 알리는 방어적 내용. 저자: 명세에서 무엇인가 잘못된다면, 이를 수정할 책임있는 명세서 소유자를 지정해야 하며, 이 사람 이름이 명세서에 찍혀 있어야 한다....
명세서 작업의 가장 중요한 결실은 바로 프로그램 설계다. 프로그램이 세부적으로 어떻게 동작하는지를 기술하다 보면, 자연스럽게 프로그램을 설계하게 된다. 의사소통 시간의 절약이다. 명세서 작업을 할 때, 프로그램을 어떻게 동작하게 할지만 알려주면 되고, 함꼐 일할 팀원은 이 명세서만 읽으면 된다. 세부 명세서 없이는 일정을 계획하기가 불가능하다. 명세서 작업은, 명세서가 없다면 묻혀버릴 모든 결정 사항을 못박아 버리는 방법이다.
ASCII 7비트로 영문자만 처리하는 문자 인코딩 대다수 컴퓨터가 8비트인 바이트 단위를 사용하므로, ASCII 문자를 저장하고 비트를 하나 더 확보할 수 있었다. 워드스타에서는 32미만인 코드는 인쇄 제어 목적으로 사용했다. IBM PC는 OEM 문자집합을 고안했는데, 이는 유럽 언어를 위한 몇몇 강조문자와 선그리기 문자를 사용할 수 있었다. 하지만 미국 이외의 지역에서 PC를 판매하기 시작하면서 온갖 OEM 문자 집합 형식이 나오기시작했으며, 각자 요오에 맞춰 128글자를 정의했따. ANSI 표준 위원회에서느 ANSI 표준을 체계적으로 정리함에 따라 OEM 난투극이 끝났다....
“코드 재사용은 좋다. 바퀴 재발명은 나쁘다"는 항상 맞는 말은 아니다. 적어도 핵심 비즈니스 기능과 목표는 파악한 후 직접 수행해라.
세상에 쉬운 일은 없다 항상 위험을 줄여라 위 둘을 해결하기 위해서는, 구현에 앞서 설계를 해야한다. 설계를 하지 않고 구현하면, 수정하는데 더 많은 시간을 사용할 수 있다. 점진적인 설계과 구현은 좋다. 형식에 지나치게 얽매이는 설계는 시간낭비다.
방법론을 조심하라. 방법론은 쓸만한 수준으로 그저 그런 성능을 내는 데는 괜찮은 방법이 될 수 있지만, 동시에 유능한 인재를 쫓아낼 수도 있다.
자기 업무에 대해 훨씬 더 신중한 태도를 지녀야 한다. 자기가 맡은 업무에 대해 최고 결정권을 가지는 곳이 일하기 좋은 곳이다.
조직 내에서 변화를 시도할 만한 결정권이 없는 사람도 있을 것이다. 혼자라도 하십시오 한 사람의 힘이라도 프로젝트르 개선할 여지가 많다. 입소문의 힘을 이용하십시오 조엘 테스트 중 많은 항복은 팀이 비협조적이더라도 혼자 실천할 수 있다. 그 중 성공적인 항목은 분명히 나머지 팀원에게 퍼지게 돼있다. 우수한 인재를 모으십시오 채용과 인터뷰 업무에 참여하세요. 우수한 인재가 여러분 팀에 합류하도록 홍보해라. 개선할 의지와 능력이 있는 사람을 찾아 같은 편으로 만들어라. 뒤처진 팀원이 있으면 배울 기회를 주세요....
dog fooding: 자기회사 제품을 실제로 사용해 보는 과정 고객 입장에서 제품을 실행해보니 버그가 바로 눈에 띄었다. 고객 입장에서 사용 편의성을 직접 이해할 수 있다.
아래는 소프트웨어 팀이 얼마나 업무를 잘 수행하고 있는지 판단하는 조엘의 비공식적인 평가테스트 방법이다. 소스코드 관리시스템을 사용하고 있습니까? 소스코드 관리시스템을 사용하지 않으면, 다른 프로그래머가 무엇을 했는지 알 길이 없으며, 실수르 쉽게 되돌릴 수 없다. 한방에 빌드를 만들어낼 수 있습니까? 빌드 프로세스가 한 단계로 끝나지 않을 경우, 실수하기가 쉽다. 출시 날짜가 가까워질 수록 ‘마지막’ 버그를 수정하고 최종 EXE 파일을 생성하는 사이클을 짧게 유지해야 한다. 일일 빌드를 하고 있습니까? 빌드가 꺠진 문제성 코드를 우연히 체크인하는 경우, 다른 직원을 작업을 진행할 수 없게된다....
마이크로소프트가 장기간 살아남은 이유는 치명적이고도 아둔한 실수를 저지르지 않았기 때문이다. 실수 중 대다수는 기술관련 지식이 없는 비즈니스 쪽 사람이 기술적인 기본 사실을 이해하지 못하기 때문에 발생한다. 프로그래머를 조타수로 두지 않는 소프트웨어 회사는 결코 성공할 수 없다. 그러나 프로그래머가 저지른 실수 또한 많다. 소프트웨어 비즈니스에서 성공하려면 프로그래밍에 해박한 동시에 비즈니스도 이해하고 좋아하는 관리층이 있어야한다.
측정 역기능: 지식 노동자의 효율을 측정하려 들면 모든 질서가 급격히 붕괴돼버린다. 직원을 완전히 통제할 수 없을 떄 측정 역기능이 필연적으로 발생핟나.
프로그래밍 작업을 더 쉽게 만들어 준다는 추상화 작업을 마쳤더라도 위대한 프로그래머가 되기 위해 알아야 하는 지식이 날로 늘어나고 있다. 허술한 추상화는 우리가 하키 스틱처럼 생긴 학습 곡선에 따라 살아가는 사실을 의미한다. 일주일만 배우면 활용하는데 필요한 90%를 배울 수 있다. 하지만 나머지 10%는 몇 년이 걸려야 겨우 따라잡을 수 있다. 한 세계에서만 살아본 사람이 다른 세상에 존재하는 복잡성에 대한 이야기를 들을 떄마다, 자신이 속한 세계는 복잡하지 않다는 생각이 든다. 소프트웨어 제작과정에서 의존할 언어 클래스, API, 플랫폼 등에 대해 몇년간 옹골진 경험이 있는 아키텍트를 한 명이라도 확보하지 못했다면 새로운 프로젝트를 시작하지 마십시오....
추상화: 아랫부분에서 일어나는 아주 복잡한 어떤 작요을 간소화하는 방법 수많은 컴퓨터 프로그래밍은 추상화 요소를 포함하고 있다. 허술한 추상화의 법칙: 모든 쓸 만한 추상화에는 어딘가 구멍이 존재한다. 허술한 추상화의 법칙은 추상화가 의미하는 바와는 달리 우리 삶을 정말로 단순화시키지 못한다는 사실을 의미하기 떄문에 문제가 된다. 무언가를 추상화하는 듯이 보이는 코드생성 도구는 구멍이 있으며, 이런 구멍을 제대로 메워주는 유일한 해결책은 추상화 동작원리와 추상화 대상을 배우는 방법뿐이다. 추상화는 그저 일하는 시간을 절약해주지만, 배우는 시간을 절약해주지는 못한다....
고객은 자신이 원하는 내용이 뭔지 모른다. 고객이 자신이 원하는 내용이 뭔지를 알아내길 기대하지 마라. 멋진 사용자 인터페이스는 실제 프로그래밍 작업의 10%를 차지할 뿐이고, 나머지 90%의 작업은 보이지 않는 물밑에 가라앉아 있다. 프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘 못 만들어진 화면을 보여주면, 사람들의 전체 프로그램의 90%가 잘못됐다고 생각한다. 프로그래머가 아닌 사람에게 아름다운 사용자 인터페이스로 100% 무장한 화면을 보여주면, 프로그램이 거의 다 끝났다고 생각할 것이다. 멋지고 산뜻하게 다듬었으나 분량이 네 페이지인 웹 사이트를 운영하는 닷컴은, 3700여년에 이르는 자료로 무미건조하게 꾸며놓았지만 실용적인 사이트보다 훨씬 더 높은 평가를 받을 것이다....
프로그래머가 항상 코드를 버리고 새로 시작하기를 원하는 미묘한 이유가 있다. 예전 코드가 엉망진창이라는 생각 떄문이다. 예전 코드가 엉망진창이라는 생각은 다음과 같이 기본적이며 근원적인 프로그래밍 법칙때문에 생긴다. “코드 쓰는 작업보다 읽는 작업이 더 어렵다” 함수가 점점 길어지고 비대해지는 이유는 버그 수정 때문이다. 코드를 버리고 새로 시작하면, 여기에 속한 노하우도 모두 버려야 한다. 이미 존재하는 코드를 다시 작성하느라 쓸데없이 많은 돈을 낭비하는 셈이다. 프로그래머가 작성한 코드를 완전히 엉망진창이라고 말할 때, 이와 관련해서 잘못된 이유가 세가지 있다....