180730-180805

2018년 07월 30일 ~ 2018년 08월 05일 주간 회고


180730-180805 주간회고

Weekly Review

  • 이번 주는 사내에서 ELK 스택 구축에 거의 모든 시간을 보냈다.
    • 어느 정도 개념을 잡아가고 있지만 아직 시작하는 단계이고 앞으로 계속 수정 보완해 나가면서 프로덕트 환경에 적용시키는 것이 목표이다.
    • 공부하면서 정리한 내용들을 블로그에 계속해서 업데이트할 예정이다.
  • 첫 알고리즘 스터디 모임을 가졌다.
    • 알고리즘 문제 해결 전략 책으로 시작하고 있는데 생각보다 난이도가 높아서 깜짝 놀랐다. 앞으로 시간도 많이 투자하고 스터디 기간 동안 빠짐없이 열심히 해야겠다는 생각이 들었다!
    • 코드 리뷰는 깃랩을 통해서 진행하기로 하였다.
  • 독서 모임 트레바리를 신청하였다.
    • 평소에 관심있는 주제로 진행하는 모임이 있어서 곧장 신청을 하였다.
    • 해당 모임이 개설되면 주제를 공개할 것이다(인원 미달로 개설이 안될 수도 있으므로..)

학습

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

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

  • 빵집 개발자 양병규씨가 쓴 글 입니다 아이디어는 자신이 구현 가능한 기술의 범위에서 나온다
    • 첫번째
      • 좋은 소프트웨어를 만들려면 좋은 소프트웨어를 봤을때 ‘우와~ 좋다~’라고 느낄 수 있어야한다.
      • 좋은 소프트웨어를 보고 느낄 수 있는 것은 그냥 저절로 되지는 않는다. 많이 경험해 봐야한다.
    • 두번째
      • 포기하지 않고 열심히 하다보면 언젠가는 되기 시작한다. (한강의 강 바닥에 벽돌을 쌓는다 생각. 조금하다가 포기하지 말고 일년, 이년 계속 하면 언젠가는 수면으로 떠오른다.)
      • 기초를 튼튼히 해야 더 높이 올라갈 수 있다.
    • 세번째
      • 프로그래머는 자기만의 꿈이 있어야한다.
      • 큰 꿈을 항상 간직하고 있어야한다. 지금 직장 생활을하고 고생하는 것은 그 꿈을 이루기 위해서 필요한 지식과 경험을 만들어 가는 과정이다.
      • 지금은 못 만들더라도 지금부터 그것을 완성시킬 수 있을만한 지식과 경험을 쌓아 가라.
      • 이 꿈을 가지면서부터 지금까지도 모든 프로젝트를 할 때에 나의 꿈을 이루기 위해서 필요한 지식과 경험을 쌓는다라고 생각하며 일하고 있다.
      • 프로그래머는 물건을 만드는 사람이다. 건물을 만드는 사람이지 벽돌을 나르는 사람이 아니다. 어떻게 만들지도 중요하지만 뭘 만들지가 더 중요하다
      • 프로그래머는 항상 머리속에 “방법”보다는 “대상”이 그려져 있어야 한다.
      • 다시 말해서 어떤 기능을 수행할 수 있는 기술을 배우는데 모든 정력을 투자하지 말아야한다.
      • 물론 기술은 당연히 가지고 있어야한다. 하지만 기술 자체가 목적이 되어서는 안된다.
      • 기술이 아니라 물건에 항상 관심을 가지고 그 물건을 만들어 내기 위해 필요로 하는 기술을 배워야한다.
      • 모든 프로그램을 비평할 수 있어야 좋은 물건을 만들 수 있다.
      • 그럴려면 많은 최신기술에 민감하게 반응할 필요가 있고 세상 돌아가는 일에도 관심을 가져야한다.
    • 마지막으로, 아이디어는 자기가 구현할 수 있는 기술의 범위 안에서 나온다.
      • 바로 위의 이야기와 상반되는데, 우의 이야기가 프로그래머써 소프트웨어 프로젝트의 기획 능력을 말한다면 이번에는 기술에 관한 이야기.
      • 프로그래머가 많은 아이디어를 배출해 낼려면 많은 분야의 기술을 습득하고 구현할 수 있어야 한다.
  • (번역) Art of Clean Pull Requests - 클린한 Git PR의 기술 효율적인 실무를 위한 Branch 관리 및 PR 방법에 대하여 전반적으로 다루는 글이다. 여러 팁들과 왜 기능별로 브랜치를 나워야 하는지, Merge와 Rebase의 차이가 무엇인지 등을 배울 수 있는 글이다.
  • 학습에 실패한 이야기 익혀야 할 것은 무수히 많고 시간은 한정되어 있다.   따라서 어떤 것을 먼저 할지 우선순위를 정하고, 선택하고, 집중해야 한다다. 그것도 아주 효과적인 방법으로.
    • 무엇을 잘못했나?
      • 막연한  목표 설정 (막연하고 두리뭉실하여 학습의 성과를 측정하기 힘듬)
      • 편안한 학습법 (단순히 책을 읽고 강의를 듣고 예제를 따라하며 반복하는 편안한 방식의 학습)
      • 진척도를 측정하기 힘든 학습 목표, 끝이 정해져 있지 않은 학습 과정. 
    • 의식적인 연습
      • 재능보다 노력이 중요한데 이 노력과 성실함에도 전략이 필요하다.
      • 단순히 행위를 반복하는 것은 연습이 되지 않으며 실력이 늘지 않는다. 노하우만 쌓일 뿐.
      • 자신의 약점을 고치려고 의식적으로 노력해야 한다.
      • 김창준 애자일 코치님의 ‘프로그래밍 어떻게 공부할 것인가’ 강의에서 업무와 놀이는 연습이 아니라고 말합니다.
      • 집중하고 고치고 반복하라
        • 널리 알려지고 통용되는 효과적인 훈련 기법을 통해 기술을 연마한다.
        • 자신의 현재 능력을 살짝 넘어서는 작업을 지속적으로 시도해야 한다.
        • 명확하고 구체적인 목표를 가지고 진행된다.
        • 신중하고 계획적이다.
        • 피드백이 있고 피드백에 따른 행동 변경을 수반한다.
        • 효과적인 심적 표상을 만들어 내고 거기에 의존한다.
        • 기존에 습득한 기술의 특정 부분을 집중적으로 개선함으로써 이를 한층 발전시키거나 수정하는 과정이 수반된다.
    • 프로그래밍 의식적 연습하기
      • 기존에 했던 방법을 돌아보면 구체적이지 못한 목표를 세우고 단순 반복적으로 읽는 학습 방식을 취했으며 성과를 측정할 방법이 마땅치 않았다.
      • 단순히 많은 시간을 들여 꾸준히 한다면 실력이 늘 것으로 생각했지만 의식적인 연습 방법들은 이제까지 해왔던 방법들과 조금 달랐다.
      • 학습 시작 전에 구체적인 계획과 목표 세우기
      • 단순 타이핑 하지 않기
        • 공부한 내용을 일정한 주기로 인출 혹은 회상하는 것이 기억을 강화하고 망각을 막아준다고 한다. 따라서 책을 통해 학습한다면 한번 전체적으로 살펴본 후, 코드를 작성하는 일은 최대한 스스로 하려 한다.
      • 일정 주기로 반복하기
        • 한 달 또는 일정 주기로 이전에 학습했던 내용을 다시 학습해 보는 것은 장기 기억에 도움이 된다고 한다. 이전에 풀었던 알고리즘 문제를 다시 풀어보거나 작성했던 코드를 개선.
      • 부서둬 좋은 장난감 만들기
        • 하나의 프로그램을 만드는 과정은 많은 실행 오류들을 겪게 되고 자신의 노력을 끌어내게 된다. 이를 바람직한 어려움Desirable Difficulties이라고 하는데 적절한 학습의 난이도는 더욱 탄탄한 학습으로 이어진다. 또한, 이렇게 작성된 프로그램은 다른 용도로 또다시 활용될 수 있다. 이런 프로그램들은 언제든 바꾸고 부술 수 있는 장난감이기 때문에 새 기능을 마음대로 추가하고 다양한 방식으로 리팩토링해 볼 수 있는 놀이터play ground로 활용할 수 있다.
      • 피드백을 받을 방법과 피드백에 따른 교정
        • TDD, 정적 분석 도구, 다른 코드와 비교, 다른 개발자의 코드 리뷰, 스터디 모임 등.
    • 왜 공부하는가
      • 뛰어난 동료들, 그럼에도 꾸준한 자기계발. 그런 분위기 속에서 어떤 목표를 위한 학습이 아니라 단지 ‘학습해야 한다!’라고 자신을 압박만 했다.
      • 결국 프로그램은 잘 동작하고 코드는 사람이 이해하기 쉽도록 작성하기 위해 학습한다고 정리했고, 이 목표는 학습의 우선순위 등을 정할 때 가장 먼저 고려 될 부분
  • (번역) 10년 안에 시장에서 리더가 되는 방법 많은 대기업과 싸워 살아남고 시장에서 마켓 리더 중 하나로 된 Todoist에서 전하는 ‘지속 가능한 회사를 세우며 배운 것들’
    • 당신 자신의 문제를 풀어라
      • 만약 당신이 새로운 아이디어를 찾고 있다면 당신이 갖고 있는 문제를 선택하고 그것을 해결해라.
      • 수백만명이 사용하게 될 것 이라는 환상에 사로잡히지 말고 당신 스스로의 문제를  푸는데에만 집중해라.
    • 전력질주가 아니다. 마라톤이다.
      • 회사를 만든다는 것은(무언가를 엄청 깊이 배운다는 것은) 길고 힘들고 지겹고 낙담할만한 마라톤이다.
      • 우리의 Todoist 성공은 우리가 빠르거나 똑똑해서 이뤄낸 것이 아니다. 그건 우리가 10년 넘게 꾸준히 열심히 했기 때문이다.
      • 내가 가장 좋아하는 개발자를 위한 조언은 구글 연구소장 Peter Norvig의 10년안에 프로그래밍을 배우는 법이다.
      • 어떤 분야에서든 연구자들은 10년 가까이 전문성을 키워야 한다. 그것이 체스이든, 작곡이든, 미술이든, 음악이든, 수영이든, 테니스이든, 신경심리학이든, 기하학이든말이다. 열쇠는 의식적이고 의도적인연습에 있다. 그것을 단지 반복하는 것만이 아니라 스스로를 현재 한계를 넘도록 끊임없이 도전시키는 것을 의미한다. 그리고 스스로의 퍼포먼스를 분석하고 어떤 실수를 수정하는 것을 의미한다. 열쇠는 단지 이것들의 반복일 뿐이다.
      • 당신이 10년안에 이룰 수 있는 일을 선택해라. 단지 몇달 걸리는 게 아니라.
      • 당신이 마라톤에 집중한다면 그것을 즐겨라. 부처는 이미 진리를 깨달았다.
        • 행복은 여행이지 목적지가 아니다.
      • 목적지에 도착하는 것(많은 돈, 많은 유저 등)이 당신을 행복하게 해줄 것이라고 생각하는 것은 아주 쉽다. 그러나 대부분 그건 사실이 아니다
  • (변역) 아주 거대한(자바스크립트) 어플리케이션을 구축하기 큰 주제는 자바스크립에 관한 이야기이지만 중간 중간에 커리어, 코드 스타일 등의 좋은 글귀들이 많았다.
    • 시니어의 다음 단계로 나아가는 글은 ‘공감’에 있다.
      • 저는 시니어가 된다는 것의 의미를, 제게 주어지는 거의 모든 문제를 해결할 수 있는 능력이 있는 것으로 생각한다. 적절한 도구와, 적절한 도메인 지식을 알고 있으니까. 그리고 또 하나의 중요한 의미는, 주니어 개발자가 언젠가 시니어가 될 수 있도록 돕는 것이다.
      • 제가 생각하는 시니어의 다음 단계는, 스스로 “나는 다른 사람이 어떻게 문제를 풀어야 할지 안다”고 당당히 말할 수 있는 것이다.
      • 조금 더 구체적으로 말해보면 이렇습니다. “나는 내가 선택하는 API 또는 내가 프로젝트에 도입한 추상화가, 다른 사람이 문제를 푸는 데 어떤 영향을 미칠지 예상할 수 있다.” 
      • 이걸 ‘공감하며 앱 만들기(An application of Empathy)’ 라고 부를 수도 있다. 당신의 행동 하나하나와 당신이 다른 개발자에게 주는 API 하나하나가, 그들이 소프트웨어를 개발하는 데 어떤 영향을 미칠 것인지 생각해보는 것이다.
    • 개발자가 옳은 방향으로 가도록 보장하는 테스트를 추가하라.
      • 당신의 앱 인프라에서 주요하게 지켜져야 하는 부분을 보장하는 테스트를 추가하는 걸 주저 하지 마라.
    • 인간이 판단해야 할 상황을 되도록이면 피하라.
      • 비즈니스 로직이나 코드 분할과 같은 것들을 도입할 때, 모든 개발자가 이해하지 않아도 그들이 잘 작업할 수 있도록 하는 방식으로 도입하도록 노력하라.
    • 코드를 삭제하기 쉬운 구조로 만들어라
      • 코드를 지우기 쉽게 만드는 건 정말 중요하다.
      • 애초에 앱이 아주 거대해지지 않도록 하라.
      • 그러기 위한 가장 좋은 방법은 너무 늦기 전에 코드를 지워나가는 것
    • 공감과 경험을 통해 올바른 추상화를 도입하기 위해 노력하라.
      • 좋은 추상화로 가기 위한 방법은 팀의 개발자들에게 공감하고, 함께 생각하는 것이다. 그들이 API와 추상화를 어떤 식으로 사용하게 될 것인지에 대해서. 경험이 쌓이면 공감능력에 살을 붙여나갈 수 있다.
  • AWS Lambda를 시작하기 전 알았으면 좋았을 것들 제목 그대로 Lambda를 시작하기 전에 알고 시작하면 좋았을 것들을 친절하게 설명해주는 글이다. 더 이상 하나의 플램폿 하나의 단일한 황경에서 개발하는 시대가 아닌 다양한 플랫폼에서 다양한 환경으로의 개발이 대세가 되고 있는데 이러한 환경에서 개발을 하기에는 AWS Lambda(서버리스)는 아주 훌륭한 환경이 될 수 있을 것 같다.
  • 서비스 단계별로 개선하기 서비스 개선을 위해 대규모 업데이트를 목표했다가, 단계별로 서비스를 최적화하는 방식으로 전략을 선회하면서 이를 위해 어떤 과정을 거쳤는지 실사례를 들어 소개하는 글.
    • 여러 해 동안 서비스를 유지보수 해온 팀이라면, 제품 개선에 자연히 많은 욕심이 생깁니다. 하지만 기존의 시나리오와 디자인, 코드 베이스로 오랜 기간 서비스를 해왔다면, 현재의 서비스 또한 어느 정도 ‘고객이 이해하고 사용할 수 있는 상태’라는 믿음을 가져야 합니다. 또한, 서비스를 무조건 대규모로 개선하려고 하는 시도가 자칫 이를 사용하는 고객을 더욱 괴롭게 하는 일이 되어서는 절대로 안 될 것입니다.
facebook share twitter share
0%