Post

실용주의 프로그래머 4장 실용주의 편집증

실용주의 프로그래머 4장 실용주의 편집증

내용

4장. 실용주의 편집증

항목 23. 계약에 의한 설계(맡은 부분)

  • 계약에 포함할 내용
    • 선행 조건
      • 테스트 코드 상으로 given에 해당
    • 후행 조건
      • 테스트 코드 상으로 then에 해당
    • 클래스 불변식
      • 이것도 then. 하지만, 코드 짤때 자주 간과되었던것 같다.
    • 선행조건을 만족하면 루틴(메소드 든 로직)수행후 후행과 불변식을 만족한다.
    • DBC. Designed By Contract
    • 테스트와 비슷하지만 훨씬 더 범위가 길다
  • 동적 계약(dynamic contracts)은
    • ➡️ 고정된 문서가 아니라, 시스템의 구성 요소(에이전트)들이 상황에 따라 협상하고 재정의할 수 있는 유연한 계약 개념이다.
    • Ai agent 시대에 도입될 중요한 개념중 하나가 될듯.
    • 기존 DBC의 확장판이며, 자율적·지능적인 소프트웨어 시스템을 지향할 때 중요한 개념이다.
  • 연습 문제 14
    • 선행 : 비어있지 않고 한단계 속도를 바꾼다
    • 후행 : (바꾼 방향 + 기존속도)의 속도로 변화한다.
    • 불변 : 실행 전과 후, isFull()의 상태가 동일하다. 실행전과 후 속도의 차이가 1이다.
  • 클래스의 동작을 구체적으로, 모호함없이 사용하고 싶을때 적용하기 좋다.
    • 책의 예시는 실제로 구현할 클래스의 상단에 불변 조건을 주석형태로 정의하고, 각 메서드에 선행 후행 조건을 주석형태로 정의하여 사용했다.
      • 주석으로 쓰거나, 문서화하거나 방식은 사용자가 선택하면 될듯.

항목 24. 죽은 프로그램은 거짓말을 하지 않는다

  • 망치지 말고 멈춰라
    • 때로는 빠른 해결을 위해 컴퓨터 재부팅마냥, 프로그램도 그게 빠를수도
      • 단 빈번히 발생할경우 로그나 그런것 분석은 필요.

항목 25. 단정적 프로그래밍

  • 단정문으로 불가능한 상황을 예방하라 -> java assert
  • 참고 디버깅행위가 디버깅하려는 시스템의 행위를 바꾸진 않도록 할것(하이젠버그적 문제)

항목 26. 리소스 사용의 균형

  • 자신이 할당받은 리소스는 자기가 끝내기
  • 로그, 디비데이터, 파일이미지까지 생성, 유지, 삭제를 위한 전략이 필요하다
  • try catch finally
  • Wrapper를 사용해서 사용이 올바른지 검증하라

항목 27. 헤드라이트를 앞서가지 말라(맡은 부분)

  • 소프트웨어 개발도 우리의 헤드라이트는 제한되어 있다.
    • 우리는 너무 먼 미래를 내다볼 수 없고, 정면에서 벗어난 곳일수독 더 어둡다.
      • 작은 단계들을 밟아라. 언제나.
        • 너무 고정관념. ai 보편화 시대에 때로는 큰 단계를 밟고, ai driven하게 해결 가능하다.
        • 때로는 작게도 밟고(ex) 모듈 설계, 프로젝트 migration. 기능 체크를 단계들을 밝아가며 꼼꼼히 해야한다.
    • 어떤 작업시 단계의 크기를 업무에 따라 적절히 정의할 필요는 있다.
    • 미래가 어떤 모습일지 더 많이 예측하려 할수록 여러분이 틀릴 가능성은 계속 높아질 것이다.
      • si 개발시 고객과 소통을 훨씬 자주해서 예측하지 말고, 빈번히 대화하여 업무 효율을 높이자.
This post is licensed under CC BY 4.0 by the author.