개발을 할 때, 사람을 대할 때 좋은 태도가 있습니다. 좋은 태도에 대한 글이나 말을 들어도 항상 까먹어서 한 곳에 보면 좋을 것 같아 이 글에 정리하려고 합니다.

개발 태도

  • 반 년에 한 번씩 내가 사용하고 있는 기술들이 트렌드인지 파악하자
  • 모든 일을 완벽하게 하려고 하지 마라. 완벽하게 하려고 하면 시간도 오래 걸리고 쉽게 지친다. 완벽하게 하는 것이 아니라 완벽을 추구할 때와 추구하지 않을 때를 아는 것이 중요하다.
  • 환경에 휘둘리지 않으면서 내가 정한 기준으로 묵묵히 걸어갈 수 있는 용기를 갖자
  • 경험이나 실력이 쌓이다보면 나의 모름을 인정하는 게 쉬운 일이 아니다. 그런데도 불구하고 본인의 모름을 초심자 앞에서 인정하는 모습이 멋져보였다. 나의 모름을 인정하고 꾸준히 성장하자
  • 주어진 일만 하는 게 아니라 주도적으로 일을 찾아서 적용하자
  • 시키는대로 하는 것이 아니라 근거만 확실하다면 내 주장을 펼칠 줄 알아야 한다
  • 누군가 모르는 게 있다면 화이트보드를 동원해서라도 최대한 이해할 수 있도록 설명하자
  • 어딜가도 업무를 빨리 익힐 수 있도록 적응력을 기르자
  • 어떤 문제를 겪었을 때 바로 해결하자(미루지 말고 바로)
  • 표준화하려고 노력하자
  • 문서화를 잘하자 (누군가 처음 들어와도 해당 도메인을 이해할 수 있도록)
    • 레퍼런스가 충실한 글
    • 개성을 줄이고 건조하게 쓴 글
    • 남에게 수정 가능성을 열어둔 글
    • 일관된 구성
  • 내가 당연하게 쓰고 있는 기술을 잘 알고 있나?
  • 문제가 발생했을 때 해결방안보다는 원인을 분석해서 그 원인에 대해 공부하고 해결방안을 공부하자
  • 회사의 Context들을 관리하기 쉽게 한 곳에 저장하고 공유하자
  • 변화는 생각보다 어렵다. 그래서 실패해도 괜찮다.
  • 개발자의 시야는 좁다. 개발은 여러 단계 중 하나라는 걸 자각해야 한다
  • 이슈를 많이 만들고 많이 닫자. (지금 내가 뭘 하고 있는지 PM에게도 알릴 수 있다)
  • IDE와 이슈 상태를 연계해서 개발에 집중할 수 있도록 하자
  • TDD나 스크럼같은 제도가 중요한 게 아니라 사람이 중요합니다. 사람이 제도를 만들어갑니다
  • 코드리뷰를 하자. 코드리뷰는 생각보다 나를 더 성장시켜준다.
  • 이 회사가 어떤 문화가 있느냐보다 내가 와서 얼마나 바꿔갈 수 있느냐가 중요하다
  • 우리 팀은 금요일 오후에 배포할 수 있는 팀일까?
  • 프로일수록 공수산정의 오차가 적다. (자신의 실력 파악 및 버퍼까지 생각)
  • 설계는 완벽할 수 없다. 설계의 큰 틀만 잡고 바로 개발에 들어가자
    • 설계의 아웃풋 중, Flow를 이해하는 게 중요하다
  • 유지보수성이 높은 코드
    • 프록시, 퍼사드, 팩토리, 델리게이트 패턴 사용
  • 좋은 질문은 오히려 좋은 평가를 받는 초석이 된다. 나쁜 질문이라도 안 물어보고 결과를 망치는 것보다는 훨씬 나으며 그를 통해 질문 스킬을 향상시키면 된다.
  • 부탁은 언제나 거절당할 수 있다. 상대방의 거절에는 합리적인 이유가 있을 것이다.
  • 만약 내 질문이나 부탁이 시급한 것이라면 이를 명시하여 그들의 의사결정을 돕는다. 만약 일정 시간이 지나도 응답이 없다면 다시 메시지를 보낸다. 이는 재촉이 아니라 정중한 확인 요청이다.
  • 나는 동료에게 무언가를 부탁받았을 때, 맥락 이해가 잘 되지 않는다면 얼마든지 컨텍스트 보충을 요청할 수 있다. 예를 들어 ‘우리가 그 문제를 해결하는 게 지금 시점에 왜 중요하다고 보는가?’를 묻는 것이며, 이는 상대방이 가진 권위와 상관없이 이루어져야 한다. 마찬가지로 내가 동료에게 도움을 요청할 때는 언제나 충분히, 정확하게 컨텍스트를 공유하려고 노력해야 하고, 상대방이 나에게 역으로 뭔가 질문하거나 요청할 수도 있음을 감안해야 한다. 누구라도 나의 말에 의문을 표하고, 더 자세히 말해주길 요청하고, 정정해주고, 반박 의견을 개진할 수 있다.
    • 이는 현상이 아닌 본질에 더 집중하기 위함이지 상대를 공격하기 위함이 아니다. 질문에 대한 답변을 듣고 도움을 받았을 때에도 당연히 감사를 표해야 하지만, 본질에 집중하게 해주는 좋은 질문을 받았을 때에도 감사인사를 하자.
  • 90%에서 중단하지 말자. 프로젝트가 끝났어도 아직 할 일이 있다.
    • 작업한 내용을 다른 팀에게 발표하기
    • 동료들이 나중에 사용할 수 있게 코드를 어디엔가 올려두기
    • 작업에 대한 블로그를 작성하기
    • 계속 진행할 계획이 없더라도, 다음 작업에 대한 문서를 작성하기 (다음에 할 일과 이유를 설명)
    • 작업한 것에 구멍을 발견할 수 있는 사람을 찾고 그 문제를 해결하기
    • 공유하기, 문서화, 다듬기는 매우 중요하다.
  • 마지막 1%까지 마무리하기 (사실 1%는 아닌 거 같다)
    • 유지보수 문서 작성
    • How to, FAQ 문서 작성
    • 퍼포먼스, 사용량, 오류 지표 대시보드
    • 테스트 자동화 등등..

의사소통

  • 미리 일정 공유하기
  • 맥락 파악하고 명확하게 공유하기
  • 몰라요, ~같아요 같이 애매한 말 하지 않기
  • 왜 해야하는 지 물어볼 때 말투 신경쓰기
  • 리액션하기 (관심은 인간의 기본 욕망)
  • 커뮤니케이션의 기본은 자기 개방
  • 긍정이든 부정이든 빠른 답변

개발 방법

  • 일을 적절히 분리해서 진행하고 우선순위를 이해한다.
  • 일단 최소한의 기능을 가진 프로덕트로 개발하자. 최소한의 기능을 가진 프로덕트로 개발해야 quick & dirty로 만들어도 그 과정에서 쌓이는 기술 부채가 얼마 되지 않는다.
  • quick & dirty로 개발하는 방법
    • 잘못된 추상화만큼 코드를 재앙으로 이끄는 것도 없다. 초기에 좋은 추상을 하기 힘들다면 추상화를 하지말고 미뤄라
    • 좋은 extract method가 떠오르지 않는다면, 그냥 하지 않는 게 더 낫다
    • 상속 구조는 OOP에서 가장 잘하기 어려운 부분이다. 상속 계층은 되도록 만들지 않는 게 좋다
    • depth를 늘리지 마라
    • 안 쓰는 코드, 파일은 빠르게 삭제하자
    • 코드 외의 기술적인 사항은 반드시 문서를 남기자
      • 소스를 어떻게 빌드하는지
      • 서버를 어떻게 배포하는지
      • 서버에서 어떤 cron job이 돌고 있는지
      • 권한은 어떻게 줬는지
      • 서버 시작과 중단은 어떻게 하는지
      • 서버에 어떤 설정 파일을 건드렸는지 등등…
  • Quick & dirty 방식으로 접근하되 항상 품질을 염두에 두고 접근하자
  • Quick & dirty 후에는 반드시 Clean 과정이 포함되어야 한다
  • 버저닝 시스템을 확립하자. 일자 + 빌드 버전같은 방식으로.
  • 슬랙에 나의 상태를 표시한다. (휴가중, 개발중등등…)
  • 공식 문서를 제대로 읽는다
  • 로그를 제대로 따라가자
  • 요청 API나 DB IO에서 페이징, 청크 단위로 나눠서 보내자
    • 한계를 지정하면 일정한 성능을 낼 수 있다
    • 오류에도 청크 단위로 분리되니 유연하게 대응할 수 있다
    • 메모리에 들어가는 단위도 한 번에 다 들어가는 게 아니고 청크 단위로 들어가니 더 유연하다.
  • 기본적인 CRUD는 사용자 요청이 없더라도 만들어놔야 한다. 직접 API 콜을 통해서 삭제할 일이 있기 때문에.
  • 다른 큰 컬렉션 안에 큰 컬렉션을 중첩하지 말자. 그러면 가지고 오는 데이터가 엄청나게 커질 수 있다. 차라리 API를 나눠서 단위로 나눠서 가져오도록 하자.
  • API 속도 제한. rate limit을 걸어놓자.
  • 코드를 작성하기 전에 설계의 문제점을 찾는 게 훨씬 더 효율적이다.

끊임없이 고민하기

  • 나는 어떤 삶을 살 것인가?
  • 나는 왜 프로그래머가 되려고 하는가?
  • 나에게 프로그래밍이란 어떤 의미인가?
  • 나는 어떤 개발자로 살 것인가?
    • 체계가 없다면 체계를 만드는 개발자
      • 기술 블로그 활성화, 테스트코드 스타일 등…
    • 회사의 코드 수준을 높이는데 일조하는 개발자
    • 실수하더라도 실수하고 얻은 인사이트를 공유하는 사람
  • 나는 지금 Comfort Zone에 있는 건 아닐까?

개인 프로젝트

  • 개인 작업을 할 때는 반드시 기간을 정해놓자.
  • 대충 해도 괜찮으니 무조건 완성시켜라.
  • 완벽할 필요 없다.
  • 다양한 시도를 해봐라.
  • 내가 왜 이런 기술을 썼는지 블로그에 글을 쓰자
  • 로컬에서 작동하는 버전을 만들어두자
  • 다양한 환경(웹, 모바일 등등)에서 돌아가는 영상을 찍어두자.
  • 가능한 혼자서 하자. 디자인과 개발 모두 혼자 해보자. 같이 하면 스케줄 자체가 달라서 일정이 꼬인다.
  • 내가 한 번 만들어본 걸 다시 만들어보는 게 중요하다. 새로운 관점이 보인다.

좋은 팀이란?

  • 고민을 이야기할 수 있는 사람이 있는 팀
  • 혼자서 서비스를 맡는 것이 아니라 사수가 있는 팀

성장하는 방법

  • 이종립님의 경우, 자신의 글을 랜덤을 볼 수 있는 랜덤버튼을 활용한다고 한다. 보통 글을 작성하면 다시 보지 않는다. 즉, 신입일 때는 잘 모르고 썼던 글이 틀릴 수도 있고 업데이트가 필요한 글일 수도 있다는 것이다. 종립님은 자기 전에 랜덤 버튼으로 자신의 글을 5개 정도 읽으신다고 한다. 그리고 새롭게 알게 된 정보가 있으면 추가하고, 잘못된 정보가 있으면 업데이트하고. 이로써 자신도 다시 공부하고 남들에게 더 나은 정보를 제공해줄 수 있다.

출처