소프트웨어 장인

2020.01.10 ~ 회사분이 추천해주어서 읽고 있는 소프트웨어 장인

읽으면서 많이 생각했던것 그동안의 내 개발 코드보단

• 첫회사를 다니면서 있었던 과정과 프로젝트 진행이 이책의 내용처럼 흘러가고 있었던 것
• 지금 회사에서 개발하고 있었던 필터 관련한 일
• 나 자신에 대한 생각
• 팀장님도 틀릴 수가 있다

들을 생각하며 읽고 있는중이다

첫번째, 영화보고 와서 써야지, 닥터 두리틀 영화를 2020.01.11 (토) 혼자 보고, 2020.01.12 시험감독이 끝나고 오후 4시 넘어서 집에 도착한 후, 이 블로그를 끝내야 후련하겠다 싶어서 다시 이어간다.

• 몰X변X기 설계프로젝트
  나의 첫 회사에서 첫 프로젝트. 호주에서 2017년 01월 26일날 1년만에 귀국하고 2월 13일날 회사에 출근을 하였다. 주위 친구들에게 또한 인터넷으로 개발자들의 생태계를 많이 들었고, 많이 찾아도 보고 야근이 당연하다고 생각을 하였다. 개발자는 대표와 나 둘뿐이였고, 개발 프로젝트는 1월부터 시작해서 9월에 끝났다. 중간에 5월에 중고급 8월에 중급 프리랜서를 투입하였다. 처음 개발이였고 옆에서 아~ 이런거구나, 마치 지식을 습득하는 정도였다. 빨리 끝내야했기에 비즈니스 로직이 복잡하지 않는 쪽으로 개발을 맡아서 하면서, 대표의 찡얼거림을 받아주는 일을 했다...
• 티X러스
  이프로젝트야 말로 이 책의 내용과 비슷한 상황들이 많았다. 첫번째, 설계! 처음에 자신을 과시하기 위해 설계란 설계를 엄청나게 복잡하게 설계를 하였다. 기획이자 개발을 했던 개발자.. 안봐도 비디오다. 나중에 하나 수정하려니 모든게 다 얽혀 있어서, 개발자들이 죽어나려고 했다. 대표고 나발이고, 이름 부르면서 왜 이따구로 설계를 했냐 라고 밑에 있는 직원이 혼을 냈던 웃픈 기억이 난다. 두번째 할 수 있다! 라고 한 것. 처음엔 이 기획들이 어느정도의 일정이 나오는지 잘 몰랐나 보다. 된다 할 수 있다 한게 나중에 개발자들만 죽어났다. 결국 '이 기능들은 SM으로 돌려야 겠다.' '이 기능은 이 일정으론 무리가 있을 것 같다' 등 이야기를 하며 PM 분은 열이란 열은엄청 받았고, 결국 영업 부르고, 맛있는거 사주면서, 살살 구슬리기 작전을 펼쳤다.

두번째, 필터관련하여 생각을 하며 읽으니 이 책에 암과 같다는 문구가 있다.. 물론 이 이슈를 망쳐서 다른것들까지 퍼지게끔 코딩을 해야지 하는 생각을 하며 개발한게 아님에도 불구하고 자신감이 하락하는 기분이 들었다..
심지어 금요일날 sso 체크 관련하여, 내 코드에슈 request를 초기화하여 user id 가 null로 변경되는것을 확인했기 때문이다

사진에 업로드 한 것 처럼 이 이슈를 근 3주넘게 갖고 있었고, 개발시간이 오래진행 되었는데 과연 코드의 품질은? 하는 물음표가 생겼다

세번째, 나는 딱히 불평 불만이 없는 사람인 것 같다. 근데 싫어하는 사람이나 말도 안되는 상황이라면 극단적으로 그 부분만 생각해서 엄청 불평을 하며 내 인생에서 필요없는 사람, 상황으로 배제한다. 쓰다보니 불평이 있는 사람같다.
이 책을 읽으면서, 어떠한 불편함이 생겨서 편하게 제품을 사용해야지 이렇게 하면 편하지 않을까 이런 생각을 하지 않는다. 나 또한 나보다 나이가 많거나 직급이 높으면 그 사람들의 생각이 나보다 낫다는 생각을 우선적으로 생각하는 나의 성격때문인 것 같다.
지금 팀에 대부분의 말에 한마디씩 하는 분이 계신데, 어쩜 저렇게 다른 대안을 생각을 할 수 있지 ?라는 생각을 했다.

이 책에서 아니오 라는 대답을 할땐 최소한 하나의 대안이 있어야 한다는 문구를 보았고, 마음에 와닿았다.

네번째, 에 대한 생각은 팀장님도 사람이라 틀릴 수 있다 라는 생각을 하면서 이 책의 13장을 보면서 왠지 모르게 틀릴 수도 있지 않을까 하며 비교하며 읽게 되었다. 지금 팀을 이끌고 있는 팀장님께 배울점이 너무나도 많다. 우선 백엔드만 고집했던 나의 개발에 대한 시야를 넓게 바꾸게 해주신 점. 솔직히 고집이 너어어무나도 강한 나에게 계속적으로 나는 팀장님의 모습을 보면서 팀장님 처럼 개발을 잘하고 싶다라기 보다는 팀장님처럼 다른 개발언어들에대해 읽어보자 읽자 읽어! 라는 주입을 계속적으로 했던 것 같다.

또한 책 내용중에 히스토리를 찾지말고 라는 내용이 있다. 이 내용에 무척 공감한다. 히스토리 찾아서 그 사람 붙잡고 뭐라하는건 그 사람을 위한것도, 그런 모습을 보여줘서 다른 개발자들한테도 좋지는 않다고 생각한다. 분명 잘못 개발이 되면, 나중에라도 수면 위로 올라온다. 처음에 개발자분이 이거 누가했어 이거 누가 개발했냐고 찾아봐달라고 부탁한적이 있다. 그리고 다른분은 회사에서 테스트 하다가 이거 누가 했는지 내가 찾아낼거야 라는 걸 들을때마다 솔직히 좋은 생각은 하지 않는다..

이건 그냥 책을 읽고 난 후의 나의 생각이기에, 생각은 할 수 있지 않은가..

조금더 고민하고, 조금더 내 코드에 애정을 쏟을 수 있는 개발자가 되고 싶다.