wanna be a software craftman step by step

독일에 와서 정말 제대로 느낀게 하나 있다. 금요일 이후에, 스케쥴 표에 우리팀만 이름이 빠져있어서, 채워넣야하지 않냐고 물어봤는데 아무도 답이 없었다. 그러다 다음 월요일에, 다른 사람이 이야기를 다시 꺼내서, 채워넣야 하니 미팅을 하자고 했더니 다들 참여했다.  미팅에서 screenshare 할사람이 없어서 조금 기다리는 공백이 있었는데. 이때라도 나섰어야 했는데 머뭇거렸다. 아무일도 아니었음에도 말이다. 그러곤 빈 slot 에 각자 이름을 넣을 사람을 찾는데 저마다 자기 이름을 넣어달라고 했다. 나는 기회를 기다렸다가 말하려고 했는데. 내가 말할 틈을 주지 않았다. 진짜 모여서, 자기가 되는 시간은 주저없이 자기 이름을 넣어도 된다고 바로바로 말했다. 그렇게 약 5분만에 미팅이 끝났다. 공정한 분배나 이런건 말하지도 않았다.  아무도 기다려주지 않는다. 모두가 서로 돕고 돕는다. 그런데 도와달라고 말을 해야한다. 그러면 언제든 도와준다. 하지만 말을 해야한다. 적극적으로 의사표현을 해야한다. 내가 하겠다고 해야한다. 도움이 필요하다고 해야한다. 뭔지 잘 모르겠다고, 내가 할 수 있다고, 말을 해야한다.  쭈볏쭈볏 머뭇머뭇 하면 기회가 날라가는 것이다. 

 주입식 교육의 단점이라기엔 스스로 잘하는 사람들이 너무 많다. 소극적인 성격이라기엔 소극적인거랑 일 하는거랑 무슨 상관인가. 양으로 치는거. 이거이거 이렇게 해. 라고 누가 정해주는거. 이런건 밤을 새고, 주말을 써서 한다. 그리고 혼자 뿌듯해한다. 해냈다. 이러면서.  하지만 빈 종이와 연필을 주고. 한번 해봐. 하면 못한다.  뭘 어떻게 해야할지 모르겠다.아무런 생각도 들지 않는다. 리서치를 해야한다고 해도 뭘 어떻게 서칭 해야하는지 감이 안잡힌다. 스펙 던져주고 구현해 라고 하면 마음이 편하다. 이런 방식은 남이 봤을때 비효율적이다. 시간을 많이 투자할줄만 알지, 그 시간 대비 효율성을 따졌을때 가치가 높지 않다. 다른 이유도 있지만, 경력에 비해 경험의 깊이가 별로 깊지 않은 이유이다. 논리적 전개를 해내지 못하면, 다양한 변수가 발생하는 상황에서 일단 문제 해결이 힘들다. 하더라도 효율적인 방안을 제시하지 못한다.  혼자서 생각해내는 힘이 없으면, 평생 남이 던져주는 스펙만 개발하고 살아야 한다. 극히 일부분만 보면서. 그러면 더 높은 곳으로 올라갈 수가 없다. 좋고 나쁘고가 아니라. 연차에 비해 지혜가 없으면 설 자리가 없게 된다.  그러면 시키는대로만 했기 때문에, 경험도 별로 쌓이지 않는다. 회고 할 것도 없고. 가치있는 경험을 했다고 말하기 어렵다.  지금이라도, 늦었더라도, 자유도 100이 주어지면. 나만의 전략을 세워야 한다. 그러기 위해선 목표가 무엇인지를 항상 기억하고. back tracking 이 될수도 있다. 전략을 세우고 싸워봐야. 지더라도 배우는게 있고 발전이 있다. 

처음으로 동료들로부터 feedback 을 받았다. 내가 지정한 동료들로부터 받으나, 나에게 돌아오는 결과는 익명이다.  예상했던 대로 self-initiative 는 낮았다. 그러나,quality of work, 나 efficiency  에서도 좋은 점수를 받지 못했다. 평균이란 소리는, 더 잘해야 한다는 소리다. 의외로 team effect 나 knowledge, work commitment 는 좋은 점수를 받았다. 열심히 하고 잘 아는데, 효율적이지 못하고, 스스로 나서지 않으며, 신경써서 일하지 않는다는 결과. 문제를 해결할 때 문제 해결뿐만 아니라, 그 주변의 코드들로 추가적으로 보는 습관들 들여야 한다. 문제를 해결할 때 이 해결된 방안이 다른 부분에 영향을 끼치지는 않는지도 생각해야 한다.  적극적 참여와 의견 개진은, 계속해서 들어오고 있는 피드백이다. 빠르고 바로바로 커뮤니케이션 하라는 주문도 들었다. 말도 못하고 영어는 더 못하는 나를 동료들도 답답해 한것이다.  미안함과 동시에, 답답하기도 했고. 발전의 여지를 인지했고, 발전했음을 나중에 볼 수 있다면 좋겠지만. 참 힘들것이라는것을 알기에. 마음이 좋지만은 않다.

- 툴박스에 쓸 버튼을 하나 만들었다고 치자. 이 버튼을 상속시켜, 여러가지 저장하기, 복사하기, 붙여넣기 등의 버턴을 만든다고 치자. 뭐가 문젠가? - 문제가 충분히 될 수 있다. 일단, subclass 종류가 너무 많다. 그건 그렇다 치더라도, 복사하기가 버튼에만 있는게 아니고. 메뉴에도 있고, 단축기로도 가능하다. 단축기나 메뉴를 버튼에서 상속하자니 말이 안되고, 그렇지 않으려면 중복된 코드가 생기게 된다.  - command 패턴을 레스토랑에 비교했다. 손님이 테이블에서 주문을 하면, 웨이터는 이를 받아 적어 주방 어딘가에 stick note 를 붙여 놓는다. 요리사는 이 목록대로 음식을 만들어서 다시 내놓고. 웨이터는 목록과 음식을 최종 확인 한 뒤 손님에게 가져다준다. - 비즈니스로직과 GUI 분리의 관점에서, 위 상황의 버튼과 기능을 분리하는게 당연하지만, command 패턴이 말하는건 그냥 분리가 아니다. GUI 가 비즈리스 로직에 request 를 바로 보내는 것이 아니라, 따로 분리된 Command 라는 클래스에, 비즈니스 로직에 필요한 데이터들을 모아두고,  Command 라는 클래스에는 이 요청을 수행하는 method 하나가 존재한다. 그러면 GUI 가 비즈니스 로직에 대해 잘 몰라도, Command 만 트리거 하면 된다.  - Command 클래스는 보통 parameters 가 없는 execute method 하나만 가진다. - 그럼 명령 수행에 필요한 매개변수 같은건 어떻게 넘기는가? 아래 예제를 보면,  Command abstract class 에 생성자로  Editor 를 받는데, Editor 자체로 충분하다. 다른 경우에도, 생성자의 매개변수로 넘기고, execute() 함수에서 각 command 별 자세한 처리를 한다.  - Command  패턴은 이렇듯 객체와 할 행동을 같이 묶어 객체로 넘기는데 사용되고, 객체로 넘기기 때문에 serialize 가 가능하고, rev...

원래 올해 목표가 하루 30분씩 쉐도잉 하는거였다가, 하루 20문장 영작 연습하는걸로 바꿔서, 일단 한 20일정도 진행한것 같다.   그리고 주말에 간만에 쉐도잉을 훈련을 다시 해봤다. 다시 하니까 확실히 또 답답하다. 한참 열심히 할때보다 더 느려지고, 버벅이고, 속도를 못따라 가겠다. 이미 반복해서 했던 컨텐츠인데도. 그런데 쉐도잉을 안하다가 간만에 몇번 해보다 보니, 이게 이런 훈련이구나 라는게 느껴졌다. 무슨 말이냐하면.  영어를 말할때의 과정을 굳이 나눠봤다.  1. 머릿속에서 영어로 생각해서 말하기 전까지의 과정 2. 입모양과 목소리를 이용해 영어로 실제로 말을 하는 과정 쉐도잉은 2번을 위한 훈련이라는 결론이 내려졌다. 빠르게 말할때의 입모양, 발음, 억양을 훈련하기에는 쉐도잉이다.영작 훈련은 1번 훈련이다. 실제 상황에서 머릿속에 떠오르는걸 바로 말할 수 있으려면. 한국어로 되어 있는걸 보고 거의 자동으로 영어로 머릿속에 떠올라야 한다.  나는 아직 머릿속에서조차도  느려터졌는데, 입밖으로 내는 훈련이 잘되봐야 무슨 소용인가. 생각해보면 영어로 말할때 매번 느끼는 그 답답함은 1번이지 2번이 아니다. 너무 느려서도 안되겠지만,  2번이 아무리 훈련이 되었더라도 1번에서 보내주지 않으면 소용이 없는 일이다.  내가 회의할때나 이야기할때, 영어 단어를 말할때 사용하는 입모양이 빠르게되지 않아서 더듬거렸던가. 단 한번도 없었다. 머릿속에서 한참 걸린거지. 미리 준비된 대본을 여러번 연습해서 숙지해서 말하는 속도만큼 빠르게 말할 단계는 아직 멀었다.  쉐도잉을 믿고 작년부터 철석같이 믿고 계속 했던 내가 한심스러워지려고 한다. 그러면서 왜이렇게 안늘지 하고 있었다니. 도움이 안되진 않는다. 쉐도잉을 훈련하니 듣기가 느는걸 체감했다.  어쨌든, 다양한 방법으로 시도해보려고 하니 발견하지 못했던걸 알게 되네. 변화가 있다는걸 느꼈다. 계속 해야한다고 생각했던 쉐도잉을...

목표는 하루 25문장이다. 한글을 영어로 영작하고, 정답과 비교하는 연습이다. 약 1시간정도가 걸린다. 그래서 쉐도잉은 주말에만 하는것으로 변경했다. 내 부족한 점 중 하나인 순발력, 속도, 이런것들+ 어쨌든 실전에서의 사용 경험도 중요하기 때문에 회화 수업도 1주일에 1회씩은 되도록이면 계속 진행하려고 한다.  생각해보니 내가 한국어->영어로 바꾸는 영작 연습을 얼마나 해봤던가 싶다. 토익에만 빠져 살다가, 토플 공부한다고, 아이엘츠 공부한다고 학원다니다가. 영국에 잠깐 갔다 왔던 빨로, 오픽이랑 토익을 취업 준비 점수에 맞춰놓고. 이후 전화 영어, 원어민 1대1 회화, 아이엘츠 단과 등을 다니긴 했지만. 영작만 이렇게 하루 1시간씩 훈련을 해본적이 있었나.  회화 실력을 늘리고 싶어 전화영어, 화상영어, 1대1영어 등을 했는데. 아주 미세한 발전은 조금씩 있었겠지만 매번 내가 느끼는건 좌절과 답답함이었다. 그때 필요한게 영작 훈련이었을텐데. 토익 LC 에 나온 것들이라도 잡고 할껄. 무작정 원어민이랑 말하는 기회를 늘리는게 답인줄 알았었다. 나도 모르게, 영어 학원의 현란한 광고들을 보고 혹 했겠지. 그러다 속도가 문제인줄 알고 쉐도잉을 훈련하기 시작했는데. 사실 속도도 속도지만 진짜 원인은 영작 자체가 매우 어렵고 느렸던것이다.진짜 원인은 모른채 쉐도잉만 했네. 그때도 영작에 대해 생각을 안해본건 아니었다. 하지만 그때는, 영작 하면 꼭 어딘가에 글을 써야하는 작문처럼 느껴졌고, 똑같은 말을 한번 이상 하는 경우가 얼마 될까 하여, 모든 경우에 대해 1대1로 영작을 하는게 비효율적이라고 생각했고, 어느세월에 그걸 다 하나 싶었다. 맞는지 틀린지 확인해주는 사람도 없었고. 그런데 지금 돌아보니 그때 그 생각이 틀렸다. 모든 경우에 대해 1대1로 하는게 비효율이라고 해버리면, 나는 한마디도 할수 없다. 그때부터라도, 첫번째 문장부터 하나씩 다 겪어봤어야 그게 쌓였을것이였다. 그때는 말하기 뿐만 아니라 듣기도 문제였으니까 여기까지 신경 쓸...

 Spring 에서는 총 일곱가지의propagation 옵션을 제공한다. @Transactional  로 묶인 함수나 클래스에서 excpetion 이 발생하면 rollback이 된다. 하지만 스프링에서 제공하는 noRollbackFor, noRollbackForClassName, rollbackFor, rollbackForClassName 같은 옵션을 통해 이 역시 설정 할 수 있다. 1.REQUIRED 물리적 transaction 이 없으면 만든다. 이미 존재하면 그 transaction 에 참여한다. 그리고 각각의 @Transactional REQUIRED 로 설정된 메소드 들은 논리적 transaction 을 갖는데, 각각 경계를 가지고 있고, 저마다 범위가 있다.  모든 transaction 이 하나의 물리적 transaction  에 매핑되기 때문에 그중 하나라도 논리적 transaction 이 실패하게 되면 rollback  모든 그 물리적 transaction 에 있는 논리적 transaction 들이 rollback 된다. 바깥에서 catch 해서 처리 한다 하더라도 여전히 transaction 은 rollback 된다. 이미 실패된 논리적 transaction 에서 rollback-only marker 라는것을 세팅 해버리기 때문이다. 이렇게 되면 같은 물리적 transaction 에 있는 것들은 rollback 될수밖에 없다. 2.REQUIRES_NEW 이는 이름에서처럼, 스프링이 항상 새로운 물리적 transaction 을 만들도록 한다. 그렇기 때문에 바깥의 물리적 transaction 의 속성(timeout, isolation level, readonly)을 상속받지 않는다.  각각의 물리적 transaction 은 각각의 database connection 을 필요로 한다는것을 염두해야 한다. 예를 들어 메소드 A 가 메소드 B 를 호출했는데, B 가 REQUIRES_NEW 로 열렸다...