반응형

오늘은 카프카에서 hdfs 데이터를 적재하는 카뮤(camus) 대해서 학습하고 생각해보는 시간을 가졌다.


아직 카뮤? 카뮈? 내부 아키텍쳐가 어떻게 설계되어져 있는지 확인하지는 못했지만 카뮈를 이용하면 카프카에서 생각보다 쉽게 hdfs 적재가 가능하다. 카뮈가 아니였다면? 자바로 카프카 컨슈머를 구현하고 hdfs 적재하는 로직처리를 해줘야 겠지?


그렇게 어플리케이션을 개발하더라도 카뮤에서 카프카 offset 확인해 데이터 누락을 최소화해주는 부분에 대한 구현은 힘들었을 같다.


물론 자바로도 할수 있겠지만....카프카에서 offset정보를 가져와서 처리할 있는 api 제공하는지는 잘모르겠다.


아무쪼록 깊이 파고들어 카뮤를 이해하고 실제로 카프카 토픽의 데이터를 받아오는 작업을 진행해보자!


백문이불여일행

반응형
반응형

앞으로라도 간단히 데이터 엔지니어로서 일을 하면서 경험했던 것들 생각들을 가볍게 공유해보고자 한다.


오늘은 데이터 유입쪽에 대한 파악작업을 진행하였다. 


nginx http요청으로 매체쪽 태그매니저로부터 들어오는 로그들이 어떻게 처리되는지


nginx 설정은 어떻게 되는지에 대해서 확인했다. 


기존 웹 서버 개발할 때는 아파치만 쓰다가 nignx를 보니 뭐 정확하게 어떻게 돌아가는지 정확한 이해는 안갔지만


대충 설정들을 보니 예상정도는 할 수 있었다. 


오늘 이해하고 파악한 부분은 nginx -> fluentd -> kafka 로 통하는 flow에 대한 전반적인 이해를 하였고


실제 알파 클러스터에서 설정을 변경해보며 이것저것 테스트해보았다. 


생각보다 td-agent 쪽에서도 offset 작업이 잘 이루어져 실제 nginx로 데이터가 들어왔을 때 td-agent가 죽어 있었더라도


다시 td-agent를 시작하게되면 읽어오지 않은 데이터부터 읽어 카프카로 전송하더라


아직 유입쪽에 쿠키발급부분이라던지 확인할 부분이 많지만 전반적인 유입 flow와 설정들을 이해한것만으로도 굉장히 뿌듯하다.





반응형
반응형

 

 모르면 손 발이 고생하는 Eclipse 단축키에 대해 알아보자. 작업을 할 때 단축키를 사용한다는 것은 굉장히 생산성을 향상시켜주는 일이다. 꼭 단축키를 사용하여 생산성을 향상 시키도록 하자!


[ Eclipse 단축키 ]


기본적으로 Preference > General > Keys에서 대부분(모든) 단축키 확인 가능합니다.
Ctrl+Shift+L : 단축키 보기 Hint

 

[거의 달고 사는 단축키]


ctrl + s : 저장 파일
ctrl + i : 소스 깔끔 정리(인덴트 중심의 자동구문정리)
ctrl + space : 어휘의 자동완성(Content Assistance)
ctrl + 1 : Quick Fix(Rename 주로 사용)
ctrl + shift + M : 캐럿이 위치한 대상에 필요한 특정클래스 import
ctrl + shift + O : 소스에 필요한 패키지의 자동 임포트
ctrl + / : 한줄 또는 선택영역 주석처리/제거
ctrl + Q : 마지막 편집위치로 가기
ctrl + L : 특정줄번호로 가기
ctrl + D : 한줄삭제
ctrl + H : Find Replace
ctrl + K : 다음찾기(또는, 찾고자 하는 문자열을 블럭으로 설정한 키를 누른다.)
ctrl + shift + K : 이전찾기(또는, 찾고자 하는 문자열을 블럭으로 설정한 역으로 찾고자 하는 문자열을 찾아감.)
alt + shift + j : 설정해 기본주석 달기
Ctrl + 객체클릭(혹은 F3) : 클래스나 메소드 혹은 멤버를 정의한 곳으로 이동(Open Declaration)


[
사용하면 유용한 단축키]


ctrl + shift + f : 소스 깔끔 정리
ctrl + 2 + R : Rename(리팩토링)
ctrl + shift + / : 선택영역 block comment 설정
ctrl + shift + \ : 선택영역 block comment 제거
alt + shift + up : Enclosing Element 선택(괄호의 열고 닫기 확인에 유용함)
ctrl + O : Outline창열기
Alt + ->, Alt + <- : 이후, 이전
해당프로젝트에서 alt + enter : Project 속성
sysout > Ctrl + Space : System.out.println();
try > Ctrl + Space : 기본 try-catch 완성
for > Ctrl + Space : 기본 for 완성
템플릿을 수정,추가 : Preferences > java > editor > Templates

 

[알고 있으면 아는척좀 있는 단축키]


ctrl + N :
새로운 파일 프로젝트 생성
ctrl + shift + s :
열려진 모든파일 저장 컴파일
alt + / : Word Completion
alt + shift + R : Rename
ctrl + shift + G :
특정 메써드나 필드를 참조하고 있는 곳을 찾는다.
ctrl + shift + B :
현재커서위치에 Break point설정/해제
ctrl + alt + R
ctrl + f11 :
실행
f11 :
디버깅 시작
f5 : step into
f6 : step over
f8 :
디버깅 계속
ctrl + . :
다음오류부분으로 가기
ctrl + , :
이전오류부분으로 가기
f12 :
에디터로 커서이동
ALT + UP,DOWN :
현재 위치 이동
Ctrl + j :
검색할 단어를 입력하면서 실시간으로 검색
Ctrl + Shift + j :
검색할 단어를 입력하면서 실시간으로 거꾸로 검색
F4 :
클래스명을 선택하고 누르면 해당 클래스의 Hierarchy 있다.
ctrl + alt + up/down :
한줄 duplicate
alt + shift +
방향 : 선택
ctrl + shift + g :
케럿이 위치한 객체가 참조 되는 곳을 찾아 준다

 

 

########################################################

===== 실행 =====
1. Ctrl + F11 :
바로 전에 실행했던 클래스 실행

 

===== 소스 네비게이션 =====
1. Ctrl +
마우스커서(혹은 F3) : 클래스나 메소드 혹은 멤버를 상세하게 검색하고자 할때
2. Alt + ->, Alt + <- :
이후, 이전
3. Ctrl + o :
해당 소스의 메소드 리스트를 확인하려 할때
4. F4 :
클래스명을 선택하고 누르면 해당 클래스의 Hierarchy 있다.


===== 문자열 찾기 =====
1. Ctrl + k :
찾고자 하는 문자열을 블럭으로 설정한 키를 누른다.
2. Ctrl + Shift + k :
역으로 찾고자 하는 문자열을 찾아감.
3. Ctrl + j :
입력하면서 찾을 있음.
4. Ctrl + Shift + j :
입력하면서 거꾸로 찾아갈 있음.
5. Ctrl + f :
기본적으로 찾기

 

===== 소스 편집 =====
1. Ctrl + Space :
입력 보조장치(Content Assistance) 강제 호출 => 입력하는 도중엔 언제라도 강제 호출 가능하다.
2. F2 :
컴파일 에러의 빨간줄에 커서를 갖져다가 키를 누르면 에러의 원인에 대한 힌트를 제공한다.
3. Ctrl + l :
원하는 소스 라인으로 이동
  
로컬 히스토리 기능을 이용하면 이전에 편집했던 내용으로 변환이 가능하다.
4. Ctrl + Shift + Space :
메소드의 가로안에 커서를 놓고 키를 누르면 파라미터 타입 힌트를 있다.

5. 한줄 삭제 CTRL + D

6. 파일 닫기 : CTRL+W

7. 들여쓰기 자동 수정. (3.0 NEW) : CTRL+I 

8. 블록 주석(/*..*/) 추가.(3.0 NEW): CTRL+SHIFT+/

  8.1 Ctrl + / 해주면 여러줄이 한꺼번에 주석처리됨. 주석 해제하려면 반대로 하면 .
9.
(아래)줄과 바꾸기 : ALT+UP(DOWN)

10. 블록 선택하기.  : ALT+SHIFT+방향키

11. 메소드의 파라메터 목록 보기. : CTRL+SHIFT+SPACE
12.
자동으로 import 하기 : CTRL+SHIFT+O

13. 열린 파일 모두 닫기 : CTRL + SHIFT + F4

14. 블록 주석 제거 : CTRL+SHIFT+

15. 전체화면 토글 : CTRL+M

16. 한줄(블럭) 복사 : Ctrl + Alt + (아래)

17. 다음 annotation(에러, 워닝, 북마크 가능)으로 점프 : Ctrl + , or .

18. 픽스 : Ctrl + 1  
19.
메소드 정의부로 이동 : F3
20.
하이어라키 팦업 띄우기(인터페이스 구현 클래스간 이동시 편리) : Ctrl + T 

21. 메소드나 필드 이동하기 CTRL + O 
22. ULTRAEDIT
EDITPLUS CTRL+TAB 같은 기능. : CTRL+F6 

 

===== 템플릿 사용 =====
1. sysout
입력한 Ctrl + Space 하면 System.out.println(); 으로 바뀐다.
2. try
입력한 Ctrl + Space 하면 try-catch 문이 완성된다.
3. for
입력한 Ctrl + Space 하면 여러가지 for 문을 완성할 있다.
4.
템플릿을 수정하거나 추가하려면 환경설정/자바/편집기/템플리트 에서 있다.

 

===== 메소드 쉽게 생성하기 =====
1.
클래스의 멤버를 일단 먼저 생성한다.
2. override
메소드를 구현하려면 : 소스->메소드대체/구현 에서 해당 메소드를 체크한다.
3.
기타 클래스의 멤버가 클래스의 오브젝트라면 : 소스->위임메소드 생성에서 메소드를 선택한다.

 

===== organize import =====
1.
자바파일을 여러개 선택한 소스 -> 가져오기 체계화 해주면 모두 적용된다

 

===== 소스 코드 형식 공통 주석 설정 =====
1.
환경설정 -> 자바 -> 코드 스타일 -> 코드 포멧터 -> 가져오기 -> 프로파일.xml 불러다가 쓰면 된다.
2.
또한 다수의 자바파일에 프로파일을 적용하려면 패키지 탐색기에서 패키지를 선택한 소스 -> 형식화를 선택하면 된다.
3.
환경설정 -> 자바 -> 코드 스타일 -> 코드 템플리트 -> 가져오기 -> 템플리트.xml 불러다가 쓰면 된다.

 

===== 에디터 변환 =====
1.
에디터가 여러 파일을 열어서 작업중일때 Ctrl + F6 키를 누르면 여러파일명이 나오고 F6키를 계속 누르면 아래로
2. Ctrl + Shift + F6
키를 누르면 위로 커서가 움직인다.
3. Ctrl + F7 :
뷰간 전환
4. Ctrl + F8 :
퍼스펙티브간 전환
5. F12 :
에디터로 포커스 위치

 

Alt + 위아래 방향키move line(block)

가장 많이 쓰는 애용 단축키 이다. 설명하자면 단순히 한줄(혹은 블럭)의 내용을 위아래로 옮기는 것이지만, 쓸데 없는 Cut & Paste를 줄여준다거기다, 블럭안팍으로 옮기면 자동으로 들여쓰기까지 해준다.

 

Alt + Ctrl + 위아래 방향키copy line(block)

요즘 아무리 재사용성이 증가했다라지만 프로그래머가 가장 많이 쓰는 기능이라면  머니머니해도 Copy & Paste이다. Alt 방향키가 Cut & Paste라면 이번에 Copy & Paste이다 한줄(혹은 블럭)의 내용을 위/아래 줄로 복사해준다. 역시 쓸데없는 반복작업을 많이 줄여준다.

 

Alt + Shift + 좌우 방향키select block

프로그래머는 섬세한 마우스 손놀림이 필요하다. 항상 정확한 부분부터 블럭을 잡아 카피 페이스트를 해야하기때문이다! 이때 유용한 기능이 바로 이것! 지금 커서 위치의 단어의 의미있는 블럭을 똑똑하게 잡아주고 확장 축소해 준다. 글로 읽어보기 보다 직접 사용해 보라. 멋지지 아니할 수 없다.

 

Alt + Shift + R  : Rename Refactor

게으른 프로그래머의 전형중에 하나가, 제멋대로 작명이다. 설계도 제대로 안하고 제멋대로 작명해서 쓰거나, 오타로 인해 toString toSring이 되어버렸거나.. 이런 경우 가만 내버려두면 그 확산 범위는 잘못하면 프로젝트 전체로 퍼져나가게 되어 걷잡을 수 없게된다. 이때 유용하게 쓸수 있는것이 Rename이다. 리팩토링메뉴에 편리한 기능들이 엄청 모여있지만 그중에 가장 많이 쓰게되는 기능일것이다. 프로젝트 전체에 관계된 이름을 깔끔하게 싹 바꿔준다.

 

Ctrl + Shift + F4 : Close All Opened Window

열려져 있는 모든 파일(View)을 닫아준다. 프로그래밍을 하다보면(특히 JSP Model2같은) 끝없이 파일을 열게 되서 화면이 무척 지저분해 질때까 있다. 그때 살짜쿵 눌러주고 다시 열때 편리하다.

 

Ctrl + Shift + G : Find references

이글을 보고 계시는 대부분의 분들은 사용되는 변수(혹은 메소드, 클래스, 객체 등)의 선언으로 가는 방법 정도는 알고 계실것이다. 바로 Ctrl + 클릭 혹은 F3 이다. 물론 선언으로 바로 가고 싶을때도 많지만 선언된 변수의 참조(사용처)를 찾아가고 싶을때가 더 많다. 그럴때 유용한 것이 이 단축키이다워크스페이스 내에서 참조된 곳을 전부 찾아서 Search View에서 List형태로 보여준다.

 

Ctrl +3 : Quick Access (Eclipse 3.3 Europa)

유로파를 쓰시는가? 그럼 축복받은 단축키 Ctrl + 3을 쓸 수 있다. 보통 단축키를 쓰다보면 마우스에는 손이 잘 안가고 뭐든지 키보드로 해결하려 하게 된다. 하지만.. 모든 기능에 단축키를 부여할 수는 없는법! 그래서 나온기능이 Quick Access이다. 메뉴들을 직접 타이핑해서 찾을 수 있고 history기능까지 제공한다


해당 글 reference : http://strikerhan.tistory.com/8


[ Bobby의 싸가지 ]

한 가지. 무식하면 손 발이 고생한다

두 가지. 무슨 일을 하든 신속히 처리할 수 있는 방법을 생각하고 적용하자.

세 가지. 단축키를 쓰고 안쓰고는 하늘과 땅의 차이다.

네 가지. 손에 익히고 행동으로 옮기자.

 



반응형
반응형

 


 안녕하세요. 오늘은 최근 작업했던 특정 서비스의 웹 개편 작업 중 경험한 장애 상황에 대해 포스팅 해볼까 합니다. 새롭게 단장한 고객센터 페이지를 해당 서비스에 적용하고 테스트 까지 잘 맞췄었는데 그 다음 날 장애 상황을 경험하게 되었습니다.

먼저 현재 회사의 많은 서비스 고객센터 페이지가 API 형태로 붙게 되는데요. 그렇다보니 그 많은 서비스들의 고객센터 페이지를 계속해서 만들어 낼 수도 없는 상황인지라 사이트메쉬와 데코레이터 패턴을 이용하여 신규 서비스가 오픈하면 해당 서비스에 맞게 CSS를 입혀 서비스하는 방식으로 몇몇 서비스들이 이루어지고 있습니다. 최근 특정 서비스의 웹 리모델링에 맞춰 변경된 CSS로 작업을 진행하는 도중 문제가 발생했습니다.


[상 황]

 웹페이지의 리모델링에 맞춰 CSS작업 팀으로 부터 변경 된 CSS를 받아 특정 서비스의 고객센터에 적용해야하는 상황. 물론 CSS를 새로 받게 되면 로컬에서 CSS를 적용시켜보고 웹 페이지를 띄워 노출되지 않는 이미지가 있는지 깨지는 부분이 있는지를 확인하는 작업이 요구된다. 그렇게 여러번의 수정 작업을 마치고 페이코 웹 개편 작업 반영을 하게 되었다. 

 이번 같은 경우에는 해당 서비스의 메인 페이지 및 다른 부분도 모두 개편되는 부분이라서 여러 팀이 순서대로 반영을 하는 상황. 테스터 분들도 모두 동참하여 반영이 이루어졌다. 그렇게 모든 팀의 반영 및 테스트 작업이 약 7~8시간에 걸쳐 진행되었고 잘 마무리 짓게 되었다.


[ 문제상황 ]

반영이 끝난 그 다음날 오전 TTS(TROUBLE TICKET SYSTEM) 5급(등급이 낮을 수록 심각 1~5)을 맞게 되었다. 특정 서비스에 문제가 생길 경우 해당 사이트에 문제 상황이 뜨고 담당자에게 연락이 감. 문제는 고객센터 '1:1문의 페이지'에서 문의를 작성한 후 '완료'하는 버튼이 보이지 않는 상황이었다.

 

[동의란 밑에 아무 버튼도 노출되지 않고 있음]



[정상적인 모습]

 

그 문제상황을 보고 받고 속으로 '어떻게 그렇게 테스트를 여러번 했는데 문제가 났다는 게 말이되나?'하는 의구심을 받고 페이지에 접속한 결과 정상적으로 버튼이 노출되고 있는 것을 확인하였다. 그럼 그렇지 하며 익스플로러에서도 확인 결과 정상적으로 버튼이 노출되고 있는 것을 확인하였다. 


[문제원인 & 처리]

그렇게 뭐지???하고 생각하던 중 팀장님께서 외부망으로 접속해보라고 하셨다. 그렇게 외부망으로 접속을 하자 버튼이 노출되지 않고 있음을 파악할 수 있었다. 문제는 변경된 CSS의 버튼의 이미지 경로가 내부망(#밑에 설명) 주소로 박혀있었던 것이다. 보통은 이미지 경로가 해당 작업 하시는 분의 디렉터리 구조에 맞춰 상대경로로 되어 있어 CSS를 받아 적용해보면 어떤 이미지가 없는지 파악이 가능했고 그 이미지를 요청해서 얻어오는 식이었는데 어떻게 보면 뒤통수를 맞은 격이었다. 그것도 딱 해당 2개의 버튼만 "http://{내부망ip}"로 되어 있었던 것이다. 이에 파일을 다운 받아 프로젝트 내에 넣고 경로를 맞추어 준 후 반영을 했지만 뭔가 씁씁한 기분은 가시 질 않았다.


#내부망 

내부망은 일정 조직 내에서 인터넷이 아닌 내부 네트워크를 통해 PC끼리 자원을 공유하게 하거나 그룹웨어 등을 사용할 수 있게 하는 근거리 통신망(LAN, Local Area Network)로 '인트라넷'을 생각하면 이해하기 쉬울 것 같다. 망분리는 현재 정통망법 시행령에 따라 망법 적용을 받는 기업중 개인정보 100만명 이상, 매출액 100억원 이상의 기업은 의무적으로 망 분리를 실시해야고 한다. 보통 보안적인 이슈 때문에 적용하는 듯 하다.


[느낀점]

이런 문제를 처음 경험해 본 나는 적잖이 당황했던 것 같다. 좀 더 꼼꼼히 파악을 했더라면 좋았을 텐데 그렇기엔 그 긴 CSS를 다 파악하기 힘든 상태였고 웹 페이지에 CSS를 적용 후 깨지는 이미지와 CSS에만 초점을 맞춰 작업을 했던게 이런 문제점을 나았다. 외부망으로 한 번 만 확인을 해보았으면 이런 실수가 발생하지 않았을텐데 하는 아쉬움이 남는다. 이번 경험을 계기로 다음부터는 꼭 외부망으로도 접속해 테스트 해보도록 해야겠다. 



똑같은 실수를 반복하지 말자.



반응형
반응형


 

안녕하세요. 오늘은 작년 신입 교육 때, 딱 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에서 보았던 것과 뭔과 비슷한데..."하고 생각할 수 있기를 바라는 것이다.


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


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


 




반응형
반응형

 


  안녕하세요. 오늘은 Fiddler를 통해 모바일 웹을 디버깅 하는 법에 대해서 포스팅 해보도록 하겠습니다. 보통 웹 업무를 하다보면 fiddler를 많이 사용하게 되는데 이번 작업을 하던 중 모바일 웹에서 기능 수정 한 부분에 대해서 확인해야 하는 상황이 있었습니다. 하지만 어떻게 해야 할지 도무지 감도 안 오고 그저 생각나는 방법은 '알파나 베타에 수정한 부분을 배포해서 확인을 해야하나?'였습니다. 하지만 fiddler를 사용하면 로컬환경에서도 모바일 웹을 디버깅 할 수 있다는 점! 지금 부터 시작하도록 하겠습니다. 


 1. Filddler란 무엇이냐

 : "웹 트래픽을 모니터링, 조사, 조작할 수 있는 확장 기능을 갖춘 프리웨어 디버깅 프록시"라고 정리 되어 있는 글을 본 적이 있는데 말 자체가 너무 어렵네요. 단순히 말해 클라이언트와 서버가 요청과 응답을 한 번씩 주고 받은 세션의 목록을 보여주는 프리웨어라고 볼 수 있습니다. 말은 이렇게 단순히 했지만 피들러로 할 수 있는 일들은 어마어마 하다는 거


 피들러로 할 수 있는 일


   ⊙ 브라우저, 클라이언트 프로그램, 서비스 등에서 오고 가는 웹 트래픽을 볼 수 있다.

   ⊙ 자동 또는 수동적인 방법으로 어떠한 응답이나 요청도 수정할 수 있다.

   ⊙ HTTPS 트래픽을 복호화하여 살펴보거나 수정하는 것도 가능하다.

   ⊙ 캡쳐한 트래픽을 저장하여 보관해 두고 후에 불러올 수도 있다. 다른 컴퓨터의 트래픽도 이런 식으로 다룰 수 있다.

   ⊙ 클라이언트 프로그램으로 가는 응답을 이전에 캡쳐해 두어 서버가 오프라인 상태라 해도 응답을 재현할 수 있다.

    맥/리눅스 시스템, 스마트폰, 태블릿 컴퓨터 등을 포함한 대부분의 PC와 모바일 기기에서 발생한 웹 트래픽을 디버깅할 수 있다.

   ⊙ TOR 네트워크 등 프록시 서버에 업스트림(upstream)을 연결(chain)할 수 있다.

   ⊙ 클라이언트 컴퓨터나 모바일 기기를 다시 설정하지 않고도 역 프록시(reverse proxy)로 동작하여 트래픽을 캡쳐할 수 있다.

   ⊙ 피들러 스크립트나 .NET 기반 확장 모듈을 통해 새로운 기능을 추가할 수 있어 더 강력해질 수 있다.


 


 그림을 통해 보면 내가 요청한 페이지에 대한 세션 정보와 해당 서버측에서 넘어온 세션 정보 등을 파악 할 수 있습니다. 그럼 이제 본격적으로 모바일 웹을 디버깅 하기 위해서는 어떤 설정들이 필요한지 알아 보도록 합시다.



 2. 모바일 웹을 디버깅하기 위한 Fiddler의 설정 첫 번째

 Fiddler를 키고  상단의 Tools > Fiddler Options 를 클릭하면 밑과 같은 창이 뜨는데 Connections 탭에서 Allow remote computers to connect 칸에 체크를 해줍니다. 말 그대로 외부 기기가 연결될 수 있도록 허용해주는 설정입니다.



  2. 모바일 웹을 디버깅하기 위한 Fiddler의 설정 두 번째 ( 모바일 와이파이 설정 셋팅 )


 Fiddler에서 위와 같은 설정을 맞췄다면 이제 해당 Fiddler에 붙기 위해 사용하고 있는 와이파이 설정을 해줘야 합니


다. 와이파이 설정을 들어가 고급 옵션 표시 항목에 체크를 하면 다음과 같은 화면을 볼 수 있습니다. 프록시를 수동으


로 바꿔주고 프록시 호스트 이름에 fiddler가 설치된 PC의 IP를 입력해 줍니다. 그리고 프록시 포트 부분에는 위의 그


림에서 Fiddler listens on port란에 쓰여있는 포트번호를 적어주고 저장해주면 됩니다. 


  

3. 모바일 웹을 디버깅하기 위한 Fiddler의 설정 세 번 째 ( 로컬 환경으로 호스트 셋팅 )

실제로 모바일 화면에서 웹을 띄워 내가 작성한 코드가 잘 수정되었는지 확인하기 위하여 fiddler에서 Host를 맞춰 줍니다. Fiddler 상단의 Tools를 누르면 HOSTS...라는 항목이 보이고 클릭하게 되면 Host Remapping이라는 창이 뜨게 되고 여기에 호스트 설정을 해주면 됩니다. 


  

4. 모바일에서 접속해 보기

 실제로 모바일로 작업하고자 하는 url에 접속하게 되면 fiddler에 내가 보낸 요청들의 세션이 찍히는 것을 볼 수 있다. 또한 로컬에서 디버깅으로 프로젝트를 띄워논 후 모바일로 해당 페이지에 접속하게 되면 디버깅이 걸려 들어오는 것 까지 확인할 수 있었다. 

 


이렇게 Fiddler를 통해 모바일 웹을 테스트 할 수 있는 방법에 대해서 알아보았다. 혹시나 와이파이 설정 및 fiddler 설정을 다했는데도 제대로 접속이 안되는 경우 디바이스를 재부팅하거나 피들러를 다시 껏다 킨 후 다시 접속해 보기 바란다. 이상으로 이번 포스팅을 마치겠다.





반응형
반응형



 부서를 처음 배정받고 선배님들이 'Legacy 코드'라는 말을 자주 사용하는 것을 들을 수 있었다. 그 당시에는 Legacy코드가 뭔지에 대해서 감도 전혀 없었고 Legacy 코드에서 작업하는 것이 새롭게 프로젝트를 진행하는 것보다 어려운지 또한 알지 못했다. 하지만 요즘 Legacy 코드 위에서 작업을 하면서 몸소 그 어려움에 대해 체험하는 중이다. 하지만 반면으론 현재 서비스되고 있는 거대한 양의 코드들을 다루며 내가 그동안 프로그래밍을 하면서 알지 못했던 방식이나 방법들에 대해서도 프로그래밍을 함에 있어 지향해야 할 부분과 지양해야 할 부분에 대해서도 많이 생각해보고 적용해보며 견문을 넓혀 가고 있는 중이다.그렇다면 Legacy코드가 무엇인지에 대해서 알아보고 그 위에서 어떻게 작업해가면 좋을지에 대해서 살펴보도록하자

 Legacy란???먼저 Legacy의 사전적인 의미로는 "(남이 남긴)유산"으로 해석할 수 있다. 그럼 Legacy코드란? 많은 사람들이 이에 대해 다양한 정의를 내리고 있지만 간단히 말해 '다른 사람에게 넘겨받은 읽기 어렵고 수정하기 어려운 오래된 코드'를 말한다. 특히 기술의 변화가 많은 웹 프로젝트들에 있어서는 시간이 지나면서 기술이 발전할 수록 Legacy 코드들이 점점 쌓여저만 간다. 그렇다면 Legacy 코드 위에서 작업할 때 부딪히는 문제들에는 어떠한 것들이 있을까?


 Legacy Code에서 작업할 때 부딪히는 문제점은??? 첫번 째, 해당 코드를 이해하기 어려운 문제점이 있다. (변수명, 메소드명이 명확하지 않거나 매우 복잡함)

 두번 째, 해당 코드에 대해 완벽하기 이해하기가 어렵기 때문에 수정이 필요한 곳도 쉽게 수정하기 힘들어 진다. 또한 해당 부분을 수정한다고 했을 때 그에 따른 사이드 이펙트(기능 수정으로 인해 예상치 못한 부분에서 에러 발생)가 어디에서 발생할지에 대해서도 예측하기가 힘들다.

 세번 째, 코드에 대해 이해가 힘들다보니 해당 프로젝트에 대한 유지보수 작업을 진행함에 있어 자신감이 하락하게 된다.

 그렇다면 Legacy 코드를 만들지 않기 위해서는 어떻게 해야할까??? 1. Magic Number를 사용하지 말자.

 ①번 방식처럼 사용하게 될 경우 숫자1과 숫자2과 무엇을 의미하는 코드인지 알기 힘들다 ②번 방식처럼 Magic Number를 제거하고 사용하게 되면 좀 더 이해하기 쉬운 코드를 짤 수 있다.


 2. 의도를 나타내는 이름을 사용하자. 예를 들어 다음과 같은 메소드가 있다고 하자. (밑의 코드를 예를 들기 위해 짠 코드이기 때문에 메서드 명에 집중해주기 바란다)

 위 메서드가 어떠한 작업을 하는지 메서드명만 봐서는 도무지 감을 잡을 수가 없다. 반면 밑의 코드를 보면

 해당 메소드가 무엇을 하는 메소드인지 단번에 알 수 있다. 이렇든 명확한 이름을 사용하여 코드를 이해하는데 드는 시간을 줄일 수 있다.


 3. 가급적 프로그래밍을 할 때 부분만 옳은 것보다 전체적 대칭을 지키자. 예를 들어,district.setDong("정자")district.setGu("분당")district.setMetroPolitanOrSi("성남") 와 같이 부분만 옳은 동떨어진 메서드를 사용하기 보다는district.setDong("정자")district.setGu("분당")district.setSi("성남") 와 같이 전체적 대칭을 지키는게 나을 때가 많다. 따라서 기존의 코드와 대칭을 이루는 메서드명을 사용하는게 명칭이 잘못됬다 할지라도 나을 경우가 있다.


 4. if문이 덕지덕지 붙어있는 복잡한 조건식을 피하자.될 수 있으면 조건문을 사용하기 보단 다양한 패턴들을 활용해 복잡한 조건식을 피하고 메서드를 세분화 시켜주자.


 5. 사용하면 안 되는 클래스/메서드가 있을 경우

위와 같이 deprecated를 해놓으면 이클립스 등에서 코딩할 때 메서드에 취소선이 나와, 개발자의 주의를 환기시킨다. 하지만 아무런 설명이 없기 때문에 왜 저 메서드를 사용하면 안되는지에 대해 알 수 없다. 그렇기 때문에 무책임하게 @deprecated만 선언하지 말고 왜 @deprecated 되었는지 설명 또한 달아주도록 하자.




 6. 뻔한 중복 주석은 피하자.메서드 명이나 변수명만 봐서도 충분히 파악할 수 있는 부분에 대해서는 추가적인 주석을 달 필요가 없다. 특별한 경우나 이름 만으로만 이해하기 힘든 부분이 있을 경우 꼭 필요한 부분에 있어서 주석을 사용해주자. (의미없는 주석 사용 nono)


 7. 기능에 해당하는 테스트 코드를 작성하자.


 8. 리팩토링 작업을 지속적으로 하자. 리팩토링 - 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법으로, 소프트웨어 시스템을 변경하는 프로세스이다. 리팩토링을 별도의 작업이 아니라 개발의 한 부분으로 생각하도록 하자.


 현장 TIP1. Q) 얼마 전 중복이 많고 복잡한 코드를 GOF 디자인 패턴을 적용하여 리팩토링 했다. 그런데 코드리뷰 때 다른 개발자가 더 코드가 더 보기 어려워졌다고 한다.

 A) Communicative Code의 요건 중 배려가 있다. 따라서 분명히 구조적으로 좋아졌다고 하더라도 팀 내 다른 개발자가 모두 코드 읽기를 어려워 한다면 한번 더 생각해볼 만한 부분이라고 생각한다. 가치의 상충이 일어나는 것인데 '구조적 개선 vs 읽기 어려움'이다. 각각을 통해 얻게 될 가치를 종합적으로 잘 비교해보고 취사선택하는 것이 좋을 것이라 본다. 또한 GOF 디자인 패턴 적용의 초점이 문제해결이 아닌 적용 그 자체에 있을 때가 종종 있다. 이런 형태의 적용은 득보단 실이 많기 때문에 가급적 피하는 것이 좋다.


2. Q) Legacy 코드를 수정 중인데 너무 읽고 이해하기 어려운 클래스 xxx가 있다. 아무래도 안될 것 같아 New XXX를 만들었다. 하지만 예전 클래스를 사용하는 곳 까지 모두 수정하기는 어려워 이번에 작업하는 범위의 클래스에서만 New XXX를 사용하게 바꾸었다. 이렇게 해도 괜찮은 건가?

 A) 경험이 비추어 볼 때 절대 하지 말아야 할 형태의 개선이다. 이런 형태의 개선을 할 때 New, New2, New3가 계속 생기며, 기존 클래스는 정리가 안 되어 이후 복잡도가 높아지고 혼란을 가중시키는 사례를 봐왔다. 따라서 가급적 신규 클래스를 도입하는 형태의 개선은 트랜잭션과 마찬가지로 'All or Noting' 원칙이 적용되어야 한다고 본다. 신규 클래스를 도입하려면 반드시 기존 클래스를 제거하고, 그게 힘들다면 신규 클래스를 만들지 말고 예전 클래스 기반에서 수정하는 것이 올바른 방향이락 본다.


3. Q) Legacy 코드를 수정하기에 앞서 Cover & Modify를 하려고 하고 있다. 그런데 의존하는 객체가 너무 많았다. 할 수 없이 하나하나 만들어가며 테스트를 만들었다. 그런데 새로운 객체를 생성하는 등의 리팩토링을 하다 보니 기존에 만든 테스트가 다 실패한다. 도움을 주기보다는 거추장스러운 느낌이 나는데 왜 그런가?

 A) BO나 Service를 대상으로 단위 테스트를 만들면 대게 객체간의 인터랙션을 테스트하는 코드를 만들게 된다. 하지만 이런 테스트는 객체 간의 인터랙션을 조정하는 등의 리팩토링을 하게 되면 테스트를 고쳐줘야 하고 따라서 위와 같이 의미가 퇴색 될 수 있다. 따라서 이런 때는 통합 테스트를 활용하여 상태를 기반으로 검증하는 것이 좋다. BO의 예를 들면 실제 BO나 Service를 호출하고 데이터베이스 등에 값이 제대로 들어갔는지 등을 검사하는 것이다. 이렇게 만든 테스트는 객체의 관계를 조정하는 등의 리팩토링을 해도 달성되는 결과는 같기 때문에 테스트를 수정할 필요가 없고 안전망으로써 역할을 잘 수행한다.

 지금까지 Legacy코드와 Legacy 코드를 만들지 않기 위한 방법, 현장 Tip등 에대해 알아보았다. 많은 내용은 NHN에서 교육했던 'Legacy 코드에서 작업하기'교재에서 참고하여 정리하였다.


반응형
반응형



@QueryParam ? @PathParam?

흔히 API설계하실 때 특히 GET 방식의 URI 만드실 때 쿼리 파라미터로 설계할지 패스파라미터로 설계하실지 고민들하실텐데요.


저또한 많이 고민하다가 관련해서 열띤 토론?을 나눈 stackoverflow글이 있어 공유합니다.



---------------------------------------------------------------------------------------------------------------------------------------


This is what I do.

If there is a scenario to retrieve a record based on id, for example you need to get the details of the employee whose id is 15, then you can have resource with @PathParam.

GET /employee/{id}

If there is a scenario where you need to get the details of all employees but only 10 at a time, you may use query param

GET /employee?start=1&size=10

This says that starting employee id 1 get ten records.

To summarize, use @PathParam for retrieval based on id. 

User @QueryParam for filter or if you have any fixed list of options that user can pass.


[ 자세한건 참고 : StackOverflow]

http://stackoverflow.com/questions/11552248/when-to-use-queryparam-vs-pathparam

-------------------------------------------------------------------------------------------

[ 결 론 ]

결국에는 특정 정보를 가지고 올 때는  PATH PARAMETER를 데이터에 특정 조건(필터)를 주거나 SORT를 해서 가지고 오고자 할 경우에는 쿼리파라미터를 사용하면 좀 더 깔끔하게 API 를 설계하실 수 있을 것 같습니다.

감사합니다.

 




반응형

+ Recent posts