We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)
우리는 조그마한 효율성에 대해 고민할 필요가 없다. 대략 97%의 경우, 어설픈 최적화는 모든 악의 근원이라 말하고 싶다.
소프트웨어란 개발된 양이 아닌 실행되는 순간의 가치로 판단되어야 한다. - 김국헌. 컬럼 'IT강국의 허상을 넘어서' 중
컴퓨터는 믿기지 않을 정도로 빠르고, 정확하고 바보스럽다. 사람은 믿기지 않을 정도로 느리고, 부정확하고 뛰어나다. 둘이 힘을 합치면 상상할 수 없는 힘을 가질 수 있다. -앨버트 아인슈타인
최고의 아키텍처는 상아탑의 '아키텍트’에게서 나오지 않습니다. 공동의 노력을 기울여야 최고의 아키텍처가 나옵니다. 전문가 한 명이 독주해서 완성한 아키텍처 문서를 여러분 앞에 던져 놓고 가게 하지 말고, 팀이 함께 일해서 모든 이의 경험을 발휘하고 쌓아나가도록 하세요. - Ship it 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드
The cheapest, fastest, and most reliable components of a computer system are those that aren’t there. - Gordon Bell
세상에 가장 흐린 먹물도 가장 좋은 기억력보다 낫다. - 실용주의 프로그래머 중
앞으로 대규모 생산성 증가는 오직 소프트웨어의 본질적 어려움(복잡성, 일치성, 변화가능성, 비가시성)들을 해결할 때만 이루어 질 수 있다. - 스티브 맥코넬
오늘날의 프로그래밍은 소프트웨어 엔지니어와 우주가 경쟁을 벌이는 양상으로 진행되고 있다. 소프트웨어 엔지니어는 바보조차 쉽게 사용할 수 있는 프로그램을 만들기 위해 노력하고, 우주는 바보를 만들어낸다. 적어도 지금까지는 우주가 승리를 거두고 있다. - 리치쿡 ( '뉴욕의 프로그래머’에서 인용된 내용)
건물을 짓는 사람들이 프로그래머가 소프트웨어를 제작하는 방식으로 건물을 짓는다면, 창공에서 날아온 첫 번째 딱따구리는 전 인류의 문명을 파괴할 것이다. - 와인버그의 두번째 법칙
소프트웨어 개발은 흥미진진한 것이다. 그렇지 않다면 그 프로젝트는 잘못된 것이다. 소프트웨어 개발은 예술,과학,그리고 공학을 정교하게 섞는 기술, 즉 장인정신이다. 그것은 단지 일이 아니다. 그것은 일에 대한 열정이다. - 피트 맥브린
우리는 모델을 만들고, 그 모델이 다시 우리를 만든다. - 피에트 하인(Piet Hein)
좋은 디자인은 자연을 닮았다. 자연을 닮은 것이 본질적으로 좋은 이유는 자연이 이미 오랜 세월 동안 문제를 해결하기 위해서 노력해 왔기 때문이다. 그렇기 때문에 어떤 답이 자연을 닮았다면 그것은 항상 좋은 신호다. - 폴 그레이엄, 해커와 화가 중
예제는 아무리 많아도 지나치지 않다. (포넬리의 법칙) - 제리 포넬리(Jerry Pournelle) Byte.com의 수석 칼럼니스트
컴퓨터 과학의 거의 모든 문제는 또 다른 간접지정 수준(level of indirection)을 통해서 해결될 수 있다. -실용주의 프로그래머(?)
품질이란 누가 보지 않을 때에도 제대로 돌아가는 걸 뜻 한다. - 헨리포드
컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴파울러 (리팩토링 중)
프로그램은 오직 사람이 읽기 위해서 작성되어야 한다. 컴퓨터가 그것을 실행하는 것은 부차적인 일이다. - 컴퓨터 프로그램의 구조와 해석(Structure and Interpretation of Computer Programs) 서문
페어프로그래밍이 의미를 갖는 것은 물론 공평한 규칙이 지켜지는 것에 한해서이다. 공평한 규칙의 요소는 '실력’이 아니라 '열정’이다. 프로그래밍 실력은 차이가 나도 페어프로그래밍을 수행하는데 아무 상관이 없다. 그렇지만 열정의 수준은 동등해야 한다. - 임백준 ( '뉴욕의 프로그래머’에서)
개발자들이 문제점을 이야기하면 고객은 질책을 한다. 고객이 중요한 사항을 이야기하면 개발자는 무시한다. -켄트 백(Kent Beck)
동료검토(Peer Review)는 기술적인 측면과 사회적인 측면을 모두 가진다. 한쪽을 무시하고 다른 한쪽에만 치우치면 큰 실패를 초래한다.
소프트웨어 문제에 대해서 최상의 솔루션이 하나인 경우는 거의 없다. - 로버트 L 글라스, 소프트웨어 공학의 사실과 오해
자기가 짠 코드에서 버그를 찾는 것은 매우 어려운 일이다. 자기가 짠 코드에 버그가 없다고 생각할 때는 더욱 그러하다. - 스티브 맥코넬
눈이 많으면 찾지 못할 버그는 없다. - 에릭레이몬드
누락된 요구사항은 가장 수정하기 힘든 오류다. - 로버트 L 글라스, 소프트웨어 공학의 사실과 오해
컴퓨터 사이언스를 가르치는 교육이 어떤 사람을 전문적인 프로그래머로 만들지 못하는 것은, 붓질과 채색방법을 가르치는 교육이 어떤 사람을 전문적인 화가로 만들지 못하는 것과 같다. - 에릭레이먼드, 해커와 화가 중
프로그래밍에서는 평균적인 수준의 노동력을 유지하는 것보다 영감이 샘물처럼 솟아나는 소중한 순간을 놓치지 않는 것이 중요하다. 그래서 프로그래머에게 자유는 생명이다. - 임백준
프로그래머로서 일하는데 있어서 중요한 것은 주어진 질문에 대한 정답을 찾는 능력이 아니라, 질문 자체를 정확하게 구성하는 힘이다. - 임백준
유능한 프로그래머는 그의 두뇌가 가지고 있는 한계를 또렷이 의식하는 사람이다. 그러한 한계를 알기 때문에 그는 프로그래밍을 언제나 겸허한 자세로 대하며, 영특한 꾀를 부리는 거은 그것이 흑사병이라도 되는 것처럼 극구 피한다. - 애드가 디지크스트라
어린 시절에 어셈블리(Assembly)어를 한 번쯤 해킹해 보지 않는 사람은 열정이 부족한 사람이다. 어른이 되어서 어셈블리어를 해킹하는 사람은 두뇌가 부족한 사람이다. - 준 무어
기술이 보안 문제를 해결할 수 있다고 생각한다면, 문제도, 기술 자체도 이해하지 못한 것입니다. - 브루스 슈나이더
초과근무 시간 증가는 생상성 감소 기법이다. 스트레스를 받는 사람들은 머리가 빨리 돌아가지 않는 법이다. - 톰 디마르코(Tom Demarco)
아홉 명의 여자가 투입된다고 해서 아기를 한 달만에 낳을 수는 없다. - Fredrick P.Brook, The Mythical Man-Month
변경을 허용하지 않는 것은 나쁜 계획이다. - 푸볼릴리우스 시루스
하루를 잃는데는 수없이 많은 방법이 존재하지만, 하루를 만회하는 데는 단 한가지방법조차도 존재하지 않는다. -톰 디마르코
지연되는 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다. - 프레드릭 부룩스(Mythical Man-Month에서 )
가장 해볼만한 가치가 있는 프로젝트는 당신 회사의 프로세스 레벨을 완전히 한 등급 낮춰 줄 그런 프로젝트이다. -탐디마르코, 피플웨어
관리자가 진정해야 하는 일은 사람들에게 일을 시키는 것이 아니라 그들이 일에 전념할 수 있는 환경을 만들어 주는 것이다. -탐디마르코, 피플웨어
업무에서 발생하는 문제들은 대부분 기본적으로 기술의 문제가 아니라 조직사회학의문제다. -탐디마르코, 피플웨어
사람들이 업무의 인간적인 측면보다 기술적인 측면에 주로 매달리는 가장 큰 이유는 기술적인 부분이 더욱 중요하기 때문이 아니라 거기에 매달리는 것이 훨씬 더 쉽기 떄문이다. -탐디마르코, 피플웨어
많은 프로젝트의 성공과 실패는 어떻게 수행하는가보다 누가 수행하는가에 따라 결정된다. - 로버트 L 글라스, 소프트웨어 공학의 사실과 오해
대부분의 프로젝트는 기술이 아니라 인적 자원과 프로젝트 관리의 문제로 실패한다. - R. Thomsett
높은 사람에게 데모를 하면 할수록 성공율이 낮아진다. - Dan
버그 리포트를 받으면 먼저 그 버고를 밖으로 드러나게 할 수 있는 단위테스트를 작성하라. - 리팩토링
프로그래밍 솜씨가 뛰어난 사람일수록 자신의 코드를 믿지 못하여 반복해서 테스트를 수행하고, 프로그래밍 솜씨가 떨어지는 사람일수록 자신의 코드가 완벽하다는 순진한 믿음을 갖는다. - 임백준
프로그램을 작성할 때 습관적으로 유닛테스트 코드를 작성하는 사람과 그렇지 않은 사람 사이엔 그 자체로 이미 프로그래머로서 가능함기 어려울 만큼 깊은 수준차가 존재하는 것이다. 자기 화사의 업무 환경이 특별히 열악하기 때문에, 혹은 시장에서의 경쟁이 치열하기 때문에 개발 일정을 넉넉하게 가질 수 없고, 따라서 유닛테스트 코드를 작성할 시간이 정말 없다고 말하는 사람이 있다. '어차피 테스트 팀에서 테스트를 할 텐데, 얼른 완성해서 그쪽으로 넘기는 것이 더 낫지 않겟어?' 시간이 부족하다는 변명과 유닛테스트라는 개념에 대한 혼동은 확실히 취향의 문제가 아니라 수준의 문제이다. 유닛테스트를 작성하는 것은 실제 기능을 구현하는 것보다 더 재미있다. 일단 맛을 들이고 나면 정말 그렇다. 유닛테스트 코드를 작성하는 것이 습관이 된 사람들은 유닛테스트의 옷을 입지 않은 벌거숭이 코드를 작성하는 것이 불안하게 느껴진다. 유닛테스트에 중독이 되었기 때문이다. 하지만 그것은 건강하고 유용한 중독이다. 이 달콤한 중독의 맛을 아직 모르는 사람은 안타깝게도 프로그래밍의 맛을 반밖에 모르는 사람이다.
테스트 될 수 없다면, 요구하지도 말라 - 켄푸
소프트웨어를 디자인할 때는 저는 건축가입니다. 유저 인터페이스를 디아니할 때는 예술가이며, 구현할 때는 장인이 됩니다. 하지만 테스트를 할 때는 아마 쳐죽일 놈이 될 것입니다. - 스티브 맥코넬