웹 프로그래밍 하면서 참고할 사항들

www.edwith.org/boostcourse-web/joinLectures/12943

[부스트코스] 웹 프로그래밍 강좌소개 : edwith

§  코딩전 생각을 정리하고 시작 §  하는 것에 항상 궁금증을 갖기 - 웹서버와 WAS차이는? 웹서버 - 정적인 컨텐츠 제공, WAS를 거치지 않고 바로 자원을 제공 ( 예, Apache Server, Nginx, IIS등) WAS - DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server ( 예, Tomcat, JBoss, Jeus, Web Sphere) 다양한 구조를 가질 수 있다. Client -> Web Server -> DB Client -> WAS -> DB Client -> Web Server -> WAS -> DB
§  주석, super(), serialVersionUID등을 남겼으면 이유가 있어야한다. (정확한 기능을 파악) §  dateformat같이 계속 사용하는 것은 상수로 빼주는 것이 좋다. -  new가 cost가 높음 §  id와 class용도 -  id는 구분하기 위해 class는 같은 css를 적용하기 위함 (가독성을 높이기 위해서) §  button은 다른기능이 있을때 사용하는 것이 좋다. 단순 link는 <a>태그가 좋을 것이다. -  Semantic Tag (의미론적 태그) (table, article, section, footer등 내용의 의미를 유추할 수 있게 하자) §  Servlet의 package 이름은 보통 url을 거꾸로해서 작성한다. aboutme.today.com → com.today.aboutme §  <br>을 썼으면 실제로도 enter쳐주자 - 가독성을위해	· SUID(serialVersionUID) 필수 값은 아니다. · 호환 가능한 클래스는 SUID값이 고정되어 있다. · SUID가 선언되어 있지 않으면 클래스의 기본 해쉬값을 사용한다. (해쉬값 알고리즘은 링크에서 확인이 가능) nth-child : 해당 엘리먼트의 n 번째 자식 nth-of-type : 해당 엘리먼트 타입의 n 번째 엘리먼트
§  변수, 메소드명은 약어를 쓰지 말자 getCon() → getConnection() §  update는 PUT과 PETCH를 쓰는데 일부만 update할때는 PETCH가 좀 더 목적에 맞다 §  DBUtil에서 static으로 Connection을 가져올때 exception처리를 했는데 아예 Tomcat이 실행되지 않도록 하는 것이 서비스 제공 입장에서 적절하지 않나? §  try-with-resource에서 catch 처리 & try문이 너무 많아서 가독성이 떨어짐. §  datetime format을 가져올때 select문에서 부터 처리해도 괜찮을 것 같음 §  Convention에서 처음과 끝은 띄지 않는 것 §  get을 제외한 요청에서는 요청을 body에 넣어서 처리 §  string equal 비교시 "TODO".equals(dto.getType()) 으로 하는 것이 NULL처리에 효과적 §  db예약어 대문자 §  추가 확인 enum 사용, js falsy값
§  apiController에서 반환값은 뭘 반환하는지 확인해보기 §  다시 한 번 말하지만 함수명은 좀 더 의미있게 §  sql문 작성시 들여쓰기를 해서 보기 쉽게 표현하기 §  this.jdbcTemplate.queryForObject 에서 this가 필요하지 않은 경우 제거 §  !!dataSource()를 두 개 만드는 것, 의미를 확인해보기 §  +=4 에서 4 의 의미를 매직넘버로 표현해준다. §  script가 위에 있으면 script rendering에 의해 느리다 §  NamedParameterJdbcTemplae 와 JdbcTemplate 차이점 PreparedStatement에서 인덱스 기반의 파라미터가 아닌 이름을 가진 파라미터를 사용할 수 있도록 지원하는 템플릿 Class. §  Exception을 처리 - exception 생성자에 text까지 넣어줌, exception발생시 parameter값을 보통 넣어줌 §  data-source를 사용하자	-접근 제한자 public : 모든 접근을 허용 protected : 같은 패키지에 있는 객체와 상속관계의 객체들만 허용 default : 같은 패키지에 있는 객체들만 허용 private : 현재 객체 내에서만 허용 -Bean을 주입받는 방식 (3가지) @Autowired - setter 생성자 (@AllArgsConstructor 사용) -> 권장방식
§  api요청에서 required 항목이 false여야만 하는지 생각해보기 §  sql에서도 JOIN ON과 WHERE에 기능에 맞춰서 쿼리를 작성해주자 §  똑같은 기능을 하는 경우에는 해당 부분만 따로 빼서 관리해주는 것도 괜찮다 §  data type이 date인 경우는 date객체를 가져가는 것이 나중에 핸들링 하기 편하다. §  메소드명에서 두 가지를 바꾸는 경우 toggle이라는 이름이 괜찮다. §  객체 literal을 나누는 것을 좀 더 생각해보는 것이 좋을 것 같다. §  광범위한 이름을 지양하자 §  db에서 가져오는 것이 null인 경우를 쿼리에서 처리해주자 §  추상화 단계를 생각해보자 §  jQuery 같은 경우는 full name을 써주자 $를 사용하는 패키지가 또 존재하므로 §  노출되는 text로 분기를 처리하지 않는 것이 좋다 (화면 텍스트 같은 경우 가장 많이 바뀌는 부분 중 하나)
§  sql문에서 like를 = 으로 바꿔서 데이터 접근을 줄임 §  api요청에서 네트워크가 비용이 쌔다 최대한 줄이도록 §  request mapping에서 name과 path만 있는 경우 spring에서 알아서 처리해주므로 없애는 것이 코드 보기에 좋다. -default 값에 대해 알아보고 코드를 처리 §  RestControllerAdvice나 ControllerAdvice를 통해서 error를 관리할 수 있다. §  매개변수로 들어오는 것을 수정하는 것은 좋지 않다. 혼동 되지 않게 반환하는 것이 있는 것이 좋다.
§  pathVariable는 경로 이름과 인자 이름이 같으면 name을 생략 간으하다 §  system.out.println 대신debug모드를 사용하여 실시간 디버깅을 하자 §  controller에서 if else를 사용할때 validate영역은 위로 추출해서 return하는 것이 보기에 편하다. §  LocaleDateTIme의 경우 서버에 위치에 따라 값이 달라질 수 있다. 보통 db에서 처리한다. §  transactional에 대해 공부하고 insert를 수행할때 사용해주자
§  query문에 경우에도 나중에 수정을 할 수 있기 때문에 명확하게 alias를 주는 것이 좋다. §  localedatetime 을 사용해보자 §  session에서 email을 가져올때 어노테이션을 이용하자 §  이벤트에 내부 html이 변하는 경우 wrapper에 event delegation을 통해 event를 다루면 편리하다. §  header와 footer에 경우 jsp include를 사용할 수 있다. §  random 날짜와 같은 것은 service영역에서 처리하는 것이 좋다. §  email checking을 통해 session이 생성되는 경우 이런 관련 항목은 get이 아닌 다른 방식을 사용하는 것이 좋다 -  구글의 크롤링 같은 경우는 get을 이용한 요청 모두를 수행 §  error은 error자체로 판단하자 0과 같은 숫자를 준다면 파악하기 힘들어진다.
§  insert나 upload같은 경우 수정을 할 수 있으므로 transactional을 달아준다. §  파일 크기에 경우 1024*1024*10으로 해도 jsp로 올라갈때 계산 되어서 저장된다. §  이미지 저장 경로는 application properties로 뽑아낸다. 환경에 따라 적절한 변수들을 넣어주기 위해서 §  코드를 일관성을 준다. §  return 값의 경우 isValid 변수를 주는 것이 아니라 true false 같이 명시적으로 준다. §  userEmail나 login 같은 경우 url을 통해 interceptor 처리해준다. §  함수명은 메소드 안에서 하는 일을 설명해주는 것이 좋다.
§  debug 레벨을 중요하다고 생각하는 레벨로 설정 §  getAttribute 말고 dataset을 이용해서 js 코드를 작성 §  http error 코드에 맞는 변수를 반환	·         400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다. ·         401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다. ·         402(결제 필요): 이 요청은 결제가 필요합니다. ·         403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음) ·         404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다. ·         405(허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.