아무거나 하는 블로그

1. 이름짓기는 어렵다 회사에서 개발할 때 생각보다 많은 시간을 쓰는게 이름짓기다. 마음에 안들어서 썻다 지웠다를 몇 번 반복하고, 클래스나 메서드를 구현하다가 더 괜찮은 이름이 생각나서 다시 바꾸기도 하고, 어떨 때는 도저히 안떠올라서 func, temp 이런식으로 일단 임시 이름을 두고 구현을 먼저할 때도 많다. 지금 돌아보면 이름이 딱 안떠오르는 경우는 메서드나 클래스를 만들기로 결정한 순간에 이놈이 뭘 하는 놈인지 책임을 명확하게 생각하지 않았을 확률이 높지않을까 생각한다. 물론 책임은 명확히 알겠는데 어울리는 단어를 못찾은 경우도 많다. 아무튼 하고싶은 말은 이름 짓기는 어렵다. 그래서 이번 과정을 수강하면서 배우고있는 것 중 하나인 이름 짓기에 대해서 배운 것과 내생각을 정리해보려고 한다. 2..

오늘 다른 분이 옛날에 작성한 FE 코드를 읽다가 객체 prpoerty 순회할 대 hasOwnProperty라는 걸 사용하는 부분을 봤다. 메서드 이름으로 대충 "property가 있는가 검사하는 것이 겠구나" 추측은 했는데 이미 존재하는걸 아는데 왜 한 번 더 체크하는걸까? 싶어서 찾아봤다. MDN 문서 : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty Object.prototype.hasOwnProperty() - JavaScript | MDN The hasOwnProperty() method of Object instances returns a boolean in..

2023년 회고 미루고 미루다가 2월이 되어서야 2023년 회고를 작성한다. 사실 귀찮은데... 그래도 2023년 회고를 해야 2024년 목표가 명확해질 것 같아서! 1. 회사 - 9월 부터 출근을 재개한 것이 가장 큰 변화였다. 원래도 월 2회 출근하긴 했지만 사실 거의 이벤트성 출근이고... 사실상 2020년 초 이후로 3년만?에 사무실로 출근을 하게됐는데, 초반에 살짝 힘들었지만 금방 적응해서 잘 다니고있다. 2024년부터 주 1회 재택근무마저 사라져서 좀 충격이긴한데... 그것도 어째 어째 적응하고있는 것 같긴하다. 사실 주중에 일을 많이 하고 금요일은 좀 일찍 퇴근하는 편이라 그나마 적응이 되는 것 같다. 하 그래도 제발 금요일 재택 돌려줘요~~ - 2022년부터 진행했던 FE 리뉴얼 프로젝트 ..

책이 얇아서 읽기 시작한지 그리 오래 되지 않아 완독을 했다. 내용을 요약하면, 객체는 어떤 데이터(상태)를 가지고 있느냐가 아니라 어떤 '행동'을 하느냐로 정의해야한다. 무턱대고 클래스 설계부터 할 생각 하지 말고, 객체들간에 무슨 메세지를 받고 보내는지(무슨 행동을 하는지)에 집중하라. 그 메세지 교환 창구가 결국 인터페이스를 결정한다. (객체가 받을 수 있는, 즉 처리할 수 있는 메시지가 인터페이스로 정의됨) 더 많은 내용들이 있는데, 가장 중요한건 결국 객체간 메세지 교환(행동)에 집중해야한다는 것 같다. 즉 무슨(What) 행동을 하는지 파악하고, 정의한 행동에 필요한 상태(값, 데이터)들을 따라서 정의하면 된다. 동어 반복이 많은 느낌이였는데 그만큼 작가님이 중요하다고 생각하시는 부분을 강조하..

BO (service) 에서 조회 조건 검색 넘겨줄 때, 파라미터가 많아지는데 이걸 검색 VO 같은걸 만들어서 처리하는게 나을까? 근데 이러면 BO 함수 사용하는 쪽(주로 controller)에서 좀 번거로워짐...계속 searchVO에 값을 set해줘야해서... 파라미터 개수의 준을 정하고 그 보다 많으면 객체로 묶어볼 수 있을 듯... 하지만 재사용성이 너무 떨어지거나 하면 그냥 그대로 두거나 차라리 메소드의 기능을 쪼개보는게 어떨까? 기능이 쪼개지면 필요한 파라미터도 쪼개질 것 같은데 select 쿼리들을 하나로 계속 통합하는 방향이 나을까?(하나의 쿼리에 검색 조건 동적으로 계속 추가하면서) => 기본적으로 범용성을 우선적으로 생각하고, 성능 문제 같은 어떤 이슈가 있을 때 분리를 결정하는게 좋은..

- DB를 통해 자료 list를 select만 해오는 기능을, 즉 'aaaMapper.selectAAA' 와 같은 것은 한줄 짜리라도 serivce 계층에서 함수로 분리하는게 맞을까 아니면 그냥 그정도는 바로 쓰는게 나을까. 함수를 만들자니 당장 체감되는 장점은 없고 코드만 늘어나는 느낌... 그냥 차후에 있을지 모르는 기능 확장을 대비한다는 느낌? => 보통 service 함수에 transaction이 걸리기 때문에 가능하면 service 함수를 통해서 접근하는게 좋다. 경우에 따라서 아주 간단한 조회 기능인 경우 그냥 바로 dao(sqlmapper)를 통해서 불러오기도 한다. - language 정보를 이용해 필요한 컬럼 정보를 가져와야한다. 예를 들면 user_name_lang1, user_name..

1. 비지니스(서비스) 계층에서 트랜잭션 처리하기가 생각보다 쉽지 않다 앞서 3장에서(https://hongod.tistory.com/25?category=1063676) 트랜잭션을 시작하고 종료하는 계층을 비지니스 계층이라고 했었다. 이 비지니스 계층의 코드를 작성할 때 가장 중요한 원칙이 하나 있는데 바로 최대한 의존성을 버리고 순수한 자바코드로 작성해야한다는 것이다. 프렌젠테이션 계층은 웹, 서블릿 HTTP 와 같은 기술에 의존하고, 데이터 접근 계층은 JDBC, JPA와 같은 구체적인 DB 접근 기술에 의존하기 때문에 차후 기술 발전에 따른 코드 수정은 불가피하지만, 서비스 계층만은 핵심 비지니스 로직이 바뀌기 전에는 수정하지 않도록 순수한 자바 코드로 격리해놔야 유지보수와 테스트가 용이한 애플리..

이 글은 Microsoft 사에서 제공하는 ODBC 관련 공식 문서(https://docs.microsoft.com/en-us/sql/odbc/reference/what-is-odbc?view=sql-server-ver15)를 읽고 번역한 글이며, 영어 실력이 미천하여 오역이 다수 포함될 수 있습니다. 문제가 될 시 삭제하겠습니다. ODBC란? 컴퓨팅 세상에는 ODBC에 대한 많은 오해가 있다. End user 에게는 윈도우즈 제어판의 아이콘일 뿐이고, 어플리케이션 개발자에게는 데이터 접근 routines을 포함한 라이브러리이며, 그 외 많은 사람들에게는 수 많은 DB 접근 문제들에 대한 해답이다. 그 중에서 ODBC를 가장 잘 설명해주는 말은 'DB API에 대한 스펙'이라고 할 수 있다. 이 API는..

이 글은 '친절한 SQL 튜닝(저자 조시형, 출판사 (주)DBian)을 읽고 정리한 글입니다. 1.SQL 튜닝 1. SQL이 느린 이유 SQL이 느린 이유는 대부분의 경우 I/O, 특히 디스크 I/O 때문인데 이 I/O는 프로세스의 일시적 중지(sleep)를 일으킵니다. 특히나 디스크 I/O는 메인 메모리 I/O에 비하면 매우 오래 걸립니다. 만약 동시 다발적으로 디스크 I/O 요청이 들어오면 I/O를 수행하는 시간에 대기시간 까지 추가되어 더 오래 걸리게 됩니다. 물론 I/O 요청이 발생하면 DBMS가 우선적으로 메인 메모리에 있는 캐시를 탐색하고 여기서 같은 내용에 대한 I/O를 찾지 못한 경우에만 실제 디스크 I/O 요청을 수행하기 때문에 실제 디스크 I/O로 이어지는 것을 많이 줄일 수 있지만, ..

1. 거래(영어 : Transaction) 한 건의 완성 A에게서 B에게로 5000원을 송금하는 과정은 아래의 두 가지 동작으로 나눌 수 있다. 1) A의 잔고에서 5000원을 차감 2) B의 잔고에서 5000원을 증가 만약에 1)의 과정만 수행되고 2)의 과정이 수행되기 전에 오류로 인해 DB 커넥션이 끊어져버리면 어떻게될까? 거래가 제대로 수행되지 않고 A의 잔고에서 5000원이 증발해버린 상황이 펼처지게된다. 회계로 따지면 차/대가 불일치하는 상황(?)이 펼쳐지게 되는 것이다. 이렇게, 작게 봤을 때에는 부분으로 나뉘어지지만 전체적으로 하나의 과정으로 처리돼야하는 DB 통신 과정은 DB에서 제공하는 트랜잭션이라는 기능을 이용하면 각 파트들이 모두 다 함께 수행되거나, 그렇지 않으면 모두 수행 되지 ..