본문 바로가기
[실용주의 프로그래머] 요구사항의 구렁텅이 [실용주의 프로그래머] 요구사항의 구렁텅이 -완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 빼낼 것이 없을 때 얻게 되는 것이다. - 생택쥐페리 -요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 깊이 묻혀져 있다. -요구사항을 수집하지 말고 채굴하라. -어느 것이 진정한 요구사항인지 어떻게 분간할 수 있을까?요구사항이란, 어떤 것이 성취되어야 한다는 진술이다. ex) 직원 기록은 지명된 사람들만 볼 수 있다. 해당 직원의 관리자와 인사부에서만 그의 기록을 열람할 수 있다. -> 비지니스 정책이 내포된 진술로 수시로 바뀔 수 있다. 요구사항에 이를 고정하는 건 그리 좋은 생각이 아니다.실린더헤드 온도는 임계값을 넘으면 안 되며, 이는 엔진마다 다르.. 2018. 11. 8.
[실용주의 프로그래머] 사악한 마법사 [실용주의 프로그래머] 사악한 마법사 -마법사를 이용한다고 평범한 개발자가 자동으로 동등한 수준의 전문가가 되지는 않는다.자신을 위해 만들어진 코드를 정말로 이해하지 못하는 한, 그는 자기 자신을 속이는 것이다. 그는 우연에 맡기는 프로그래밍을 하고 있다.마법사는 일방통행 길과 같다.여러분을 위해 코드를 만들어 주고, 그걸로 끝이다.마법사가 만들어 준 코드가 지금 상황에 맞지 않다면, 또는 상황이 바뀌어서 코드를 변경해야 할 필요가 생긴다면, 여러분 혼자 힘으로 해야 한다. -자신이 이해하지 못하는, 마법사가 만들어 준 코드는 사용하지 말라. -마법사 코드는 깔끔한 인터페이스 뒤로 옮겨놓을 수 없다.마법사가 생성한 코드는 평범한 개발자가 작성하는 기능과 줄 단위로 섞인다.결과적으로, 그 코드는 마법사의 .. 2018. 11. 7.
[실용주의 프로그래머] 테스트하기 쉬운 코드 [실용주의 프로그래머] 테스트하기 쉬운 코드 -소프트웨어를 만들 때 맨 처음부터 테스트 가능성을 만들어 넣고, 코드들을 서로 연결하기 전에 코드를 하나하나 철저하게 테스트해야만 한다. -모듈을 통제(control)된 환경에서 철저하게 테스트하고 나면, 더 넓은 환경에서 그 모듈이 어떻게 행동할 것인지 더 감을 잡을 수 있다. 소프트웨어 단위 테스트란 어떤 모듈에게 이것저것을 시켜보는 코드를 가리킨다.일반적으로, 단위 테스트는 일종의 인위적인 환경을 구축한 다음, 테스트할 모듈의 루틴들을 호춣한다.그런 다음 반환된 결과들을 이미 알고 있는 값과 비교해 보거나 똑같은 테스트를 이전에 돌렸을 때 나온 값과 비교해보아서(회귀 테스트(regression testing)) 올바른지 검사한다. -대개 프로그래머들은 .. 2018. 11. 6.
[실용주의 프로그래머] 리팩터링 [실용주의 프로그래머] 리팩터링 -코드가 더 이상 잘 맞지 않아서 장애물에 부딪혔을 때, 사실은 하나로 합쳐져 있어야 할 두 개를 발견했을 때, 어떤 것이든 ‘잘못’ 되었다고 생각될 때, 그것을 변경하는 일을 주저하면 안 된다. 언제나 바로 지금이 최적기다. 어떤 것이라도 코드를 리팩터링해야 할 이유가 될 수 있다. 중복, 직교성이 좋지 않은 설계, 유효기간이 끝난 지식, 성능 -코드를 리팩터링하는 것은 사실 고통 관리(pain management)를 실천하는 것이다.현실을 피하지 말자. 소스코드를 이곳저곳 변경하는 것은 굉장히 고통스러운 작업일 수도 있다.거의 작동하는 수준까지 올려놓은 코드였는데, 이제 완전히 망가져 버린다.코드를 산산조각으로 해체하는 일을 주저하는 개발자들이 많은데, 그 까닭은 그런.. 2018. 11. 5.
[실용주의 프로그래머] 알고리즘의 속도 [실용주의 프로그래머] 알고리즘의 속도 -실용주의 프로그래머가 거의 날마다 사용하는 추정이 있다.알고리즘이 사용하는 자원, 곧 시간, 프로세서, 메모리 등등을 추정하는 것이 그것이다.대문자 O 표기법(big O notation)이라고 불리는 근사값을 기록하는 방식을 이용하면 답을 찾을 수 있는 경우가 많다. -일반적으로 입력의 크기는 알고리즘에 영향을 준다. 입력의 크기가 클수록, 알고리즘의 수행시간이 길어지거나 사용하는 메모리 양이 늘어난다. -알고리즘과 시간의 상관관계가 선형적이라면(늘어나는 시간이 입력값과 비례한다면) 큰 상관이 없다.그러나 알고리즘은 대개 선형적이지 않다.선형보다 더 적은 경우도 있지만, 훨씬 많은 경우도 많다. -우리는 반복문이나 재귀 호출을 담고 있는 코드를 작성할때면 언제나 .. 2018. 11. 4.
[실용주의 프로그래머] 우연에 맡기는 프로그래밍 [실용주의 프로그래머] 우연에 맡기는 프로그래밍 -일단 코딩에 들어가면 대부분 기계적으로 따라가야 하는 일, 곧 설계 내용을 컴퓨터가 실행할 수 있는 문장으로 바꾸는 일만 남는다는 생각이 일반적이다.이런 태도가 우리 생각에는 보기 흉하고, 비효율적이고, 구조가 엉망이고, 유지보수하기 힘들고, 한마디로 완전히 잘못된 프로그램이 그렇게나 많게 된 가장 큰 원인이다. -적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍(programming by coincidence)을 하는 것이다. -실용주의 프로그래머는 모든 코드를 비판적인 눈으로 바라보는데, 자기 자신의 코드도 예외가 아니다.우리는 스스로 만든 프로그램과 설계에서 언제나 개선할 여지가 남아있음을 느낀다. -여러분이 코드를 작.. 2018. 11. 3.
[실용주의 프로그래머] 칠판 [실용주의 프로그래머] 칠판 -칠판 접근방법의 몇가지 중요한 특징은 다음과 같다. 어떤 형사도 다른 형사들의 존재를 알 필요가 없다. 형사들은 칠판을 보며 새로운 정보를 얻으며 자기가 발견한 것을 추가해 쓴다.형사들은 저마다 서로 다른 종류의 훈련을 받았거나, 다른 수준의 교육과 경험을 지녔을 수 있으며, 아예 같은 관할구역에 속하지 않을 수도 있다. 사건을 해결하고 싶은 마음은 모두에게 있지만, 공통점은 그뿐이다.수사 과정에서 여러 형사들이 들어오거나 나갈 수 있고, 임무 교대 시간도 제각기 다를 수 있다.무엇을 칠판에 올려도 되는지에 대한 제한이 없다. 사진, 증언, 물리적 증거 등등 어떤 것이라도 상관없다. 칠판 구현 -일반적인 분산 앱을 작성할 때는 시스템 내부의 모든 분산 트랜잭션과 상호작용마다.. 2018. 11. 2.
[실용주의 프로그래머] 단지 뷰일 뿐이야 [실용주의 프로그래머] 단지 뷰일 뿐이야 -우리는 전부터 프로그램을 커다란 덩어리 하나로 짜지 말고, “나눠서 정복하기(divide and conquer)” 방법을 써서 여러 모듈로 나누어 짜야 한다고 배웠다.모듈마다 자기만의 책임이 있다.사실, “잘 정의된 단 하나의 책임만 가지는 것”이라는 말이야말로 모듈(또는 클래스)에 대한 좋은 정의가 된다. -이벤트를 이용하면 어떤 객체의 상태 변화를 이에 관심을 가질 다른 객체들에게 알릴 수 있다.이벤트를 이렇게 이용하면 객체들 사이의 결합을 최소화할 수 있다. 출판/구독 -모든 이벤트를 루틴 하나에 몰아넣는 일은 나쁘다.하나의 루틴이 여러 객체들 사이의 상호작용에 대한 상세한 지식을 지니게 된다.그리고 결합도도 증가된다.그외에도 DRY 원칙 어김, 직교성 어.. 2018. 11. 1.
[실용주의 프로그래머] 시간적 결합 [실용주의 프로그래머] 시간적 결합 -소프트웨어 아키텍처에서 시간이라는 측면은 자주 무시된다. 우리가 신경쓰는 유일한 시간은 일정뿐이다.시간적 결합(temporal coupling)에서의 시간은 일정과 관련이 없다.동시성(같은 시각에 일어나는 일들)과 순서(시간 속에서 일들의 상대적인 위치)에 대한 이야기이다. -우리는 동시성을 허용할 필요가 있고, 시간이나 순서에 따른 의존성의 결합을 끊는 방법을 생각할 필요가 있다.그렇게 함으로써 유연성도 얻을 수 있고, 작업흐름 분석, 아키텍처, 설계, 배치(deploy)와 같은 개발의 여러 측면에서 시간과 관련된 의존성도 줄일 수 있다. 작업 흐름 -요구사항 분석의 일부로서 사용자들의 작업흐름을 모델화하고 분석하는 작업이 필요하다.우리가 원하는 것은 동시에 일어나.. 2018. 10. 31.
반응형

티스토리툴바