Hacker News 의견

• 새로운 기능을 두 번 작성하는 것이 좋은 전략임. 하지만 비즈니스 개발자나 프로젝트 매니저에게는 불필요한 지연으로 보일 수 있음

  • 기능을 처음부터 끝까지 작성하면 논리를 정리하고 리팩토링하는 데 도움이 됨
  • 재작성은 논리 흐름을 명확히 하고, 더 선형적으로 계획을 따를 수 있게 함
  • 나중에 대규모 리팩토링의 필요성을 줄이는 경향이 있음

• "24시간 내에 끝내야 한다면?"이라는 질문은 프로젝트 매니저가 할 수 없는 질문임

  • 이는 개인적인 교육적 연습이지, 일을 더 빨리 끝내기 위한 방법이 아님

• 좋은 코드는 적절한 추상화를 선택하여 작성됨

  • 적절한 추상화를 선택하려면 전체를 알아야 함
  • 다른 공학 분야에서는 CAD 레이아웃 같은 좋은 청사진 패러다임을 사용함
  • 소프트웨어에서는 이러한 청사진이 부족함
  • 경험이 중요한 이유는 균형을 맞추는 데 있음

• 유능한 동료가 있으면 단시간에 무엇을 할 수 있는지 보여줄 수 있음

  • 빠르게 작업하는 것이 중요한 이유는 많음
  • 자동차 수리와 마찬가지로, 시간이 오래 걸릴수록 재조립을 잊을 가능성이 높음
  • 하루 만에 기능을 구현하면 위험이 줄어듦
  • 도구에 대한 확실한 이해와 신뢰할 수 있는 CI/CD 프로세스가 필요함

• 소프트웨어를 두 번 작성하는 것이 좋다는 의견에 공감함

  • 한 번 작성한 코드를 잃어버린 후 다시 작성할 의욕을 잃음
  • 다시 작성하려고 하면 집중이 안 되고, 접근 방식을 기억하지 못함

• 며칠 후에도 기능을 구현할 수 없다면, 필요한 인프라나 리팩토링을 먼저 수행해야 함

  • 도구의 '어휘'를 구축하고 유지하는 것이 중요함

• "24시간 내에"와 "모든 것을 두 번 작성"은 서로 연관이 있음

  • 코드를 대충 작성하면 결국 다시 작성하게 됨

• 이 게시물은 최고의 "프로그래밍 조언" 중 하나임

  • grug brained developer의 조언과 비슷함

• 때로는 문제를 해결하기 위해 백그라운드 스레드를 돌리는 것이 필요함

  • 경험이 많은 사람은 이러한 문제를 더 빨리 식별할 수 있음
  • 문제를 잠시 놔두고 다른 일을 하는 것이 더 나을 때가 있음

• 다음 접근 방식이 유용함

  • 문제를 해결할 여러 아이디어를 먼저 작성함
  • 작업을 '한 세션 내에 완료할 수 있는' 방식으로 나눔
  • 세션이 끝날 때마다 코드가 항상 '작동'하도록 구현함
  • 세션이 끝날 때마다 주석이나 README에 브레인 덤프를 작성함