‘개발자의 글쓰기’를 읽고…

  • 개발자의 글: 정확성, 간결성, 가독성이 상충
  • 글쓰기: 서술식, 개조식, 도식
  • 쉬운 띄어쓰기 원칙: 조사,순서, 숫자, 하다, 기호만 붙인다.
  • 영어
    • 정확한 반대말: show/hide, visible/invisible
    • 뉘앙스 차이: stop/end/finish/pause/suspend/hold, change/modify/revise, must/should
    • 외래어 표기법: Python
  • 이름 짓기
    • 약어는 보편성 기준
    • 중요한 단어를 앞에?
    • 좋은 이름 SMART: easy to Search/Mix/Agree/Remember/Type
  • 주석없는 코딩 연습
    • 코드는 의미를, 주석의 의도를
    • 검색을 위해 주석을 반복해야할 때도 있다.
    • 주석도 코드처럼 관리/최신화
  • 에러 메시지 이전에 에러를 없애자
    • 개발자용 오류 메시지와 사용자용 오류 메시지를 분리하자.
    • 사용자 오류 메시지 내용 순서: 원인-내용-대책 => 대책-원인-결과
    • 사용자 관점 메시지
    • 오류 메시지 이전 예방 활동
  • 릴리스 문서와 장애 보고서 쓰기
    • 너무 짧아도, 너무 길어도 X
    • 회사>독자>개발자 순위로 내용 선정
    • Versioning: 호환성
    • 문제, 문제점, 해결책, 후속 계획
    • 장애: 내용, 영향, 원인, 조치 상황, 조치 결과, 핵심 원인, 향후 대책
    • 장애보고는 확률로?
  • 서비스 설명
    • 장점: 절대적, 강점: 상대적
  • 개발 가이드 쓰기
  • SI 제안서 쓰기
  • 기술 블로그: 저/술/편/집
    • 저: 경험한 이야기(개발 일지, 적용기)
      • 성공 루트 + 문제 해결
    • 술: 분석, 설명(기술 소개, 오류 해결법)
      • 원전과 비교
    • 편: 자료 정리(프로그램 설치 방법, 튜토리얼?, 세미나 후기, 책 리뷰?)
      • 순서를 요약(묶어서 의미를 부여)
    • 집: 흩어진 자료 모음(명령어 모읍, 팁, N가지 규칙)
  • 기업의 기술 블로그
    • 채용
    • 노하우 축적
    • 개발자 성장