현재 모두가 '깨끗한' 코드를 위해 노력하고 있는 것 같습니다. 작성자가 접근 방식이 얼마나 깨끗한지 알려주지 않고는 블로그 게시물을 읽을 수 없습니다. 엔지니어링 팀이 함께 모여 가능한 솔루션 중 가장 깨끗한 솔루션을 논의합니다. 다른 개발자들은 '깨끗한 코드'를 연습한다고 확신합니다.
그래도 깨달았습니다. 깨끗한 코드는 없습니다.
'깨끗함'은 유용한 척도가 아닙니다. 단순히 'clean'이 코드에 대해 설명하지 않기 때문에 코드를 정리할 수 없습니다.
얼마나 위선자!
나는 나 자신이 순수하지 않다. 나는 과거에 '깨끗한'이라는 용어를 많이 사용했다. 또한 이 용어를 사용하는 사람을 폄하하려는 것이 아님을 분명히 하고 싶습니다.
마케팅 용어 또는 비전이나 정신에 대한 설명으로 '깨끗한'은 훌륭합니다! 그러나 기술적인 용어로 몇 가지 문제가 있습니다 ...
깔끔한 코드가 좋은 코드죠?
사람들이 코드를 깨끗하다고 설명할 때 일반적으로 코드가 어떤 면에서 좋다는 의미입니다.
문제는 코드가 여러 가지 이유로 좋을 수 있다는 것입니다. 그것은 수:
- 가독성
- 이해할 수 있는
- 단순한
- 성능
- 안전한
- 우아한
- 테스트 가능
- 캡슐화
- 확장 가능
- 유지보수 가능
- 재사용 가능
- 삭제하기 쉬움
- 단정하고 깔끔
- 비침습적
- 체계적인
- 일관된
- 또는 기타 여러 가지
그러나 이러한 특성은 어떤 면에서 서로 상충됩니다. 가장 단순한 코드는 아마도 가장 테스트하기 쉽지 않을 것입니다. 이러한 모든 인터페이스와 주입된 종속성은 편리한 테스트를 제공하지만 단순성 측면에서 비용이 있습니다.
싱글톤에 대한 의존도가 높으면 이해하기 쉬울 수 있지만 유지 관리 가능한 애플리케이션으로 이어지지 않을 수 있습니다.
이러한 것들 중 일부는 동시에 모두 충족될 수 없는 근본적으로 반대되는 힘들이라고 주장할 수 있습니다. 엔지니어링은 절충점에 관한 것이므로 우리가 제안하는 절충안을 인식하고 팀으로 논의할 수 있습니다.
코드가 좋으면 이유를 말해야 합니다.
누군가가 해결책이 '깨끗하다'고 말할 때, 그들은 종종 그 이유를 합리화하지 못한 채 그것을 더 나은 선택이라고 선전합니다.
기술 솔루션에 대해 건설적인 토론을 하고 싶다면 한 솔루션이 다른 솔루션보다 더 나은 이유를 서로 설명할 수 있어야 합니다. 어떤 솔루션이 '가장 깨끗한' 것인지에 대해 논쟁하는 것은 좋지 않습니다. 마치 우리가 이 신비한 척도에 따라 각 솔루션의 무게를 측정해야 하는 것처럼 깨끗한 측정기에서 꺼내야 하는 것처럼 말입니다.
어떤 접근 방식이 다른 접근 방식보다 더 낫거나 더 나쁜 이유를 때때로 표현하는 것은 실제로 상당히 어렵지만 연마할 가치가 있는 기술입니다.
차라리 이런 토론을 하시겠습니까?
"솔루션 X가 마음에 듭니다. 훨씬 깨끗해졌습니다."
아니면 이거?
“솔루션 X가 마음에 듭니다. 핵심 논리에서 오류 메시지 표시를 분리합니다. 두 가지를 동시에 고려할 필요가 없기 때문에 이해가 더 쉽습니다. 이 분리는 또한 다른 개체를 테스트하는 동안 두 개체 중 하나를 조롱할 수 있으므로 일부 테스트 가능성을 해제합니다. 부모 개체가 종속성을 주입하도록 요구하는 비용이 발생하지만 테스트 가능성을 위해 가치 있는 절충안입니다.”
두 번째 진술은 실제로 우리가 논의하고 있는 솔루션의 장단점에 대해 실질적인 것을 전달합니다. '깨끗한'과 같은 용어는 우리의 아이디어를 표현하는 능력을 향상시키기 위해 일하기 보다는 자제할 수 있도록 합니다.
정확한 용어를 사용해야 합니다
코딩은 일반적으로 팀 스포츠입니다. 혼자 해킹한다면 원하는 대로 할 수 있지만 팀과 함께 일할 때는 아이디어를 논의해야 합니다. 특정 언어를 사용하여 기술 솔루션에 대해 토론하고 팀 전체에서 공통적으로 이해하는 것은 서로를 이해하는 데 매우 중요합니다.
'클린 코드'는 누구에게나 다른 의미 입니다.
일부 개발자에게 코드는 잘 정의된 아키텍처를 가지고 있기 때문에 깨끗합니다. 다른 개발자에게 코드는 일관된 서식 스타일을 사용하기 때문에 간단합니다.
'encapsulated', 'testable', 'mockable', 'reusable'과 같은 단어에는 우리 모두가 동의할 수 있는 의미가 있습니다. 우리 프로젝트에 영향을 미치는 다양한 코드 특성을 설명하는 보다 구체적인 단어를 사용할 때 우리는 모두 같은 페이지에 있다는 것을 확신할 수 있습니다.
'깨끗함'은 '좋음'과 같은 수준의 정밀도를 갖습니다. 코드가 깨끗하다고 말할 수 있는 것처럼 코드가 훌륭하다고 말할 수 있지만, 그렇다고 해서 더 구체적인 근거로 이를 정당화해야 하는 것은 아닙니다.
그렇다면 클린 코드는 무엇일까요?
저는 코드를 '깨끗한' 것으로 설명할 때 코드가 좋다고 생각하지만 그 이유를 완전히 확신할 수 없는 경우가 많다는 결론에 도달했습니다. 딱 맞는 솔루션인 것 같습니다.
또는 때때로 우리는 코드가 좋은 이유를 알고 있지만 그것을 명확하게 설명할 단어를 찾을 수 없으며 어떻게든 블로그 게시물의 결론은 "보십시오! 얼마나 깨끗한지 보세요!” .
직관을 구축하는 것은 좋지만 여기서 멈출 수는 없습니다. 우리 는 코드가 좋다고 생각하는 이유 를 이해하고 명확히 하기 위해 이러한 감정을 넘어서 더 깊이 파고들 필요가 있습니다. 이 코드에는 다른 솔루션에는 없는 어떤 특성이 있습니까? 이것이 우리 프로젝트에 가장 적합한 특성입니까? 아마도 결국 그것은 실제로 올바른 해결책이 아닐 것입니다.
당신이 정말로 깨끗한 코드가 필요하지 않다는 것을 확신할 수 있기를 바랍니다. 당신은 _____ 코드가 필요합니다. 프로젝트에 필요한 것을 설명하는 단어로 빈칸을 채우는 것은 당신에게 달려 있습니다.
Deleted! ⚠️
Original comment is phishing. 🐠
Sorry. 🙏
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit