181126_181202

2018년 11월 26일 ~ 2018년 12월 02일 주간 회고


181126_181202 주간회고

Weekly Review

  • 스프링 부트 스터디가 끝났다.
    • 이로써 올해 진행했던 모든 스터디를 마무리하였다.
    • 올해 하반기에 스프링5 레시피, 스프링 부트, 알고리즘 총 3개의 스터디를 진행하였는데 모두 좋은 사람들 만나서 너무 많은 것을 배우고 느꼈다.
    • 스터디를 통하여 무조건 적으로 지식을 배운다기보다는 내가 공부한 것에 대해서 다른 사람들은 어떻게 생각할까? 얘기를 나누고 토론을 나누면 배울 점은 항상 있다는 것을 많이 느꼈다.
    • 앞으로 할 게 조금 더 남긴 했는데 잘 마무리해서 좋은 결과를 얻고 싶다.
    • 하고 싶은 말은 더 많지만, 올해 회고 작성할 때 얘기하면 좋겠다는 생각이 든다.
  • 최근에 사내 레거시 코드를 건드리는 일이 많아지면서 리팩토링, 디자인 패턴, 클린코드, OOP, TDD 등의 주제들을 제대로 학습하고 싶은 욕구가 치솟고 있다.
    • 솔직히 잠깐 공부한다고 해결될 주제들은 아닌 걸 알아서 계획을 어떻게 짜야 할지 고민이 많다.
  • 이제 2018년 마지막 12월이 왔다.
    • 조금은 여유롭게 부족했던 것을 채우는 시간으로 올해를 마무리해보자 한다.

학습

다음 주 목표 (꾸준히 읽고 정리하고 강의듣기)

이번 주에 읽었던 좋은 글(출퇴근지하철)

  • Docker 기초 확실히 다지기 도커 기초를 깔끔하게 잘 정리한 글. 한동안 도커를 사용 안 해서 까먹을까 봐 불안했었는데 전반적인 내용을 다 담고 있어서 다시 한번 상기시키기에 적합한 글이었다.
  • 쏘리! 리눅스, 이제 주인공은 ‘쿠버네티스’다.
    • 이제 운영체제는 더 이상 중요하지 않다. 이는 개발자나 클라우드에 있어 리눅스가 더 이상 중요하지 않다는 의미이다.
    • IBM은 레드햇 엔터프라이즈 리눅스 때문에 돈을 쓴 것이 아니다. 전혀 그렇지 않다. IBM이 그렇게 많은 돈을 들여 얻고자 했던 것은 쿠버네티스로 구동하는 클라우드에 대한 실마리였다.
    • 쿠버네티스는 관심을 독점했던 과거의 리눅스처럼 하나의 운영체제 비슷하게 될 것이다.
  • (번역) 좋은 코딩을 위한 13가지 간단한 규칙
    • 최적화 VS 가독성, 최적화 보단 가독성
      • 코드는 항상 읽기 쉽고 개발자들이 이해할 수 있게끔 작성하라. 읽기 어려운 코드를 읽는데 소모되는 시간과 비용은 최적화로부터 얻을 수 있는 것보다 더욱 크다.
    • 아키텍처 우선
      • 코드를 작성하기 전에 먼저 수행 할 작업, 사용 방법, 모듈화 방법, 서비스가 서로 어떻게 동작하는지, 구조가 무엇인지, 테스트 및 디버깅 방법, 업데이트 방법들을 먼저 생각하고 이해해야한다.
    • 테스트 커버리지
      • 테스트는 좋은 일이지만 항상 비용 효율적인건 아니며 프로젝트에 따라 다르다. 나쁜 테스트 코드와 함께 코드를 짜는 것은 테스트가 없는 코드보다 더 위험할 수 있음을 기억하라.
    • 간단하고 단순하게
      • 복잡한 코드를 작성하지말라. 간단하게 작성하면 버그가 줄어들고 디버깅 시간도 줄어들 수 있다.
    • 주석
      • 주석은 나쁜 코드를 보여준다. 좋은 코드는 주석 없이도 이해할 수 있어야한다.
    • 강한 결합 VS 느슨한 결합
      • 항상 마이크로서비스 아키텍처를 사용하도록 노력하라. 모놀리틱 소프트웨어는 마이크로서비스 소프트웨어보다 빠르지만, 단일 서버 환경에서만 그렇다.
    • 코드 리뷰
      • 코드 리뷰는 좋을 수도 있고 나쁠 수도 있다. 여러분 팀에 코드의 95%를 이해하고 있고 시간 낭비 없이 모든 업데이트 사항을 모니터링 할 수 있는 개발자가 있는 경우에만 코드 리뷰를 도입하도록 하라.
    • 리팩토링은 작동하지 않는다
      • 처음부터 여러번 소프트웨어를 다시 개발할 수 있는 자금이 있는게 아니라면 부채를 만들지 말라.
    • 피곤하거나 컨디션이 좋지 않을때 코딩하지 말라
      • 개발자들이 피곤할 땐 평소보다 2-5배 더 많은 버그와 실수를 만들어낸다.
    • 모든걸 한꺼번에 작성하지 말라 - 반복적으로 개발하라
      • 코드를 작성하기 전에 우선 여러분의 고객과 클라이언트가 정말로 필요로 하는걸 분석하고 예측하고, 짧은 기간동안 개발할 수 있는 MVF(Most Valuable Features)를 추려내라.
    • 자동화 VS 수동
      • 자동화는 장기적으로 100% 성공이다. 따라서 지금 당장 무언가를 자동화 할 수 있는것이 있다면 바로 하도록 하라.
    • 나가서 취미를 갖자
      • 일의 차별화는 정신 능력을 향상시키며 새롭고 신선한 아이디어를 제공한다. 따라서 잠시 쉬고 신선한 공기를 마시거나 친구들과 이야기를 하거나 기타를 연주하는등의 취미를 가져라.
    • 여유 시간에 새로운걸 배워라
      • 학습을 중단하면 퇴화하기 시작한다.
  • 아시아-태평양 서울 리전(AP-NorthEast-2)의 Amazon EC2 DNS 확인(Resolution) 이슈 요약 현 직장에서도 해당 이슈로 인해 곤혹을 느꼈는데 정확한 원인이 무엇인지 짚고 넘어가기 위해 꼭 한번 읽어봐야 한다고 생각한다. 이번 사건을 계기로 많은 분들이 사내 시스템 구조를 되돌아보는 시간이 되었을 것 같다.
  • ‘기능 공장’에서 일하고 있다는 12가지 신호 그냥 공장에 앉아서, 하찮은 기능들을 뱉어내고, 라인에 올려보내는 ‘기능 공장’에서 일하고 있진 않은지 다시 한번 되돌아보게 되는 글이다.
  • (번역) 최신 네트워크 로드 밸런싱 및 프록시 소개 솔직히 이해가 되지 않는 부분이 많고 잘 받아들여지지 않는다. 아직 경험과 지식이 부족한 탓인 것 같다. 당장은 아니더라도 앞으로 로드 밸런싱은 꼭 이해 해야 되고, 잘 알고 싶은 내용이긴하다. 그래도 L4, L7 로드밸런싱의 개념과 차이 정도는 알게 되어 좋았다.
  • 대규모 서비스를 지탱하는 기술 대규모 서비스를 지탱하기 위해 사용되는 기술들에 대한 힌트를 얻을 수 있다. 최근에 관심이 많은 주제인데 많이 도움 된 자료이다.
  • 시대의 바람을 봐야 해요 - 블록체인 개발자 이정주 배울 점이 많다고 느낀 interviewee(이정주 님)의 인터뷰 글. 특히 비트베리라는 암호화폐 지갑을 처음 알게 되었는데 놀라웠다. MEW(My Ether Wallet) 설치하고 메타 마스크 설치하고 사용자들이 키 관리하는데 이렇게 불편한 걸 누가 사용하겠냐고 항상 개발하면서도 생각했었는데 비트베리는 혁신인 것 같다는 이정주 님의 의견에 매우 동의했다.
    • 시대의 파도를 보는 게 아니라 시대의 바람을 봐야 한다. 우리는 파도를 보고 있잖아요. 그런데 바람이 불어오는 방향이 어딘지 모르잖아요. 파도를 보면 바람의 방향을 읽을 수 있겠죠. 근데 사람들은 파도만 봐요. 바람은 어디로 가는지 모를다는 거죠.”.
  • Java 예외(Exception) 처리에 대한 작은 생각 예외처리를 어떻게 하는 것이 맞는 것일까? 최근에 예외 처리 때문에 고민이 많다. 여러 글을 찾아보며 학습하던 중 잘 정리된 글이 있어 기록으로 남겨둔다.
  • Git을 이용한 더 나은 버전관리 Git 기초 내용을 아주 잘 정리한 발표자료이다. 발표를 듣지 않고 해당 자료만 가지고도 쉽게 이해가 가능할 만큼 상세하게 작성되어 있다. Git을 처음 접하는 사람에게 Git에 관해 설명을 해줄 때 참조하면 좋을 것 같다는 생각이 들었다.
facebook share twitter share
0%