분류 전체보기 33

하이버네이트 2차캐시 도입 후기...

1. 여태 우리는 그 흔한 redis 도 잘 안쓰고 있었고, 2차캐시 또한 안쓰고 있었다. 2. 처음엔 redis로 자주 호출하는 entity 를 캐싱처리해서 작업하려 했고 적용했다. 3. 눈으로 보기에 캐시 히트율은 높았지만 쿼리 갯수가 비약적으로 줄진 않았다. (select 쿼리 약 20% 줄음) 4. 캐싱된 entity들에 대한 호출 쿼리가 계속 있어서 확인해보니 entity graph 로 가져오는 아이들이 있었다. 5. 해당 graph get 은 ddl이란 명목하에 쓰는곳이 너무 많았기 때문에 지울 수 없었다. 6. 결국 hibernate 2차캐시 쓰기로 결정!. 7. 다만 잘 고려해야할 부분은 메모리 캐시 이기 때문에 db 가 외부에 다른 instance에서 변경되는 경우 캐시 만료 전 까지 서..

회고록 2023.04.20

spring boot major 버전 업 개발 및 배포에 대한 회고

최근에 회사에서 스프링 부트 1.5-> 2.6 으로 업데이트하는 작업을 실시하였다. 느낀점. 스프링 부트 업데이트는 서비스 전체적으로 영향을 일으키므로 스트레스 테스트가 필수이다. 부트 업데이트시 gradle 과 호환되는 버전을 찾자. gradle 변경에 따른 dependency 설정 방법의 차이가 좀 생기는데 implement 방식은 외부에서는 해당 의존성 코드는 못보게 하는 설정이다 monggodb 4.2 로 올라가면서 transactional 이 생겼는데 이를 무분별하게 사용하면 안된다. (몽고db의 경우 일반적인 find(select) 라도 해당 id를 기준으로 lock을 걸어버리기 때문에 성능문제가 생길 수 있다. lock aquire time out) 배포 후 에러가 올라온다면 로그를 유심히 ..

회고록 2023.04.12

로컬라이징 방식에 대한 고찰

프로그램을 globalizing 시키기 위해서는 localize한 언어를 리소스화 시켜서 저장시키는 것이 중요한데 요즘 작업중 느낀점이 많음 > LocalizeResourceKey값 Naming에 대한 고찰. 1. 현재 프로젝트 상태는 localizeResource의 key값에 대한 Naming 을 해당 단어나 문장의 뜻에 대한 걸... 기준으로 만듬. 2. 나라마다 지역마다 같은 내용도 단어가 다른경우가 많고 같은 단어도 뜻이 다른게 있고 해서 이렇게 짜다보면 리소스데이터자체가 변경될 가능성이올라감. 3. 그래서지금 불편한게 한두개가 아님,, 차라리 key값은 어떤 뷰에서 어떤 위치에서쓰이는지를 중심으로 Namin하는게 확실하고 마음이 편함. ( 수정가능성 ▽ ) 4. 따라서지금 이걸 바꿀까 하는데 아..

SVN!

최근 내가 개발하던 프로그램이 릴리즈 되면서, 급하게 SVN을 사용만 하다가 관리하게될 일이 생겼다....아무것도 모르는 상태에서 이것저것 형상관리 계획을 수립하는 과정에서 보기엔 굉장히 비효율적으로 보이는 SVN 파일시스템에 대해 그리고 SVN기능들에 대해 궁금증이 생겼다.. 단도직입적으로는. 지금 trunk폴더에 정상은 아니지만 용량이 꾀나 큰 IDE설치셋을 들고 있어서 빌드중 태깅을 하다보면 이것들이 전부 copy되는데 저장공간이 남아나나 의심을 하게되었다. 결론적으로는 태깅방법이 fullcopy가 아니라서 괜찮다는 것인데 아무튼 이 과정중에서 찾게된 좋은 svn 기능 관련 포스팅이 있어서 링크해본다. http://www.pyrasis.com/main/Subversion-HOWTO

구글에서 쓰던 소스코드관리방법

이라고 한다. 구글 모든 제품의 소스코드를 저장소 딱 하나로 관리한다. 소스코드 관리도구는 Perforce 라는 것을 사용한다. 그러나 개인적으로는 Git 을 사용하고 Git -> Perforce 변환하여 올린다. 성능보다 코드의 읽기 쉬움이 중요하다. 코드를 최적화 하여 서버 비용을 100만원 아꼈다고 할지라도 변경된 코드가 읽기 어려워져서 개발자 인건비 300만원을 소모한다면 커밋이 안된다. 소스코드를 청소하는 팀이 있다. 인수한 회사의 소스코드도 모두 컨벤션에 맞추도록 변경한다. 구글은 개발 문서 거의 없다. 소스코드에 개발 문서 거의 담는다. 어떤 코드는 처음 300줄이 문서다. 클래스에 입력과 출력에 대해 자세히 쓴다. 퍼왔지만 이분도 퍼온거라고 한다. 퍼온곳은 트랙백에

객체지향 5대 설계원칙

1. OCP(Open-Closed Principle) 개방-폐쇄원칙모듈 구현은 확장에는 개방되어있어야 하지만, 변경에는 폐쇄되어 있어야 한다.이미 구현 해 놓은 로직에서 새로운 모듈 추가에는 유용하게 되어야 하지만 추가 한다고 해서, 구현된 코드가 변경 되면 안된다.이를 지원하기 위해서, 추상메소드, 인터페이스가 존재함.JAVA 개발시 유의할 점. (해당 모듈 개발 시, 같은 기능의 다른 모듈 을 붙일 수 있는가? 그렇게 만들 수 있는가? 생각하고 반드시 추상메소드, 및 인터페이스를 활용하여 작성해 볼 것.)2. LSP(Liskov Substitution Principle) 리스코프 치환 원칙기반이 되는 부모클래스를 참조하는 다른 클래스들의 경우 부모 클래스의 자식 클래스를 알아야 할 필요를 느끼면 안된..

Packege 설계 원칙.

패키지의 설계 원칙은 클래스의 설계원칙과 기본적인면에서 큰 차이가 없다. 현재까지 잘 알려진 설계 원리들은 다음과 같다. CRP (Common Reuse Principle) - 패키지의 클래스들은 전체적으로 재사용됨.CCP (Common Closure Principle) - 패키지의 클래스들은 동일한 유형의 변경에 대해서 닫혀있어야 함. 만일 클래스가 변경되어야 한다면 패키지의 모든 클래스들은 마찬가지로 변경되어야 함.그정도로 서로 강하게 결속된 것 들만 한 패키지로 모으라는 뜻 같다.SOC (Separation Of Concerns) - 여러 관심사를 혼합시키지 마라.세개 모두 High Cohension에 관한 얘기이다. 하나의 패키지는 하나의 클래스와 마찬가지로 Single Responsibility..