GN⁺: 2024년, 내가 프로그래밍 하는 방법

• 오랫동안 사용할 수 있는 프로그램을 선택하고 신뢰할 수 있는 인프라를 구축하는 방법에 대해 이야기했지만, 여전히 그것을 잘 하지 못하고 있음을 인정함
• 최근 2년 동안 사용해온 프로그램의 핵심을 한 달 동안 다시 작성했고, 이를 통해 지난 인생의 프로그래밍 변화를 되돌아봄

2015년

• 추상화를 의심하고 테스트와 버전 관리를 중시함
• 추상화의 남용과 테스트/버전 관리의 부족이 문제의 원인이라고 생각함
• 테스트와 레이어를 기본 제약으로 하는 플랫폼 Mu1을 설계함

2017년

• Mu1을 현재의 Mu로 재작업 시작
• 처음에는 새로운 테스트와 레이어 아이디어를 모두 사용했으나 점차 사용을 중단함
• Mu에는 많은 테스트가 있지만 기존의 방식이며, 레이어 인프라는 포팅하지 않음

2022년

• Freewheeling Apps 작업 시작
• 처음에는 테스트 없이 시작했다가 텍스트 편집기의 핵심 부분에 대해 철저한 테스트를 작성함
• 나머지 부분은 테스트하기 어려웠지만 잘 작동함

2024년

• 한 달 전 모든 테스트를 삭제함
• 다른 Freewheeling Apps와의 병합 충돌을 걱정했던 방식으로 텍스트 편집기를 급진적으로 재작업함
• 버전 관리에 대해 고민하지 않게 됨
• 테스트와 버전을 포기하고 훨씬 더 나은 프로그램을 만들게 됨

지속 가능한 프로그래밍에 대한 현재의 통합된 견해

1. 많은 사람을 위해 지속 가능하게 구축하는 것은 너무 어려우므로 시도조차 하지 말 것
2. 대부분의 소프트웨어는 단기적으로 많은 사람을 위해 봉사하려는 인센티브에 감염되어 있음. 로고가 적고, 구축이 쉽고, 의존성이 적으며, 자동 업데이트를 하지 않는 소프트웨어에 초점을 맞출 것
3. 컨텍스트의 작은 변화가 프로그램이 컨텍스트에 얼마나 잘 맞는지를 근본적으로 바꿀 수 있음
4. 새로운 프로그램은 어떤 식으로든 미지의 세계로 향하게 됨. 어떤 방향으로든 정확히 무엇을 하고 있는지 모를 때가 많음
5. 유형, 추상화, 테스트, 버전, 상태 머신, 불변성, 정형 분석 등은 익숙하지 않은 지형에서 사용할 수 있는 도구임
6. 불가피하게 이러한 도구 중 일부를 과도하게 사용하게 됨. 이상적인 사용량은 우리가 생각하는 것보다 훨씬 더 작음. 초과 사용은 기술 부채임
7. 맥락에 대한 이해가 안정되면 프로그램의 상당 부분을 버리고 처음부터 다시 하는 것이 가치가 있음
8. 다시 작성하기 전에 프로그램에서 원하는 모든 것과 프로그램이 처리해야 하는 모든 시나리오를 한꺼번에 머릿속에 넣어야 함
9. 모든 것을 한꺼번에 구축할 것

• 테스트와 버전 관리는 이러한 진화의 마지막에 도달하는 데 방해가 됨
• 테스트는 우려를 잊게 하고 버전 관리는 과거에 연연하게 만듦

GN⁺의 의견

• 프로그램이 너무 복잡해지면 8단계에서 모든 것을 기억하는 것이 불가능해질 수 있음. 이는 대부분의 소프트웨어, 특히 둘 이상의 사람이 작성한 소프트웨어에 해당함
• 모든 소프트웨어가 반드시 9단계에 도달할 필요는 없음. 많은 Freewheeling Apps는 초기 설계 선택과 관계없이 몇 명만 사용해도 버그가 없는 상태로 안정화될 수 있을 만큼 충분히 단순하고 느리게 진화함
• 9단계에 도달하는 데 데이터 중심 설계가 분명히 유용함. 맹목적으로 적용할 수 있는 도구가 아니라 immediate data structure choices를 넘어 프로그램이 데이터에 액세스하는 방식의 큰 그림을 바라보는 사고방식임
• 이 단계들은 완전히 옳지 않을 수 있음. 경험이 적은 도구를 과소평가하고 있을 수 있음
• 이러한 단계를 넘어 어떤 단계가 있을지 궁금함