개발자가 알아야 할 기본적인 것들, Quora 번역

개발자의 입장에서 피가 되고 살이 될 것 같은 문구들을 간단히 우리 말로 옮겨 놓으려고 한다. 우리 존재 파이팅

* 오역 지적 환영합니다.

개발자가 알아야 할 기본적인 것들에는 무엇이 있을까요?

5.4k upvotes, Gavin Thorn, Wrote my first program on a Sinclair ZX-81, remember those?

1. 테스트 되지 않은 코드는 작동하지 않는 코드와 같다.
2. 소스 관리는 당신의 친구다. 꼭 사용하라.
3. 단지 당신이 쓴 코드라고 해서 당신만의 전유물로 생각하지 말라.
   다른 팀원이 당신의 코드를 수정한다고 해서 기분 나빠할 일은 아닌 것이다.
4. Don't reinvent the wheel, 라이브러리는 쓰라고 있는 것이다.
5. 가장 빠른 코드는 실행되지 않는 코드이다. Look for early outs.
6. 당신이 쓴 코드만이 훌륭한 코드는 아니다.
7. 코드는 컴파일러에게 당신이 하고 싶은 일에 대한 지시를 줄 뿐이지, 실제 그 일을 하는 것은 아니다.
8. 이해하기 어려운 코드는 유지 보수하기도 어렵다.
9. 유지 보수하기 어려운 코드는 쓸모 없는 코드와 같다.
10. "이 파일을 수정하는 동안 #$%@#@를 해야지" 라고 생각하는 것은 이상한 기능과 버그를 만들어내는 훌륭한 방법이다.
11. 코드의 레이아웃이 깔끔해질 수록, 코드의 가독성은 좋아진다.
    코드의 가독성이 좋아질 수록, 이해하기 쉽고 유지 보수하기 좋은 코드가 된다.
12. 코드 자체로 문서의 역할을 하진 않는다. 동료들을 위해 코멘트를 작성하라. 당신은 5년 뒤에 코멘트 없이 이해할 수 있을까?
13. 당신이 남긴 구린 코드는 계속 당신을 따라다닐 것이다.
14. 5분 걸릴 일은 사실 한나절 정도 걸릴 일이다.
15. Magic numbers are bad.
16. 상수는 자리를 차지하지 않고 컴파일될 때 바꿔치기 되는 것이다.
17. 프로젝트 관리자는 항상 우리가 2배 빠르게, 그리고 2배의 일을 해내길 바란다.
18. 버그가 있다면, 고객은 결국 알게 될 것이다.
19. 코드 리뷰는 서로 비평하는 시간이 아니다.
20. 코드의 양(quantity)은 문제 거리가 아니다. 코드의 질이 중요한 것이다. 어떤 멍청이라도 수 천 줄의 코드를 쓸 수 있지만, 그 코드가 제대로 기능한다고 볼 수는 없다.
21. 구린 코드의 진정한 비용은 유지 보수 측면에서 나온다.
22. 네 똥은 네가 치워라. 당신이 쓴 코드에서 버그를 해결하는 것은 당신 실력을 향상 시켜주는 일이다.
23. 코드는 시간이 지나면 썩게 마련이다.
24. 고객이 요청하지 않는 기능을 당신이 신경 쓰지 마라.
25. 정말 중요한 사항이므로 다시 한 번 적는다. 테스트 되지 않은 코드는, 작동하지 않는 코드와 같다.

3.2k upvotes, Brian Knapp, Christian, author of Creative Genius. Email hi@brianknapp.me

1. 구린 코드보다 구린 아키텍쳐가 더 심각한 문제다.
2. 코딩보다는 생각하는 시간을 더 가져야 한다.
3. 연봉을 더 받는 최고의 방법은, 취직하기 전에 연봉 협상을 잘 하는 것이다.
4. 코딩 실력보다는 인간 관계 실력이 당신의 성공에 더 큰 영향을 미친다.
5. 사용자들은 그들의 문제를 해결하기 위해 (개발자가 의도하지 않은) 별 이상한 방법을 찾아낸다.
6. (버전 관리) 커밋을 더 자주 하라.
7. (버전 관리) 언제나 feature 브랜치에서 작업하라.
8. 기본적인 UNIX 활용 능력은 도움이 되지만, 필수적인 것은 아니다.
9. Vim이나 Emacs는 당신을 새로운 세상으로 인도할 것이다.
10. 모든 추정치는 거짓말이고, "좋은 추정치"는 새빨간 거짓말이다.
11. 80%의 개발자는 맡은 바의 일을 하기에도 버거운 사람들이다.
12. 기업은 돈을 벌기 위해 존재하는 것이지, 코드를 짜라고 존재하는 것이 아니다.
13. 소프트웨어는 문제를 해결하라고 있는 것이지, 예술을 하라고 있는 것이 아니다.
14. 애자일은 트랩이다. 당신은 벗어날 수 없지.
15. 80%의 개발자는 자기 개발을 위해 어떠한 노력도 하지 않고, 회사 일만 한다.
16. 상사들은 당신을 언제든 교체 가능한 자원이라고 생각한다.
17. 직장은 직장일 뿐, 가족도 아니고 교회도 아니고 종교도 아니다.
18. 기업 문화라는 것은 종종 당신의 연봉을 낮추기 위한 수단으로 쓰일 수 있다.
19. 최고의 개발자는 항상 무언가 만들어내는 사람이다.
20. 어떤 IDE를 쓰냐는 중요한 문제가 아니다.
21. 어떤 언어를 쓰느냐 역시 중요한 문제가 아니다.
22. 어떤 framework을 쓰느냐 역시 또한 중요한 문제가 아니다.
23. 이러한 기술적인 논쟁은 초딩들이 로봇 장난감 가지고 싸우는 것과 똑같은 것이다.
24. 스타트업 대박이 난다고 해서 당신이 부자가 되진 않을 것이다.
25. QA 테스터들과 친하게 지내라. 그들이 당신의 삶의 질을 올려줄 것이다.
26. 항상 당신의 회사가 어떻게 돈을 버는지 알아둬라. 그래야 당신이 누구에게서 월급을 받는 건지 알 수 있다.
27. 당신이 software developer로서 일하는 것을 중요하게 생각한다면 tech company에서 일을 해야 한다.
28. (비개발자) 사람들은 항상 새로운 기능을 추가하는 것을 기존 코드의 리팩토링보다 우선적으로 생각한다.
29. Sometimes a train wreck has to happen for anyone to care about the brakes.
30. You are not your job. 일에 먹히지 말라.

1.6k upvoted, Robin Thomas, Software Engineer at Works Applications (2016-present)

1. 당신의 첫 코드는 절대 원하는 대로 작동하지 않을 거야. 이것을 받아들이고 앞으로 나아가면 돼.
2. 절망과 좌절은 당신의 최고의 친구가 될 거야. 서로 친하게 지내도록.
3. 인내심이 당신의 미덕이 아니라면...... 미덕으로 삼기를 바라! 앞으로 인내할 일이 많아질 거야.
4. 디버깅하는 법을 빨리 배워 놔. 코딩보다 디버깅을 하는 시간이 더욱 늘어나게 될 거야. 기계가 대신 코딩해주지 않을 거라면 말이지.
5. 탭 vs. 스페이스, Vim vs. Emacs, Windows vs. Linux, C++ vs. Java vs. Python, Atom vs. Eclipse vs. Sublime ... 이런 전쟁에서는 한 발 빠지도록 해.
6. 동료들은 코딩을 도와주는 당신을 우러러 보고, 컴퓨터를 고치는 당신을 내려다 봐.
7. 성급한 최적화는 피하자. Python을 사용한다고 해서 몇 microseconds 손해 볼 수 있는데, 사실 그거 별 일 아냐.

---

참조 링크

Quora 원본
https://www.quora.com/What-are-some-of-the-most-basic-things-every-programmer-should-know