1P by neo 15일전 | favorite | 댓글 1개

컴퓨터를 위한 코드 작성은 어렵지만, 사람을 위한 코드 작성은 더 어렵다

  • 컴퓨터를 위한 코드를 작성하는 것은 이미 어렵다. 큰 비즈니스 목표를 작은 논리적 명령어로 분해해야 하기 때문임.
  • 하지만 사람을 위한 코드를 작성하는 것은 더 어렵다. 이는 컴퓨터 과학과 심리학이 결합된 작업임.
  • Richard Feynman의 말처럼, 전자가 감정을 가지고 있다면 물리학이 얼마나 어려울지 상상해보라. 이는 사람을 위한 프로그래밍을 설명하는 데 적절함.

시작이 곧 제품이다

  • 사용자 피드백을 듣는 것은 중요하지만, 대부분의 피드백은 제품을 자주 사용하는 파워 유저로부터 옴.
  • 생존 편향이 존재함. 시작하지 않은 사용자의 피드백은 거의 듣지 못함.
  • 소비자 제품은 오랜 기간 동안 온보딩 과정을 최적화해왔음. 개발 도구도 동일해야 함.
  • 온보딩 과정을 제품의 일부로 간주하고, 설정을 최소화하여 사용자가 몇 분 내에 제품을 사용할 수 있도록 해야 함.

사람은 '핵심 개념'이 아닌 예제로부터 배운다

  • 사람은 패턴 매칭에 뛰어남. 반면 컴퓨터는 엄격한 논리를 따름.
  • 많은 개발 도구 문서는 컴퓨터 프로그램처럼 작성됨. 이는 사람에게 적합하지 않음.
  • 예제를 통해 배우는 것이 더 효과적임. 예제는 사용자가 도구를 이해하는 데 도움이 됨.

성공의 함정에 빠지기

  • 프로그래밍의 기본 모드는 오류 수정임. 사용자는 대부분의 시간을 오류 수정에 보냄.
  • 오류를 성공으로 유도하는 것이 중요함.
  • 오류를 기회로 삼아 사용자를 올바른 경로로 안내해야 함. 예외 처리에 코드 스니펫을 포함시키고, 경고 메시지를 통해 도움을 제공해야 함.

개념적 과부하 피하기

  • 새로운 개념을 이해해야 하는 것은 마찰을 일으킴.
  • 2-3개의 개념은 괜찮지만, 8개의 새로운 개념을 배우는 것은 부담스러움.
  • 적은 개념으로 강력한 기능을 제공하는 프레임워크가 이상적임. 예를 들어, React는 몇 가지 간단한 개념으로 강력한 기능을 제공함.

개념적 오리 원칙

  • 새로운 개념을 도입할 때, 사용자에게 친숙한 용어를 사용하는 것이 중요함.
  • 예를 들어, 새로운 값을 평가하는 것을 '함수'라고 부르는 것이 좋음. 이는 사용자가 기존의 정신 모델을 활용할 수 있게 함.

프로그래머블리티

  • 사용자는 코드베이스에서 창의적인 작업을 할 것임.
  • 프레임워크의 거의 모든 것이 '프로그래머블'해야 함.
  • CLI 대신 코드에서 직접 호출할 수 있도록 하고, 설정을 SDK나 API로 전환해야 함.

마법, 기본값, 구문 설탕에 신중해야 함

  • 기본값과 마법 같은 기능은 신중하게 도입해야 함.
  • 기본값이 97% 이상, 마법이 99% 이상 적용되지 않는다면 도입을 피해야 함.
  • 코딩은 골프가 아님. 최소한의 코드 작성을 목표로 하지 말고, 가독성을 중시해야 함.

사람을 위한 코드 작성은 어렵다

  • 대부분의 것들은 불변해야 함.
  • '스캐폴딩'(코드 생성)을 피해야 함.
  • 피드백 루프를 매우 빠르게 만들어야 함.
  • 사용자가 쉽게 대처할 수 있도록 폐기 절차를 마련해야 함.
  • 문서와 예제에서 코드 스니펫에 대한 자동 테스트를 사용해야 함.

GN⁺의 정리

  • 이 글은 사람을 위한 코드 작성의 어려움과 그 해결책을 다룸.
  • 사용자 친화적인 개발 도구를 만드는 것이 중요하며, 이는 온보딩 과정에서 시작됨.
  • 예제를 통해 배우는 것이 효과적이며, 오류를 성공으로 유도하는 것이 핵심임.
  • 새로운 개념을 도입할 때는 사용자에게 친숙한 용어를 사용하고, 프로그래머블리티를 고려해야 함.
  • 기본값과 마법 같은 기능은 신중하게 도입해야 하며, 가독성을 중시해야 함.
Hacker News 의견
  • 사람들은 각기 다른 방식으로 배움

    • 핵심 개념을 먼저 이해한 후 예제를 보는 것을 선호함
    • 많은 튜토리얼이 레고 조립처럼 손을 잡아주는 방식임
    • 결정을 내리는 방법과 이유를 알고 싶음
    • 새로운 라이브러리나 프레임워크를 접근할 때, 소개 텍스트를 먼저 읽고, "Getting started" 코드 샘플을 건너뜀
    • 고급 섹션에서 개념에 대한 논의가 더 많아 이를 먼저 탐구함
  • 글쓰기와 공감 능력이 중요함

    • 코드 작성과 애플리케이션 작성은 다름
    • 외부 지향적인 개발자는 아키텍처와 문서화에 더 신경 씀
    • 단순함이 중요함
    • 애플리케이션 작성은 에세이 작성과 비슷함
    • 프레임워크는 개발자의 조직 능력을 저해함
  • 모든 사람이 예제로부터 배우는 것은 아님

    • 일반에서 구체로 배우는 사람도 있음
    • 이런 사람들은 K12 교육에서 소외됨
  • 코드는 인간을 위해 작성됨

    • 문제를 포괄적으로 이해하고, 이해관계자와 협력하며, 효율적인 알고리즘을 고안하는 것이 중요함
    • 코드 작성은 어렵지 않음
  • Code Complete에서 인용

    • "프로그래밍의 작은 부분은 컴퓨터가 읽을 수 있도록 프로그램을 작성하는 것이고, 큰 부분은 다른 인간이 읽을 수 있도록 작성하는 것임"
  • 코드 작성은 인간을 위한 것임

    • 컴퓨터는 기계 명령어로 충분함
    • 코드는 인간의 생각을 형식화하는 방법임
  • IDE의 발전에 대한 의견

    • 기본 intellisense는 개선되었지만, 코딩의 개념은 크게 변하지 않음
    • 새로운 도구와 라이브러리 접근이 쉬워짐
    • 코딩 작업을 컴퓨터에 맡기고 창작에 집중하고 싶음
    • 언어의 작은 세부 사항을 자동으로 처리하는 도구가 필요함
    • 여러 메서드를 동시에 화면에 표시하고 싶음
    • 데이터 변환을 자동으로 처리하고 싶음
  • 블로그 포스트 홍보

    • "Move Fast & Document Things"라는 블로그 포스트를 작성함
    • 코드 작성 문화를 공유함
  • 프로그래밍 학습 방법에 대한 의견

    • 작은 프로그램을 작성하며 배움
    • 기본 지식이 부족해 더 좋은 소프트웨어 개발 직업에 지원할 수 없었음
    • 기본을 항상 배우는 것이 중요함
  • 예제와 핵심 개념의 중요성

    • 예제와 핵심 개념 모두 중요함
    • 잘 정의되고 문서화된 핵심 개념이 필요함
    • "Getting Started" 가이드에는 예제가 포함되어야 함