본문 바로가기
[실용주의 프로그래머] 위대한 유산 [실용주의 프로그래머] 위대한 유산 -현실적으로 프로젝트의 성공은 사용자들의 기대를 얼마나 잘 충족하는가에 따라 측정된다.그들의 기대에 못 미치는 프로젝트는 이론적인 면에서 결과물이 얼마나 훌륭하건 간에 상관없이 실패로 간주된다.기대를 너무 지나쳐 버려도 역시 실패할 것이다. -사용자의 기대를 부드럽게 넘어서라. -기대를 상호 소통해야 한다.사용자들과 함께 일해서 장차 여러분이 어떤 것을 넘겨줄 것인지 그들이 정확히 이해하도록 해라.그리고 개발 과정 전체에 걸쳐 그렇게 하라.앱이 해결하기로 한 비지니스 문제에 대해 절대로 눈을 떼지 마라. -우리의 역할은 사용자들의 희망을 제어하는 게 아니다.그들과 협동해서, 그들이 아직 이야기하지 않은 기대까지도 포함해서, 개발 과정과 최종 전달물에 대한 공통된 이해에.. 2018. 11. 17.
[실용주의 프로그래머] 결국은 모두 글쓰기 [실용주의 프로그래머] 결국은 모두 글쓰기 -아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다 - 중국 속담 -프로젝트에서 생산되는 문서에는 기본적으로 내부, 외부의 두 종류가 있다.내부 문서에는 소스코드, 주석, 설계와 테스트 문서 등이 포함된다.누구를 독자로 생각하는지, 또는 작가의 역할(개발자 혹은 테크니컬 라이터)이 무엇인지 불문하고, 모든 문서는 코드의 거울이다.불일치가 있다면 중요한 것은 코드다. 좋건 나쁘건. -문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어넣으려고 하지 말라. -코드에는 주석이 있어야 하지만, 너무 많은 것은 너무 적은 것만큼이나 좋지 않다. -일반적으로 주석은 왜 이렇게 되어 있는지, 그 목적을 논해야 한다. 코드가 이미 어떻게 되어 있는지 보여 주기 때문에 이에.. 2018. 11. 16.
[실용주의 프로그래머] 가차 없는 테스트 [실용주의 프로그래머] 가차 없는 테스트 -개발자 대부분은 테스트를 싫어한다.코드가 어디에서 깨지는지 무의식적으로 알고 약한 지점을 피해 다니면서, 살살 테스트하려 한다.실용주의 프로그래머들은 다르다.우리는 당장 버그를 찾아 나서도록 내몰리지만, 그 대신 나중에 다른 사람이 자기 버그를 발견하게 되는 수치를 피할 수 있다. -일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라. -코드를 작성하자마자 테스트해야 한다. -버그가 빨리 발견될수록 고치는 비용이 적어진다.코드 조금, 테스트 조금은 스몰토크 세계에서는 유명한 격언이다.우리는 제품 코드를 만드는 것과 동시에(혹은 이전에) 테스트 코드를 만듦으로써 그 주문을 우리것으로 할 수 있다. -사실 훌륭한 프로젝트에는 제품 코드보다도 테스트 코드가 더 많.. 2018. 11. 15.
[실용주의 프로그래머] 유비쿼터스 자동화 [실용주의 프로그래머] 유비쿼터스 자동화 -생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다. - 알프레드 노스 화이트헤드 -수작업 절차를 사용하지 말라. -사람들은 컴퓨터만큼 반복가능하지 않을 뿐더러, 그런 것을 기대해서도 안 된다.쉘 스크립트나 배치 파일은 동일한 명령들을 매번 똑같은 순서로 수행한다.이걸 소스코드 관리 시스템에서 관리할 수 있기 때문에 시간이 지남에 따라 그 절차가 어떻게 변했는지도 조사할 수 있다. -또 다른 인기 있는 자동화 도구는 cron(윈도우는 at)이다.이것으로 무인 작업이 주기적으로(일반적으로 한밤중에) 실행되게 일정을 설정해 놓을 수 있다. -프로젝트 컴파일, 확인, 테스트, 출하를 자동화 하라 -코드 생성을 자동화 하라. -회귀 테스트를 자동.. 2018. 11. 14.
[실용주의 프로그래머] 실용주의 팀 [실용주의 프로그래머] 실용주의 팀 -깨진 창문을 없애라.품질은 팀의 이슈다.만약 가장 부지런한 개발자라 해도 품질에 무심한 팀에 배치된다면 귀찮은 문제를 고치는 그의 열정은 줄어들 것이다. -팀 전체가 깨진 창문(아무도 고치려고 하지 않는 사소한 결점)을 용납하지 않아야 한다.팀은 상품의 품질에 책임을 져야만 한다.팀은 '깨진 창문을 없애라' 철학을 이해하는 개발자들을 지원하고 그렇지 못한 개발자들은 이해하도록 격려해야 한다. -개인보다는 팀이 삶은 개구리가 되기 쉽다. (서서히 도태된다.)사람들은 누군가가 문제를 처리하겠거니 생각하거나, 사용자가 요구하는 변화에 대해 팀 리더가 이미 오케이 했거니 하고 여긴다.제 아무리 단단히 통제되는 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에 대해 둔감할 수.. 2018. 11. 13.
[실용주의 프로그래머] 동그라미와 화살표 [실용주의 프로그래머] 동그라미와 화살표 -개발 실천방법과 개발 능력의 맥락 안에 그것을 넣어보지도 않고 맹목적으로 받아들이는 것은 단지 실망을 맛보기 위한 비법이다. 형식적 방법의 노예가 되지 마라. -대부분의 형식적 방법은 다이어그램과 거기에 추가된 설명의 조합을 이용해서 요구사항을 포착한다.이런 그림들이 요구사항에 대한 설계자의 이해를 표현한다.하지만 대개의 최종 사용자는 이런 다이어그램들을 전혀 이해하지 못하므로, 설계자가 해석해 주어야 한다.따라서 실제 시스템의 사용자들이 정말 형식적 확인을 통해 요구사항을 점검하는 일은 없는 셈이다. -형식적 방법들은 전문화를 권장하는 것처럼 보인다. 한 집단은 데이터 모델 작업을 하고, 다른 집단은 아키텍처를 보는 동안, 요구사항 수집자들은 유스 케이스를 모.. 2018. 11. 12.
[실용주의 프로그래머] 명세의 함정 [실용주의 프로그래머] 명세의 함정 -프로그램 명세화란 어떤 요구사항을 가져와 프로그래머가 자기 기술로 작업을 시작할 수 있는 시점까지 정리하는 과정이다.명세화는 주요한 모호함들을 제거하는 등의 방법으로 세계를 설명하고 명확하게 만드는 의사소통의 한 행위다.명세는 맨 먼저 구현할 개발자들과 하는 대화일 뿐만 아니라, 코드를 유지보수하고 개선할 미래의 프로그래머들을 위한 기록이다.명세는 사용자와 하는 약속이기도 하다. 즉 사용자의 필요를 명문화한 것이며 최종시스템이 그요구사항과 일치할 거라는 암묵적인 계약이기도 하다. -명세의 작성에는 굉장히 무거운 책임이 따른다.문제는 많은 설계자들이 명세서 작성을 멈추지 못한다는 점이다. 설계자들은 사소한 세부사항까지도 고난에 차도록 시시콜콜하게 밝혀놓지 않는 한 그날.. 2018. 11. 11.
[실용주의 프로그래머] 준비가 되어야만 [실용주의 프로그래머] 준비가 되어야만 -어떤 일을 뛰어나게 수행하는 사람들은 공통점이 하나 있다.그들은 언제 시작해야 하고 언제 기다려야 하는지 안다. 만약 앉아서 키보드를 치기 시작했는데 마음속에 어떤 의심들이 자꾸 거슬린다면 그 느낌을 따르라. -준비가 되었을 때 시작하라. -자신이 단지 늑장부리고 있는지, 모든 조각들이 올바른 장소로 맞아 들어가기를 책임감 있게 기다리고 있는지 어떻게 판단할 수 있을까?효과를 볼 수 있는 기법은 프로토타이핑을 시작하는 것이다.어려울 것 같은 부분을 고른 다음, 일종의 개념 입증용 코드를 작성해보라. 보통 다음 둘 중 하나가 일어난다.1. 시작한지 얼마 되지 않앗는데 시간을 낭비하고 있다는 느낌이 들기 시작한다. 이렇게 지루함을 느끼는 것은 아마 처음의 머뭇거림이 .. 2018. 11. 10.
[실용주의 프로그래머] 불가능한 퍼즐 풀기 [실용주의 프로그래머] 불가능한 퍼즐 풀기 -퍼즐을 푸는 비법은 (상상 속이 아닌) 실제의 제약 조건을 알아내고, 그 속에서 해법을 찾는 것이다어떤 제약 조건은 절대적이지만, 다른 것들은 단순히 지례 짐작한 것들에 불과하다.절대적 제약 조건에 대해서는, 그것이 아무리 불쾌하거나 멍청해 보이건 간에 경의를 표해야만 한다.반면에 그럴싸해 보이는 제약 조건들이 사실은 실질적 제약 조건이 전혀 아닐 수도 있다. -어떤 퍼즐이든 그것을 해결하는 열쇠는 제약을 인식하는 것과 더불어 여러분에게 주어진 자유의 정도가 얼마나 되는지도 깨닫는 것이다. 퍼즐의 해답은 그 자유의 정도 안에서 발견된다. -생각의 틀을 벗어나지 말고, 틀을 찾아라 -풀리지 않는 문제와 마주쳤다면, 생각해 볼 수 있는 모든 가능한 해결 경로를 눈.. 2018. 11. 9.
반응형

티스토리툴바