Medium - 4 Habits That Make You an Inefficient Developer
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 비효율적인 개발자로 만드는 4가지 습관; 여러분은 안좋은 개발자가 아니라 단지 안좋은 습관들을 가지고 있을 뿐입니다.
Photo by Joshua Hoehne on Unsplash
우리는 모두 나쁜 습관을 가지고 있습니다. 지구 상에 누구라도 완벽한 사람은 없죠. 개발자로서 나쁜 습관을 가지고 있는 것은 여러분의 효율성에 심각한 데미지를 줍니다. 그리고 여러분 주변에 있는 사람에게까지 영향을 줄 수 있죠. Jack Canfield는 여러분의 습관이 미래를 결정한다고 말했습니다. 개발자로 성장하고 싶다면 나쁜 습관들을 깨부숴야 합니다. 만약 그렇게 할 수 있다면 여러분의 효율성은 엄청나게 상승할 것입니다. 그러니 나쁜 습관들에 대해 알아보고 가능한 빨리 깨버립시다.
Saying Yes to Everything
먼저 말씀드리자면 모든 것에 긍정하는 것은 매우 겸손하고 이기적이지 않은 것입니다. 다른 사람을 돞고 싶어하고 손해를 감수하는 것이죠. 그러나 모든 것에 “네”“라고 하는 것은 엄청난 생산성 킬러입니다. 결국에는 여러분은 아마 코드를 여러분 스스로 전달해야 할겁니다.
제 말은 다른 개발자들을 돕지말아야 한다는 것이 아닙니다. 다만 여러분의 생산성을 죽이지 말라는 것입니다. 어떤 게발자는 엄청나게 많은 것을 묻는 경향이 있습니다. 아주 작은 것마다 여러분에게 찾아와서 도움을 구하죠. Paulo Coelho는 여러분이 타인에게 yes라고 할 때마다 스스로 no라고 말하지 않을 것인지 확실하게 하라 고 했습니다.
만약 스스로 거절하는 데 어려움이 있다면 다른사람들에게 특정 시간에만 여러분의 책상으로 오라고 하세요. 스스로에게 집중할 수 있는 시간을 줘서 작업을 마무리 할 수 있게 하세요. 이것은 또한 다른사람들에게 스스로 문제의 해결책을 찾아볼 수 있도록 하는 것으로 그냥 당신에게 물어보기만 하는 것을 줄일 수 있습니다. 만약 그들이 진짜 답을 못찾더라도 질문을 작성하거나 문제를 축소시킬 수 있습니다. 결국에 그들은 여러분의 자리에 질문이 적힌 종이와 함께 나타날 것입니다. 이것이 여러분의 많은 시간을 절약시킬 것입니다. 왜냐면 질문 하나가 생길 때 마다 방해받는 것이 아니라 한번에 모든 질문을 봐줄 수 있으니까요.
Your Definition of the Word “Done” Is Probably Not Really “Done”
개발자들마다 “done”이라는 단어의 의미가 다르기 때문에 누군가는 아마 done의 의미가 수만가지는 될 것이라고 합니다. 애자일팀에서 예를 들면 개발자는 스프린트를 완수하고 싶어합니다. 이것은 엄격한 시간제한이 있고 개발자는 낭비할 시간이 없는 것처럼 느껴지죠.
done이라는 단어의 정의가 달라도 적어도 최소한 해당 단어는 피쳐의 코드를 작성하는 것보다는 많은 것을 포함하고 있을 겁니다. 여러분이 완료했다고 생각을 할때마다 한번은 심사숙고해서 결과물을 들여다봐야 합니다. 코드는 리팩토링하셨나요? 여러분의 코드를 다른 개발자들이 이해할 수 있을까요? 이런 질문들 중에 하나라도 no가 나온다면 당장 고치세요!
문서화는 어떤가요? 이번 피처에 필요한가요? 테스터가 어떻게 피처가 테스트될 지 알고 있나요? 테스터가 알아야할 사전정보는 없나요? 테스터에게 피쳐가 어떻게 될 것인지 말해주는 것은 서로에게 많은 시간을 절약해 줍니다. 캘리포니아 대학의 Gloria Mark의 연구에 따르면 평균적으로 한번 방해를 받으면 다시 집중하는데 23분이 걸린다고 합니다.
마지막으로 진짜 최소한 결과물에 테스트는 하셨나요? 단순히 happy-path 시나리오를 말하는 것이 아닙니다. 테스트에 관한 습관은 다음에서 이어집니다.
Not Testing Your Own Code
개발자가 되는 것에서 좋아하는 부분이 있다면 분명 그게 테스트는 아닐 것입니다. 모든 개발자들은 자신의 코드를 테스트할 때 좀 게을러지기 마련이죠. 해피-패스 시나리오 대로 클릭을 하는 것은 아마 모든 개발자들이 그렇게 하고 있을 것입니다. 이 나쁜 습관은 올바른 피처를 전달하기 까지 많은 시간을 소비하게 합니다. 적절하게 코드를 테스트 하지 않으면 테스터는 수분내로 버그를 찾아낼 것입니다.
테스터가 버그를 리포트하면 여러분은 같은 코드를 또 손봐야합니다. 추가적으로 테스터는 여러분이 고친걸 또 테스트 해야합니다. 이건 진짜 정말 비효율적인 것이죠. 테스트가 개발 시간을 증가시킨다? 아닙니다. 이것은 완전히 잘못된 인식입니다. 테스트는 오직 여러분이 테스트를 적절하게 하는 것을 알지 못하는 초기 단계에만 개발시간을 증가시킵니다. 여러분은 테스트를 개발 프로세스에서 중요한 것으로 생각하고 적절하게 수행해야 합니다. 그리고 이것이 좋은 습관이 됩니다. 테스트는 많은 시간을 절약시켜주고 미래의 두통으로부터 구해줄 것입니다.
Making Commits That Are Much Too Big
하나의 비효율적인 습관은 너무 큰 덩어리로 커밋을 하는 것입니다. 거대한 커밋은 숲에서 나무를 보지못하게 하는 것처럼 만듭니다. 커밋에서 너무 많은 것이 바뀌었기 때문에 실제로 뭐가 바뀌었는지 불분명해 지는 것이죠. 게다가 백줄이 넘는 코드가 바뀐 것을 리뷰하면 기분이 어떻겠어요? 아마 저주하고 싶을 겁니다. 아마 해당 커밋을 리뷰하고 싶은 생각도 안들겠죠.
스몰 커밋은 여러분의 친구입니다. 이것은 개발자들이 더욱 커밋 메시지를 잘 구성할 수 있게합니다. 그리고 미안하지만 “fixed some issues”는 전혀 서술적인 커밋메시지가 아닙니다. 코드리뷰는 작은 커밋일 수록 더욱 쉬워집니다. 작은 커밋은 그때 변한 것만 리뷰할 수 있기 때문에 리뷰어에게 개발자의 생각의 흐름을 잘 이해할 수 있도록 해줍니다.
작은 커밋은 디버깅 또한 쉬워집니다. 특정 커밋으로 롤백해서 버그가 존재하는지 안하는지 테스트하기 쉽습니다. 커밋이 작은 경우 버그가 어디에 있는지 찾아도 버그를 발생시킨 코드가 작을 것입니다. 이런 것이 많은 노력없이 작업을 더욱 효율적으로 만들 것입니다.
Summary
- 작은 커밋; 코드 리뷰 및 디버깅의 효율을 높여줌
- 모든 것에 Yes 라고 하는 것; 업무에 집중할 수 있는 시간을 확보할 것
- 테스트를 게을리 하는 것; 적절하게 테스트 하는 법을 배워야 함
- 작업 마무리를 확실하게 하지 않는 것; 문서화, 기본적인 테스트를 비롯해 한번 한 일을 또하게 하지 않도록 하는 것
