나의 프로그래밍 변천사

그때그때 기록을 잘 남겼으면 좋았을텐데, 지난 기억을 되새기며 작성했다. 부정확한 부분들이 있다.

시작

나는 경력을 시작하고 10년 동안 외주개발자(솔루션SI)로 일했다.
업무를 빠르게 파악하고, 소통하고, 문제없는 개발결과물 내는 것을 잘했다.
처음 3~4년 야근을 많이하고, 업무시간 이후에 업무/개발하는게 너무 싫었다.
개발은 나에게 일이고, 재미없지만 억지로 하는 것이었다.

 

java, spring, javascript, jquery, oracle등 기술스택을 사용하고
controller, service, dao의 3layer에 업무를 구현했다. DB가 중심인, 트랜잭션 스트립트였다.

 

4~5년차쯤 하나의 회사에 4년정도 파견근무 했다.
년차도 차고, 한 코드를 오래보게 되었다. 코드에 뭔가 개선이 필요하다. 이대로 계속 프로그래밍하면 점점 더 나빠진다는 문제는 인식을 했다.
회의때 문제제기해보기도 했지만, 어떻게 해결해야되는지 모르고, 외주개발자이기에 좀 더 적극적이지 못했고, 무엇보다 열정/관심이 부족했다.
개발 커뮤니티도 기웃거리고, 좋다는 책도 꽤 샀는데, 공부하고 싶은 생각은 별로 없었다.(이때 처음 연애함, 결혼도 함)

 

TDD책만 유일하게 읽었다.(1부만) 예제를 타이핑하면서 읽었는데, 개발책이 이정도로 재미있을 수 있구나 놀랐다. 회사코드에서 TDD를 하는 것은 상상하지 못했다.

기술 선택 권한

스타트업을 경험하고싶어서, 한 회사에 입사했다.
기존 기술 리더가 퇴사하면서, 내가 기술 리더격이 됬다.
경력 처음으로 기술선택을 할 수 있는 권한이 주어졌다. 처음으로 스스로 업무시간 외에도 업무를 위해 시간을 썼다. 호기심이 생기고 재미가 붙었다.
JPA 강의를 보고, 업무에도 개선사항을 적용해봤다.
이때 클린 아키텍처를 접했다. 그동안 내가 잘 못됬다고 느낀걸, 딱딱 집어주는 것이 너무 속시원했는데, 그래서 회사코드를 어떻게 바꿔야되는지는 몰랐다.
좋은 개발문화를 가진 회사에서, 좋은 개발에 대해 배우고 싶었다.

NextStep - TDD, clean code

nextstep의 TDD, 클린코드 강의 이후 내 코드가 급격히 변하기 시작했다.
강의를 들으며, 회사코드에도 커밋/코드 컨벤션을 적용하였다. 주변동료들에게도 전파했다.
객체지향생활체조, 클린코드 책의 지침들도 적용해보았다. 그동안 지루했던 회사코딩이 꽤 재미있어졌다.
하지만 회사코드에 테스트코드를 작성하는 것이, 특히 TDD를 적용하는 것이 어려웠다.

회사에서 테스트코드 작성하기

강의를 마치고, 클린아키텍처 책을 보았다.
너무나 옳은 말씀이었는데, 어떻게 회사코드에 적용할지를 몰랐다.
좋은 회사에서는 어떻게 회사코드를 만드는지, best practice는 무엇인지 궁금했다.
만들면서 배우는 클린아키텍처 책을 보고, Repository를 추상화하는 것을 알았다.
이제 회사코드의 테스트코드를 작성하는데 어려움이 없어졌다. 책에 있는 것처럼 헥사고날 아키텍처로 회사코드를 작성해봤다.
TDD는 아직 어색했다. 테스트를 먼저 만든다는게 잘 와닿지 않았던 것 같다.

회사에서 TDD 하기

엘레강트 오브젝트 책을 보았다.
객체지향에 대해 더욱 생각하게 되었다. 클래스를 만들때, ‘무엇’인지 생각하고, 어떻게/행동/속성들을 감췄다.
점점 interface를 정의하는게 익숙해졌다. TDD가 점점 더 익숙해졌다.
사용할때 어떻게 쓰일 것인지를 먼저 생각하게 되었다.
책에서는 불변객체를 강조했는데, 모든 속성을 불변으로 만드는 것이 어려웠다.

회사에서 불변객체 사용하기

새로입사한 신입개발자에게, TDD와 객체지향을 가르쳐주고 싶었다.
그 분도 관심이 있었고, 나도 가르치는 경험을 해보고 싶었다. 페어프로그래밍도 하고 직접 만들어 보여주며 비교하기도 했다.
nextstep에서 배운 미션(카타)를 가지고 진행을 많이 했다. 내가 처음 미션을 할때보다 코드가 많이 간결해졌다.
그러면서 ‘자동차 경주 게임’을 모두 불변객체로 만들어보고 싶었다.
처음엔 잘 안됬는데, 가변 행동을 하는 메서드에서, 새로운 객체를 만들어 리턴하면 되는 것을 알게되었다.
회사코드에도 외부참조하는 클래스, 직렬화대상 클래스를 제외하고는 불변 클래스로 만들기 시작했다.

디자인 패턴

엉클밥이 클린코더에서 프로 소프트웨어 개발자라면 알아야하는 최소한의 기술 목록을 이야기했다.
그 목록에 디자인패턴이 있었는데, 계속 마음에 걸렸다.
패턴에 관한 다른 책들도 있지만, 영 학습이 되질않았다. 몸에 붙질 않았다.
원조격인 GoF의 디자인 패턴책을 샀다.
서문을 보니 패턴달달 외우기보다, 객체지향 디자인을 잘 아는 것이 중요하단다?
각 패턴을 보니 상속을 쓰는 패턴이 너무 많다.

 

이펙티브 자바에서 상속은 충분한 이득이 있을때만 계획하에 쓰라고 했는데,
엘레강트 오브젝트에선 아예 쓰지말라고 한다.
코드의 중복을 제거하는 두가지 방법, 상속/구성 중에 구성만 써도 될 것 같다?
듣자하니 함수형 프로그래밍에서는 모든 것을 함수로 해결하기 때문에 디자인 패턴이 없다고 한다.
그럼 함수형 프로그래밍을 알아보고 싶은데..

함수형 프로그래밍

엉클밥이 매우 푸시중인 클로저, 진짜중에 진짜 함수형 언어 하스켈을 튜토리얼 정도 해봤다.
코드가 수학 공식처럼 느껴진다.
클로저와 하스켈로 만든 리얼월드를 확인해봤다. 함수형이라 기대했는데 코드가 너무 복잡하여, 자바/스프링보다 나아보이질 않는다.
이 코드들이 잘되어있는 코드인지 알수는 없지만, 굳이 함수형이야되는가 의문이 들었다.

 

쏙쏙 들어오는 함수형 코딩 책을 알게되었다.
실용적인 측면에서 함수형 프로그래밍를 이야기 해준다고 한다. 아직 완독전인데,
계산/데이터/액션을 나누는 것을 보며, 불변객체를 적극적으로 사용하는 코딩과 별로 다르지 않음을 느꼈다.

DDD

는 여기에 자세한 내용이 있다.
도메인 주도 개발책을 출퇴근하며 목차중에 호기심생기는걸 보고있는데, 그때(책은 2003/08에 나왔는데, 3?4?년간 쓴거라고 한다.) 이미 불변에 중요성을 강조했었다.
힘들지만, 읽을만한 책인 것 같다.