7장. 코딩하는 동안
코딩은 기계적인 작업이 아니며, 매 순간 결정을 내려야 한다.
CASE: Computer-aided Software Engineering
- 소프트웨어 제작 도구에 여러 가지 소프트웨어 공학 방법론을 반영하는 것
(실제로는 소프트웨어가 복잡해질수록 적용과 관리가 어려웠음)
실용주의 프로그래머는 모든 코드를 비판적인 시각으로 바라본다.
테스트는 버그를 찾는 작업이 아니라, 코드에 대한 피드백을 받는 작업이다.
테스트의 긍정적인 효과는 테스트를 수행할 때가 아니라 테스트에 대해서 생각할 때, 테스트를 작성할 때 나타난다.
37. 파충류의 뇌에 귀 기울이기
더 동물적인 부분 = 파충류의 뇌 lizard brain (서늘한 신호, 개빈 드 베커)
프로그래머로서 경험이 늘어날수록 뇌에는 암묵적인 지식이 쌓인다 (잘 되는 방법, 안 되는 방법, 오류 형태별로 가능한 원인 등)
파충류와 이야기하는 법 (무의식에 귀기울이는 법)
1. 하고 있는 일을 멈추고 뇌가 정리할 수 있도록 시간과 공간을 확보하라.
2. 그 방법이 잘 안되면 문제를 표면으로 끄집어 내라. 동료에게 설명하거나 해서 뇌의 다른 부위에 문제를 노출해라.
3. 그래도 막혀 있다면 뇌에게 지금 하려는 일이 별 문제가 없다고 알려 주어라 - 프로토타이핑
왠지 이상하게 느껴지거나, 무언가 마음을 불편하게 한다면 하던 일을 멈추고 그 느낌을 분석하라.
38. 우연에 맡기는 프로그래밍
무엇을 작성하는지 모르고 돌려 보니 잘 돌아가는 것 같아 영원히 덧붙이다가 어느 날 오류가 발생하면 돌이킬 수 없다.
왜 돌아가는지 모르는 코드를 작성하면 오류도 잡을 수 없다. 운이 좋았을 뿐이다.
코드가 망가진 이유를 모르는 것은 왜 코드가 돌아갔는지도 몰랐기 때문이다.
무언가를 신뢰할 수 있을지 판단하기 어렵다면 일단 최악의 상황을 가정하라.
가정을 기록으로 남기고, 실제로 테스트해 보라.
39. 알고리즘의 속도
대문자 O 표기법: 어떤 함수가 O(n²) 시간이 걸린다고 하면, 이 함수가 실행되는 데 걸리는 시간의 최대값이 n²보다 더 빨리 늘어나지 않는다는 뜻.
코드 자체에 대해서도 생각해야 한다. 입력값 n이 작은 경우에는 단순한 O(n²) 코드가 복잡한 O(nlogn) 코드보다 더 나을 수 있다.
40. 리팩터링
리팩터링은 무언가를 알게 되었을 때 한다.
손해 보는 일 없이 리팩터링 하는 방법
- 리팩터링과 기능 추가를 동시에 하지 않는다
41. 테스트로 코딩하기
테스트는 버그를 찾기 위한 것이 아니다.
테스트는 코드의 첫 번째 사용자다 - 메서드를 외부의 시선으로 볼 수 있게 한다.
무언가를 테스트하기 좋게 만들면 결합도도 낮아진다.
상향식 vs 하향식 → 상향식이나 하향식이 아니라 끝에서 끝까지 만들어라.
테스트가 중심이 되면 안 되고, 나아갈 때마다 목적지를 떠올려야 한다.
43. 바깥에서는 안전에 주의하라
조용히 숨어 있는 것으로 보안을 대신하려는 생각은 통하지 않는다.
44. 이름 짓기
이름을 지을 때 내가 이것을 왜 만드는건지 생각한다.
'TIL' 카테고리의 다른 글
실용주의 프로그래머 9장: 실용주의 프로젝트 (1) | 2024.11.07 |
---|---|
실용주의 프로그래머 8장: 프로젝트 전에 (0) | 2024.10.26 |
flutter 패키지 설치 명령어 (0) | 2024.09.01 |
VSCode Flutter - Widget Inspector (0) | 2024.08.21 |
실용주의 프로그래머 6장: 동시성 Concurrency (1) | 2024.08.20 |