반응형


 

안녕하세요. 오늘은 작년 신입 교육 때, 딱 1년 전 읽었던 책 ( 열혈강의, 자바 웹 개발 워크북 )에 대해 정리해 보는 시간을 갖도록 하겠습니다. 책상 옆에 놓여있길래 막상 꺼내 펼쳐 보니 잊고 있었던 내용들도 있고 다시 한 번 상기할만한 내용들이 있어 이렇게 정리하게 되었습니다. 이제 막 웹을 시작하시는 분들이 보시기에 좋은 책인 것 같습니다. 정리라는게 챕터별로 정리하는 게 아닌 개인적으로 메모해놓고 다음에 다시 상기해 볼 만한 내용들이나 괜찮은 내용이다 싶은 부분만을 추려 정리하는 것이기 때문에 자세한 내용을 알고 싶으실 경우 책을 사서 보시길 추천해드립니다.

 

 

[ 프록시 서버 (Proxy Server) ]

클라이언트와 서버 사이에서 통신을 중계해 주는 컴퓨터나 프로그램을 말합니다. 프록시 서버의 주된 용도 중 하나는 빠른 전송을 위하여 서버의 응답 결과를 캐시에 저장해 두는 것입니다. 프록시 서버를 두는 두 번째 이유는 보안적인 부분인데, 첨단 기술을 다루는 회사의 경우 내부 사용자의 기밀 유출에 민감할 수밖에 없습니다. 이런 경우 프록시 서버를 이용하면 외부로 전달되는 데이터를 검사하여 특정 단어가 포함된 자료의 송.수신을 차단하거나 보안 팀에 경고 메시지를 보낼 수 있습니다.

 

[ 멀티 프로세스와 멀티 스레드 ]

멀티 프로세스 방식은 클라이언트가 연결 요청을 하면 서버 프로그램은 자신을 복제하여 클라이언트에 대응하게 하고, 자신은 다른 클라이언트의 요청을 기다립니다. 이 방식은 원본 프로세스의 메모리를 모두 복제하기 때문에 자원 낭비가 심합니다. 그에 비해 멀티 스레드 방식은 클라이언트 요청을 처리하는 일부 코드만 별도로 분리하여 실행하기 때문에 전체 메모리를 복제할 필요가 없어, 멀티 프로세스 방식보다 메모리 낭비가 적습니다.

 

[ 요청 헤더 ]

헤더에는 세 가지 종류가 있는데 요청이나 응답 모두에 적용할 수 있는 '일반 헤더(General-header)'와 요청 또는 응답 둘 중 하나에만 적용할 수 있는 '요청 헤더 또는 응답 헤더(Request-header/Response-header)', 보내거나 받는 본문 데이터를 설명하는 '엔티티 헤더(Entity-header)'가 있습니다. 요청 헤더가 담는 헤더명중 User-Agent가 있는데 클라이언트의 정보를 서버에게 알려주는 헤더입니다. 웹 서버는 이 헤더를 분석하여 요청자의 OS와 브라우저를 구분합니다.

 

[ CGI(Common Gateway Interface) ]

웹 서버와 프로그램 사이의 데이터를 주고받는 규칙을 CGI(Common Gateway Interface)라고 합니다. 이렇게 웹 서버에 의해 실행되며 CGI 규칙에 따라서 웹 서버와 데이터를 주고 받도록 작성된 프로그램을 'CGI 프로그램'이라고 합니다.

 

[ 서블릿 컨테이너 ]

서블릿의 생성과 실행, 소멸 등 생명주기를 관리하는 프로그램을 '서블릿 컨테이너(Servlet Container)'라 합니다. 서블릿 컨테이너(Jave EE 기술 중에서 서블릿, JSP 등 웹 관련 부분만 구현한 서버로 아파치 재단의 톰캣, Jetty등)가 서블릿을 대신하여 CGI 규칙에 따라 웹 서버와 데이터를 주고받습니다.

 

[ WebContent/Web-INF ]

웹 애플리케이션의 설정과 관련된 파일을 두는 폴더로 이 폴더에 있는 파일은 클라이언트에서 요청할 수 없다. 따라서 HTML이나 JavaScript, CSS 등 클라이언트에서 요청할 수 있는 파일을 이 폴더에 두어서는 안 됩니다.

 

[ GET 요청으로 넘어온 매개변수 값의 인코딩 설정 ]

GET 요청은 매개변수 값이 URL에 포함되기 때문에 setCharacterEncoding()으로는 문자 집합을 설정할 수 없다. 톰캣 서버에서 server.xml을 열어 <Connector>태그에 URIEncoding 속성을 추가하고, 값은 UTF-8로 설정한다. 웹 브라우저가 웹 서버로 데이터를 보낼 때는 웹 페이지의 기본 문자집합으로 인코딩하여 보내기 때문에 사용자가 입력한 값은 UTF-8로 인코딩되어 서버에 전달된다. 반면 서블릿은 UTF-8(한글 한 자를 3바이트로 표현) 3바이트를 하나의 문자로 인식하지 않고 각각의 바이트를 개별 문자로 취급하여 유니코드로 변환한다. 이렇기에 server.xml에 설정을 해주지 않을 경우 한글이 깨지게 된다.

 

[ SeverletContext 보관소 ]

웹 애플리케이션이 시작될 때 생성되어 웹 애플리케이션이 종료될 때까지 유지된다. 이 보관소에 데이터를 보관하면 웹 애플리케이션이 실행되는 동안에는 모든 서블릿이 사용할 수 있다.

 

[ HttpSession 보관소 ]

클라이언트의 최초 요청 시 생성되어 브라우저를 닫을 때까지 유지됩니다. 보통 로그인할 때 이 보관소를 초기화하고, 로그아웃하면 이 보관소에 저장된 값들을 비웁니다. 따라서 이 보관소에 값을 보관하면 서블릿이나 JSP 페이지에 상관없이 로그아웃하기 전까지 계속 값을 유지할 수 있습니다. JSP에서는 session변수를 통해 이 보관소를 참조할 수 있습니다.

 

[ ServletRequest 보관소 ]

클라이언트의 요청이 들어올 때 생성되어, 클라이언트에게 응답 할 때까지 유지됩니다. 이 보관소는 포워딩이나 인클루딩하는 서블릿들 사이에서 값을 공유할 때 유용합니다. JSP에서는 request변수를 통해 이 보관소를 참조할 수 있습니다.

 

[ JspContext 보관소 ]

JSP 페이지를 실행하는 동안만 유지됩니다. JSP에서는 pageContext 변수를 통해 이 보관소를 참조할 수 있습니다.

 

[ HttpSession ]

HttpSession 객체는 클라이언트 당 한 개가 생성됩니다. 웹 브라우저로부터 요청이 들어오면, 그 웹 브라우저를 위한 HttpSession 객체가 있는지 검사하고, 없다면 새로 HttpSession 객체를 만듭니다. 이렇게 생성된 HttpSession 객체는 그 웹 브라우저로부터 일정 시간 동안 Timeout 요청이 없으면, 삭제됩니다.

 

[ JspContext의 활용 ]

JSP 페이지를 작성하다 보면 <jsp:include>와 같은 특별한 태그를 사용하게 됩니다. 이런 태그들은 JSP 엔진이 서블릿 클래스를 생성할 때 특정 자바 코드로 변환됩니다. 이때 이 태그의 값을 다루는 객체를 '태그 핸들러'라고 부릅니다. 바로 이 태그 핸들러에게 데이터를 전달하고자 할 때 JspContext 보관소를 사용하는 것입니다.  JSP 페이지에 선언된 로컬 변수는 태그 핸들러에서 접근할 수 없습니다. 따라서 태그 핸들러에게 전달할 데이터가 아니라면 JspContext에 값을 보관할 필요가 없습니다.

 

[ EL(Expression Language) ]

EL(Expression Language)은 콤마(.)와 대괄호([])를 사용하여 자바 빈의 프로퍼티나 맵, 리스트, 배열의 값을 보다 쉽게 꺼내게 해주는 기술로 스태틱(static)으로 선언된 메서드를 호출 할 수도 있습니다. EL은 ${}와 #{}를 사용하여 값을 표현합니다. ${표현식} 으로 지정된 값은 JSP가 실행될 때 JSP 페이지에 즉시 반영됩니다. 그래서 ${}을 '즉시 적용(immediate evaluation)'이라 부릅니다. #{}을 '지연 적용(deferred evaluation)'이라 부르는데 UI를 만들 때 사용된다고 합니다.

 

[ DI(Dependency Injection) ]

작업에 필요한 객체를 외부로부터 주입 받는 것으로 다른 말로 역제어(IoC, Inversion of Control)'라고도 부릅니다.

 

[ mybatis ]

mybatis는 반복적이고 지루한 JDBC 프로그래밍을 단순화하기 위해 클린턴 비긴이 만든 작은 라이브러리에서 출발하였다. 이 라이브러리는 iBATIS라는 이름으로 2004년 아파치 소프트웨어 재단에 기부되면서 알려지게 되었다. 좀 더 효율적인 개발 관리를 목표로 2010년 6월 아파치 재단에서 구글 코드로 이사하였고 프로젝트 이름도 mybaits로 바뀌었다. mybatis의 핵심은 개발과 유지보수가 쉽도록 소스 코드에 박혀있는 SQL을 별도의 파일로 분리하는 것이다. 또한 단순하고 반복적인 JDBC 코드를 캡슐화하여 데이터베이스 프로그래밍을 간결하게 만드는 것이다.

 

[ mybatis javaType속성 ]

<result>에서 javaType을 사용하면, 칼럼의 값을 특정 자바 객체로 변환할 수 있다. 다음과 같이 'STA_DATE'칼럼에 대해 javaType을 java.sql.Date으로 설정하면, 칼럼 값을 꺼낼 때 그 객체로 변환된다.

<result column="STA_DATE" property="startDate" javaType="java.sql.Date"/>

 

[ mybatis <id> 엘리먼트 ]

SELECT 문을 실행하면 레코드 값을 저장하기 위해 결과 객체가 생성되는데, SELECT문을 실행할 때마다 매번 결과 객체를 생성한다면 실행 성능이 나빠질 것입니다. 이를 해결하기 위해 SELECT를 통해 생성된 결과 객체들은 별도의 보관소에 저장(캐싱, caching)해두고, 다음 SELECT를 실행할 때 재사용합니다. 이때 보관소에 저장된 객체를 구분하는 값으로 <id>에서 지정한 프로퍼티를 사용합니다.

 

[ mybatis의 SELECT 결과 캐싱 ]

SELECT를 실행할 때마다 결과 레코드에 대해 매번 객체를 생성한다면, 속도도 느리고 메모리도 낭비됩니다. 이를 개선하기 위해 mybatis는 객체 캐싱을 제공합니다. 즉 한 번 생성된 객체는 버리지 않고 보관해 두었다가, 다음 SELECT를 실행할 때 재사용하는 것입니다. 첫 번째 질의를 수행할 때 생성된 결과 객체는 풀(pool)에 보관해 둡니다. 두 번째 질의에서는 질의 결과에 대해 새로 객체를 생성하기 전에, 객체 풀에 보관된 객체 중에서 해당 칼럼의 값과 일치하는 객체를 먼저 찾습니다. 있다면 기존 객체를 사용하고 없다면 새로 객체를 생성합니다. 이것이 mybatis의 객체 캐싱 기법입니다.

 



반응형
반응형

 


 이번에는 최근에 읽은 책인 '읽기 좋은 코드가 좋은 코드다'에 대해서 리마인드도 할겸 조금이라도 생각하게 만들었던 문장들에 대해 정리해보는 시간을 가지도록 하겠습니다. 책을 읽으면서 그동안 저의 안좋았던 코딩 습관들에 대해서 다시 한 번 돌아보는 시간을 가졌고 뭔가 어렵게 짜려고 하기 보다는 심플하면서도 읽기 좋은 코드를 짜도록 노력해야겠다고 다짐하며 정리를 시작하도록 하겠습니다. 가볍게 한 번 읽어주시면 좋을 것 같습니다.



⇒ 코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.


⇒ Alt + / = 자동완성(이클립스) >> 그동안 ctrl+space를 많이 사용했는데 옆의 명령어는 바로 자동완성을 해주는 기능


⇒ 팀에 새로 합류한 사람이 이름이 의미하는 바를 이해할 수 있을까? 만약 그렇다면 그 이름은 괜찮은 것이다. (네이밍의 중요성, 내 주관적인 의미에만 집중해서 작성하지 않기!!!)


⇒  대상을 자세히 묘사하는 구체적인 이름을 사용하라. ex) ServerCanStart()보다는 CanListenOnPort()


⇒ 변수명에 중요한 세부 정보를 덧붙여라. 예를 들어 밀리초의 값을 저장하는 변수 뒤에 _ms를 붙이거나 이스케이핑을 수행하는 변수의 앞에 raw_를 붙이는 것이다. 


⇒ 본인이 지은 이름을 "다른 사람들이 다른 의미로 해석할 수 있을까?"라는 질문을 던져보며 철저하게 확인해야 한다.


⇒ 경계를 포함하는 한계 값을 다룰 때는 min과 max를 사용하라.(start, end보다는 경계를 표현하기 위해서는 min, max가 더 정확)


⇒ 주석의 목적은 코드를 읽는 사람이 코드를 작성한 사람만큼 코드를 잘 이해하게 돕는 데 있다.


⇒ 코드에서 빠르게 유추할 수 있는 내용은 주석으로 달지 말자.(너무 뻔한 내용들에 대해서는 주석으로 남기지 않는다.)


⇒ 일반적으로 사람들은 코드가 가진 나쁜 가독성을 메우려고 노력하는 '애쓰는 주석'을 원하지 않는다. 프로그래머들은 이러한 규칙을 대개 좋은 코드 > 나쁜 코드 + 좋은 주석이라는 공식으로 설명한다. (나쁜 코드를 짜고 주석을 다는 방식이 아닌 누가 봐도 이해할 수 있는 좋은 코드를 짜는데 집중하자)


⇒ 좋은 주석은 단순히 '자신의 생각을 기록하는 것' 만으로도 탄생할 수 있다. 즉, 코딩할 때 생각했던 중요한 생각을 기록하면 된다. ex) 놀랍게도, 이 데이터에서 이진트리는 해시테이블보다 40%정도 빠르다. 


⇒ 작성하는 코드의 이러저러한 내용을 훗날 수정할 거라는 생각이 들면, 그러한 생각을 주석으로 작성하는 일은 당연하게 받아들여야 한다는 사실이다. 주석은 코드를 읽는 사람에게 코드의 질이나 상태 그리고 추후 개선 방법 등을 제시하여 소중한 통찰을 제공한다.


⇒ 상세하고 공식적인 문서를 작성해야 한다는 생각에 압도당하지 말라. 잘 선택된 몇몇 문장이 아무것도 없는 것보다는 훨씬 나은 법이다.


⇒ 주석을 다는 목적은 코드를 작성하는 사람이 알고 있는 정보를 코드를 읽는 사람에게 전달하는 것이다. 


[ 주석으로 설명하지 말아야 하는 것 ]


:: 코드 자체에서 재빨리 도출될 수 있는 사실


:: 나쁜 함수명과 같이 나쁘게 작성된 코드를 보정하려고 '애쓰는 주석'. 그렇게 하는 대신 코드를 수정하라.



[ 주석으로 기록해야 하는 것 ]


:: 코드가 특정한 방식으로 작성된 이유를 설명해주는 내용


:: 코드에 담긴 결함. TODO:혹은 XXX:와 같은 표시를 사용


:: 어떤 상수가 특정한 값을 갖게 된 '사연'


⇒ 기본적으로 if/else를 이용하라. ?: 를 이용하는 삼항 연산은 매우 간단할 때만 사용해야 한다. (삼한 연산자로 표현은 간결해지지만 오히려 읽기 이해하기 힘들어지는 연산들이 있다. 이때는 삼한 연산자보다는 읽기 쉽게 if/else를 사용하여 코딩하도록 하자.)


⇒ "전역 변수를 피하라". 전역 변수는 어디에서 어떻게 사용되는지 일일이 확인하기 어려우므로 이는 합당한 조언이다. 또한, 전역 변수의 이름과 지역 변수의 이름이 중복되어 이름공간이 더러워 질 수도 있고, 어떤 코드가 지역 변수를 변경할 때 실수로 전역 변수를 변경하거나 혹은 그 반대의 경우가 일어 날 수 있다.


⇒ 할머니에게 설명할 수 없다면 당신은 제대로 이해한 게 아닙니다. -알버트 아인슈타인 (참 맞는말이다. 무엇인가를 이해했다는 건 해당 지식이 전무한 사람에게도 설명할 수 있어야 한다. 그만큼 제대로 된 이해는 중요하다 )


⇒ 복잡한 생각을 다른 사람에게 설명할 때 중요하지 않은 자세한 내용 때문에 듣는 사람을 혼동시키는 일이 종종 있다. '쉬운 말'로 자신의 생각을 지식이 부족한 사람에게 전달하는 기술은 매우 소중하다. (누군가에게 설명하기 위해서는 해당 부분에 대한 완벽한 이해가 수반되어야 함을 명심하자. 이해하면 설명하고 싶어진다 by 김동범)


⇒ 일반적인 '유틸리티'를 많이 생성하여 중복된 코드를 제거하라.


⇒ 사용하지 않는 코드 혹은 필요 없는 기능을 제거하라.


⇒ 코드를 제거하는 작업을 코딩을 하는데 투자한 시간이 쓸모 없는 시간이었다고 여기는 사고를 버려야 한다. 프로그래밍은 창의력을 요구하는 분야다. 사진사, 작가, 영화감독 같은 사람은 모든 작업 결과를 보존하지 않는다. (코드 리무버가 되기 위해서는 해당 소스 코드에 대한 정확한 이해와 판단이 필요하다. 즉 아무나 코드를 제거할 수 없다.)


⇒ 매일 15분씩 자신의 표준 라이브러리에 있는 모든 함수/모듈/형들의 이름을 읽어라. 라이브러리 전체를 암기하라는 게 아니다. 그냥 그 안에 무엇이 있는지 감을 잡아놓고, 나중에 새로운 코드를 작성할 때 "잠깐만, 이건 전에 API에서 보았던 것과 뭔과 비슷한데..."하고 생각할 수 있기를 바라는 것이다.


⇒ 다른 프로그래머는 종종 테스트 코드를 실제 코드가 어떻게 동작하며 어떻게 사용되어야 하는지에 관한 비공식적인 문서라고 생각한다. 따라서 테스트 코드가 읽기 쉬우면, 사용자는 실제 코드가 어떻게 동작하는지 그만큼 더 쉽게 이해할 수 있다. (테스트 코드의 중요성)


이렇게 리마인드 할 겸 내용을 정리해 보았는데 정리하면서 다시 한 번 머리에 각색이 된 것 같다. 앞으로도 꾸준히 코드를 작성함에 위의 내용들에 유의하며 작성할 수 있도록하고 꾸준히 해당관련 도서 (리팩토링, 클린코드)등을 읽으며 리마인드 해보는 것도 많이 도움이 될 것 같다. 이상으로 포스팅을 마친다.


 




반응형

+ Recent posts