[실용주의 프로그래머] 6일차

책.책.책을 읽어요!

• 오늘의 책읽기: 4장.실용주의 편집증 까지!
• 오늘의 과제: TIL 작성하기
• 제출기간: 익일 오전 6시까지

TIL 작성하기

• TIL, Today I Learned 는 책 감상평을 쓰는 방법 중 하나 입니다.
• TIL 작성방법을 숙지한 후. TIL을 작성해주세요.
• TIL 책 감상평 예시 를 참고하세요.

니꼬쌤의 TIL 감상문 (제 2장을 읽고나서...)

• Software that is well designed is ETC, easy to change. Most good software design principles product ETC software. DRY. Knowledge should never be duplicated within a system. Systems must be Orthogonal, this means, changing one part of the system should not affect the others.
• Our code and architecture should be flexible to changes, all decisions are reversible and our code should be able to handle them. Our code should be able to support multiple futures! We should prototype when we want to learn. The code in a prototype is disposable. When asked for an estimate, it’s better to slow down and spend time thinking. Don’t give an immediate answer.
• 잘 설계된 소프트웨어는 ETC - 변경하기 쉽다. 대부분의 우수한 소프트웨어 설계 원칙은 제품 ETC 소프트웨어이다. DRY. 지식은 시스템 내에서 중복되어서는 안된다. 시스템은 직교여야 한다. 즉, 시스템의 한 부분을 변경해도 다른 부분에는 영향을 미치지 않아야 한다.
• 코드와 아키텍처는 변화에 유연하게 대응해야 하며, 모든 의사결정이 뒤집힐 수 있어야 하며, 코드가 이를 처리할 수 있어야 한다. 우리의 코드는 여러가지 가능성을 염두해두고 지원할 수 있어야 한다! 우리는 배우고 싶을 때 프로토타입을 만들어야 한다. 프로토타입의 코드는 일회용이다. 견적을 요구받았을 때, 천천히 생각하고 시간을 보내는 것이 좋다. 즉답은 하지 말자!

제출방법

• 제출기간: 익일 오전 6시까지
• 업로드 하신 게시물 링크를 아래 제출하면 끝!
• 그 다음은 바로 퀴즈~! 입니다-!

---

계약에 의한 설계

나의 관심이 많은 부분이 바로 설계부분이다. 그러기 위해 더 많이 공부하지만 아직 부족하다. 특히 어떤 설계가 바람직한 설계인지 판단하기가 굉장히 어렵다. DBC (Design By Contract) 요구사항 명세 기법중하나로 보여진다. '자신이 수용할것은 엄격하게 확인하고 내어줄 것에 대해서는 최소한도를 약속하는 것이다.' 라고 한다.
명확한 코드는 명확한 요구사항에서 나온다고 생각한다. '단순하게 XXX기능을 추가해 주세요.' 라는 말에 기능을 추가하고 에자일 기법을 돌리다보면 요구사항에 대한 부족했던 분석때문에 개발결과가 산으로 가버린 경험이 다수 있었다. 그렇다고 여기서 요구사항을 차단하고 밀어 붙이라는 말은 아니다. 계약관계처럼 내가 사용할 input 과 output을 명확하게 그리고 필요한 기능을 명확히 프로그램을 통해 받아야한다.

헤드라이트를 앞서가지 말라

20주년 기념판인데도 여전히 각광받는 한구절이라고 생각된다.

• 헤드라이트를 앞서가지말라.
  이는 정말 시대를 앞서나가는 생각인것 같다.
  하지만 뜻대로 잘 되지 않는게 TDD 라고 생각한다.
  한가지 책임을 위해 작업한다는게 현재 프로그램 개발어디에나 쓰이는 이야기다.
  프로그램 한줄 작성하고 테스트를 돌리고, 한가지 목적만을 추가하는 Pull Requeset를 작성한다는 것은 사실 엄청나게 어려운 과제처럼 느껴진다.
  한가지 프로그램을 수정하다보면 다른 것들이 눈에 들어오고 이전에 적용되지 못한 수정사항이 나도모르게 린트가 반영해서 넣어버리는 경우도 있다. 이렇게 되면 TDD처럼 목적을 달성했는가? 라는 단위 업무로 나뉘는 것이 아니다보니 review에서 점점 시간이 걸린다.
  단순하게 목적을 가진 설계를 이해하는데도 시간이 오래걸리는데 다른 변경사항까지 확인하려니 더 죽을맛일 수밖에 없다고 생각한다.

그러니 오늘부터, PR, TEST모두 한번 1개씩 헤드리아트를 앞서지말고 개발해나가보자.