Chapter3.1 - 에러 메시지를 쓰기 전에 에러부터 없애자 친절한 404, 불친절한 404 구글, 위키피디아의 경우 간단하게만 에러페이지 출력 다음이나 YES24의 경우는 친절하게 안내 404 에러가 죄송할 일인가? 404 에러를 만나는 경우 사용자가 URL을 잘못 입력한 경우 사용자가 링크를 클릭했으나 해당 페이지가 없는 경우 이 경우는 개발자가 죽은 링크를 처리하지 않은 것 깨진 링크는 개발자의 책임이다 브로큰링크체크닷컴 구글 서치콘솔을 이용하여 깨진 링크 확인 가능 개발자용 에러 메시지와 사용자용 에러 메시지를 분리하자 사용자에게 보여지는 메시지와 개발자용 메시지를 분리하여 정의하기
Chapter2.5 - 다른 개발자를 배려하는 주석 쓰기 코드는 의미를, 주석은 의도를 개발자가 의도를 전달하는 이유는 다른 개발자를 위한 것 letsEatSomething() // 내가 배가 고픈 상황 letsEatSomething() // 네가 배가 고픈 상황 letsEatSomething() // 내가 심심한 상황 주석의 반복 문서를 처음부터 보는 경우는 반복이 필요가 없을 것임 특정 부분만 검색해서 확인하고자 할때는 주석이 필요할 것임 독자에 따라 작성하는 것이 좋음 주석의 발췌와 요약 중요한 부분을 뽑으려면 덜 중요한 것을 빼야함 예시 // 사용자가 레벨업하려면 로그인을 10회 이상하고 게시물을 5개 이상 작성해야 한다. if(user.getLoginCount() >= 10 && user.get..
Chapter2.4 - 좋은 코드에는 주석이 없다? 이름을 잘 지으면 주석을 줄일 수 있다 이름이 주석을 대신할 수 있도록 // bad example // 스크린 최대 높이를 480으로 지정 int h = 480; // 사용자 유형을 분류해서 등급 값을 리턴 levelUser(); // good example int screenHeightMax = 480; classifyUserAndReturnClass(); 처음부터 주석 없이 코딩하는 연습을 하자 JSON에는 주석을 달 수 없었음 // 요청에 대한 성공/실패 여부 구분 "isRequestSucess": true, // 잘못된 이메일 주소 형식, 추가하지 않음 "noCreatedBecauseWrongEmail": [ ] 주석이 필요한 때도 많다 upda..
Chapter2.3 - 좋은 이름의 기준, SMART 한 번에 좋은 이름을 지을 수 없다 좋은 이름이 가진 5가지 특징 easy to Search easy to Mix easy to Agree easy to Remember easy to Type easy to Search: 검색하기 쉽게 이름 짓는 법 고전적 범주화를 이용해 한 단계 상위 범주의 이름을 태그처럼 덧붙이기 고전적 범주화: 특정 대상들을 묶어 상위 범주를 만들기 에러에 대한 내용이 있을 경우 앞에 ERROR를 붙이기 사용자에 구별 시 user 붙이기 같은 접두어의 함수, 변수의 개수가 너무 많으면 구분 체계 먼저 다듬기 easy to Mix: 조합하기 쉽게 이름 짓는 법 개발 언어의 문법과 조합하여 이름 짓기 easy to Agree: 수긍..
Chapter2.2 - 변수 이름을 잘 짓는 법 i는 변수 이름이지만 d는 아니다 반복문, 조건문 등에서 가장 많이 사용하는 i는 사실 integer의 약자 // Bad Example int d; int m; int y; // Good Example int someday; int today; int thisMonth; int finalYear; int daysSinceCreated; int monthSinceUpdated; int yearsSinceRegistered; 긴 이름? 짧은 이름? 검색 잘 되는 이름! 변수길이와 오탈자와는 이제 별개 검색이 쉽도록! 복수형을 나타내는 s를 붙여야 하나 변수명은 짧기에 s가 눈에 잘 띄지만 함수명은 길어서 잘 보이지 않음 -s보다 list of 같은걸로 대체 하..