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

복잡한 소프트웨어는 조금만 수정해도 문제가 생기죠. 이런 소프트웨어를 담당한다는 것은 개발자에게 악몽이나 다름 없습니다. 이렇게 잘못 만들어진 소프트웨어는 대부분 개발자의 잘못된 마인드 셋에서 비롯 되는데요. 관련해서 오늘은 dev.to에 올라와 있는 글 중 Fundamentals of Good Developer Mindset 이라는 글을 읽고 그 내용을 요약 정리해봤습니다.

 

원문 : Fundamentals of Good Developer Mindset

 

버그를 고치면 새로운 버그가 생기고, 작은 변경도 어렵고, 이전에 만든 코드를 재사용하지도 못하고 중복 코드를 양산하게 되는 소프트웨어가 있다. 이런 소프트웨어를 만들지 않으려면 어떤 Mindset을 가져야 할까?

1. 소프트웨어의 목적

개발자는 의사결정을 할 때 가장 먼저 소프트웨어의 목적을 생각해야 한다. 소프트웨어의 목적이 무엇인가? 바로 사용자에게 도움이 되어야 한다는 것이다. 나쁜 개발자는 사용자에게 그다지 도움도 되지 않으면서 쓸데없이 복잡한 소프트웨어를 만든다. 따라서 개발할 때는 항상 이 소프트웨어가 사용자에게 어떤 도움을 줄지를 염두에 두어야 한다.

2. 소프트웨어 디자인

소프트웨어 디자인(설계)이 잘못되면 기능을 추가하거나 수정이 어려워진다. 결국 유지보수가 어려운 시스템이 되고 수명은 짧아질 수 밖에 없다. 소프트웨어 디자인은 개발자의 일을 쉽게 만든다. 따라서 소프트웨어 디자인을 할 때는 미래의 자신과 다른 개발자들을 고려하여야 한다.

3. 이해와 오해

무엇을 개발하지는 제대로 이해하지 못한 개발자는 시스템을 복잡하게 만든다. 그리고 부족한 이해와 오해는 악순환을 반복한다. 특히 나쁜 개발자는 자신이 하는 일에 대해 완전히 이해하지 않은 채 일을 시작하곤 한다.

4. 간결하게 만들기

프로그래밍은 복잡한 것을 간단하게 만드는 일이다. 좋은 개발자는 쉽고 간결한 코드를 생산한다. 반면 나쁜 개발자는 복잡성을 줄이지도 못하고 오히려 증가시킨다. 가끔 자신의 똑똑함을 증명하기 위해 다른 개발자가 이해하기 어려운 코드를 만드는 개발자가 있다.

5. 복잡성 관리

복잡함을 관리하는 것은 프로그래밍의 핵심이다. 소프트웨어가 실패하는 이유는 복잡하기 때문이다. 좋은 개발자는 새로운 기능을 추가되더라도 늘어난 복잡성을 관리할 수 있어야 한다.

6. 유지보수

유지보수는 소프트웨어 개발에서 중요한 부분을 차지한다. 그런데 나쁜 개발자들은 이를 무시한다. 빠른 개발과 배포가 더 중요해보일 수도 있다. 그러나 미래의 유지보수를 무시한다면 재앙이 될 것이다. 당신이 직접 유지보수를 하지 않더라도 미래의 개발자를 위해 유지보수에 대한 부분을 충분히 고려하자. 

7. 일관성

변수나 함수 이름을 지을 때는 일관성을 유지해야 한다. 들쑥날쑥한 명명법은 코드의 복잡성을 증가시킨다. 다시 말하지만 복잡성은 소프트웨어가 실패하는 가장 큰 원인이다.

8. 우선순위

소프트웨어를 수정해야할 때 어떤 기준으로 우선순위를 결정해야할까? Code Simplicity라는 책에서는 다음과 같은 기준(D=V/E)을 제시하고 있다.

• 변경 우선순위 (D : The desirability of a change)
• 변경으로 인해 어떤 가치를 얻는가 (V : The value of a change)
• 얼마나 effort가 들어가는가 (E : The effort required to perform the change)

그리고 D = V/E 공식으로 우선순위를 결정한다. 다시 말해 얼마나 작은 변경으로 얼마나 많은 가치를 얻을 수 있는지 그 비율를 측정하여 우선순위를 정하는 것이다.

9. 문제 해결

문제 해결의 첫 번째 단계는 상황을 이해하는 것이다. 문제 상황을 손으로 적고 다른 사람에게 설명해보라.

두 번째 단계는 계획이다. 절대로 바로 코드 타이핑부터 하지 말라.

세 번째 단계는 분류이다. 큰 문제를 한방에 해결하려고 하지 말라. 작은 task로 나누고 하나씩 해결해야한다.

10. 적당한 완벽주의

Perfect is the enemy of good 

완벽함이 무조건 옳은 것은 아니다. 개발자 중에는 처음부터 상세하게 계획을 짜는 개발자도 있다. 하지만 그러면 정작 문제의 본질인 사용자들에게 어떤 도움이 줄지를 생각하지 못하게 된다. 처음부터 완벽할 수는 없다. 작게 시작하고 그것을 개선하고 확장하는 방식으로 일을 진행하라.

 

글이 너무 길어지니 다음 항목들은 2편에서 다뤄보도록 하겠습니다. 잘못된 내용이 있으면 답글로 남겨주시면 수정하도록 하겠습니다. 

 

11. 예측

12. 가정

13. 중복 개발

14. 저항성

15. 자동화

16. 코드 측정

17. 생산성

18. 테스트

19. 과소평가

20. 재작성 금지

21. 문서화와 주석

22. 기술 스택 선택

23. 자기 개발

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

25. 질문하지 말고 도움을 요청하라

 

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

 

**