[책읽고 적어놓기] 개발자의 글쓰기

개발자의 글쓰기
개발자의 글쓰기
김철수 지음
영어단어 선택과 래어 표기법
  • stop :잠시 중단한 것이어서 언제든 재시작 할수 있다.
  • end : 완전히 중단되어 재시작할 가능성이 없다.
  • finish : 끝장을 본 상태여서 재시작을 고려할 필요가 없다.
  • pause : 아주 잠시 일시적으로 중단된 것이어서 금방이라도 다시 시작할수 있다.
  • suspend : 다음단계를 중단한 것이다
  • hold : 어떤 의도가 있어서 중단한 것이다.
  • get : 어떤 값을 돌려받아서 반환하는 함수에 사용한다.
  • return : 함수이름에 쓰지 않는다. 주로 함수 안에서 제어에 쓰기 때문이다.
  • retrieve : 검색해서 가져온다. 검색에 무게가 실린다면 이 단어를 쓰는게 낫다.
  • acquire : 독점한다는 뜻이다 다른 함수가 가져가지 못하게 독점하고자 할때 쓴다.
  • fetch : 현재 값을 가리키는 포인터가 다음값으로 이동한 것 가져온다는 뜻이다.
  • set : 값을 변경하거나 설정하는 함수에 쓴다.
  • init : 초기화설정할때 쓴다.
  • register : 이미 정해진 틀에 값을 집어넣는 것이다.
  • create : 정해진 틀이 없으므로 먼저 틀을 만들때 쓴다.
  • change : 내용을 단순히 바꾼다는 뜻이다.
  • modify : 잘못된 것을 바로 잡을 때 쓴다.
  • revise : 기존에 없던 새로운 정보나 아이디어를 덧붙여 기존 내용과 달라졌음을 분명히 할때 사용한다.
  • parameter : 매개변수로 함수를 정의한 변수를 뜻한다.
  • argument : 전달 인자로 함수를 호출할 때 전달되는 값을 의미한다.
  • attribute : html에서 태그안에 속성을 넣을 때 사용되는 요소다.
  • property : attribute를 html DOM에서 가리킬 때
  • must : 필수요구사항이다. 요구 그자체이므로 구현돼야 한다는 의미다.
  • must not : 결코 구현돼서는 안되는 일이다. 해서는 안되는 일, 일어나서는 안되는 현상을 정의할때 사용한다.
  • should : 권고 또는 권장사항이다. 가능하면 지키거나 구현해야 한다. 만약 구현이 어렵다면 다른 방법을 취할수도 있다.
  • should not : 구현되지 않는 것이 더 좋다는 의미다. 필요하다면 다른 방법을 취하는 것이 좋다.
  • 행동이 필요한 함수라면 do를 써서 doSomething()으로 이름을 짓기도 한다.
  • bool값을 반환하는 함수라면 is나 does를쓰기도 한다.

     

네이밍 컨벤션, 이유를 알고 쓰자
  •  BEM  (Block Element, Modifier) 표기법 : 대상 –요소__상태를 의미한다
    form {}
    form–button {}
    form–button__disabled {}
 

변수이름 잘 짓는 법

  • 일자 Day : 임의의 날(someday), 특정한 날(thisDay), 마지막날(finalDay)
  • 중요한 단어를 앞에 쓴다. (ex: int visitorTotal, int registerTotal, buyerTotal, WindowSizeMax, vipCount..)
좋은 이름의 기준, SMART

좋은 이름의 5가지 특징

  • easy to Search 검색하기 쉽고
  • easy to Mix 조합하기 쉽고
  • easy to Agree 동의하기 쉽고
  • easy to Remember 기억하기 쉽고
  • easy to Type 입력하기 쉽고
에러 메시지를 쓰기 전에 에러부터 없애자
깨진 링크는 개발자의 책임이다.
  • 브링크링크체크닷컴(https://www.brokenlinkcheck.com)-깨진 링크 찾아주는 서비스
  • 구글서치콘솔(https://www.google.com/webmasters/tools)를 이용하면 구글검색엔진에서 특정사이트의 깨진 링크를 쉽게 찾아낼 수 있다.
에러 메시지 대신 예방 메시지를 쓰자

결재요청시
재확인 방식 : 결재요청 → 재확인 → 결재처리
취소방식 : 결재요청 → 결재처리 + 취소기능
혼합방식 : 결재요청 → 재확인 → 결재처리 + 취소기능

사용자입장에서 보자.  재확인 방식에서는 사용자가 결재요청버튼을 누르면 순간 무조건 재확인해야 한다. 재확인은 경고다. 사용자가 의사결정을 했는데 그 결정이 확실하지 않을 수 있으니 다시 확인하나는 시스템의 강요다. 사용자의 의사결정은 근본적으로 실수가 잦고 믿을 수 없다고 보는 관점이다.

사용자가 실수로 결재 요청 버튼을 누르는 것을 막기 위해야서라면 다른 방식을 써야 한다. 결재요청버튼의 위치나 크기를 다시 설정해야 옳다. 또 그렇게 실수를 했더라도 다음 화면에서 취소기능을 보여줘서 사용자가 스스로 취소할 수 있게 해야 한다. 그렇게 함으므로써 자신의 행동을 주체적으로 책임지게 만들어야 한다.

이것은 철학의 문제다. 개발자가 사용자를 불완전한 존재로 인식하는 순간 모든 사용자의 행동에 경고로 대응한다. 그러면 시스템도 불완전해진다. 사용자의 행동 하나하나가 불완전하므로 사용자의 모든 행동을 검증해야 한다. 사용자를 성인이 아니라 미숙아로 취급하는 것과 다름없다.

어떤 방식을 쓸지는 서비스와 사용자에 따라 달라지겠지만, 개발자도 자신만의 철학을 가져야 한다.

릴리스 문서는 문제 해결 보고서처럼 쓰자
문제, 문제점 해결책, 후속계획 순으로 적자.
비지니스를 이해하는 장애 보고서를 쓰기
  • 질문에 대답하는 신속한 글쓰기
  • 원인과 이유를 찾는 분석적 글쓰기
  • 상사를 고려하는 비지니스 관점의 글쓰기
  • 원하는 것을 얻는 정치적 글쓰기
(예) 장애보고서 제목: 서버 모듈 변경 문제로 사용자 결제 불가(10-11시)