오늘은 좋은 글을 발견해 이를 정리해보려고 합니다.

코드는 사람을 위한 것이다. 컴퓨터를 위한 것이 아니다.

코드를 작성할 때 이 코드가 그저 작동하는 것을 넘어 다른 사람이 쉽게 이해할 수 있도록 만듭니다.

코드에 얽매이지 않는다.

코드를 만들다가 더 좋은 코드를 만들 수 있다면 여태까지 작업했던 코드를 삭제하고 새로 작성하는 것을 두려워하지 않습니다.
피드백을 통해 더 좋은 코드를 만들려고 합니다.

코드에 일관된 기준이 있습니다.

좋은 엔지니어들은 코딩의 일관된 기준과 스타일을 고집합니다.
일관된 기준은 코드를 읽고 이해하는 것을 쉽게 만들어줍니다.
Linter를 통한 포멧팅은 팀 내에서 일관된 코드를 만드는데 도움을 줍니다.

간단한 코드를 작성합니다.

가능한 SOLID 법칙을 만족하는 코드를 작성하는 것이 좋습니다.

예상가능한 코드를 작성합니다.

코드는 예상불가능한 결과를 낳으면 안됩니다.
좋은 코드는 예상가능해야 합니다.
이를 위해 유닛 테스트, 통합 테스트, E2E테스트를 할 수 있습니다.
또한 중요한 것이 하나 더 있는데 무엇을 테스틑 하지 않을지 알고 있는 것도 중요합니다.

의사소통을 자주 합니다.

팀내에서 모두가 모든 것을 알 수 없습니다.
팀 인원 간에 아는 것에 대한 차이는 의사소통을 통해 채워져야 합니다.
의사소통과 협동은 더 나은 결과물을 만들기 위해 중요합니다.

코드를 빠르고 그리고 천천히 만듭니다.

엄청 모순 적인 말입니다.
이에 대해 설명해 보겠습니다.
위의 모든 좋은 엔지니어들의 특징은 코딩을 작성하기 까지 많은 시간을 쓰게 만듭니다. 그러나 위의 특징들은 단계적으로 프로젝트의 진행하게 만들어 줍니다.
장기적으로 보았을 때 위에서 언급한 행동을 함으로써 더 빠르게 결과물을 만들어 낼 수 있는 것입니다.

위의 원칙들은 절대적 진리가 아닙니다.

규칙을 맹몽적으로 따르기보다는 융통성 있게 적용하는 것이 중요합니다.
그리고 코드가 왜 특정 방식에 따라 작성되게 되었는지 문서화하는 것을 권장합니다.

다른 특징들

적어도 하나의 분야에서 깊은 이해를 가지고 있습니다.
엔지니어들이 자신을 적절하게 자주 마케팅하여 자신의 가치와 전문성을 알리고 있습니다.