▲

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

 (akkartik.name)
2P by neo 1달전 | favorite | 댓글 1개
  • 오랫동안 사용할 수 있는 프로그램을 선택하고 신뢰할 수 있는 인프라를 구축하는 방법에 대해 이야기했지만, 여전히 그것을 잘 하지 못하고 있음을 인정함
  • 최근 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를 넘어 프로그램이 데이터에 액세스하는 방식의 큰 그림을 바라보는 사고방식임
  • 이 단계들은 완전히 옳지 않을 수 있음. 경험이 적은 도구를 과소평가하고 있을 수 있음
  • 이러한 단계를 넘어 어떤 단계가 있을지 궁금함
▲
neo 1달전  [-]
Hacker News 의견

  • 테스트가 없으면 문제를 보지 못해 문제가 사라지는 것처럼 보임

    • 테스트를 하면 항상 버그를 발견했음
    • 테스트를 삭제하면 자신을 속이는 것임
    • 페이지를 읽고 나서, 변형/구성 관리에 지쳤다는 인상을 받음
    • 사용자가 많아야 돈을 벌 수 있음

  • 테스트와 버전을 포기하면 더 나은 프로그램을 얻었음

    • 2024년에 소스 코드 관리를 사용하지 않는 것은 이해할 수 없음
    • 여러 기기에서 작업하고, 히스토리를 보고, 롤백하고, 브랜치를 만드는 기능이 매우 유용함

  • 처음에는 저자가 틀렸다고 생각했지만, 좋은 통찰이 있음

    • 이 워크플로우는 저자에게 잘 맞음
    • Git이나 자동화된 테스트가 생산성을 떨어뜨린 경험이 있을 것임
    • 간단한 대안도 있음 (예: Dropbox, FTP)
    • 저자는 작은 프로그램을 만드는 것을 좋아함
    • 자동화된 테스트는 유용하지만, 저자의 경우에는 가치가 나타나지 않을 수 있음

  • 버전 관리와 자동화된 테스트는 실제 문제를 해결함

    • 오늘날 프로젝트를 버전 관리 없이 시작하는 것은 미친 짓임
    • 자동화된 테스트는 최선의 관행임
    • 저자의 특정 사용 사례에서는 합리적일 수 있음

  • 큰 프로그램을 작성/리팩토링할 때, 쓰고 버리고 다시 쓰는 것이 중요함

  • 이 기사는 혼란스러움

    • 왜 첫 번째로 업보트되었는지 궁금함

  • 작은 변화가 프로그램의 적합성을 크게 바꿀 수 있음

    • K9 Mail의 예시가 있음
    • K9 Mail은 비전통적인 UI로 시작했음
    • 많은 사용자가 새로운 UI에 불만을 가졌음
    • 작은 변화가 앱의 적합성을 파괴했음
    • 여전히 오래된 버전을 사용하고 있음

  • 혼자 소프트웨어를 만드는 것과 팀에서 만드는 것은 완전히 다름

    • 테스트는 수단이지 목적이 아님
    • 자신감이 있을 때는 테스트를 덜 함
    • 중요한 부분에 통합 테스트를 추가함
    • 새로운 API 디자인에는 단위 테스트가 유용함

  • 2022년에 Freewheeling Apps 작업을 시작했음

    • 테스트가 없어서 좌절감을 느꼈음
    • 테스트 스위트는 시스템을 발전시키는 자신감을 줌
    • 기능 복잡성이 증가하면 테스트가 어려워짐
    • 2024년에 모든 테스트를 삭제했음
    • 이 철학은 한 사람에게만 적용됨

  • 작은 변화가 프로그램의 적합성을 크게 바꿀 수 있다는 점에 동의하지 않음

    • 단기주의는 작은 변화에 적응하기 위한 것임

  • 저자를 좋아하고 Mu 프로젝트를 좋아함

    • 현대적인 Lisp 머신임

  • 소프트웨어 엔지니어링의 복잡성에 압도됨

    • 모든 아이디어를 거부하는 것은 해결책이 아님
    • 테스트를 작성하고, VCS를 사용하고, 추상화를 사용해야 함
    • 왜 사용하는지 알고, 이유가 없으면 재평가해야 함
답변달기