좋은 개발자가 갖춰야 하는 마인드 셋 (요약) - 2편

좋은 개발자가 갖춰야 하는 마인드 셋 (요약) 1편에 이어 나머지 항목들을 살펴보도록 하겠습니다. 참고로 아래 글은 Dev.to에 올라와 있는 글 중 Fundamentals of Good Developer Mindset 이라는 글을 읽고 그 내용을 요약 정리한 글입니다.

 

좋은 개발자가 가져야할 마인드 셋

원문 : Fundamentals of Good Developer Mindset

 

11. 예측

나중에 어떤 기능이 추가될지 너무 예측하다보면 자칫 오버 엔지니어링에 빠질 수 있다.

12. 가정

앞서 예측과 마찬가지로 가정에 기반한 개발도 지양해야 한다. 예를 들어 X가 필요해서 개발을 하다가 나중에 Y도 필요해질 것 같아서 Y까지 구현하는 개발자가 있다. 하지만 미래에 Y가 전혀 필요 없게 되거나 Z를 만들기 위해 Y를 제거해야한다면 불필요한 작업이 추가되게 된다. 따라서 개발자는 현재 상태에서 본인이 확실히 알고 있는 것에 기반하여 개발해야 한다. 절대 미래를 예측하거나 가정해서 코드를 짜지 말자.

13. 중복 개발

소프트웨어 개발에서 중복 코드는 지양해야 한다. 마치 바퀴를 새로 만드는 것처럼 백지 상태에서 부터 새로 개발하는 개발자도 있다. 다음 상황이 아니라면 바퀴(이미 있는 기능이나 코드)를 새로 만들지 말자.

• 필요한 기능이 아예 존재하지 않는 경우
• 기존에 바퀴가 있지만 너무 오래 되서 관리가 어려운 경우
• 바퀴가 전혀 유지보수가 안되고 있는 경우

14. 저항

개발자로서 변경 요청에 대한 첫 반응은 "No"여야 한다. 언제나 코드를 추가하는 것에 저항하자. 단, 그 기능이 필요하다고 확신하는 경우에는 구현해야한다. 어떤 기능이 필요한 것일까? 다시 뒤로 돌아가서 소프트웨어의 목적을 생각해보자. 그리고 작업의 우선 순위 공식 D = V/E를 적용해보자.

15. 자동화

반복되는 일에 시간을 낭비하지 말자. 그 작업을 잊을 만큼 자동화 작업을 세팅하자. 하던 일을 계속 반복하고 있다고 생각된다면 당장 자동화를 고려해보자.

If you can automate it, automate it.

16. 코드 측정과 소프트웨어의 질

코드 라인수로 소프트웨어의 질을 측정하는 것은 웃기는 일이다. 정말 잘 만들어진 소프트웨어는 간결한 코드로 이루어져 있다. 물론 코드 라인수가 적다고 무조건 좋은 것도 아니다. 적당한 균형점을 찾아한다.

17. 생산성

생산성은 어떻게 측정할 수 있을까? 수 많은 코드를 만드는 것이 생산적일까? 변경이 있을 때 개발자의 목표는 최대한 적게 코드를 수정하는데 있어야 한다

18. 테스트

언제 로그와 에러 핸들링을 남겨야 할까? 로그는 개발 초기 단계부터 남겨야 한다. 초기 로그는 문제를 빠른 시일에 찾게 하고 시간을 절약해준다. 그리고 테스트 코드는 꼼꼼히 남겨야 한다. 예를 들어 if else 문이 있다면 if문과 else문을 모두 테스트할 수 있어야 한다.

Untested code is the code that doesn't work

19. 과소평가

작업이 주어지면 얼마나 시간이 걸릴지 예측한다. 대부분 개발자가 이를 과소 평가하여 힘들어한다. 왜냐하면 문제를 뭉뚱그려서 보기 때문이다. 반드시 작은 task로 쪼갤 수 있을 때가지 쪼개서 개발 기간을 평가해야 한다. 

Everything takes longer than you think

20. 재작성 금지

나중에 고쳐야지 생각하고 일단 코드를 쓰는 개발자가 있다. 코드는 만드는 것보다 읽는 것이 더 어렵다.

21. 문서화와 주석

"이 코드는 이런 일을 한다"라는 식으로 줄줄이 주석을 남기는 개발자가 있다. 사실 이런 주석은 달리면 안된다. 코드는 가독성이 있어야 하고 읽었을 때 어떤 일을 하는지 명확히 보여줘야 하기 때문이다. 어쩔 수 없이 간결한 코드를 만들었을 때 그 보완으로 주석을 남기는 것이다.

그리고 주석은 이 코드가 "무엇을 하는지"가 아니라 "왜 내가 이 코드를 만들었는지"를 적어야 한다. 이런 내용이 없다면 다른 개발자가 그 코드를 수정할 때 많은 고민을 하게 될 것 이다..

Write a comment to explain "WHY", not to explan "WHAT".

22. 외부 기술 선택 (외부 라이브러리, 도구 사용)

외부 라이브러리와 도구에 과도하게 의존하는 것은 소프트웨어 복잡도를 높이는 원인이 되기도 한다. 심지어 이미 배포된 시스템에 치명적인 영향을 미칠 수 있다. 외부 라이브러리를 사용할 때는 다음 항목을 점검해봐야 한다.

• 실제 운영환경에서 사용된 사례가 있는 라이브러리인가
• 유지보수가 계속 되고 있고 계속될 것인가
• 문제가 생겼을 때 다른 라이브러리로 바꾸기 쉬운가
• 개발자 커뮤니티에서의 평판

23. 자기 개발

개발자는 계속 공부해야한다. 다른 언어도 배우고 툴도 배우자. 책을 읽고 직접 개발도 해봐야 한다. 이런 활동이 개발자의 시야를 넓혀준다. 그리고 이렇게 쌓인 작은 변화가 실력이 되는 것이다. 절대로 하나의 기술에 집착하지 말자. 

24. 영웅이 되려고 하지 말라

도움이 필요할 땐 선후배 상관없이 요청을 하자. (단, 막무가내식으로 하면 곤란하겠죠? 먼저 할 수 있는 것은 해보고 도움을 요청합시다)

그리고 매몰비용에 집착하지 말자. 잘못된 길로 가고 있다고 생각하면 매몰비용(개발에 들어간 시간 등)에 관계 없이 방향을 수정해야 한다.

25. 질문하지 말고 조언을 요청하라

모르는게 있다고 바로 질문하면 안된다. 먼저 할 수 있는 방법을 최대한 다해보고 그래도 전혀 모르겠다면 검색을 해보자. 그래도 해결책을 찾지 못했다면 질문보다는 조언을 요청하자.

 

이상 좋은 개발자가 갖춰야 하는 마인드 셋에 대한 글을 요약 정리해봤습니다. 글이 워낙 길어서 마지막쯤 가니 집중력이 떨어지네요. 혹시 잘못된 내용이 있다면 답글로 꼭 알려주시고, 좋은 개발자 마인드로 커리어를 잘 꾸려가시길 바랍니다.

 

** 336x280 **