Algorithms we develop software by

https://grantslatton.com/software-pathfinding

https://news.hada.io/topic?id=16383

• 최근 저명한 기술 CEO와 엔지니어와의 대화에서 흥미로운 소프트웨어 개발 방법론을 들음. 이 방법론을 통해 다른 휴리스틱과 일반화에 대해 생각하게 됨.

그의 방법

• 하루를 시작할 때 기능 작업을 시작. 하루가 끝날 때까지 완료하지 못하면 모두 삭제하고 다음 날 다시 시작. 작성한 단위 테스트는 유지 가능.
• 며칠 후에도 기능을 구현하지 못하면, 그 기능을 가능하게 할 기반, 인프라 또는 리팩토링을 생각하고 이를 구현한 후 기능으로 돌아옴.
• 이 방법은 90년대 후반과 00년대 초반의 익스트림 프로그래밍 운동과 유사함.

방법에 대한 생각

"모든 것을 두 번 작성"

• 주니어 엔지니어에게 주는 조언: 문제를 해결하고 코드를 브랜치에 저장한 후 다시 작성.
• 노트북이 고장난 후 이 방법을 우연히 발견. 재작성은 초기 구현의 25% 시간만 소요되었고 결과는 훨씬 나아짐.
• 1.25배의 시간으로 2배 더 높은 품질의 코드를 얻을 수 있음. 장기 유지보수가 필요한 프로젝트에 유용.
• "매일 다시 시작" 방법은 이보다 더 극단적. 재작성할 때마다 더 매끄러운 해결책을 찾게 됨.

"양이 질을 가진다"

• 스탈린의 인용구가 소프트웨어 엔지니어에게 적용됨. 주니어 엔지니어에게는 첫 10만 줄의 코드가 필수적.
• "매일 다시 시작" 방법은 10만 줄을 더 빨리 작성하게 도움.
• 같은 문제를 반복해서 해결하는 것이 패턴을 기억하는 데 유익함.
• 5천 줄의 완벽한 코드로 주요 패턴을 모두 볼 수 있음. 나머지 9만 5천 줄은 반복을 통해 뉴런을 재배치함.

"총을 머리에 대고" 휴리스틱과의 비교

• 문제 해결책을 제시한 사람에게 "24시간 내에 끝내야 한다면 어떻게 할 것인가?"라고 질문.
• 이 방법은 프레임과 앵커링 편향을 깨뜨림. 종종 몇 분 만에 하루 만에 끝낼 수 있는 계획을 유도할 수 있음.
• 실제로 하루 만에 끝낼 수 있는 계획은 아니지만, 새로운 해결책은 종종 며칠 내에 완료 가능.
• 이 생각 실험의 목적은 실제 해결책을 생성하는 것이 아니라, 해결책의 하한을 설정하는 것임.

경로 찾기

• 문제 공간에서 경로를 찾는 것이 핵심. 각 경로는 해결책이며, 엔지니어의 역할은 최상의 경로를 찾는 것.
• 이러한 휴리스틱과 다양한 경로 찾기 알고리듬 간의 유사성을 생각해 볼 가치가 있음.
• 엔지니어링 휴리스틱도 마찬가지로, 더 나은 엔지니어가 되는 것은 문제 공간에서 더 나은 경로를 찾는 것임.

---

HN

• 새로운 기능을 두 번 작성하는 것이 좋은 전략임. 하지만 비즈니스 개발자나 프로젝트 매니저에게는 불필요한 지연으로 보일 수 있음
  • 기능을 처음부터 끝까지 작성하면 논리를 정리하고 리팩토링하는 데 도움이 됨
  • 재작성은 논리 흐름을 명확히 하고, 더 선형적으로 계획을 따를 수 있게 함
  • 나중에 대규모 리팩토링의 필요성을 줄이는 경향이 있음
• "24시간 내에 끝내야 한다면?"이라는 질문은 프로젝트 매니저가 할 수 없는 질문임
  • 이는 개인적인 교육적 연습이지, 일을 더 빨리 끝내기 위한 방법이 아님
• 좋은 코드는 적절한 추상화를 선택하여 작성됨
  • 적절한 추상화를 선택하려면 전체를 알아야 함
  • 다른 공학 분야에서는 CAD 레이아웃 같은 좋은 청사진 패러다임을 사용함
  • 소프트웨어에서는 이러한 청사진이 부족함
  • 경험이 중요한 이유는 균형을 맞추는 데 있음
• 유능한 동료가 있으면 단시간에 무엇을 할 수 있는지 보여줄 수 있음
  • 빠르게 작업하는 것이 중요한 이유는 많음
  • 자동차 수리와 마찬가지로, 시간이 오래 걸릴수록 재조립을 잊을 가능성이 높음
  • 하루 만에 기능을 구현하면 위험이 줄어듦
  • 도구에 대한 확실한 이해와 신뢰할 수 있는 CI/CD 프로세스가 필요함
• 소프트웨어를 두 번 작성하는 것이 좋다는 의견에 공감함
  • 한 번 작성한 코드를 잃어버린 후 다시 작성할 의욕을 잃음
  • 다시 작성하려고 하면 집중이 안 되고, 접근 방식을 기억하지 못함
• 며칠 후에도 기능을 구현할 수 없다면, 필요한 인프라나 리팩토링을 먼저 수행해야 함
  • 도구의 '어휘'를 구축하고 유지하는 것이 중요함
• "24시간 내에"와 "모든 것을 두 번 작성"은 서로 연관이 있음
  • 코드를 대충 작성하면 결국 다시 작성하게 됨
• 이 게시물은 최고의 "프로그래밍 조언" 중 하나임
  • grug brained developer의 조언과 비슷함
• 때로는 문제를 해결하기 위해 백그라운드 스레드를 돌리는 것이 필요함
  • 경험이 많은 사람은 이러한 문제를 더 빨리 식별할 수 있음
  • 문제를 잠시 놔두고 다른 일을 하는 것이 더 나을 때가 있음
• 다음 접근 방식이 유용함
  • 문제를 해결할 여러 아이디어를 먼저 작성함
  • 작업을 '한 세션 내에 완료할 수 있는' 방식으로 나눔
  • 세션이 끝날 때마다 코드가 항상 '작동'하도록 구현함
  • 세션이 끝날 때마다 주석이나 README에 브레인 덤프를 작성함