실용주의 프로그래머

• 실용주의 프로그래머 팁

• 내 기술에 애정과 관심을 갖어라.
• 자신의 일에 대해서 생각하면서 일하라.
• 절대 기계적으로 일하지 말라. 언제나 생각하고, 언제나 일하면서 동시에 자신의 일을 비평하고 분석하라.
  

• 어설픈 변명을 만들지 말고 대안을 제시하라.
  • 실수를 저지르거나 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라.

"가장 큰 약점은 약점을 보일 것에 대한 두려움이다." - 보쉬에(J.B.Bossuet), Politics from Holy Writ, 1709

• 깨진 창문을 내버려두지 말라.
  • "깨진 창문"(나쁜 설계, 잘못된 결정, 형편없는 코드...)는 발견하자마자 바로 고쳐라.
  • 무엇이든지, 판자로라도 덮어두어서, 관리하고 있다는 것을 보여라.
• 변화의 촉매가 되라.
  • 촉매제가  되어 다른 성공요인을 끌어낼수있다.
• 큰 그림을 기억하라.
  • 내가 무엇을 하는 지에만 정신을 쏟지말고, 주변에서 무엇이 일어나는지 주의있게 봐라. 안그러다가, 처음 큰 그림을 망칠수가 있다.
• 품질을 요구사항으로 만들어라.
  • 타협과정에 사용자를 참여시켜라.
  • 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라. 완벽해지기란 불가능하다.
• 지식 포트 폴리오에 주기적으로 투자하라.
  • 매년 새로운 언어를 최소 하나는 배워라.(머리 터져;)
  • 기술서적을 분기마다 한 권씩 읽어라.(아;; 독서;;)
  • 비기술서적도 읽어라.
  • 수업을 들어라.
  • 지역사용자 모임에 참여하라.
  • 다른(개발)환경에서 실험해보라
  • 요즘 흐름을 놓치지 마라.
  • 인터넷을 이용하라 - 뉴스그룹 등 기술 정보를 습득하라.
• 읽고 듣는 것을 비판적으로 분석하라.
• 무엇을 말하는가와 어떻게 말하는 가 모두 중요하다.
  • 말하고 싶은게 무엇인지 알아라 - 요점을 미리 적어놓거나 생각해놓는다
  • 청중을 알아라 - 이 말을 들어야 할 다양한 종사자들을 생각해서 그들 구미에 맞게금 말하라.
  • 때를 골라라 - 잘 받아들여질 때에 말하라.
  • 스타일을 골라라 - 상대방이 원하는 의견 전달의 스타일(간단 메모?, 긴 브리핑?, 요점 브리핑?) + 내가 할 수 있는 전달 스타일.
  • 멋져보이게 하라 - 문서 작성한다면 꾸며서 멋있게.
  • 청중을 참여시켜라 - 피드백
  • 청자가 되어라. - 잘 들어야 내 말에도 경청해준다. 대화형 회의로 만들어라.
  • 응답하라 - 질문에 대한 답을 지금 못 준다고 해도, "조금 후에 주겠다" 라든가. 뭔가 응답을 하라.
  •  email 도 대화만큼이나 중요하다.
• 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
• Dry(Don't Repeat Yourself) - 반복하지 마라. 즉 중복을 피하도록 하라.
  •  강요된 중복
    • 필터, 코드생성기를 작성한다. 전처리기 사용
    • 최소한의 주석만 단다.
    • 문서화 하고 개발을 하라?? 요구사항 명세에 따라, 테스트를 거치고 완료를 하라는?
    • 문서와 코드를 항상 동일하게 유지하라는?? June
  • 부주의한 중복을 피하라. EX) 선을 표현하는 변수 startp, endp 가 있는데, 굳이 length를 둘 필요가 없다. endp-startp를 빼면 length 다.
  • 참을성이 없어서 만들어 내는 중복을 피하라. 동일한 함수를 copy and paste 남발하는 일은 하지 않도록 하라.
  • 개발자간의 코드 중복이 있을 수 있다. 이것은 리더나 설계가 책임 분배를 갖도록 해야 한다. 서로 대화하고, 소스를 공개하면서, 중복을 피해야한다.
•  재사용하기 쉽게 만들라. 재사용이 안되면 중복을 피해가기 힘들다.
• 관련 없는 것들 간에 서로 영향이 없도록 하라.
  • 직교성을 높여야 함(독립성 높이고, 결합도 낮추고), 생산성 향상, 리스크 감소.
  • 코드의 결합도를 줄이고, 전역 데이터 사용을 피하고, 유사함수를 피하라. 항상 리팩토링에 힘쓰라.
• 최종 결정이란 없다. 즉, a 요구 사항만 존재할 것이라고 여기지 말라. a가 갑자기 b요구사항으로 변모해도, 금방 변경이 가능해야 한다. 가역성을 높여라. 그것들에 대해서, 유연하게 능동적으로 대처할 수 있게 코딩을 해라.
•  목표물을 찾기 위해 예광탄을 써라. 예광탄 코드도 사용가능한 코드이다.  점진적으로 전체 기능을 확인 할 수 있다. <--대비--> 모듈 조립을 통한 거대 공학적 접근 방식.
  • 장점 : 뭔가 작동되는 것을 (점진적으로) 일찍 부터 보게 된다.  통합작업을 수행할 기반이 생긴다. use case를 한 번에 하나씩 다룬다.
  • 예광탄을 써서 맞춘 것이 목표가 아닐 수도 있지만, 조준이 가능하다.
  • 프로토타입과의 차이점 : 프로토타입은 목적에 맞는 것을 구현하기 위해 테스트용으로 만들어서 원하는 결과를 얻어낸 후 버리고 진짜 코드를 적용해서 완성해낸다., 예광탄 코드는, 점진적으로 맞춰가면서 재사용가능한 코드가 된다.
• 프로토타입을 통해 학습하라. 프로토타이핑을 통해, 배우게 되는 교휸, 이것으로 목적에 가까이 간다.
  • dummy 데이터를 쓸 수 있다. 제한된 기능만을 제공하기도 한다. 정해진 방법 외에는 실행이 안될 수도 있다. 많은 문서화가 필요하지도 않고 간단하게도 된다., 실제 개발에 사용되는 언어로 프로토타입을 작서할 수도 있지만, 대부분 고수준 언어(스크립트)를 사용한다.
  • 세부사항은 무시하고, 전체적으로 시스템 동작에 대한 감을 잡는 것이다.
  • 프로토타입 코드는 폐기 될 것이라는 것. 개발초기에, 잠재적  문제 발견 수정에 대해 비용이 적게 들기 때문에 쓴다.
• 문제 도메인에 가깝게 프로그래밍 하라.
  • 도메인의 문제만을 푸는 일에만 정신을 집중할 수 있게 하라.
  • 소형 언어를 만들어 사용하는것도 하나의 방법이다.
• 추정을 통해 놀람을 피하라.
  • 무엇을 묻고 있는지 이해하자. 질문에서 도메인의 범위에 대해 감을 잡을 필요가 있다.
  • 시스템의 모델을 만들어 보라.
  • 모델을 컴포넌트로 나누어라. 각 컴포넌트가 전체 모델에 영향을 미치는 매개변수를 찾아라.
  • 각 매개변수에 값을 주어라.
  • 답을 계산하라. 이상해 보이는 답이 나올 경우 문제를 잘못 이해했거나 모델을 잘못 만들었을 가능성도 있다.
• 코드와 함께 일정도 반복하며 조정하라.
  • 비슷한 어플리케이션을 만들어본 경험이 없다면 단순한 추측에 불과하다.
  • 점증적 개발이 도움이 될것이다.
    • 요구사항 체크하기
    • 위험 분석하기
    • 설계, 구현, 통합
    • 사용자와 함께 검증하기
• 지식을 일반 텍스트로 저장하라.(메타데이터도 일반텍스트로, 공개우려가 있다면, 암호화를 해라, 유닉스 철학)
  • 구식이 되는 것에 대한 보험
  • 호환성
  • 더 쉬운 테스트
• 명령어 셸의 힘을 사용하라.
• 하나의 에디터를 잘 사용하라.
  • 호환성, 확장성, 생산성
• 언제나 소스코드 관리 시스템을 사용하라.
• 비난 대신 문제를 해결하라.
• 디버깅을 할 때 당황하지 마라.
  • 항상 문제의 근본적인 원인을 발견하려고 노력하고, 그 문제의 특정한 증상만 고치려고 하지 마라.

    "가장 속이기 쉬운 사람은 자기 자신이다." - 에드워드 불워-리톤(Edward Bulwer-Lytton) The Disowned

• 'select'는 망가지지 않았다.
• 가정하지 마라. 증명하라.
• 텍스트 처리 언어를 하나 익혀라.
• 코드를 작성한는 코드를 작성하라.
• 완벽한 소프트웨어는 만들 수 없다.
• 계약에 따른 설계를 하라
• 일찍 작동을 멈추게 하라.
• 단정문을 사용해서 불가능한 상황을 예방하라.
• 예외는 예외적인 문제에 사용하라.
• 시작한 것은 끝내라.
• 모듈간의 결합도를 최소화하라.
• 통합하지 말고 설정하라.
• 코드에는 추상화를, 메타데이터에는 세부 내용을.
• 작업흐름 분석을 통해 동시성을 개선하라.
• 서비스를 사용해서 설계하라.
• 언제나 동시서을 고려해 설계하라.
• 모델에서 뷰를 분리하라.
• 칠판을 사용해 작업흐름을 조율하라.
• 우연에 맡기는 프로그래밍을 하지 말라.
• 여러분의 알고리즘의 차수를 추정하라.
• 여러분의 추정을 테스트하라.
• 일찍 리펙터링하고, 자주 리팩터링하라.
• 테스트를 염두에 두고 설계하라.
• 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.
• 자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.
• 요구사항을 수집하지 말고 채굴하라.
• 사용자처럼 생각하기 위해 사용자와 함께 일하라.
• 구체적인 것보다 추상적인 것이 더 오래간다.
• 프로젝트 용어사전을 사용하라.
• 생각의 틀을 벗어나지 말고, 틀을 찾아라.
• 준비가 되었을 때 시작하라.
• 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.
• 형식적 방법의 노예가 되지 마라.
• 비싼 도구가 더 좋은 설계를 낳지는 않는다.
• 팀을 기능 중심으로 조직하라.
• 수작업 절차를 사용하지 말라.
• 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
• 모든 테스트가 통과하기 전엔 코딩이 다 된게 아니다.
• 파괴자를 써서 테스트를 테스트하라.
• 코드 커버리지보다 상태 커버리지를 테스트 하라.
• 버그는 한 번만 잡아라.
• 한국어도 하나의 프로그래밍 언어인 것처럼 다루라.
• 문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어넣으려고 하지 말라.
• 사용자의 기대를 부드럽게 넘어서라.
• 자신의 작품에 서명하라.

 

 

 

---

entropy : 시스템 내의 '무질서'한 정도를 가리키는 물리학 용어.

이 글은 스프링노트에서 작성되었습니다.