[20220412] 개발자 일기 & TIL

개발자적으로(?) 일하기. '~적으로'가 번역투라 싫다면 '개발자처럼 일하기'나 '개발자답게 일하기'

클라이언트의 말도 안 되는 요구 때문에 서버에 접근 권한 없이 수작업으로 첨부 파일을 옮겨야 할 상황이 생겼었다. 데이터를 덤프 명령어나 export로 옮기면 되는 것을 일일이 파일을 다운로드해서 글에 첨부해줘야 하는 말도 안 되는 업무였는데 동료들과 같이 작업을 하면서 반드시 크롤링으로 자동화해야겠다는 생각을 했다. 계속 회의에서도 크롤링으로 해볼 수 있을 거 같다는 말을 하긴 했으나, 개인적으로 시도해봤을 때 오류가 나고 있어서 호기롭게 직접 해보겠다는 말을 할 수 없었다. 근데 어제 결국 오류를 잡아서 크롤링으로 파일을 옮길 수 있게 되었다. 글 번호를 순회하면서 파일을 모두 다운로드하고 파일 정보를 파이썬의 딕셔너리 타입으로 받아놓았다. 오늘 개발 서버에 insert가 되는 것을 확인해고 내일 좀 더 테스트를 해보면서 운영서버에도 반영할 계획이다.

 

이번 크롤링 작업을 통해서 개발자답게 일할 필요성을 절실히 느꼈다. 노가다 작업이 있으면 무조건 자동화하려고 시도하고 시간이 오래 걸리는 작업이나 코드, 쿼리가 있으면 효율화할 방법을 무조건 찾자.

 

TIL

어제에 이어서 '1장 스프링 프레임워크 소개'를 읽으며 배운 것들을 정리하려고 한다.

 

스프링 IoC 컨테이너는 root-context.xml, application-context.xml과 같은 설정 메타데이터를 읽어서 애플리케이션 객체들과 그들의 의존 관계를 인스턴스화한다.

 

설정 메타데이터를 제공하는 방법에는 XML, 자바 애너테이션, 자바 코드 등의 방식을 이용한다.

 

스프링 프레임워크에서는 객체의 생성과 관리를 스프링 IoC에 위임한다.

 

스프링 컨테이너는 POJO(Plain Old Java Object, 일반 자바 객체, 프레임워크가 지정하는 인터페이스나 클래스를 구현/확장하지 않음)로 애플리케이션을 모델링할 수 있다. 이 때문에 스프링 프레임워크를 EJB 객체를 상속받아야 했던 기존 프레임워크에 대비해서 경량 프레임워크라고 한다.

 

스프링은 '추상화 계층'을 제공하는 방식으로 JMS 공급자, JNDI, MBean 서버, 이메일 서버, DB 등과 상호작용을 쉽게 해 준다.

 

스프링에서는 선언적 트랜잭션 관리(declarative transaction management)를 사용해 트랜잭션을 관리할 수 있다. @Transactional 애너테이션으로 트랜잭션을 설정할 수 있다. 트랜잭션을 사용하기 위해 별도의 클래스나 인터페이스를 상속/구현할 필요가 없으므로 비침입적(non-invasive)하다.

 

스프링은 트랜잭션, 보안, JMX, JMS, 캐시 등 각종 서비스를 POJO에 투명하게 공급할 수 있고 그에 따라 개발자가 저수준 API를 자세히 알 필요가 없어 엔터프라이즈 애플리케이션 개발이 쉬워진다.

 

스프링 애플리케이션 개발과정

객체 간 의존 관계 파악 -> POJO 클래스 작성 -> 설정 메타데이터 만들기(XML, 애너테이션, 자바 설정 클래스) -> 세터 메서드를 이용하여 의존 관계 주입 -> 스프링 컨테이너 인스턴스 생성 (자바 독립 실행 애플리케이션만 해당) -> 스프링 컨테이너에 있는 빈 접근(자바 독립 실행 애플리케이션만 해당)

 

스프링 컨테이너가 관리할 객체는 설정 메타데이터에 빈 등록을 해주어야 한다. 일반적으로 DTO 등 도메인 객체는 빈을 등록하지 않고 스프링이 객체를 관리하지 않는다. 따라서, new 생성자를 이용하여 생성하는 방식으로 사용한다.