몇 달전에 회사의 선배분께서 읽어보라고 주셨던 링크입니다만.. 드디어 다 읽어 보았네요..
정말로 열심히 공부해야겠습니다..
https://hackernoon.com/few-simple-rules-for-good-coding-my-15-years-experience-96cb29d4acd9에서 가져온 글입니다.
틀린 부분 지적 정말로 감사합니다.(저를 때려 주.. 으읍.. 지적 해주십시오!)
좋은 코딩을 위한 13가지 규칙(나의 15년동안의 경험에서 발췌)
안녕 여러분들, 난 프로그래머로서 15년보다 더 일하면서 다양한 언어들, 패러다임, 프레임워크와 그외의 망할것들을 사용해왔어. 그리고 난 좋은 코드 작성법의 나의 규칙을 공유하고자해.
1. 최적화 VS 가동성. 최적화는 꺼져버리라고 해.
항상 개발자들이 이해하기 쉽고 읽기에 간단한 코드를 작성해.
왜냐하면 당신이 최적화시키는 것보다 코드를 읽는 시간과 자원이 더 많기 때문이니까.
만약 당신이 최적화시킬 필요가 있다면 DI(Digtal input)와 같은 독립모듈을 만들때처럼 100% 테스트시키고 1년동안은 만지지마.
2. 아키텍처 먼저.
난 “우리는 아키텍처를 만들 시간을 가지고 있지 않으니 빠르게 해야 할 필요가 있다”라고 말하는 많은 사람들을 보았어. 그리고 99%는 이런 생각때문에 큰 문제가 발생했지.
아키텍처를 코드를 생각없이 작성하는 것은 그것들을 계획없이 당신의 욕망에 대해 꿈꾸는 것과 같은 방법처럼 쓸모없어.
첫번째 코드를 작성하기 전에 당신은 이해해야 할거야 무엇을 할 것인지, 어떻게 사용할 것인지, 어떤 모듈, 다른 것들과 서비스가 잘 작동하는지, 어떤 구조를 가지고 있을것인지, 어떻게 디버그하고 테스트할 것인지 그리고 어떻게 업데이트 할 것인지를..
3. 테스트 커버리지.
테스트는 좋지만 그것이 항상 저렴하지않고 프로젝트를 위한 것은 아니다.
테스트가 필요할 때 :
— 당신이 모듈을 작성할때, 한 달동안은 만지지 않을 수 있는 마이크로 서비스.
— 당신이 오픈소스 코드 작성할 때.
— 그것이 금융과 관련된 것을 작성할때.
— 테스트를 업데이트 시키는 동시에 코드가 업데이트되었을때.
당신이 테스트가 필요가 없을 때 :
— 스타트업일때.
— 당신이 작은팀이고 코드 변경이 잦을 때.
— 당신이 출력으로 확인해볼 수 있는 간단한 테스트를 작성할 때.
기억해 나쁘게 작성한 테스트 코드는 테스트없는 코드보다 더 해로울 수 있다.
4. 간단히해, 멍청아.
복잡한 코드를 작성하지마. 더 간단히 버그를 줄이고 디버그에 필요한 시간이 단축되었을지도 모른다. 코드는 오직 추상화나 다른 망할 것들(특히 콘솔 자바 개발자들이 관계있음)이 없이 필요한 것이어야 하고 추후에 20%이상을 간단한 방법으로 업데이트할 수 있을지도 모른다.
5. 주석.
주석은 나쁜 코드를 보여준다. 좋은 코드는 주석 한줄없이 이해할 수 있어야한다. 하지만 새 개발자를 위해 시간 절약을 하려면 무엇을 해야합니까?
간단한 문서와 메소드 작동 방법을 작성해야합니다. 이것은 이해하는 것에 많은 시간을 절약할 수 있고 더 나아가 사람들에게 더 좋은 메소드를 구현할 수 있는 기회를 제공한다. 또한 그것은 세계적인 코드 문서의 좋은 시작이 될 것이다.
6. 강한 결합 vs 약한 결합.
마이크로 서비스 아키텍처를 사용하는 것을 항상 시도해라. 모놀리식 소프트웨어는 마이크로 서비스 소프트웨어보다 더 빠르게 동작할 수 있지만 오직 한 서버에서만이다.
7. 코드 리뷰.
코드 리뷰는 나쁜 것만큼 좋을 수도 있습니다.
당신은 95%의 코드를 이해하고 시간낭비하지 않고 모든 업데이트를 모니터링하는 개발자가 있을때만 코드 리뷰를 할 수 있습니다. 다른 상황에서는 시간을 낭비하는 것이고 모두가 이것을 싫어할것이다.
이 부분에 많은 질문들을 가져서 더 깊게 설명해보세요.
많은 사람들은 코드 리뷰를 신입 또는 코드의 다른 부분에서 작업하는 팀원들을 가르치기에 좋은 방법으로 생각할 것이다.
하지만 코드 리뷰의 진짜 목적은 코드 품질 유지이지 가르치는 것이 아니다.
너의 팀이 냉각 제어 시스템, 원자로 우주로켓엔진에 대해 코드 작성하는 것을 상상해보아라. 그리고 너는 매우 중요한 로직에서 큰 실수를 만들었고 신입에게 코드 리뷰를 하라고 주었다. 당신은 사고의 위험에 대해 어떻게 생각하지? — 나의 70%이상 연습.
좋은 팀은 각자의 역할을 가지고 정확한 작업에 대해서 책임지는 것입니다. 만약 누군가 코드의 다른 부분을 이해하는 것을 원하면 그것을 책임지고 있는 사람에게 가라. 모든 것을 아는 것은 불가능하고 30%는 다른 사람들보다 코드의 세세한 부분을 더 잘 이해해야한다.
8. 리팩토링은 작동하지 않는다.
내 경력 동안 나는 “우리가 앞으로 리팩터할 것을 걱정하지마라”라고 오랫동안 들어왔다. 그리고 앞으로 이 결과들은 큰 기술 부채가 되거나 모든 코드를 지우고 처음부터 작성하게 될 것이다.
따라서 당신은 처음부터 소프트웨어를 개발할 돈을 가지고 있지 않는 한 부채를 가져오지 마십시오.
9. 당신이 피곤하거나 컨디션이 안좋을때 코드 작성하지 마라.
개발자는 피곤하고 힘들때 2~5배 더 버그를 만들고 실수를 합니다. 그래서 더 일하는 것은 매우 나쁜 습관입니다. 그렇기 때문에 하루 약 6시간 일하는 국가가 점점 더 생겨나고 그들 중 일부는 이미 그렇게 하고 있습니다. 정신적인 일은 당신이 힘 쓰는 일과는 같지 않습니다.
10. 한번에 모두 작성하지말고 반복적으로 개발하십시오.
코드를 작성하기 전에 당신의 customers/clients들이 정말 필요한 것을 분석하고 예상해서 당신이 단기간에 좋은 품질로 개발할 수 있는 MVF(Most Valuable Features : 가장 가치있는 기능)을 선택하세요. 그러한 반복을 사용하여 쓸모없는 욕망에 시간과 자원을 낭비하지 않고 품질을 희생시켜 품질을 업데이트해나가십시오.
11. 자동 VS 수동.
자동화는 장기간으로 100% 성공합니다. 그래서 만약 당신이 자동화하는 어떤 자원을 가지고 있으면 지금 당장 끝내야합니다. 당신은 “5분밖에 안 걸리는데, 왜 자동화해야하지?”라고 생각할지도 모릅니다. 하지만 이것을 계산해보세요. 예를들어 5명의 개발자 팀을 위한 일상적인 업무입니다. 5분 * 5개발자 * 21일 * 12월 = 6300분 = 105시간 = 13.125일~5250달러. 그리고 만약 당신이 4만명의 직원이 있다면 얼마나 많은 비용이 들 것 같습니까?
12. 나가서 취미를 가져라.
다른 일은 정신 능력을 향상시키고 새로운 신선한 아이디어를 줍니다.
그래서 잠시 일을 멈추고 나가서 신선한 공기, 친구들과의 대화, 기타도 쳐보기도하고 등등을 해보십시오.
13. 당신은 자유시간을 가지면서 새로운 것을 배워라.
사람들은 배우는 것을 멈추면 그들은 저하되기 시작합니다.
만약 당신이 좋은 코드를 작성에 대해서 댓글로 당신의 생각과 경험을 공유할 수 있다면 나는 매우 감사할 것입니다.
출처 : https://hackernoon.com/few-simple-rules-for-good-coding-my-15-years-experience-96cb29d4acd9
Andrey Nikishaev.
Thank you for sharing your good ideas.
