레이블이 책 메모인 게시물을 표시합니다. 모든 게시물 표시
레이블이 책 메모인 게시물을 표시합니다. 모든 게시물 표시

2022년 2월 1일 화요일

자바 성능 튜닝 이야기 책 메모

오랜만에 책 메모!!

꼭 자바 성능에 대한 내용이다 라기 보다는 시스템 전반적인 성능에 대해 참고해야할 내용을 설명하는 느낌이었다.
엄청 생소한 내용보다는 어디선가 나오는 '이런건 하지마라~' 를 모아놓은 느낌?!

책의 내용을 바탕으로 문제 발생 시 검색 능력이나 원인 파악을 향상 시킬 수 있을 것 같다.


시스템의 성능이 느릴 때 가장 먼저 해야하는 작업은 병목 지점을 파악하는 것이다.

...

성능 튜닝의 비법

- 하나만 보지 말아라
- 큰 놈을 없애라
- 깊게 알아야 한다
- 결과 공유는 선택이 아닌 필수


해당 챕터는 다시 볼만하다. 

  • 01_디자인 패턴 꼭 써야 한다

  • 03_왜 자꾸 String을 쓰지 말라는 거야

  • 04_어디에 담아야 하는지...

  • 06_static 제대로 한번 써 보자

  • 08_synchronized는 제대로 알고 써야 한다

  • 16_JVM은 도대체 어떻게 구동될까?

  • 17_도대체 GC는 언제 발생할까?

2021년 2월 14일 일요일

메이크 타임 책 메모

메이크 타임 메모

심심해서 읽은 책.

'매일 하이라이트를 지정하여 그 하이라이트를 방해없이 집중해서 진행하자'

하루를 메일, SNS, 미디어에 끌려다녀 하루를 만족스럽게 보내지 못한 사람들을 위한 책이다.

미라클 모닝과 뭔가 비슷한 느낌...


  • 우리가 배운 첫번 째 교훈은 우선순위가 높은 하나의 목표로 하루를 시작하면 마법 같은 무언가가 일어난다는 것이다.

    • 스프린트의 각요일에 우리는 한 가지 중요한 일에 주의를 집중했다.
  • 메이크 타임의 네 단계 프로세스

    • 하이라이트 : 초점을 선택하는 것으로 하루하루를 시작하라.

      • 물론 하이라이트가 그날 하는 유일한 일은 아니다. 하지만 그 일이 당신의 최우선이 될 것이다.
    • 초집중 : 방해꾼을 물리쳐 하이라이트를 처리할 시간을 만들어라.

    • 에너지 충전 : 뇌를 충전하기 위해 몸을 돌보아라

      • 운동, 음식, 잠, 조용한 휴식, 직접 사람을 만나 대화하며 배터리를 충전한다
    • 돌아보기 : 시스템을 조절하고 개선하라

  • 메이크 타임의 목표는 수도승이 되곘다는 맹세가 아니라 실행할 수 있고 융통성 있는 일련의 습관이다.

  • 하루가 끝날 무렵 누군가가 "오늘의 하이라이트는 뭐였나요?"라고 물어보면 뭐라고 대답하고 싶은가? 하루를 돌아봤을 때 어떤 활동이나 성취나 순간을 음미하고 싶은가? 그것이 바로 당신의 하이라이트이다.

  • 오늘 절대적으로 꼭 해야 하는 무언가가 있다면 그 일을 하이라이트로 정하라.

  • 하이라이트는 60~90분이 가장 적합하다. 의미 있는 무언가를 하기에 충분할 뿐만 아니라 스케줄에서 만들어내기에도 적당한 시간이다.

  • 복리와 비슷하다. 하이라이트에 오래 집중을 유지할수록 그 일이 더 매력적으로 느껴져 더 잘할 수 있다.

  • 막힌 채로 있어라. 포기하지 말라

    • 텅 빈 스크린을 물끄러미 바라보거나 종이에 써보거나 이리저리 걸어다니뇌 지금 하는 프로젝트에 초점을 유지하라.
    • 뇌의 조용한 부분들은 일을 진행하면서 앞으로 나아가고 있다.
    • 결국 막힌 부분이 풀릴 것이다.
  • 주말에 늦잠을 자는 것은 몸속 시계에 혼란을 주고 본래 부족하던 잠에서 회복하기가 훨씬 더 어려워질 수 있다.

    • 매일 같은 시간에 알람을 설정하라
  • 일정표를 싹 비울 필요는 없다. 특별한 무언가에 주의를 집중할 60~90분만 있으면 된다.

    • 목표는 중요한 일을 할 시간을 만들고 더 균형을 잡고 오늘을 더 즐기는 것이다.

2020년 11월 12일 목요일

미라클모닝 책 메모

 

미라클 모닝 책 메모

출근 길에 읽을 책이 없어서 방황하다가 예전에 군대에서 읽어본 것 같은 미라클 모닝책을 구매해보았다.
어찌보면 뻔한 '일찍 일어나서 하루를 시작하자' 이지만 항상 책에는 배울 점이 조금씩은 있는 것 같다.

나도 한 시간 일찍 일어나서 물 한 잔, 오늘 해야할 일 정리(trello), 가벼운 운동으로 하루를 시작해보고 있다.
나름 상쾌하게 하루가 시작된다.(물론 일찍 일어날 수 있다면...)


  • 이런 책의 목적은 고이 보존하는 게 아니라 그 책에서 뽑아낼 수 있는 가치를 극대화하는 데 있기 때문이다. 아무 때나 책을 다시 펼쳐서 전부 다 다시 읽지 않고도 핵심 내용을 금방 다시 볼 수 있도록 책들에 표시를 한다.

  • 평범함을 극복하는 법을 발견했다. 바로, 목적 있는 삶을 사는 것이다.

    • 평범함에 안주하게 되는 원인들을 물리치기 위해서는 삶의 목표가 필요하다. 마음을 움직이고 영감을 주며 매일 아침 잠에서 깨어나게 만드는 목표라면 어느 것이든 상관없다. 더 나은 삶을 살아가게 하는 목표라면 더할 나위 없다.

    • 삶의 목표는 아무 때나 바꿔도 괜찮다는 사실을 기억하자. 당신이 성장할수록 당신의 목표도 진화할 것이다. 핵심은, 어떤 목표든 간에 선택헤서 지금부터 목표에 맞춰 살아가는 것이다.

    • 지금부터 일주일 동안 삶의 목표에 대해 생각해보고, 명확하게 그려보자. 그리고 매일 확인할 수 있도록 잘 보이는 곳에 적어두자.

  • 긍정적이고 진취적인 사람들과 많은 시간을 보낸다면 성공을 부르는 그들의 태도와 습관이 당신에게 흡수될 것이다.

  • 당신을 믿고 존중하며, 목표지점까지 삶을 이끌어주는 사람들 찾아야 한다. 그런 사람은 우연히 당신 앞에 나타나지 않는다. 영향력 집단을 강화하는 사람을 적극적으로 찾아야 한다.

  • 지금까지 한 번도 성취하지 못했던 성공을 거두기 위해서 지금까지 한 번도 해보지 않았던 노력을 기꺼이 할 준비가 되어 있어야 한다.

  • 미라클 모닝의 여러 의도 중 하나는 생생한 에너지로 가득했던 아침의 기억을 되찾아주는 것이다. 그리고 그 기억을 삶 전체로 확대 시키는 것이다. 일어나야 하기 때문에 잠에서 꺠는 게 아니라 목표를 가지고 침대를 박차고 나오게 하는 것이다.

  • 책을 한 번만 읽고 그 책에서 얻을 수 있는 모든 가치를 내 것으로 만들기는 어렵다. 어느 분야든 통달하기 위해서는 반복이 요구된다. 어떤 아이디어나 전략, 혹은 기술도 마찬가지로 그것에 계속 반복해서 노출해야만 그것들이 잠재의식에 새겨질 수 있다.

  • 나만의 미라클 모닝을 시작하며 머리로만 생각했던 아이디어를 꺼내어 일기장에 옮겨 적는다. 이를 통해 생각만 했을 때에는 절대로 알 수 없었던 통찰력을 얻게 된다. 기록하기는 새로운 아이디어와 당면한 문재의 돌파구, 새로운 깨달음이나 교훈, 성장과 발전의 발자취를 미래에 다시 한 번 확인할 수 있도록 기억을 저장하는 역할을 한다.

2020년 9월 6일 일요일

개인의 시대가 온다 책 메모

 

개인의 시대가 온다 책 메모

퇴사 예정인 혹은 퇴사를 생각하는 사람들에게 해주는 경험 공유 느낌 책이다.
책 광고를 보고 끌려서 보게 되었다. 자신의 퇴사 후 비즈니스 경험을 소개하는 책이었고 회사에 있을 때 챙겨야할 것들 중요하게 유지해야하는 것들을 소개해준다.
거의 퇴사 후 자신의 비즈니스를 키우면서 필요한 내용같았고 책의 모든 내용이 와닿진 않았지만, 나름 가볍게 볼만했다.


  • <타임>이 예측했던 진정한 '개인의 시대'는 각자가 개인의 중요성을 꺠닫고, 스스로를 내세워면서 살아가고자 하는 가치가 만발하는 시대, 바로 '지금'이라고 생각한다.

  • 정규직보다 더 위에 있는 비정규직, '슈퍼 비정규직'의 탄생이며 바로 이것이 '프리랜서 이코노미'를 이끌어 가고 있다. 이러한 경제구조에서는 개인이 곧 회사가 된다.

  • 미래의 경제와 기업은 프로젝트의 단위에 따라서 사람을 고용하고, 그 프로젝트가 끝나면 팀은 해체된다.

  • '끊임없이 변하는 세상'에서 '고정적인 인건비'를 사용하는 일은 기업 입장에서 과도한 비용만 나가는 일이다. 그럴 바에야 차라리 외부의 전문 인력을 필요한 기간만 쓰는 것이 훨씬 더 장점이 많다.

  • 자발적인 비정규직이 늘어나는 이유를 좀 더 현식적인 이유에서 찾아보자. 그것은 바로 세계 경제의 구조가 그렇게 변하고 있기 떄문이다. 가장 큰 두 가지의 이유는 '새로운 기술' 과 '자본주의'의 본질적인 속성 때문이다.

  • 지금 시장이 어디로 향하고 있는지, 그 시장 안에서 무엇이 중요하게 여겨지는지를 반드시 따져보아야 한다. 그 안에서 자신만의 영역을 찾을 수 있다면, 새로운 시대와 함께 승승장구할 수 있는 비즈니스를 펼쳐나갈 수 있기 때문이다. 이것을 빅웨이브라고 표현하고 싶다.

  • 사업이 성공하려면 누군가가 소비를 해주어야 한다. 그리고 이 소비의 기준은 이제껏 우리가 알고 있는 가격이나 제품의 퀄리티 등으로 통칭되는 '경쟁력'이다. 가성비라는 말도 결국 이러한 경쟁력을 지칭하는 말이다.

  • 과거에는 제품 그 자체를 보거나 혹은 브랜드를 보고 제품을 구매했다면, 이제 새로운 세대의 소비는 제품이 가지고 있는 '가치'를 본다는 의미이다.

  • 가치를 중심으로하는 이러한 시장 질서는 '소비에서의 개인의 시대'가 왔다는 사실을 잘 보여준다. 가치란 결국 개인의 신념이고 철학이다. 과거의 소비 과정에서는 이런 개인의 신념과 철학이 끼어 들어갈 틈이 없었다. 하지만 이제는 소비에서도 개인의 모습이 전면적으로 드러나고 있다.

  • '가치'란 양쪽 면에서 파도치듯 다가오는 빅 웨이브다. 비즈니스의 방향성을 물론이고, 그것을 함께하는 사람들 사이에서도 더할 수 없는 중요성을 가지고 있다. 모든 일의 출발점에서 가치를 점검하고, 함꼐 일하기 전에 조직 내의 가치를 다지는 것. 바로 이것이 '가치 중심의 소비'라는 새로운 트랜드를 반영하는 일이다.

  • 개인의 시대가 우리에게 과거보다 훨씬 많은 자유와 힘을 주었지만, 그 힘이 '누구에게나' 주어지지는 않는다.

    • 개인의 시대가 주는 자유와 힘을 누리고자 한다면 그만큼 더 많은 노력을 기울여야 한다.
  • 환경이 제한하는 인식에서 벗어나라

    • 자신이 처한 환경은 자신의 인식을 제한한다.
    • 비록 내가 지금 직장인이라고 하더라도, 얼마든지 다양한 분야에 진출할 수 있고, 또 얼마든지 위아래의 직급을 오갈수 있다고 가정해야만 한다.
  • '해보지 않았으니까 모른다'는 것은 곧 '해보면 알 수 있다'는 새로운 가능성에 대한 메시지를 준다. 그런 점에서 이것은 자신 앞에 있는 벽을 문으로 바꾸는 열쇠다.

  • 우리가 죽을 때까지 새로운 것을 배우듯, 죽을 때까지 나 자신을 테스트하는 것을 멈춰선 안된다. 언제나 세상은 변하고, 예상이 불가능하고, 또 새로운 것이 등장하기 떄문이다.

  • 자신의 능력을 발휘해 일을 열심히 하고 싶다면 오히려 직업 자체는 많아져야 한다. 주변 영역으로 계속해서 확장해나가면서 새로운 분야를 습득해 나가는 것이기 때문이다.

    • 원소스 멀티 유저 : 하나의 콘텐츠를 개발해 그것을 기반으로 여러 분야에 활용하여 파급효과를 노리는 마케팅 전략
  • 회사에서 할 수 있는 것은 다 해볼 필요가 있다. 한히 말하는 '라인'도 타보고, '파벌싸움'도 해보자. 상사의 눈치를 보면서 기분을 맞추는 스킬도 체득하자. 회사에서 할 수 있는 것은 다 해볼 필요가 있다.

  • 누군가에게는 회사는 어떻게든 일을 줄이면서 아등바등 월급을 받는 공간이자 미래의 퇴사가 두려워 눈치를 보는 곳이다. 하지만 어떤 이에게는 회사는 자기계발을 위한 훌륭한 인재개발원이 되기도한다. 또한 그 안에서 최대한 성과를 내면서 회사와 윈윈의 관계를 만들어낼 수도 있다.

  • 자신의 멘토를 경쟁자로 삼는 것도 하나의 방법이다. '나는 언제쯤 저 사람을 따라갈 수 있을까?' 라는 존경의 시선을 자신에게 투영하먄, 자신에 대한 엄격한 기준을 세울 수도 있다.

  • 어떻게 보면 도태는 환경의 변화에 의한 것이라기보다 자기 스스로 만든 틀 안에 갇힐 때 발생한다.

  • 물건이나 서비스가 만들어지는 그 모든 프로세스에 대한 충분한 이해가 있어야한다. 이것은 특정 분야에 대한 지식을 통해 퇴사 이후 자신만의 전문적인 영역을 만들어가는 데에도 매우 중요하다.

  • 기획력은 흔히 '어떤 대상에 대한 목표를 설정하고, 그것을 이뤄내기 위해 가장 적합하고 효율적인 행동을 설계하는 것'을 의미한다.

  • 기획력을 높이는 수많은 방법이 있지만, 현장에서 일하며 느낀 중요한 한 가지는 '질문을 잘해야 한다'는 점이다.

    • 질문은 새로운 관점을 자극하는 훌륭한 방법이다. 늘 해오던 행동이라도 여기에 질문을 던지는 순간, 주위가 환기되고 다른 식으로 사고하게 된다.
    • 질문은 주어진 현상의 핵심과 본질로 접근할 수 있도록 도와준다.
  • 일이라는 것은 최종적으로 누군가의 평가를 받는 일이다. 그래서 모든 것을 다 완성한 뒤에 내놓는 것이 아니라 처음에는 전체의 레이아웃을 보여주면서 의향을 물어보고 ,그 다음에는 조금 더 디테일을 보이면서 최종적으로 일의 끝을 향해 가는 방식이다.

  • 넷플릭스의 가이드 (자유와 책임의 조직문화에 대한 가이드)

    • 어지간한 성과를 내는 사람들이라면 퇴직금을 많이 주면서 내보낸다.
    • 넷플릭스는 성과가 중심이다. 성과를 잃어버리는 순간, 모든 것은 수포로 돌아가고 만다. 그래서 탁월하지 않으면 퇴직금을 줘서라도 내보낸다. 추상적인 슬로건을 내세우는 것은 아무런 의미도 없다.
    • 회사에서의 진짜 가치는 그럴듯해 보이는 구호가 아닌, 누가 보상받고, 승진하고, 해고되는지로 나타난다.
    • 우리는 가족이 아니고 팀이다.
  • 충분한 정보의 전달과 정확한 일의 배분, 그리고 전체 팀의 지행을 골고루 알려주는 것이 바로 '맥락 속에서의 이해'이다.

  • '레드오션 안의 블루오션'이라는 관점을 가질 필요가 있다. 뭉뚱그려서 '거기는 레드오션이다.'라고 생각하지 말고, 그 안에 비어 있는 부분을 찾아낼 필요가 있다.

  • '1분짜리 자기소개','5분','10분'를 모두 준비해야 한다. 기회가 왔을 때 단 한순간도 주저함 없이 자신에 대해 제한된 시간 안에 줄줄 말할 수 있을 정도가 되어야 한다.

  • 만약 상대방이 나에 대해서 부정적으로 느끼게 되면 매력도가 현저하게 떨어지게 되고 함께 일하고 싶은 마음의 문이 닫힐 수 있다.

    • 상대방을 소비하는 사람이 되지 말아야한다.
    • 부정적인 기운을 내뿜는 사람이 되어서는 안된다.
    • 사심이 없는 사람이 되어야한다. 대화를 하다 보면 매사에 계산적이고 늘 자신의 욕망을 불어넣는 사람이 있다.
    • 상대방의 문제에 솔루션을 제공해주려는 마음 자세를 갖는
  • 아무리 열심히 일을 해도 일을 되게 만들지 않으면 소용이 없다. 일을 되게 한다는 것은 목표한 바를 전진하는 동력이다. 힘을 가해져야 목표를 향해 굴러간다. 그런 점에서 '지금 내가 하는 일이 목표를 향해 굴러가게 만드는 일인가?'를 계속 되돌아봐야한다.

  • 기존의 관습에서 벗어나 일이 다른 경로로 성공을 향해 도약하게 만드는 것, 바로 이것이 '일을 되게 하는 것'이라고 할 수 있다.

  • 독립 사업자를 꿈꾼다면, 돈과 노동에 대한 이러한 일반적인 관점을 해체해야 할 필요가 있다. 심지어 돈이 안되는 일도 해야 하는 것이 새로운 세계에서 필요한 관점이다.

  • 협업의 시대에서 협업의 정의의 대해 '자신의 생각과 노력을 집단의 뇌에 녹여 혼자 일할 때보다 더 나은 결과를 낳으려는 의지와 능력'이라고 했다.

  • 흔히 우리의 전통 문화인 품앗이를 '서로 힙을 합치는 것'이라고 보지만, 어떤 의미에서는 '최적의 타이밍을 놓치지 않으려는 집단행동'일 수도 있다. 사업도 결국 타이밍 싸움이다. 타임의 힘과 자원을 집중적으로 끌여들여 단시간에 작업을 끝내면 타이밍을 놓치지 않게 된다.

  • 나쁜 사람으로 인해 자꾸만 부정적인 영향을 받으면, 결국 그것이 나를 통해 좋은 사람에게도 영향을 미치기 때문이다. 결국, 힘빼기를 통해 최대한 관계를 해결하기 위해 노력하지만, 그것이 한계에 봉착했을 때는 남아 있는 더 좋은 사람들을 위해서 관계를 포기하는 결단도 내려야 한다.

  • 진정한 리더쉽 이론에서는 자신의 실수와 약점, 나약함을 솔직하게 인정할 때 지도자와 추종자 간에 훨씬 밀접한 관계가 형성된다.

  • 대게 상대에게 더 주는 4:6정도가 되어야 비로소 상대는 5:5로 받아들이곤 한다. 이는 기본적으로 인간의 삼라애 존재하는 '호혜성'에서 기인한다. 끊임없이 뭔가를 주고받아야 상대와 내가 동시에 성장하고 발전하게 된다. 그리고 이 호혜성의 무게 중심이 내가 아닌 상대방에게 주어질 때 관계는 좀 더 빠르게 발전해나갈 수 있다.

  • 우리가 정말 추구해야할 것은 '남들의 시선'이 아니라 얼마나 진짜 나를 단단하게 만들어나갈 수 있느냐이다.

2020년 7월 8일 수요일

학교에서 알려주지 않는 17가지 실무기술 책 메모

학교에서 알려주지 않는 17가지 실무기술 책 메모

  • 해커와 화가라는 책을 읽다가 너~무 재미없어서 책을 변경했다. (너무 옛날 이야기같기도 하고, 지루했다.) 
    벌써 6권째 전자책 완독이다! 리디북스 베스트 셀러에 보이길래 목차보고 흥미로워서 구매했다. 
    책 제목처럼 정말 학교에서는 배우지 않은 내용들이지만 업무하면서 어디선가 필요한 내용이었다. 나같은 기초가 부족한 주니어 개발자 혹은 취준생이 읽으면 아주 좋을 것 같다. 

    물론 책에서 해당 내용에 대해 깊게 설명하진 않지만, 해당 기술이 어디서 필요한지, 실무에선 어떻게 사용하는 것이 좋을지, 심화적으로 공부해보면 좋을 것을 소개해주고 있어 가볍게 보기 좋은 것 같다. 
    파이썬을 통해 예제 또한 제공하여 이해를 돕고있다. 
    특히 HTTPS, OAuth 부분은 직접 깊게 찾아보지 않는 이상 잘 정리된 내용을 접하기 힘든데, 쉽고 빠르게 설명해주어서 흥미롭게 읽었다!!

  • 문자열 인코딩

    • UTF - 8

      • 오늘날 가장 많이 사용하는 문자열 인코딩(최소 1바이트, 최대 6바이트, 대부분 4바이트 이내로 처리)
      • 아스키 코드와 호환 가능
      • JSON은 UTF-8 인코딩만 사용한다.
    • MySQL에서 UTF-8과 완벽히 호환되는 문자 집합을 쓰고 싶다면 utf8mb4를 써야한다.

  • 날짜와 시간

    • 서버 개발자라면 ETCD나 주키퍼를 사용해보는 것도 좋다.
  • 정규표현식

    • 특수문자를 찾을 때는 프로그래밍 언어가 한 번, 정규식 표현식이 한 번 문자를 이스케이프해서 해석할 수 있도록 역슬래시 두 개를 사용해야 한다.
    • 정규표현식 검사로 인해 처리속도가 늦어질 수 있다. 성능을 생각한다면 parser 라이브러리를 사용하는 것이 좋다.
  • 범용 고유 식별자

    • UUID는 충돌 가능성이 낮아서 범용적인 고유 식별자로 사용하기 좋다. 하지만 16바이트나 필요하고 UUID만으로는 정보를 식별하기 어렵다.
  • 해시 함수

    • 해시 함수는 임의의 입력값을 고정된 길이의 해시 값으로 변환하는 함수다.

    • 암호학적으로 안전한 해시 함수는 다음의 조건들을 만족해야한다.

      • 해시 값으로 입력 값을 복원하는 방법이 불가능해야 한다.
      • 서로 다른 입력값으로 같거나 비슷한 해시 값을 찾는 방법이 불가능해야 한다.
    • 대규모 사용자를 기반으로 한 서비스를 개발할 때는 SHA-2 해시 함수를 사용하는 대신 멀티 코어를 사용할 수 있는 Blake2b 해시 함수를 사용해야 한다. (SHA-256 또는 SHA-512 해시함수는 비밀번호와 같은 민감한 데이터를 안전하게 저장할 수 있으나, 해시 값을 계산하는 비용이 매우 크다)

    • 거의 모든 경우 클라이언트에서 평문으로 된 비밀번호를 보내고, 서버에서 가능한 빨리 해시 값으로 변환한 후 사용하는 게 이상적이다. 평문으로 된 비밀번호가 유출되는 상황은 높은 수준의 암호화 방식을 적용한 HTTPS를 사용하는 것으로 쉽게 방지할 수 있다.

  • JSON

    • JSON은 숫자, 문자, 참 또는 거짓 등 여러 형태 데이터를 키와 값으로 구조화 된 객체에 담아 처리하는 규격이다.
    • JSON 메시지가 예측할 수 없는 외부 (사용자 입력, HTML 폼요청 등)로부터 온 데이터인 경우에는 앞서 본 예제 코드와 같이 읽기 전에 키가 존재하는지 검사하는 게 좋다.
    • JSON 객체와 배열을 읽을 때는 객체 내부 또는 배열 요소가 정렬됐다는 가정을 하지 않는게 좋다.
    • 실무환경에서 JSON 메시지를 만들 때 null을 사용하지 않는 게 좋다. (그 키가 어떤 데이터를 담고있는지 알수 없다)
    • JSON 규격의 데이터는 읽기 쉽지만, 텍스트 기반이기 때문에 데이터를 표현하는데 비용이 크다는 단점이 있다.
  • YAML

    • JSON과 비슷하지만 YAML만의 고유한 특징으로 차세대 설정 파일 표준 규격으로 영역을 넓히고 있음
    • 주석지원, 앵커, 별칭 기능
    • 앵커는 & 으로 시작하는 식별자, 별칭은 * 로 시작하는 식별자
    • YAML은 텍스트 기반 데이터 규격으로 읽기 쉬우면서 중괄호나 큰 따옴표를 사용하지 않음. 바이너리 규격에 비해 비효적임
  • XML

    • 웹에서 규격화된 데이터를 효율적으로 주고받기 위해 만든 마크업 언어
    • 데이터 직렬화를 위한 규격이 필요하고 반드시 xml을 써야할 이유가 없다면 JSON 또는 바이너리 기반 프로토콜 버퍼를 고려할 것.
    • 애플리케이션 설정 파일을 만들기 위한 규격이 필요하면 YAML을 고려할 것
  • 프로토콜 버퍼

    • 구글에서 만든 데이터 직렬화 규격
    • 바이너리 기반 규격이기 때문에 더 빠르고 효율적으로 데이터 가공, 처리 가능
    • 메시지를 받은 소프트웨어도 데이터를 가공하고 보낸 곳과 같은 메시지 규격을 사용해야만 메시지 복원, 읽기 가능
    • 인터페이스 코드 : 컴파일러가 스키마를 읽어 만들어낸 결과물. 모든 프로그램은 이 코드를 통해서만 데이터 직렬화/역직렬화 가능
    • 프로토콜 버퍼는 메시지만 정의하면 검증, 누락과 관련된 인터페이스를 자동으로 생성하기 때문에 관리의 필요성이 줄어든다. 메시지 크기도 작고 빠름.
  • Base64

    • 바이너리 데이터를 아스키 코드 일부와 일대일로 매칭되는 문자열. 단순 치환하는 인코딩 방식
    • 바이너리 데이터를 문자열 기반 데이터로 취급할 수 있어 많은 곳에서 사용됨.
    • Base64는 XML, JSON, RESTfull API 처럼 문자열을 기반으로 데이터를 주고 받는 환경에서 바이너리 데이터를 취급할 떄 사용.
    • HTTP로 큰 파일을 보내야한다면 HTTP 멀티파트 기능을 살펴보는 게 도움이 된다.
  • zlib

    • zip파일을 압축할 때는 DEFLATE 알고리즘 사용 (INFLATE는 압축 해제)
    • 데이터 크기가 가변적인 환경에서는 모든 데이터를 압축하지 않는 게 좋다.
    • 웹 서비스의 경우 브라우저가 DEFLATE를 지원하지 않을 수 있음. 일반적으로 Nginx와 같은 서버가 알아서 처리하겠지만 웹소켓, HTTP 서버에서 항상 DEFLATE를 사용하지 않게 설정해두는 것이 좋다.
  • HTTP

    • 서버와 클라이언트가 텍스트, 이미지, 동영상 등의 데이터를 주고 받을 때 사용하는 프로토콜
    • 데이터를 안전하게 주고받기 위해 HTTP에 전송계층보안 TLS을 더해 만든 HTTPS를 사용함.
    • HTTP는 요청 메시지를 보내기 직전까지 대상 컴퓨터가 연결 가능한지 메시지를 응답할 수 있는 상태인지 알 수 없다.(stateless 프로토콜)
    • TCP는 HTTP 보다 빠르지만 연결상태를 직접 관리해야해서 로직이 복잡함. (TCP는 실시간 멀티플레이 게임이나, 금융서비스처럼 메시지 처리시간이 로직 처리보다 오래걸리는 경우에만 사용하는 것이 좋음)
    • HTTP요청
      • GET : 웹 브라우저가 서버에 웹 페이지를 요청할 때 사용
      • POST : 클라이언트에서 서버로 데이터가 포함된 요청을 보낼 때 사용
      • DELETE, PUT : DELETE는 데이터 삭제, PUT은 이미 존재하는 데이터의 업데이트 요청을 의미하며 기술적으로는 POST와 큰 차이는 없다.
    • URL과 달리 URI는 특정 문서, 영상 등과 같은 자원의 위치를 가리킬 때 사용하는 용어임. (XML에서도 사용)
    • 로드밸런스 서비스는 사용자가 접속했을 때 부하가 가장 적은 웹 서버로 연결해주고 동작하지 않는 서버를 발견하면 서버 목록에서 자동으로 제외됨.
    • 스티키 세션 : 하나의 브라우저는 하나의 웹 서버에만 연결하게 됨
    • 교차 출처 리소스 공유(CORS) : HTTP 서버의 웹 페이지, 이미지 파일이나 API 등을 특정 호스트로 접속한 웹 브라우저만 사용할 수 있게 제현하는 정책
      • 동일 출처 정책 : 사전에 정의하지 않은 다른 곳에서 웹 페이지, API와 같은 리소스 요청을 차단하는 방어 장치 (다른 웹사이트에서 이미지, 동영상과 같은 리소스를 무단으로 가져가는 상황을 방지할 수 있음 - 다른 도메인간 리소스 공유가 필요한 경우 있기 때문에 CORS가 생김)
    • 웹서버는 요청 처리 외에도 정적 파일 캐시, 로드 밸런스, 압축 및 보안 기능 등 고려해야할 것이 많음
      • HTTP 표준에서 정의하는 기능을 바로 사용할 수있는 웹서버 소프트웨어가 있음
      • Nginx : 아파치 보다 뛰어난 성능과 가벼운 구조로 인기를 끌고 있다.
      • Nginx는 단일 스레드와 이벤트 기반으로 동작하고, 아파치보다 많은 사용자를 처리할 수 있다. (사용 권장)
    • 비동기 통신을 지원하는 표준은 HTTP 2.0과 웹소켓이 있음. HTTP 2.0은 하나의 요청에 대한 응답을 병렬로 보내는 데 초점. 웹소켓은 웹상에서 TCP처럼 데이터를 양방향으로 주고받음
  • RESTful API

    • 서버와 클라이언트가 메시지를 주고 받을 때 가장 많이 사용하는 통신 규격
    • 요청 주소와 메서드(GET,POST 등) JSON 규격을 이용하여 API를 정의하고 읽기 쉬운 형태임
    • 정해진 표준이나 규격이 없기 때문에 커뮤니티나 기업에서 제공하는 관례를 따르자.
    • API를 사용하는 입장에서 호환성을 고려할 수있도록 API 버전을 명시하자.
    • 대상을 어떻게 할 것인지는 메서드로 결정하자. (POST, PUT, PATCH, DELETE 등) (객체의 행동을 요청 주소에 정의하면 메서드 역할이 축소된다. 좋은 디자인이라고 볼 수 없음)
    • GET은 HTTP 표준에 따라 메시지 바디를 사용할 수 없는데, RESTful API에서 요청 주소 경로에 식별자를 넣는 것이 관례이다
    • 조회 시 단일 객체, 복수 객체 조회를 구분하지 않고 같은 형식으로 응답 메시지를 구성하면 API를 만드는 입장, 사용하는 입장 모두 유지보수가 쉬워진디. (재사용 가능)
    • API를 만들 때는 인수받는 방법 과 응답 규격을 최대한 일관성 있게 만들어 모두 재사용이 쉽게 하자
  • HTTPS

    • 안전하게 메시지를 주고 받기 위해 만든 프로토콜. TLS 프로토콜 기반으로 하는 HTTP
    • TLS이 등장하기 전까진 보안 소켓 계층 SSL 을 사용했음. SSL은 많은 취약점으로 더 이상 사용하지 않지만, SSL의 이름을 계속 사용중임
    • HTTPS를 사용하면 서버와 클라이언트가 주고 받는 메시지를 암호화한다. 메시지를 암호화 복호화하는 키는 HTTPS로 메시지를 주고 받는 두 컴퓨터만 안다.
    • HTTPS는 TLS를 기반으로하여 TLS버전에 따라 사용가능한 암호화 목록과 안정성이 달라진다.
    • HTTPS 통신을 하기 위해서는 반드시 인증서가 필요함.
      • 클라이언트는 키를 교환하기 전에 이 서버가 신뢰할 수 있는 서버인지 검증하는 작업이 필요한데, 클라이언트는 이 과정에서 서버가 보내는 인증서를 통해 검증함.
    • HTTPS를 소프트웨어 프레임워크에서 설정하는 것보다 Nginx나 아파치와 같은 웹서버에서 설정하는것이 안전함.
  • OAuth 2.0

    • OAuth는 데이터를 간편하고 안전하게 주고받기 위해 만들어진 표준.
    • ID와 비밀번호 대신 엑세스 토큰 기반으로 사용자 식별. 토큰은 API를 제공하는 리소스 서버만 발급.
    • 엑세스 토큰을 요청할 때 가능하면 유효 기간을 짧게 설정하고 자주 갱신하는 게 좋음.
    • 엑세스 토큰으로 RESTful API를 사용할 때는 반드시 HTTPS를 사용하는 지 확인해야 보안 위협을 방지할 수 있다.
    • JSON Web Token(JWT)을 사용하면 인가 서버를 통해 토큰을 검증하는 대신 인가 정보를 포함해 사용하기 때문에 인가 서버의 부하를 줄일 수 있음.

2020년 5월 8일 금요일

일 잘하는 사람은 단순하게 합니다 책 메모

일 잘하는 사람은 단순하게 합니다

쉬어가는 책으로 출근 중 지하철에서 간단하게 읽은 책이다. 
책에서는 기획, 보고서, 언어소통, 관계 의 네 가지 영역에서 일 잘하는 방법에 대해 설명하고 있다. 
현재 내가 하고있는 것과는 관련이 없을 수 있지만 분명 도움이 되는 내용이었고, 나중에 활용할 수 있는 내용도 많았다. 
특히 무엇인가를 보고해야할 때나 설명할 때 횡설수설하는 경우가 많았는데, 이 책의 내용을 읽고 내가 했던 말들을 되돌아보는 계기가 되었다.


  • 생각하는 대로 살지 않으면, 사는 대로 생각하게 된디.

  • 기획자는 다음의 세 가지에 꼭 대답할 수 있어야한다.

    • 목표는 무엇인가?
    • 목표를 가로막는 진짜 문제는 무엇인가?
    • 문제를 해결하고 ,원하는 미래를 달성하기 위해 할 수 있는 실현 가능한 최적의 행동은 무엇인가?
  • 단순하게 일하는 사람은 화려한 현황보다는 무엇을, 왜 해야 하는지를 분명히 보여준다.

    • 탄탄한 기획안도 회사 방향과 맞지 않으면 무용지물이다.
  • 일 잘하는 사람은 상대방이 궁금해 하는 내용과 자기가 이야기하고 싶은 내용을 가능한 한 짧게 말하는데 선수입니다.

  • 무엇을 하려고 하는지, 보고서의 핵심은 무엇인지, 무슨 얘기를 하는지, 30초 안에 깔끔히게 설명할 수 있는 습관을 길러야 한다.

  • 기획이란 어떤 대상에 대해 그 대상의 변화를 가져올 목적을 확인하고, 그 목적을 성취하는 데에 가장 적합한 행동을 설계하는 것을 의미한다.

    • 모든 기획은 '왜'부터 시작해야한다.
  • SWOP이나 4P 등의 프레임워크는 고민 과정에서 활용하되 직접적인 언급은 지양하는 것이 좋다.

  • 덩어리를 묶을 때 각 항목끼리는 독립적이어야하고, 항목을 합치면 전체가 되야한다.

  • 좁쌀 서 말 굴리는 것보다 호박 한 개 굴리는 게 낫다

    • 굵직한 기획을 진행해야한다
  • 정보의 홍수 속에서 단순하게 글을 쓰려면 '왜 쓰는지' 처음부터 알고 써야 덜 고생스럽다.

  • 하고 싶은 얘기가 아니라, 듣고 싶어할 얘기를 쓰자

  • 작성자의 설명을 들어야 이해되는 보고서는 실패다.

    • 전체 요약 박스와 소제목별 요약 한 줄은 아무리 심오한 보고서라도 직관적으로 이해할 수 있게 한다.
  • 메시지를 위한 글쓰기에서는 하나의 핵심 키워드를 찾는 일이 관건이다.

    • 스토리들은 모두 핵심 키워드를 향하고 있어야 한다.
  • 모든 사람에게 똑같은 의미를 가진 단어는 없다.

  • '중간보고'는 서로의 의도와 방향을 조절하는 기술이다.

    • 중간보고는 필요하다. 그래야 오해가 있더라도 다시 방향을 맞출 수 있다.
  • 지시할 때 가능한 한 정확하게 설명해주자. 지시하는 사람이 5분 더 쓰면, 실행하는 사람은 하루 이상의 시간을 절약할 수 있다.

  • 두괄식으로 시작해서 30초안에 하고 싶은 얘기를 모두 끝내야한다.

  • A를 물어보면 정확히 A를 대답하자. 비슷한 대답말고.

  • 회사의 공식적인 커뮤니케이션에서는 '매우, 곧, 상당히, 최선을 다해, 심각하게, 신중히' 유의 언어는 쓰지 않는 게 좋다.

    • 오해만 불러일으킬 수 있다.
  • 숫자에 해석을 함께 곁들이면 단순하고 강력한 메시지가 된다.

  • 직장에서 최고의 평판 관리는 '상사를 승진시키는 사람'이다.

  • 생각을 끄고 켜는 연습은 내가 현재에 살도록 도와준다.

2020년 3월 8일 일요일

클린 코드 책 메모

클린코드

취업 전 도서관에서 클린코드를 빌려서 읽어본적이 있었다. 물론 2장 중간에 포기하고 반납을 했었다.
그때는 무슨 소리를 하는 지 이 책은 왜이리 어려운 책인가 하고 바로 반납을 해버렸지만....
이번엔 3일만에 읽어버렸다. (물론 저자가 직접 리팩토링하면서 설명하는 부분은 좀 빠르게 읽었다)
작년에 회사 업무시간 전 차곡차곡 읽을 생각으로 산 이후로 방치되었었는데, 이번주에는 조금 시간이 넉넉하여 업무시간을 활용하였다.
지금 읽어보니 정말 쉽게 설명되어있고, 기본적으로 코드를 짤 때 필요한 내용이어서 너무 재미있게 읽었다.
왜 우아한형제 기술블로그에서 이 책의 제목이 자주 언급되는 지에 대해서 조금은 알 것 같았다.
반성도 많이하게 되고, 머리에 꽂히는 것도 많은 책이다.
꼭 다시 한번 더 읽으리라~~~ (입사,이직 전 한번 읽으면 엄청 좋을 듯!!)
이 책을 모두 정리한다는 것은 어려울 것 같다. 모든 내용이 중요해보였고, 나에게 필요해 보인다.
밑의 내용은 그냥 읽으면서 체크한 내용을 메모한 것이다.

1장 깨끗한 코드

  • 자신이 짠 쓰레기 코드를 보고 나중에 정리하겠다고 다짐하지만, 나중은 결코 오지 않는다.
  • 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

2장 의미있는 이름

  • 의도가 분명하게 이름을 지으라

3장 함수

  • 작게 만들어라!
  • 함수는 한 가지를 해야한다.
  • 인수를 줄이자
  • 부수효과를 일으키지 마라!
  • 반복하지 마라
  • 함수를 작게 만든담녀 간혹 return, break, continue를 여러 차례 사용해도 괜찮다. 오히로 때로는 단일 입/출구 규칙보다 의도를 표현하기 쉬워진다. 반면 goto문은 큰 함수에서만 의미가 있으므로, 작은 함수에서는 피해야만 한다.
  • 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 먼서 생각을 기록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다.

4장 주석

  • 코드로 의도를 표현하라 : 코드로 대다수의 의도를 표현할 수 있다. 많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다.

5장 형식 맞추기

  • 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장설에 계속 영향을 미친다.
  • 변수는 사용하는 위치에 최대한 가까이 선언한다.

6장 객체와 자료구조

  • 디미터 법칙 : 모듈은 자신이 조작하는 개체의 속사정을 몰라야 한다. 객체는 조회 함수로 내부 구조를 공개하면 안된다.
  • 시스템을 구현할 떼, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적절하다. 다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료구조와 절차적인 코드가 더 적합하다. 우수한 소프트웨어 개발자는 편견없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.

7장 오류 처리

  • null을 반환하지 마라 : null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. 누구 하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모르다.

8장 경계

  • 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자. 새로운 클래스로 경계를 감싸거나 아니면 ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자. 어느 방법이든 코드 가독성이 높아지며, 경계 인터페이스를 사용하는 일관성도 높아지며, 외부 패키지가 변했을 때 변경할 코드도 줄어든다.

9장 단위 테스트

  • 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
  • F.I.R.S.T : 꺠끗한 테스트는 다음 다섯가지 규칙을 따른다.
    • Fast 빠르게 : 테스트는 빨리 돌아야한다.
    • Independent 독립적으로 : 각 테스트는 서로 의존하면 안된다.
    • Repeatable 반복가능하게 : 테스트는 어떤 환경에서도 반복 가능해야한다.
    • Self-Validating 자가검증하는 : 테스트는 성공아니면 실패라고 결과를 내야한다. (성공여부루를 알려고 로그를 읽게 만들어선 안된다.)
    • Timely 적시에 : 테스트는 적시에 작성해야한다.

10장 클래스

  • 클래스 체계 : 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다. static public 상수가 있다면 맨 처음에 나온다. 다음으로 정적 private 변수가 나오며, 이어서 비공개 인스턴스 변수가 나온다. 변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그래램은 신문기사처럼 읽힌다.
  • 단일 책임 원칙(SRP) : 클래스는 책임, 즉 변경할 이유가 하나여야 한다.
  • 규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡합하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. 그래야 변경을 가할 때 직접 영향이 미치는 컴포넌트만 이해해도 충분하다.
  • 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.
  • 시스템의 결합도를 낮추면 유연성과 재사용성도 더 높아진다. 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다.

11장 시스템

  • 의존성 주입 : 사용과 제작을 분리하는 강력한 메커니즘. 의존성 주입은 제어의 역전 기법을 의존성관리에 적용한 메커니즘이다. 제어 역전에서는 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다. 새로운 객체는 넘겨받은 책임만 맡으므로 딘일 첵임 원칙을 지키게 된다. 의존성 관리 맥락에서는 객체는 의존성 자체를 인스턴스로 만드는 책임을 지지 않는다. 대신에 이런 책임을 다른 '전담' 메커니즘에 넘겨야만 한다. 그렇게 함으로 써 제어를 역전한다.
  • AOP에서 관점이라는 모듈 구성 개념은 "특정 관심사를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야한다" 라고 명시한다. 프로그래머는 영속석으로 저장할 객체와 속성을 선언한 후 영속성 책임을 영속성 프레임워크에 위임한다. 그러면 AOP 프레임워크는 대상 코드에 영향을 미치지 않는 상태로 동작방식을 변경한다.
  • 프로그래머는 설정파일이나 API를 사용해 피룻적인 애플리케이션 기반구조를 구현한다. 여기에는 영속성, 트랜잭션, 보안, 캐시, 장애조치 등과 같은 횡단관심사도 포함된다.
  • 시스템을 설계하든 개별 모듈을 설계하든, 실제로는 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

12장 창발성

  • 단순한 설계 규칙 네 가지
    • 모든 테스트를 실행한다.
    • 중복을 없앤디.
    • 프로그래머 의도를 표현한다.
    • 클래스와 메서드 수를 최소로 줄인다.

13장 동시성

  • 동시성 코드가 일으키는 문제로부터 시스템을 방어하는 원칙과 기술
    • 단일 책임 원칙 : 동시성 코드는 다른 코드와 분리하라
    • 자료범위를 제한하라 : 자료를 캡슐화하라. 공유 자료를 최대한 줄여라.
    • 자료 사본을 사용하라
    • 스레드는 가능한 독립적으로 구현하라 : 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할하라.
    • 자바에서 synchronized 키워드를 사용하면 락을 설정한다. 락은 스레드를 지연시키고 부하를 가중시킨다. 그로므로 synchronized 문을 남발하는 코드를 바람하지 않다. 반면, 임계영역은 반드시 보호해야한다. : 동기화하는 부분을 최대한 작게 만들어라
    • 스레드 코드 테스트하기 : 문제를 노출하는 테스트 케이스를 작성하라. 프로그램 설정과 시스템 설정과 부하를 바꿔가며 자주 돌려리. 테스트가 실패하면 원인을 추적하라. 다시 돌렸더니 통과하더라는 이유로 그냥 넘어가면 절대 안된다.

14장 점진적인 개선

  • 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다.

15장 JUnit 들여다보기

16장 SerialDate 리팩터링

17장 냄새와 휴리스틱

  • 저자가 코드를 짜면서 사용하는 기교와 휴리스틱을 나열해놓았다. 꼭 다시 한번 볼 것!!
  • 주석
    • 부적절한 정보
    • 쓸모 없는 주석
    • 중복된 주석
    • 성의 없는 주석
    • 주석 처리 된 코드
  • 환경
    • 여러 단계로 빌드해야 한다
    • 여러 단계로 테스트해야 한다
  • 함수
    • 너무 많은 인수
    • 출력 인수
    • 플래그 인수
    • 죽은 함수
  • 일반
    • 힌 소스 파일에 여러 언어를 사용한다
    • 당연한 동작을 구현하지 않는다
    • 경계를 올바로 처리하지 않는다
    • 안전 절차 무시
    • 중복
    • 추상화 수준이 올바르지 못하다
    • 기초 클래스가 파생클래스에 의존한다
    • 과도한 정보
    • 죽은 코드
    • 수직 분리
    • 일관성 부족
    • 잡동사니
    • 인위적 결합
    • 기능 욕심
    • 선택자 인수
    • 모호한 의도
    • 잘못 지운 책임
    • 부적절한 static 함수
    • 서술적 변수
    • 알고리즘을 이해하라
    • If/Else 혹은 Switch/Case 문보다 다형성을 사용하라
    • 표준 표기법을 따르라
    • 매직 숫자는 명명된 상수로 교체하라
    • 정확하라
    • 관례보다 구조를 사용해라
    • 조건을 캡슐화하라
    • 부정 조건을 피하라
    • 함수는 한 가지만 해야한다
    • 일관성을 유지하라
    • 경계조건을 캡슐화하라
    • 설정 정보는 최상위 단계에 둬라
    • 추이적 탐색을 피하라
  • 자바
    • 긴 Import 목록을 피하고 와일드 카드를 사용하라
    • 상수는 상속하지 않는다
    • 상수 대신 Enum
  • 이름
    • 서술적인 이름을 사용하라
    • 적절한 추상화 수준에서 일므을 선택하라
    • 가능하다면 표준 명명법을 사용하라
    • 긴 범위는 긴 이름을 사용하라
    • 인코딩을 피하라
    • 이름으로 부수 효과를 설명하라
  • 테스트
    • 불충분한 테스트
    • 커버리지 도구를 사용하라
    • 사소한 테스트를 건너뛰지 마라
    • 무시한 테스트는 모호함을 뜻한다
    • 경계조건을 테스트하라
    • 버그 주변은 철저히 테스트하라
    • 실패 패턴을 살펴라
    • 테스트 커버리지 패턴을 살펴라
    • 테스트는 빨라야 한다

2020년 3월 7일 토요일

나는 LINE 개발자입니다 책 메모

나는 LINE 개발자 입니다

여러 LINE 개발자들의 일기 같은 책
라인의 기업문화나 라인 개발자는 어떻게 일하나? 에 대해서 소개하는 책같아서 구입을 하였지만, 해당 내용들은 아주 조금씩 있었다...
요즘 우아한형제들 기술블로그나, 비슷한 책들을 많이 읽다보니 엄청 새로운 내용은 없었고, 라인 또한 개발자에게 좋은 회사 같다.
상당히 가볍게 읽기 좋은 책 (어려운 내용이 없어서 후루룩 읽혔다.)

  • 코드 리뷰를 통해 단순히 버그를 발견하고 수정하는 수준을 넘어 가독성과 확장성이 뛰어난 코드, 일관된 스타일의 코드, 유지보수하기 편리한 코드를 작성하려고 노력한다.
  • 개발을 가장 빨리배우는 방법은 내게 익숙한 소프트웨어를 따라 만들어보는 것이라고 생각한다.
  • 새로운 기술을 접할 때 책을 먼저 한번 보고, 기술 문서를 보고나 코드에 접근하면 내가 지금 파보고 있는 코드가 어ㄷ느 영역에 해당하는 것인지, 그리고 고민해야 하는 영역이 어떤 것인지 쉽게 알 수 있다.
  • 기술문서의 경우 용어 번역 등의 문제로 의도치 않은 오역이 발생하는 경우가 많다. 가능하면 원문으로 좀 더 정확하게 이해하기를 추천한다.
  • 어떻게 질문해야 할까? : 내 생황을 정확하게 알리자
  • 기술공유를 통해 가장 많이 배우는 사람은 역시 발표자 혹은 글을 쓰는 본인이다. 가르치는 것이 가장 좋은 배우는 방법이라는 말이 있듯이, 내가 안다고 생각해서 글로 정리하기 시작하면 더 많은 것을 정확하게 공부하게 된다.

2020년 2월 26일 수요일

엔터프라이즈 자바 마이크로서비스 책 메모

엔터프라이즈 자바 마이크로서비스

마이크로서비스의 개요와 모노리스를 마이크로서비스로 변경하는 간단한 실습이 있다.
엔터프라이즈서비스를 구현할 때 도움되는 프레임워크나 라이브러리 소개, 서비스발견개념, 히스트릭스, 도커 등 엄청 다양하고 얇게 예제를 통해 소개하고 있다.
필요한공부는 각자 깊게 해야함!
실습은 나중에 따라 해볼만할 듯. 소스원본도 있는 듯
엄청가볍게 개념만 읽으려고 본책이지만 깊게 설명한내용이 많아 그냥 넘어간내용도 많다.
실습과 함께 다시 읽어볼 필요도 있음
필요한 부분 참조해서 보면 좋을듯

  • 모노리스는 한 전개 단위 안에 모든 컴포넌트가 들어 있는 애플리케이션
  • 애플리케이션을 아주 조금 변경헀다고 해도 그 애플리케이션에 들어 있는 다른 부분들이 제대로 작동하는지 알기 위해 아주 큰 회귀 테스트를 돌려봐야한다. 자동화 했다고해도 그런 재귀 테스트는 여전히 거대한 작업이다.
  • 모노리스를 계속 유지해야 할지 어떻게 알 수 있을까?
    • 회사에 활발하게 개발과 유지보수가 이뤄지는 애플리케이션이 몇 가지밖에 없다.
    • 현재 개발팀의 인원이 십여명이라면, 두세 사람으로 구성된 마이크로서비스 팀으로 개발팀을 나누느 것은 아무 이득 없다. (12명이 좋은 예)
    • 주중에 여러 번 릴리스할 필요가 있나?
  • 애플리케이션의 필요를 충족시키기 위해 서로 통신하는 다수의 마이크로서비스가 존재할 때 마이크로서비스 아키텍쳐가 유용해진다.
  • 분산에 신경을 써야하는 이유?
    • 서비스가 위치와 무관해진다.
    • 서비스가 언어와 무관해진다.
    • 서비스 전개 규모가 작고 한 가지 목적을 위해 전개가 이뤄진다.
      • 이를 통해 기업은 더 쉽게, 거의 실시간에 준하는 방식으로 비즈니스에 대응할 수 있다.
    • 새로운 서비스는 기존 서비스 기능을 재조합하는 방식으로 정의된다.
  • JeAS는 애플리케이션 서버와 애플리케이션의 관계를 뒤집어서 애플리케이션 서버의 구성 요소 중 애플리케이션 실행을 위해 필요한 부분만을 패키징한 것
    • 꼭 필요한 만큼의 애플리케이션 서버 (Just Enough Application Service)
    • ex_ 드롭위자드, 파야라 마이크로, 스프링부트, 손테일 등
    • JeAS를 사용하면 마이크로서비스와 함께 사용하기에 꼭 필요한 런타임만을 패키징할 수 있다.
    • JuAS 런타임은 RESTFul 마이크로서비스를 전재할 때 최고의 전개방법이다.
  • JeAS 런타임을 사용한 이점
    • 패키지 크기 감소
    • 할당된 메모리 감소
    • 보안 풋프린트 감소
    • 애플리케이션 분리 증대
    • 업그레이드 단순화
  • 마이크로서비스 테스트의 핵심은 마이크로서비스가 정의하는 계약, 즉 마이크로서비스가 노출하는 API를 검증하되 마이크로 서비스가 API를 노출하는 의도에 대해서가 아니라 클라이언트가 어떤 요청을 보내고 어떤 응답을 받을 것으로 예상하는지에 대해서 검증하는 것이다.
  • IaaS, 인프라 제공서비스 (Infra as a Service)
    • 보통 가상 머신을 게스트로 실행할 수 있는 하이퍼바이저를 포함한다.
  • PaaS, 플랫폼 제공서비스 (Platform as a Service)
    • Iaas 위에서 운영체제, 다양한 프로그래밍 언어에 대한 실행환경, 데이터베이스, 웹 서버를 제공하는 계층
  • SaaS, 소프트웨어 제공서비스 (Software as a Service)
    • 애플리케이션의 일부분이나 전체 애플리케이션을 사용자의 필요나 요청에 따라 제공
  • 컨테이너를 사용하면 애플리케이션이나 서비스를 사용할 운영체제와 함께 패키지로 만들 수 있다. 이때 필요한 소프트웨어 설정도 컨테이너에 들어가는 운영체제에 포함시킬 수 있고, 전통적인 가상머신에 비해 만들어지는 이미지의 크기도 작아질 수 있다.
  • 클라우트 네이티브 개발은 클라우드 환경에서 전개할 것을 전제로 서비스나 애플리케이션을 개발하는 것을 뜻한다.
  • 미니시프트는 로컬 컴퓨터에서 오픈시프트를 사용하는 클라우드 환경을 제공한다. 따라서 여러 기계를 관리할 필요 없이 마이크로서비스를 실행하고 테스트하는 과정을 단순화할 수 있다.
  • JAX-RS 클라이언트 라이브러리를 사용하면 RESTful 마이크로서비스에 연결할 때 필요한 저수준 HTTP 연결에 대해 신경쓰지 않고 꼭 필요한 메타데이터에 집중할 수 있다.
  • 클라이언트측 부하 균일화 : 클라이언트가 어떤 마이크로서비스를 소비할지 결정하는 책임을 지는 경우
  • 서비스 발견 : 실행 시점에 한 마이크로서비스가 소비할 것을 목적으로 다른 마이크로서비의 물리적 위치를 얻을 수 있는 수단을 뜻한다.
    • 소비할 마이크로서비스의 위치를 포함하는 코드는 인스턴스가 새로 시작되거나 끝나면 잘못될 가능성이 있다. 마이크로서비스의 위치가 바뀐 경우 코드나 설정을 변경해야하고, 그런 변경의 영향이 미치는 여러 환경에 다시 전개해야하는 코드에서도 실패가 일어날 수 있다. 서비스 발견을 통해 마이크로서비스가 직접 IP환경을 다루지 않고도 축소나 확장을 할 수 있도록 다른 마이크로서비스의 위치를 코드와 분리할 수 있다.
  • 히스트릭스 : 지연시간과 내고장성을 위한 라이브러리로 원격 시스템, 서비스, 라이브러리에 대한 접근 지점을 격리시키고, 연쇄적인 샐패를 중단시키면, 분산시스템에 탄력성을 부여하려는 목적으로 만들어졌다.
  • 분산 아키텍처에 마이크로서비스를 전개할 때 지연시간이나 고장을 견딜 수 있는 내고장성을 갖추는 것이 중요하다.
  • 마이크로서비스를 소비하는 코드를 히스트릭스로 감싸서 폴백, 요청캐시, 벌크헤드와 같은 내고장성 기능을 추가할 수 있다.
  • 마이크로서비스의 보안 측면에서 인증과 권한부여가 가장 중요한 부분이다.
  • 아파치 카프카 : 분산 스트리밍 플랫폼. 카프카는 단일데이터 스트림에 속하는 데이터를 클러스터상의 여러서버에 분할해 처리할 수 있다. 추가로 내고장성을 위해 분할된 각 부분을 서버 사이에 복제할 수 있다.

2019년 12월 29일 일요일

커리어 스킬 책 메모

커리어 스킬 책 메모

전자책으로 완독한 두번째 책이다. 책 소개로는 개발자 인생 로드맵이라고 소개하고 있다.
책 소개답게 개발자가 되려면 부터 회사 생활까지 다양하게 설명해주는 책이다.
개발자를 꿈을 갖고 공부하고 있는 상황이라면 가볍게 읽기 좋을 것 같다!
필요한 내용은 직접 검색해서 찾아봐야한다. 이 책은 여러가지를 소개하는 책이라 엄청 깊게는 설명하지는 않는다.

  • 코드 구조화란 주석을 줄줄이 달지 않고도 이해하기 쉽도록 코드를 잘 작성하는 것을 가리킨다. 원래는 코드만으로도 의사 전달이 가능해야 한다.
  • 코딩 인터뷰 완전 분석은 알고리즘과 데이터구조에 대한 최고의 참고 도서다. 이 책은 알고리즘과 데이터 구조에 대해 알아야할 거의 모든 것을 다른다.
  • 구글에서 '자신이 선택한 기술 + 면접 질문'을 검색해 나온 상위 세 가지 검색 결과에 해당하는 모든 질문에 대답할 수 있도록 준비하라.
  • 단위테스트의 이점 or 하는 이유
    • 코드 설계가 개선된다. 단위 테스트를 제대로 작성하려면 코드를 가능 한 작은 단위로 고립시켜야 한다. 과정에서 코드 설계의 문제점을 알게된다. 단위 테스트 작성 원칙을 엄격히 지키기 위해 코드를 고립된 상태로 가능한한 작게 만들다보면 그 코드와 단위 설계에 존재하는 온갖 문제가 드러난다.
    • 자동화된 회귀테스트를 만드는 것. 이렇게 작성한 테스트는 소프트웨어의 동작이 저수준에서 반드시 지켜야할 명세가 되기도 한다.
  • TDD의 기본 개념은 코드를 작성하기 전에 테스트부터 작성해서 그 코드가 해야할 일을 명확하게 정의하는 명세로 쓰는 것이다.
  • TDD의 가장 큰 가치는 테스트를 명세로 쓸 수 있게 해주는 것이다.
  • 테스트는 특정환경에서 정확히 어떤 일이 일어나야 하는지 명시한다. 그래서 TDD를 쓰려면 무언가 구현하기 전에 무엇을 구현할생각인지부터 제대로 이해하는 과정ㅇ이 선행되어야 한다.
  • 모의 객체는 미리 설정한 값을 써서 의존성이 있는 기능을 흉내 내어 테스트하고자 하는 개별 클래스를 고립시킬 수 있게 도와준다.
  • 지속적 통합을 활용하는 작업 흐름 샘플
    • 코드 체크인
    • 새 빌드 시작
    • 코드 체크아웃
    • 코드 컴파일
    • 정적 분석기 실행
    • 단위 테스트 실행
    • 결과 보고
    • 소프트웨어 패키징
    • 코드의 선택적 배포(지속적배포)
    • 완료
  • 유지 보수하기 쉬운 코드를 작성하고 자신이 작성하지 않은 기존코드를 유지 보수하는 데 도움을 주는 자료
    • 로버트 마틴의 Clean Code
    • 스티브 맥코넥의 Code Complete
    • 마이클 페더스의 레코시 코드 활용 전략
    • 마틴 파울러의 리팩토링
  • 자리를 지키기 위해 정치적 게임을 하면서 어느 말에 걸어야 안정성이 보장될까 전전긍긍하기보다 고용 보장이나 안정성의 필요를 느끼지 못할 정도로 자신의 실력을 키우는 건 어떨까?
  • 사이드 프로젝트 진행을 위한 체계와 일정이 필요하다.
    • 그 프로젝트를 위해 매일 혹은 매주 얼마의 시간을 쓸 것인지 명확히 정의한다.
    • 정의한 시간이 정확히 언제인가를 정의한다.
    • 작업 진도와 해야 할 일을 추적할 수 있는 절차를 정의한다.
  • 저자의 책 추천 목록
    • 훌륭한 코드 작성하기
      • 코들 컴플리트 2: 더 나은 소프트웨어 구현을 위한 실무 지침서
      • 클린 코드: 애자일 소프트웨어 장인 정신
      • 클린 소프트웨어
    • 개발 기본 소양 갖추기
      • GoF의 디자인 패턴
      • Testing Computer Software
      • Introduction to Algorithms
        • 앤터프라이즈 애플리케이션 아키텍쳐 패턴
    • 기존 코드 다루기
      • 리팩토링
      • 래거시 코드 활용 전략
      • 패턴을 활용한 리팩토링
    • 더 훌륭한 개발자 되기
      • 소프트 스킬
      • 실용주의 프로그래머
      • 프로그래머, 열정을 말하다.

2019년 11월 18일 월요일

소프트웨어 장인 책 메모

소프트웨어 장인

첫 전자책으로 구매한 책이다. 출퇴근 시간 지하철에서 읽었으며, 가볍게 읽기 좋았다.
책은 개발자의 태도에 대해서 써있다. 애자일,TDD, 페어프로그래밍의 도입과 적용에 대해 강조하고 있다. (실제 직접 사용,적용하려면 해당 주제에 대한 책을 구매해야할 것 같다.)
팀을 이끌 때 도움이 될 만한 글이 많은 것 같다.

  • 일을 어떻게 했느냐는 일을 해낸 것만큼이 중요하다.
  • 소프트웨어 장인정신은 소프트웨어 개발자가 스스로가 선택한 커리에 책임을 가지고, 지속적으로 새로 운 도구와 기술을 익히며 발전겠다는 마음가짐이다.
  • 코드도 처음 발견했을 때보다 더 깨끗하게 관리해야한다.
  • 시간이 없다는 말 은 더 이상 변명이 될 수 없다. 우리는 항상 시간이 있다. 우리는 모두 정히 같은 시간 만큼의 시간이 주어진다. 차이점은 우리가 그 시간을 어떻게 쓰느냐일 뿐이다.
  • 의도한 대로 동작할 수 없거나, 실행 불가능한 무리한 일정에 대해서 "아니오" 라고 답하는 것은 우리의 의무다.
  • 자동화된 테스를 만들고 활용하는 데 능숙한 개발라면 코드 디버깅을 해야 하는 상황이 매우 드물다.
  • 유지보수가 쉬운 깨끗한 코드는 개발속도를 높이고 버그가 만들어질 가능을 낮춘다. 이것이 리펙토링 의 비즈니스적인 가치다.
  • Git에 익숙한지? Git이 이미 설치되어 있는지? 컴퓨터 설정이 어떻게 되어 있는지? 어떤 도구를 선호하는지? 프로젝트를 금방 시작할 수 있는지? 테스팅/목업 프레임워크가 이미 모두 가지고 있고 사용할 수 있게 설정되어 있는지? 업무 외 시간에도 코딩을 하는 개발자라면 이러한 것들이 항상 준비되어 있어야한다.
  • (그룹코드리뷰하기) 특정 코드 부분이 개선의 여지가 많은지 아니면 모범사례로 공표할만큼 훌륭한지를 놓고서 동료들간에 논쟁한다.
  • 펫프로젝트에서는 자기 자신이 상사이고 다음 피처가 뭐가 될지, 그 피처를 어떻게 만들지 마음대로 결정할 수 있다. 더욱 중요한 것은 일정 데드라인이 없다.
  • 당신의 열정과 변화 의지에 모두 관심을 가질 것으로 기대하긴 어렵다. 변화를 수용하는 사람들에게 집중하자.
  • 단순한 설계를 위한 네가지 원칙
    • 모든 테스트의 통과
    • 중복의 최소화
    • 명료성의 최대화
    • 구성요소의 최소화

2019년 1월 28일 월요일

실용주의 프로그래머 책 메모

실용주의 프로그래머 

드디어 실용주의 프로그래머를 다 읽었다.
영어공부에 대해 이야기하다가 사수에게 한글로 책을 읽고 원서로 한번 더 읽는 방법을 추천받아 이 책까지 빌리게 되었는데 1챕터 읽고 멈췄었다...
하지만, 2019년 읽을 도서 목록으로
실용주의 프로그래머 -> 이펙티브 자바 -> 클린코드 -> ...more
으로 정하여서 2019년 1월 - 약 1달에 걸쳐서 다 읽게 되었다.
사실..1월말 까지 책을 돌려줘야해서 살짝 급하게 읽었다. 중간에 대충 읽은 부분도 많다.
이 책은 어디선가 보고 들은 개발자가 가져야할 생각이나 명심해야할 것들을 모아놓은 책 느낌이었다. 그래서 더 읽는데 속도가 붙을 수 있었던 것 같았다. 책을 사서 다시 읽어봐도 좋을 듯 하다.
그땐 또 다른 느낌점들과 깨닫는 것들이 생길 것 같다.

인상깊은 문장 메모
  • 자신의 일에 대해 생각하면서 일해라!
  • 깨진 창문(나쁜설계, 잘못된 결정, 혹은 형편없는 코드)을 고치지 않은 채로 내버려 두지 마라.
  • 큰 그림에 늘 주의를 기울여라. 개인적을 무엇을 하고 있는가에만 정신을 쏟지 말고, 주변에서 무슨일이 벌어지는지 지속적으로 살펴보라.
  • DRY - Don't Repeat Yourself
  • 관련 없는 것들 간에 서로 영향이 없도록 하라. (직교성 강조하고 있음)
  • 최종 결정이란 없다. (유연성강조)
  • 언제나 소스코드 관리 시스템을 사용하라.
  • 가장 속이기 쉬운 사람은 자기 자신이다.
  • 가정하지 마라. 증명하라.
  • 단정문을 사용해서 불가능한 상황을 예방하라.
  • 시작한 것은 끝내라.
  • 모듈간의 결합도를 최소화하라.
  • 통합하지 말고 설정하라.
  • 코드에는 추상화를, 메타데이터에는 세부 내용을.
  • <의도적으로 프로그래밍하기>
    • 정말로 제대로 돌아가는 것이 아닐지도 모른다. 우리에게만 그런 것처럼 보일 수도 있다.
    • 신뢰할 수 있는 것에만 기대라. 우연한 일이나 가정에 의존하지 말라.
    • 기존 코드가 아픙로 짤 코드를 지배하도록 놓아두지 말라. 더 이상 적절한 코드가 아니라고 생각되면, 어떤 코드라도 교체할 수 있다.
    • 어떤 것이 잘돌아가는 것처럼 보이기는 하는데 그 이유를 모를 경우, 그것이 우연은 아닌지 반드시 확인하라.
  • 일찍 리팩터링하고, 자주 리팩터링 하라.
    • 리팩터링과 새로운 기능 추가를 동시에 하지마라.
    • 리팩터링 전 테스트 집합이 있는지 먼저 확인하라.
    • 단계를 작게 나누어서 신중하게 작업하라. 단계가 끝날 때마다 테스트를 돌려라.
  • 테스트 코드를 쉽게 접근할 수 있게 해놓는 것은 앞으로 코드를 사용할지 모르는 개발자들에게 매우 귀중한 자원 2가지를 제공하는 것이다.
    • 모듈의 모든 기능을 어떻게 이용하야 하는지 보여주는 예제
    • 후일 코드 변경 시 검증하기 위한 희귀 테스트를 구축할 수 있는 수단
  • 주석에 나오지 말아야 할 것들의 목록
    • 파일 내의 코드가 export하는 함수들의 목록
    • 리비전 기록
    • 이 파일이 사용하는 파일 목록

2018년 12월 23일 일요일

객체지향의 사실과 오해 - 인터페이스 부분 정리

객체지향의 사실과 오해 - 인터페이스
  • 인터페이스는 객체가 다른 객체와 협력하기 위한 접점
  • 일반적으로 인터페이스는 다음과 같은 세 가지 특징을 지님
1. 인터페이스의 사용법을 익히기만 하면 내부 구조나 동작방식을 몰라도 쉽게 대상을 조작하거나 의사를 전달할 수 있음
2. 인터페이스 자체는 변경하지 않고 단순히 내부 구성이나 작동방식만을 변경하는 것은 인터페이스 사용자에게 어떤 영향도 미치지 않는다
3. 대상이 변경되더라도 동일한 인터페이스르 제공하기만 하면 아무런 문제없이 상호작용을 할 수 있다
  • 객체가 다른 객체와 상호작용할 수 있는 유일한 방법은 '메시지 전송'
  • 책임은 객체가 메시지를 수신했을 때 수행해야 하는 객체의 행동이며, 실제로 객체의 공용 인터페이스를 구성하는 것은 객체가 외부로부터 수신할 수 있는 메시지의 목록
객체가 메시지를 수신했을 때 적절한 객체의 책임이 수행됨 -----> 메서드
  • 객체지향적인 사고방식을 이해하기 위해서는 세 가지 원칙이 중요
1. 좀 더 추상적인 인터페이스 : 지나치게 상세한 수준의 메시지를 보내는 것은 객체의 자율성을 저해함
2. 최소 인터페이스 : 외부에서 사용할 필요가 없는 인터페이스는 최대힌 노출하지 말라
(객체 내부를 수정하더라도 외부에 미치는 영향을 최소화할 수 있음)
3. 인터페이스와 구현간의 차이가 있다는 점을 인식
: 훌륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체
----> 객체 외부에 노출되는 인터페이스와 객체의 내부에 숨겨지는 구현을 분리해서 고려해야함
----> '인터페이스와 구현의 분리 원칙'
----> why? 객체의 모든 것이 외부에 공개돼 있다면 아무리 작은 부분을 수정하더라도 변경에 의한 파급효과가 객체 공동체의 구석구석까지 파고들 것임

'강조'
객체가 가져야 할 상태와 메서드 구현은 객체 내부에 속함. 이 부분을 수정하더라도 객체 외부에 영향을 미쳐서는 안됨
객체 외부에 영향을 미치는 변경은 객체의 공용 인터페이스를 수정할 때만
---> 캡슐화
  • 캡슐화: 객체의 자율성을 보존하기 위해 구현을 외부로부터 감추는 것
---> 객체의 상태와 행위를 캡슐화함으로써 협력적이고 자율적인 존재가 될 수 있음
  • 자율적인 객체? : 공용 인터페이스를 수정하지 않는 한 자신과 협력하는 외부 객체에 영향을 미치지 않고 내부의 구현을 '자유롭게' 수정할 수 있음
  • 결론: 객체가 자율적인 책임을 가지는 것이 중요하다
객체의 책임이 자율적일수록 협력이 이해하기 쉬워지고 유연하게 변경할 수 있게 된다

1. 자율적인 책임은 협력을 단순하게 만든다
---> 책임이 적절하게 추상화됨

2. 외부와 내부를 명확하게 분리
---> 요청하는 객체가 몰라도 되는 사적인 부분이 객체 내부로 캡슐화되면서 인터페이스와 구현이 분리됨

3. 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않음
---> 책임이 자율적일 수록 변경에 의해 수정되야하는 범위가 좁아지고 명확(결홥도가 낮아짐)

4. 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공
---> 설계가 유연해지고 재사용성이 높아짐

5. 객체의 역할을 이해햐기 쉬워짐
---> 객체의 응집도를 높은 상태로 유지가 쉬워짐