▲

GN⁺: 설계 문서보다 Throwaway Code 선호 현상

 (softwaredoug.com)
3P by neo 28일전 | ★ favorite | 댓글 1개

  • 우리는 소프트웨어 개발이 깔끔하고 질서 있는 흐름을 따르기를 상상함

    • 설계 문서를 작성하고, 작은 변경 사항을 PR로 롤아웃하여 기능을 구현함
    • 깃 히스토리가 깔끔하고 질서 정연하게 보임
    • 그러나 현실은 다름

  • 설계 문서와 실제 구현의 차이

    • 설계 문서를 그대로 구현하는 것은 환상임
    • 코딩을 시작하면 설계 문서의 내용을 수정하게 됨
    • 계획은 적과의 접촉에서 살아남지 못함

  • 새로운 설계 방법론: 코딩 몰입

    • 초안 PR을 사용하여 프로토타입을 구현함
    • 초기에 피드백을 받아 접근 방식을 조정함
    • 초안 PR을 역사적 설계 아이디어로 문서화함
    • 초안 PR을 완전히 버릴 준비를 함
    • 초안 PR에서 점진적으로 PR을 단계적으로 진행함
    • 각 PR을 단계적으로 테스트하고 견고성을 보완함

  • 성숙함의 중요성

    • 코딩한 아이디어를 버릴 수 있는 능력이 중요함
    • 코드 라인이 아닌 조직적 지식의 전달이 중요함
    • 중요한 부분에 대해 초기에 정렬하여 프로토타입 작업이 낭비되지 않도록 함

  • PR을 문서화로 사용하는 방법

    • PR은 개발자에게 가장 좋은 문서화 형태 중 하나임
    • PR은 특정 시점의 상태를 반영하는 역사적 유물임
    • 설계 문서는 종종 현실과 다른 정보를 제공함

  • 프로토타입의 중요성

    • 프로토타입은 1000개의 설계 문서보다 가치가 있음
    • 변화를 주도하려면 문서가 아닌 코드로 해야 함
    • 조직이 프로토타입을 해답이 아닌 질문으로 보아야 함

  • 설계 문서의 유용성

    • 다양한 이해관계자와의 피드백을 조직하고 아카이브하는 데 유용함
    • 아이디어가 너무 개념적이거나 장기적일 때 유용함
    • 코딩보다 글로 아이디어를 표현하는 것이 더 효율적일 때 유용함
    • 조직이 첫 번째 솔루션을 버릴 수 있는 규율이 없을 때 유용함
    • 주니어 직원이 시니어 개발자의 아이디어에 대해 안전하게 질문할 수 있는 환경을 제공함

  • 설계 문서의 잘못된 사용

    • 덜 숙련된 개발자에게 프로세스를 늦추기 위해 사용됨
    • 문서화로 사용되지만 빠르게 구식이 됨
    • 모든 설계 문제를 해결하려고 하지만 실제 문제는 코딩을 통해 발견됨

  • 팀이 규율을 가질 수 있다면 해킹이 설계보다 훨씬 효율적임

    • 조직 내에서 이러한 규율을 만들 것을 권장함
    • 결국 코드는 말보다 더 큰 힘을 가짐
▲
neo 28일전  [-]
Hacker News 의견

  • 프로토타이핑은 디자인 과정에서 중요한 부분이며, 문제를 정의하고 해결책을 명확히 하는 것이 필요함

    • 때로는 간단한 문서로도 충분하지만, 때로는 많은 피드백과 반복이 필요함
    • "몇 주의 코딩이 몇 시간의 계획을 절약할 수 있음"이라는 말이 있음

  • 글쓰기는 문제를 탐색하는 데 유익하며, 문제를 이해했다고 생각했지만 글을 쓰면서 새로운 질문이 생긴 경험이 있음

    • 멘토가 Lucidchart를 사용하여 6개월간의 작업을 설명한 사례를 떠올림

  • 프로젝트를 기한 내에 완료하기 위해 임시 해결책을 사용한 경험이 있음

    • 임시 해결책이 생산 지원 도구로도 사용되며, 영구적인 버전이 중단될 경우 대체 경로로 활용됨

  • 디자인 문서의 가장 큰 문제는 아무도 읽지 않는다는 것임

    • 프로토타이핑의 문제는 사람들이 이를 최종 코드로 간주하는 것임
    • 하이브리드 접근법을 선호하며, 계획과 문서화를 철저히 하고 최종 제품에 사용할 수 있는 품질의 프로토타입 코드를 작성함

  • 코드와 디자인에 대한 피드백의 차이가 큼

    • 디자인 문서는 문제 공간에 대한 "왜"라는 질문을 유도함
    • 프로토타입이 작동하면 이러한 질문을 제기하기 어려워짐

  • 많은 코드를 작성하여 무엇이 효과적인지 보는 것이 직무 설명이라면, GPT가 더 빠르고 저렴하게 대체할 수 있음

    • 무엇을 구축해야 하는지에 대한 합의를 얻는 것이 항상 도전임

  • 소프트웨어 개발이 깔끔하고 질서 정연한 흐름을 따른다고 상상하는 사람들은 거의 없음

    • 코드 작성은 글쓰기와 비슷하며, 초안은 항상 형편없고 좋은 글은 많이 수정됨

  • 코드가 Jenga처럼 쌓여 아무도 손대고 싶지 않게 되는 경우를 본 적이 있음

  • 지속적인 댓글 스레드를 사용하여 디자인 결정을 문서화하는 프로세스를 선호함

    • GitHub 이슈를 사용하여 이 과정을 진행함

  • 이 접근법에 대해 고민 중이며, 최악의 경우 많은 시간을 낭비할 수 있음

    • 문제를 충분히 생각하여 올바른 구현에 필요한 속성을 명시할 수 있을 때 디자인 문서 작성이 가장 유익했음
    • 부분적인 해결책을 구현하여 점진적으로 개선하는 것도 성공적이었음
답변달기