실용주의 프로그래머 7장 코딩하는 동안

항목 37. 파충류의 뇌에 귀 기울이기

• 뭔가 의심이 생긴다면 직감이 말을 거는 중일지도.. 따라라!
• 가끔씩은 빈 에디터, 프로그램으로 놀이를 해보자!

항목 38. 우연에 맡기는 프로그래밍

• 우연히 잘도는 코드는 의심하자.
• 자신도 잘 모르는 코드를 만들지 말라.
  • Ai driven 개발시 주의
  • 내가 알아야할 코드인지 파악해보는것도 좋을듯. 큰그림 이해는 필요.

항목 39. 알고리즘의 속도(내담당)

• 빅오 표기법
  • 알고리즘 공부 한다고 했을때, 코테 준비를 떠나서 알아두면 좋을 기초 상식.
• 다른 표기법 참고 그래도 빅오를 가장 많이 씀.

1. 빅오 표기법 (Big-O, $O$) : 상한선알고리즘의 최악의 경우(Worst Case)를 나타냅니다. “아무리 나빠도 이 정도 시간 안에는 끝난다”라는 보증수표 같은 개념입니다. 실무에서 가장 중요하게 다뤄집니다.
2. 빅 오메가 표기법 (Big-Omega, $\Omega$) : 하한선알고리즘의 최선의 경우(Best Case)를 나타냅니다. “적어도 이 정도 시간은 걸린다”라는 의미입니다.예: 정렬 알고리즘에서 이미 정렬된 데이터가 들어왔을 때의 효율성을 말할 때 사용합니다.
3. 빅 세타 표기법 (Big-Theta, $\Theta$) : 평균/딱 맞는 한계상한(Big-O)과 하한(Big-Omega)이 일치할 때 사용합니다. 즉, 알고리즘의 평균적인 수행 시간이나 아주 정확한 복잡도를 표현할 때 씁니다. 가장 강력하고 엄밀한 표현입니다.

• O(n^2/2+3n)은 O(n^2/2)와 같고, O(n^2)과 같다.

• 빅오 표기법은 시간에만 국한되지 않으며, 어떤 리소스든 가능(보통 공간(프로그램이 사용할 메모리 추정)에도 활용)

• 때로는 휴리스틱을 동원할수 있다.
  • 휴리스틱(Heuristic)은 복잡한 상황에서 엄밀한 논리보다는 경험과 직관을 바탕으로 빠르게 결론을 내리는 ‘주먹구구식 사고방식’을 의미합니다.
  • 효율성: 시간과 정보가 부족할 때 완벽한 정답 대신 ‘충분히 괜찮은 해결책’을 찾는 데 도움을 줍니다.
  • 지름길: 뇌의 에너지를 아끼는 의사결정의 지름길이지만, 때로는 고정관념이나 편향된 판단(오류)을 일으키는 원인이 되기도 합니다.
  • 실생활: ‘비싼 물건은 품질이 좋을 것이다’라고 판단하거나, 가장 먼저 떠오르는 정보를 신뢰하는 것이 대표적인 사례입니다.
  • 시간복잡도 계산 시 휴리스틱이 동원되는 예는 다음과 같습니다.
    • 1. 최악의 경우 추정: 정확한 연산 횟수 산출이 복잡할 때, 가장 빈번하게 수행되는 핵심 연산(Basic Operation)의 최대 반복 횟수만을 직관적으로 파악하여 복잡도를 가늠합니다.
    • 1. 평균 복잡도 근사: 입력 데이터의 분포를 정확히 알 수 없는 경우, 일반적인 상황을 가정하는 경험적 수치를 대입하여 ‘기대되는 성능’을 휴리스틱하게 계산합니다.
    • 1. NP-완전 문제: 이론적으로 정확한 계산이 불가능하거나 너무 오래 걸리는 문제에서, 근사 알고리즘의 효율성을 증명하기 위해 상한선(Upper Bound)을 경험적으로 설정하여 분석합니다.
• 직접 실행하여 테스트 해보기
• 이론과 실무 둘다 고려(쓰레싱)
• 성급한 최적화를 조심하자(과연 그것이 정말로 병목인가?)

개발자가 실천할만한 사항 3가지

1. 빅오 표기법으로 복잡도 평가하기

   • 최악의 경우를 기준으로 알고리즘 성능을 평가합니다.
   • 시간뿐 아니라 공간(메모리) 복잡도도 함께 고려합니다.
   • 상수항과 낮은 차수 항은 무시하고 주요 항만 고려합니다 (예: O(n²/2+3n) → O(n²)).

2. 직접 실행하여 테스트하고, 이론과 실무를 함께 고려하기

   • 이론적 복잡도만으로 판단하지 말고 실제 실행으로 성능을 측정합니다.
   • 이론과 실무를 함께 검토합니다 (예: 쓰레싱 등 실제 환경 요인).

3. 성급한 최적화를 피하고, 실제 병목을 확인하기

   • 최적화 전에 실제 병목 지점을 측정하고 확인합니다.
   • 복잡한 계산이 어려울 때는 휴리스틱을 활용해 빠르게 판단할 수 있지만, 최종 판단은 실제 테스트 결과를 기준으로 합니다.

항목 40. 리팩터링

• 코딩하는 동안 함께 진행하는 편이 좋다.
• 일정에 리팩터링할 시간을 포함시키자.
• 테스트 있나 꼭 확인
• 깨로는 빌드를 깨트려보는 것이 도움이 될수도…
  • 너무 올드한 spring boot 2점대를 3점대로 올리고, 모든 통합테스트 코드 실행 및 전수 QA.
• 내가 해볼만한 포인트.
  • 지금 프로젝트에서 리팩토링할 포인트가 있으면
    • 업무 단위가 크다! 팀단위로 해야할 이슈로 공유
    • 작다? -> 빠르게 수정하고 MR

항목 41. 테스트로 코딩하기

• 소프트웨어를 만들 땐 맨 처음부터 테스트가 가능하도록 만들고, 코드들을 서로 연결하기 전에 코드를 하나하나 철저하게 테스트해야한다.
  • 인정
  • 나의 선입견 : 단위테스트는 비용이 많이 든다.
    • 상황에 따라 다르다
    • 빠르게 만들수도 있다.
    • 무조건은 없다.
    • 단 빠르게 만든다면, TDD 방식의 도입이 가능할듯
      • 번갈아 하기
      • 메서드를 만들었다?
      • 성공 케이스 작성
      • 실패 하도록 둔다.
      • 내용 채우기.
      • 꼭 단위에 적용한다는 것은 편견. 내 생각에 통합 테스트도 필수.
  • 아이디어
    • 지금 프로젝트에 PR 생성시에 테스트 코드가 돌아가도록 하는 것은 어떠할까?
    • 테스트 코드 수행 지점은 언제가 좋지?
    • 무작위 예시 만드는 easyRandom 써보기

항목 42. 속성 기반 테스트

• 계약과 불변식을 기반으로 테스트 하자.
  • 이런 케이스에는 동작할까? 다양한 케이스를 만들어야한다.
  • 때로는 랜덤하게. 수많은 케이스로!

항목 43. 바깥에서는 안전에 주의하라(내담당)

• 기본 보완 원칙
  • 공격 표면 최소화
    • 출력 데이터는 공격 매개체다 : 응답에 오류메시지가 노출되지 않도록 주의, 코드로 관리하고, 코드의 의미는 내부에서 엄격하게 관리.
  • 최소 권한 원칙
  • 안전한 기본값
  • 민감 정보를 암호화해라
  • 보안 업데이트를 적용하라.
• 리뷰할때 보안 유의사항 체크하기.

항목 44. 이름 짓기

• 단어의 뜻을 알고 일관성 있게 사용해야한다.
• 한가지 방법은 의사소통을 장려하는 것이다.