Published by Woong Geun Jang, December 21st, 2018

• Working Effectively with Legacy Codes
• Software Estimation
• 어떻게 공부할 것인가
• 최고의 팀은 무엇이 다른가
• 커피과학
• The Pragmatic Programmer
• 헬스의 정석

• 규칙적인 생활의 가장 큰 행복은 내 시간을 제어할 수 있다는 것이다.
  예로 들어, 매일 아침 6시 반에 일어나서 11시 반에 잔다면,
  하루에 내가 몇 시간 유휴시간이 있는지, 운동할 시간이 있는지,
  공부할 시간은 있는지 알 수 있다.
• 사람은 하루에 얼마나 일할 수 있을까?
  15시간을 2년 내내 일하면, 효율적일까? 그렇게 10년을 일할 수 있을까?
  단순한 질문을 통해 장기적으로 내가 어떻게 일해야 하는지 알 수 있다.
• 규칙적인 생활은 장기적인 업무효율의 핵심이다.
• 사람이기 때문에 자존심이 상하고 방어적일 수 있지만,
  중요한 것은 그럴 때 느끼는 감정이 잘 못 됐다고 계속 가르치는 것이다.
• 불안한 상황에서 내가 할 수 있는 최대한의 선택은 냉정함을 유지하는 것이다.
• 내가 옳다고 생각하는 기준으로 남을 판단하기 보다는
  그 기준으로 확고히 나만을 판단하는 것이 더 행복한 삶을 위한 길이다.
• 의사결정에서 선행되어야 하는 것은 그 의사결정이 중요한 지를 결정하는 것이다.
• 문제를 못풀겠다면 문제가 무엇인지 누군가에게 설명한다.
  내 설명 어딘가에 너무 추상적인 부분이 있다면 그 부분을 구체화하는 것만으로도 문제가 풀릴 수 있다.
• 경험을 상상하기 전에 경험하는 것을 아껴라.
• 모든 경험이 좋진 않다.
  경험하지 않고 알 수 있으면 경험하지 않는 편이 낫다.
  다른 모든 것과 마찬가지로 경험도 효율적으로 해야 한다.
  최소 경험으로 최대경험!
• 다급할 때일수록 직관을 선택하게 되고,
• 잘못된 직관을 많이 가졌을 경우, 실수로 이어진다.
• 반복적인 연습보다는 심사숙고하는 연습 한 번이 더 낫다.
• 내가 어떤 대상에 대해서 취할 수 있는 액션은
  CRUD(Create Read Update Delete) 프레임워크 안에 있다.
• 남들은 쉽게 이해하는데 이해할 수 없다면 자괴감에 빠지지 말고 이해할 수 있는 방법을 찾는다.
• 소프트웨어 개발에서 변동사항이 있을 때마다 테스트를 진행하듯이, ‘나’를 둘러싼 내/외부환경이 변할 때마다 끊임없이 삶의 목적을 향해 가고 있는지 테스트 해야 한다.
• 누구든 생각이 바뀔 수 있다.
• 피곤하면 잔다.
• 중요한 일은 효과적으로, 중요하지 않은 일은 효율적으로 한다.
• 두려움은 실재보다 크다.
• 대안이 늘 장점만 지닐 순 없다. 늘 양쪽의 장단점을 얘기한다.
• 겸손하고 자아성찰적인 자세야말로 냉철한 이성을 유지하기 위한 핵심이다.

• 모든 유저액션에 대해서는 반응이 있어야 한다.

• 프로토타이핑과 mvp를 확실히 구분해라.
  프로토타이핑은 버리는 코드를 작성한다.
  프로토타이핑은 속도가 생명이고 mvp는 제품이다.
• 누군가와 함께 하는 일이 아니더라도 중요한 일들은 스케쥴을 미리 잡아 두어야
  다른 일이 들어왔을 때 그 일을 할 수 있는지 여부를 파악할 수 있다.
• 이슈리스트를 보고 일하려고 하지 마라.
  사람은 순차적인 방식으로 사고한다.
  이슈 리스트와 태스크 리스트를 분리해야 한다.
  이슈 리스트는 문제의 성격에 따라 구분되지만,
  태스크 리스트는 우선순서에 따라 나열된다.

• 개발자의 역할은 요구사항을 충족하면서 변화에 강한 코드를 만들어 내는 것이다.
  변화에 강한 코드를 만들기 위해서는 테스트가 필수다. (Working Effectively with Legacy Code 참고)
  좋은 디자인과 클린한 코드를 가진 프로덕트도 망가지는 이유는
  테스트 코드가 없는 레거시 코드이기 때문이다.
• 결국 순수 개발(소프트웨어 기능추가, 버그수정, 개선, 최적화, 유지보수)에서 제일 중요한 역량은 유지보수다.
  왜냐하면, 기능추가, 버그수정, 개선 그리고 최적화는 모두 기존 기능을 유지하면서 행해야 하는 액션이기 때문이다.
  (Working Effectively with Legacy Code 참고)
• 네이밍은 정말정말정말정말정말정말 중요하다.
  특히, 팀 개발에서 정말정말정말정말정말정말 중요하다.
  네이밍으로 코드에 대한 이해속도가 현저히 달라진다.
• 심플한 코드가 더 어렵다.
  대개 심플한 코드는 끊임없는 개선작업(리팩토링)을 통해 완성된다.
• 유닛테스트는 개발하면서 끊임없이 확인할 수 있어야 하기 때문에 실행속도가 중요하다.
• 어느 분야든 기본이 제일 중요하다. 개발에서 기본은 컴퓨터를 이해하는 것이다.
• 깨진 창문 이론은 정말 맞다.
  깨진 코드를 하나 내버려 두기 시작하면, 다른 코드도 깨지기 시작한다.
• 리팩토링, 코드 정리는 수시로 하는 것이다.
  정리된 책상에서 더 물건을 잘 찾을 수 있듯이,
  정리된 코드에서 버그를 잘 찾아낼 수 있다.
• 코드 주석보다는 코드를 스닙펫으로 어딘가에 보관한다.
• 쉽게 이해할 수 있는 코드의 핵심은
• 네이밍
• 디자인, 구조
• 컨벤션
• 애자일은 방법이 아니라 정신이다.
  추구하는 것이고.
  계속 추구하지 않으면 언제든 무너질 수 있다.
• 유닛테스트의 목적은 '의존성을 다 없애라’가 아니라 의존성을 없앨 수 있는 것을 없애라’다.
  괜히 의존성이 있을 필요가 없는 함수에 의존성을 만드는 것을 피하라는 것
• 얼마나 도메인 지식을 잘 이해하고 있느냐가 결국,
  소프트웨어 디자인의 유연성과 깊이를 결정짓는다.
• 라이브러리나 프레임워크를 사용하기 전에 꼭 공식문서를 읽는다.
  예술작품이 그 의도와 배경을 알면 더 잘 이해하고 아름다움을 느낄 수 있듯이 코드도 똑같다.
  특히 잘 쓰여진 공식문서가 있는지 여부는 굉장히 중요한 라이브러리 선택요소.
• 구체적이면 구체적일수록 변하기 쉽다.
• 개발 트렌드에서 뒤쳐지거나 늦게 시작했다면, 트렌드한 오픈소스를 리뷰한다.
  앞에서 나아가는 것보다 따라가는 것이 더 빠르다.
• 워크어라운드(= 시스템의 철학에 위배되는 구현)는 가장 최후의 보루다.
• 클래스에서 변수와 메서드를 정렬할 때, 우선순위는 public API가 가장 먼저다.
  그 이유는 간단. 가장 중요하기 때문
• 클래스에서 public method는 신중에 신중을 기해서 디자인
• TDD(Test Driven Development)는 단순히 개발에만 적용되지 않는다.
• 애자일에서도 역시 실행보다는 기획이 더 중요하다.
  다만 기획의 단위가 작을 뿐이다.
• 만약 버그가 생겼는데 어디서 시작할 지 막막하다면,
  에러 메세지를 하나씩 지워나가는 것을 목표로 한다.
• 코드를 효과적으로 이해하려면 ‘나라면 어떻게 만들까?’를 먼저 생각한다.
• 익숙하지 않은 코드는 복붙을 지양한다.
• 버젼도 사용자에게 의미있어야 한다.

• 객체지향은 소프트웨어 디자인 측면에서 탑다운 방식이 아니라 보톰업 방식을 가능하게 한다.
• 객체지향 프로그래밍은 객체의 상호작용을 통해서 현실의 문제를 풀듯이 소프트웨어 문제를 푸는 패러다임이다.
• 객체지향 디자인 및 프로그래밍의 가장 큰 장점은 모듈화를 통해 부분적인 디자인만으로 개발을 진행할 수 있다는 점이다.

• 개발자는 책 읽듯이 오픈소스도 틈날 때마다 읽어야 할 것 같다

• "if you are NOT tested it is Hard to have confidence"
• "Whenever you feel that some situation or some person is ruining your life, it is actually you who are ruining your life…Feeling like a victim is a perfectly disastrous way to go through life. If you just take the attitude that however bad it is in any way, it’s always your fault and you just fix it as best you can — the so-called "iron prescription" — I think that really works." Charlie Munger

• All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
  어떤 예외도 없이 모든 서비스 인터페이스는 밑바닥부터 외부로 노출시킬 수 있도록 디자인되어야 한다. 즉, 팀은 무조건 외부 개발자들에게 노출시킬 수 있도록 인터페이스를 기획하고 디자인해야 한다. 예외는 없다.
• Stubborn on Vision, Flexible on Details
  비젼에 대해서는 고집스럽게, 디테일에 대해서는 유연하게.
• "If you’re not stubborn, you’ll give up on experiments too soon. And if you’re not flexible, you’ll pound your head against the wall and you won’t see a different solution to a problem you’re trying to solve."
  고집이 없으면, 실험을 너무 이른 시점에 포기할 것이다. 반대로 유연하지 않으면, 풀려는 문제에 대한 다른 답을 보지 못하고 벽에 머리만 박고 있을 것이다.
• "I don’t think that you can invent on behalf of customers unless you’re willing to think long-term, because a lot of invention doesn’t work. If you’re going to invent, it means you’re going to experiment, and if you’re going to experiment, you’re going to fail, and if you’re going to fail, you have to think long term."
  장기적인 관점에서 생각하지 않으면, 고객을 대신해서 뭔가를 발명하기 힘들 것이라고 생각한다. 왜냐하면 많은 발명이 실패할 것이기 때문. 발명하려면, 실험해야 한다는 것이고 실험할 것이면, 실패한다는 의미다. 실패할 생각이라면 장기적인 측면에서 생각해야 한다.
• I strongly believe that missionaries make better products. They care more. For a missionary, it’s not just about the business. There has to be a business, and the business has to make sense, but that’s not why you do it. You do it because you have something meaningful that motivates you.
  missionaries를 어떻게 해석해야 할 지 모르겠네요 ㅎ. 제 생각에는 '개인적인 사명감’?

• Be a Catalyst for Change
  변화의 촉매가 되라.
• You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
  사람들에게 변화를 강요할 수 없다. 대신, 미래가 어떤 모습일 지 보여주고 그 미래를 함께 만드는 것을 도와줘라.
• DRY—Don’t Repeat Yourself
  반복하지 마라.
• Refactor Early, Refactor Often
  리팩토링은 이른 시점에, 자주!
• Abstractions Live Longer than Details
  구체적인 것보다 추상적인 것이 더 오래 살아남는다.
• Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.
  구현이 아니라 추상화에 더 시간을 투자해라. 추상화는 새로운 기술과 구현에 따른 변화로부터 살아남을 수 있다.
• Don’t Live with Broken Windows
  깨진 창문 놔두지 마라.
• Fix bad designs, wrong decisions, and poor code when you see them.
  나쁜 디자인이나 잘 못된 결정, 나쁜 코드이 보이면 고쳐라.
• Fix the Problem, Not the Blame
  탓하지 말고 문제를 고쳐라.
• It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.