GN⁺: 우리의 소프트웨어 개발 알고리듬
(grantslatton.com)- 최근 저명한 기술 CEO와 엔지니어와의 대화에서 흥미로운 소프트웨어 개발 방법론을 들음. 이 방법론을 통해 다른 휴리스틱과 일반화에 대해 생각하게 됨.
그의 방법
- 하루를 시작할 때 기능 작업을 시작. 하루가 끝날 때까지 완료하지 못하면 모두 삭제하고 다음 날 다시 시작. 작성한 단위 테스트는 유지 가능.
- 며칠 후에도 기능을 구현하지 못하면, 그 기능을 가능하게 할 기반, 인프라 또는 리팩토링을 생각하고 이를 구현한 후 기능으로 돌아옴.
- 이 방법은 90년대 후반과 00년대 초반의 익스트림 프로그래밍 운동과 유사함.
방법에 대한 생각
"모든 것을 두 번 작성"
- 주니어 엔지니어에게 주는 조언: 문제를 해결하고 코드를 브랜치에 저장한 후 다시 작성.
- 노트북이 고장난 후 이 방법을 우연히 발견. 재작성은 초기 구현의 25% 시간만 소요되었고 결과는 훨씬 나아짐.
- 1.25배의 시간으로 2배 더 높은 품질의 코드를 얻을 수 있음. 장기 유지보수가 필요한 프로젝트에 유용.
- "매일 다시 시작" 방법은 이보다 더 극단적. 재작성할 때마다 더 매끄러운 해결책을 찾게 됨.
"양이 질을 가진다"
- 스탈린의 인용구가 소프트웨어 엔지니어에게 적용됨. 주니어 엔지니어에게는 첫 10만 줄의 코드가 필수적.
- "매일 다시 시작" 방법은 10만 줄을 더 빨리 작성하게 도움.
- 같은 문제를 반복해서 해결하는 것이 패턴을 기억하는 데 유익함.
- 5천 줄의 완벽한 코드로 주요 패턴을 모두 볼 수 있음. 나머지 9만 5천 줄은 반복을 통해 뉴런을 재배치함.
"총을 머리에 대고" 휴리스틱과의 비교
- 문제 해결책을 제시한 사람에게 "24시간 내에 끝내야 한다면 어떻게 할 것인가?"라고 질문.
- 이 방법은 프레임과 앵커링 편향을 깨뜨림. 종종 몇 분 만에 하루 만에 끝낼 수 있는 계획을 유도할 수 있음.
- 실제로 하루 만에 끝낼 수 있는 계획은 아니지만, 새로운 해결책은 종종 며칠 내에 완료 가능.
- 이 생각 실험의 목적은 실제 해결책을 생성하는 것이 아니라, 해결책의 하한을 설정하는 것임.
경로 찾기
- 문제 공간에서 경로를 찾는 것이 핵심. 각 경로는 해결책이며, 엔지니어의 역할은 최상의 경로를 찾는 것.
- 이러한 휴리스틱과 다양한 경로 찾기 알고리듬 간의 유사성을 생각해 볼 가치가 있음.
- 엔지니어링 휴리스틱도 마찬가지로, 더 나은 엔지니어가 되는 것은 문제 공간에서 더 나은 경로를 찾는 것임.
GN⁺의 정리
- 이 글은 소프트웨어 개발에서 효율적인 방법론과 휴리스틱을 탐구함.
- "매일 다시 시작" 방법과 "모든 것을 두 번 작성" 방법은 코드 품질을 높이는 데 유용함.
- 반복적인 문제 해결은 패턴 인식과 뉴런 재배치에 도움을 줌.
- "총을 머리에 대고" 휴리스틱은 해결책의 하한을 설정하는 데 유용함.
- 문제 공간에서 최상의 경로를 찾는 것이 엔지니어의 핵심 역할임.
재작성에 대해서는 매우 공감합니다.
일전에 작업하던 코드를 실수로 날려먹고, 다시 작성하다보니
중간에 설계 바꾸기 귀찮아서 무시한 것들을 고려해서 만들게 되어
결과는 오히려 좋았습니다.
Hacker News 의견
-
새로운 기능을 두 번 작성하는 것이 좋은 전략임. 하지만 비즈니스 개발자나 프로젝트 매니저에게는 불필요한 지연으로 보일 수 있음
- 기능을 처음부터 끝까지 작성하면 논리를 정리하고 리팩토링하는 데 도움이 됨
- 재작성은 논리 흐름을 명확히 하고, 더 선형적으로 계획을 따를 수 있게 함
- 나중에 대규모 리팩토링의 필요성을 줄이는 경향이 있음
-
"24시간 내에 끝내야 한다면?"이라는 질문은 프로젝트 매니저가 할 수 없는 질문임
- 이는 개인적인 교육적 연습이지, 일을 더 빨리 끝내기 위한 방법이 아님
-
좋은 코드는 적절한 추상화를 선택하여 작성됨
- 적절한 추상화를 선택하려면 전체를 알아야 함
- 다른 공학 분야에서는 CAD 레이아웃 같은 좋은 청사진 패러다임을 사용함
- 소프트웨어에서는 이러한 청사진이 부족함
- 경험이 중요한 이유는 균형을 맞추는 데 있음
-
유능한 동료가 있으면 단시간에 무엇을 할 수 있는지 보여줄 수 있음
- 빠르게 작업하는 것이 중요한 이유는 많음
- 자동차 수리와 마찬가지로, 시간이 오래 걸릴수록 재조립을 잊을 가능성이 높음
- 하루 만에 기능을 구현하면 위험이 줄어듦
- 도구에 대한 확실한 이해와 신뢰할 수 있는 CI/CD 프로세스가 필요함
-
소프트웨어를 두 번 작성하는 것이 좋다는 의견에 공감함
- 한 번 작성한 코드를 잃어버린 후 다시 작성할 의욕을 잃음
- 다시 작성하려고 하면 집중이 안 되고, 접근 방식을 기억하지 못함
-
며칠 후에도 기능을 구현할 수 없다면, 필요한 인프라나 리팩토링을 먼저 수행해야 함
- 도구의 '어휘'를 구축하고 유지하는 것이 중요함
-
"24시간 내에"와 "모든 것을 두 번 작성"은 서로 연관이 있음
- 코드를 대충 작성하면 결국 다시 작성하게 됨
-
이 게시물은 최고의 "프로그래밍 조언" 중 하나임
- grug brained developer의 조언과 비슷함
-
때로는 문제를 해결하기 위해 백그라운드 스레드를 돌리는 것이 필요함
- 경험이 많은 사람은 이러한 문제를 더 빨리 식별할 수 있음
- 문제를 잠시 놔두고 다른 일을 하는 것이 더 나을 때가 있음
-
다음 접근 방식이 유용함
- 문제를 해결할 여러 아이디어를 먼저 작성함
- 작업을 '한 세션 내에 완료할 수 있는' 방식으로 나눔
- 세션이 끝날 때마다 코드가 항상 '작동'하도록 구현함
- 세션이 끝날 때마다 주석이나 README에 브레인 덤프를 작성함