No답 블로그 - 그렇다, 대놓고 고민을 하기로 했다

원래 이 블로그는 TIL - Today I Learned 를 정리해서 적으려고 남겨두었다. 하지만 그대신 개발을 하면서의 고민을 적나라하게 적으려고 한다.

우연히 내 고민을 여러 사람 앞에서 발표하는 자리가 있었고(발표제목은 ‘주니어인 내가 바라는 환경’이었으나, 그냥 고민대잔치), 발표 후에 내가 하고 있는 고민에 공감을 표현하는 분들도 계셨고, 고민을 멈추지 않았으면 좋겠다고 이야기해주는 분들이 계셨다. (정말 감사한 피드백과 진솔한 이야기를 해주셔서 감사 또 감사) 사실 고민을 빨리 해결해야하고 편해지고 싶었던 나로서는 충격이었다. n년차도 계속 고민하신다구요…?

그래서 이왕이면 고민들을 흘려보내지 않고 기록하면서 천천히 고민을 하고 해결해보기로 했다. 지금까지와는 다른 방식으로 고민해보고 싶어졌다. 당분간은 계속 개발자로 살아갈텐데 조급해하면서 스트레스 받다가 나중에는 고민을 외면하는 최악의 상황까지 가지 않기 위해서.

그렇다, 이 곳은 no답 블로그! 고민과 고민이 고민을 불러오는 그런 블로그! 고민이 주제라면, 글감 걱정없이 백년만년 쓸 수 있을 거 같다. 요즘 생각하고 있는 것들을 자유롭게 이 포스트에 적는다.


코딩

  • Exception 을 던지는 기준을 어떻게 정할 것인가?
    • 어디서는 empty collection을 반환하고, 어디서는 error를 던지고. Exception도 멋대로다. Illegal Argument exception 이고, 어떤 날에는 NullPointerException이고.
    • 프로젝트를 맡게 된 후로 쭉 해오는 고민인데 어느날은 이렇게 예외던지는게 맞는 거 같아서 고치고, 어느날은 아닌거 같아서 예외던지는 것 없애고 일관성이 엉망진창이다.
    • [시도 중] 2018.04.30. Illegal Argument exception으로 일단 통일하고 있다.
    • 2018.05.04. 위의 예시가 완전 잘못되었음을 깨달음. NPE를 내가 적어서 Exception을 던지는 정신나간 일을 왜하지… NPE를 한번에 처리하려고 했었던 거 같은데, 제대로 된 예외처리라면 발생하는 예외를 좀 더 명확한 예외로 바꿔야 하는데d이 부분에 대한 이해가 부족했다. 게다가 NPE를 한번에 처리라니… method들을 나누는 것부터 처리헀다면 지금 코드 수준에서는 저런 식으로 처리하지 않았을텐데… 왜 그랬어ㅠㅠ 과거의 나야ㅠㅠ
  • null 체크를 깔끔하게 어떻게 하지?
    • input validation 확인은 Google guava 와 spring의 기본 체크 메서드를 사용하면서 코드는 줄어들었지만 핵심에 못닿는 것 같아서 미덥다.
    • null체크를 코드내에 넣다보면 코드가독성이 떨어지고, 체크를 놓치는 경우 NPE로 고통받게 됨.
    • [시도 중] 마틴파울러 아저씨의 리팩토링 책에 관련 부분이 나와서 참고했다
    • 2018.05.04
      • 개인 프로젝트는 Java8 의 Optional을 사용해서 변경하고 있음.
      • 업무 프로젝트의 경우 아래와 같이 적용 중. (현업 프로젝트는 모두 JDK버전이 1.7이하인데, 해당JDK버전을 올리려면 클라이언트사에 요청을 해야하며, 프로젝트에서도 아직 JDK버전 업그레이드 요청에 대한 의지가 없음.)
      • 외부 라이브러리를 사용할 수 있는 프로젝트는 Guava를 사용해 Optional로 바꿀 예정이고 , 외부 라이브러리 사용이 불가한 프로젝트는 다행히 SpringFramework를 사용할 수 있으므로, Spring의 null체크를 사용 & help함수를 만들어서 사용.
      • 특히 Guava를 사용할때 Optional을 기존 코드에서 잘못 사용하고 있던 걸 걷어내고 있다. Optional을 사용하는데 if(someBean.isPresent()){ //do something } 이게 무슨 끔찍한 코드란 말인가!
        • 위 적어놓은 코드를 보고 내 스스로가 나중에 오해할까봐 덧붙임. 아래는 Optional의 map구현 내용임. 무조건 저 코드가 나쁘다는게 아님…
          public<U> Optional<U> map(Function<? super T, ? extends U> mapper) {
          Objects.requireNonNull(mapper);
          if (!isPresent())
              return empty();
          else {
              return Optional.ofNullable(mapper.apply(value));
          }
          }
          
  • 코드리뷰 없는 곳에서 셀프 코드리뷰하기
    • 현업 외 스터디들에서는 코드리뷰를 한다. 코드리뷰 아 세상에 완전 신세계다. 주니어들끼리의 하는 스터디에서 코드리뷰 서로 했을때도 기뻤지만, 시니어들과 하는 스터디를 할 기회가 있었고 코드리뷰를 받았었는데 스스로는 전혀 생각할 수 없었던 범위의 코드리뷰를 받아서 굉장히 기뻤고 행복했다.(업무 외 프로젝트이다보니 부담이 적었다. 그리고 잘못지적이 아닌 더 개선시키는 방안을 제시한다는 느낌으로 배려있고 매너있는 방식으로 코드리뷰가 이루어져서 더더욱 좋았다)
    • 현업에서 피드백을 받으려고 여러시도를 해보았는데 최근 하는 시도는 최근 간단한 issue관리와 history보면서 스스로라도 merging하면서 셀프 코드리뷰가 가능할까 싶어서 Gitlab을 시도해봤지만 제대로 한다는 느낌이 들지 않는다. 미적지근하다. 외부 환경은 외부 환경이고 스스로가 체크할 수 있는 거라도 좀 제대로 보고 싶은데 어떻게 해야할까?

프로젝트 관리 / 설계

  • issue 를 어떻게 나눌 것인가?
    • issue 단위로 작업하면서, 큰 이슈 작은 이슈가 있고, 회사마다 이슈발행크기는 다르겠지만 지금 가장 큰 문제는 task 기능 구현
    • 기능 구현 단위를 어떻게 잡지? 000기능을 이뤄지게 하려면 atomic 하게 적어야하나? 그 감각적 감각인 거 같은데 모르겠다
  • 설계는 어떻게 배우고 나아져야 하나?
    • 좋은 코드(오픈소스)를 많이 보고, 설계를 고민하는게 당연한데, 설계 이건 경험치가 쌓여야 보이는 게 있는 거같다. 디자인 패턴 책을 보면 내가 덕지덕지 디자인 패턴을 발라놓기만 할 것 같아서 불안하다. 설계는 어떤 방식으로 수련해야할까?
  • 오버엔지니어링은 무엇인가
    • 그러니까 생각해보면, 기존 프로젝트 충분히 좋은 프레임워크와 라이브러리 이고 작동된다. 안 풀리는 부분을 고민고민하고 찾아보면, 고민하던 부분을 개선한 /
  • Testcode 작성은 무의미한가?
    • 테스트 코드 작성은 생산성이 떨어지는 일인가? 장기적으로 보면(책들에 나와있는대로), 유지보수 비용을 현저히 떨어뜨리고, 버그 발생률이 줄어들기때문에 이득이라고 한다. 그럼, 지금처럼 1년 정도 잠깐 쓰고 마는 프로젝트는 초기Test code 작성하는 시간자체가 시간낭비인가? 아니라면,
    • 왜 test하는 시간을 주지 않을까?
    • 모든 일이 다 죽지않을 정도의 여유만 주어지지만… 장기적으로 봤을때는 장점 아닌가? 코드품질을 높이는 것이 비즈니스 관점에서도 이득이라는 것을 현업의 개발자들이 설득해야하는 걸까? 코드품질-비즈니스 관점에서 정량적 평가가 가능할까?

던지는 질문

  • 코딩은 어떻게 잘하게 되나
    • 프로그래밍 말고 코딩을 어떻게 잘하는지 궁금해짐. 왜냐면 내가 지금 코딩에 자신이 진짜 엄청없음. 근데 내가 왜 코딩을 못하지? 이유가 뭐지?
    • 2018.04.15 코딩을 많이 안하니까. 플러스, 더 나아지는 코드를 짜려고 의식적인 노력을 더 해야함.
      • 기반지식이 없다 / 절대 연습량이 부족하다 / 고민을 덜한다 / 잡다한 것에 신경쓴다 / 디버깅을 못한다
    • 출퇴근 시간에 코딩하기 프로젝트를 가동했다.
  • 도전해보지 않으면 깨달을 수 없다
    • 근데 도전해서 안되면 어휴, 마음 아파
  • 스스로를 존중하는 것
    • 개발자는 기이한 직업이라는 생각을 한다. 더 학습하지 않는 것에 대해 죄책감을 가져야하다니. 하루에 8시간 아니 그 이상의 야근에 (거의 어쩌다보니)익숙해져있으면서도 개인시간을 쪼개고 쪼개서 학습하지 않는 것에 죄책감을 느끼는걸까. 그러지 않으면 노력부족이 되는 걸까.
    • 그게 정말로 필요한 직무역량이라면 왜 회사는 개발자의 성장에 투자하지 않는 걸까? 개발자는 개인시간을 희생해가면서 학습을 하고 더 나아가면서도, 성장에 대한 프라이드 대신 더 열심히 하지 못했다는 죄책감을 가져야하는 걸까?
    • 2018.04.30 학습하면서 너무 지쳐있었다. 4월에 2주동안 코딩을 쉬었다. 내가 왜 개발자가 되려고 했는지를 곰곰히 생각해보았다. 명확한 답은 내리지 못했지만 무언가를 만들어내고 어딘가에 기여할 수 있다는게 나에게 소중하다.
  • 나는 왜 데이터 분석에 관심을 가지게 되었나
  • 직업으로 돈을 벌 수 있는 전문가의 기준은 뭘까?
    • Data분석 직군에 관심을 가지게 되면서 궁금해짐.
  • 피드백 구구절절 피드백! 피드백 받고 싶다
    • 내가 잘하면 상관없져. 내가 백가지 시야 다 가질 수 있으면 상관없져. 근데 난 내가 못하는 것도 알고 있고 내 시야도 접다는 걸 알고 있는 걸ㅠ 지금까지 찾은 방법은 피드백인데, 가장 큰 문제는 피드백 줄 사람이 없으면 안된다는 거다. 셀프피드백은 시야가 좁은 걸 극복할 수 없는데? 책? 강의? 책과 강의를 소화해서 적용시킬 역량이 부족하다. 아! 그럼 일단은 어떻게 하면 내용을 잘 소화시켜서 어디다 써먹을지 고민해봐야겠군!
    • 2018.04.30 의식의 흐름… 저 타이틀에서 어떻게 저 결론으로 이어질수 있었지…
  • ‘평범한 개발자’ 라는게 있을까? - 위험한 구분짓기
    • 2018.04.30. 정리되지 않은 글이지만 꾸준히 생각해보고 싶어서 단문을 포스트함.
얼마전에 내가 원하는 개발환경에 대한 주제로 발표를 했다. 평범한 개발자로 편하게 살고 싶다는거였다.
오늘 파이콘 CoC의 다양성을 생각하면서 문득, '평범한' 사람이 과연 있을까? 라는 생각이 들었다. 
각각 한명 한명이 가진 다양성을 인정한다면 '평범한'으로 쉽게 범주를 묶어낼 수 있을까? 
너무나 손쉽게 범주화해서 그 뒤에 내가 숨어버리는게 아닐까? 
범주화해서 어떤 어떤 성격을 가질 것이다 하고 단언하는게 얼마나 위험한 일인지. 

개발자가 되기로 마음먹고 나서 가장 인상깊게 다가왔던 것은 컨트리뷰션이었다. 
참여하고 기여하면서 무언가를 발전시켜나가는 것. 
모든게 이상적인 게 아니라서 때로 커뮤니티를 보면 인맥으로 얽힌 그들만의 커뮤니티같은 느낌이 들어 
실망한 적도 있었다. 기술을 다루는 실력이 좋다는 이유로, 다른 사람의 수고를 존중하지 않거나 
기술실력으로 줄 세우려는 모습을 보며 사람 위에 기술있냐,거참 하고 혀를 끌끌찬 적도 있었다.  

 CoC의 저 단순한 문구들을 보면서 앗챠 놓쳤던 것들을 다시 한번 생각하게 한다. 
고정관념, 자신의 틀에 박힌 손쉬운 단언으로 누군가의 수고로움과 노력을 너무 가벼이 보지는 않았는지. 
갇힌 생각, 갇혀있다고 생각조차 안했었던 것들. 회의하면서 나의 둔감함을 깨닫게 된다. 좋다.

커뮤니티에서 참 많이 배운다. 
모 스터디를 하면서 몇 분의 몸에 밴 배려를 보면서 감탄을 하기도 하고. 
코드 리뷰하면서 사람 마음 상하게 하면 안된다고 그 말이 마음에 남는다. 
2018.03.24
Written on March 24, 2018