코딩 모범 사례를 항상 사용해야합니까?

소프트웨어를 코딩 할 때 아키텍처는 항상 구축중인 애플리케이션과 관련하여 모범 사례 또는 실제 사례 여야합니까?

5 년 동안 살 수 있고 5 년 동안 2 가지 개선 된 2 페이지 웹 응용 프로그램을 구축하는 경우 종속성 주입, 디자인 패턴, 뷰 모델이있는 모델 뷰 컨트롤러 등으로 코딩해야합니다.

코딩 모범 사례를 항상 사용해야합니까?

항상? 아니, 그건 바보 야

모범 사례는 지침입니다. 대부분의 사람들에게, 대부분의 상황에서 약간의 정교함을 가지고 구현하면 최상의 결과를 얻을 수 있습니다. 솔루션을 고려할 때 시작하는 곳입니다. 그러나 더 나은 솔루션이 있기 때문에 모범 사례를 무시할 수있는 곳과 무시해야 할 곳이 있습니다.

문제는 인간이 미래를 볼 수 없다는 것입니다. 초보자 (및 초보자가 아닌 사람들)는 규칙이 적용되지 않는 특별한 시나리오에 있다고 생각합니다. 확실하지 않은 경우 모범 사례를 사용하십시오. 당신이나 저보다 똑똑한 수많은 엔지니어들에 대한 수년간의 토론과 경험은 지속적으로 좋은 결과를 낳는 것으로 나타났습니다. 그러나 그들 중 누구도 당신의 특정 문제를 잘 알지 못합니다. 때때로 규칙을 구부릴 수있는 예외적 인 경우가 발생할 수 있습니다.

예. 그것은 자명하다. 왜 최선을 다하지 않겠습니까?

그래도 문제는 아닙니다. 어려운 부분은 모범 사례가 무엇인지 알아내는 것입니다. 정확히 어떤 요구 사항이 있는지, 그리고 몇 년 동안 프로젝트가 어떻게 발전 할 것인지 정확히 알아야하기 때문에 그 방법이 매우 어렵 기 때문입니다.

그러나 가장 좋은 방법은 : 많은 디자인 패턴의 이름을 취하고 생각없이 함께 잼하는 것이 가장 좋은 방법은 아닙니다.

그 외에는 귀하의 질문에 실제로 대답 할 수 없습니다. 주어진 상황에서 "모범 사례"가 무엇인지 정확히 파악하는 것은 소프트웨어 엔지니어가되는 것입니다. 더 나은 답변을 얻으려면 범위를 좁혀 야합니다.

모범 사례는 기능, 유지 관리 성, 성능 등에 대한 소프트웨어의 기능적 및 비 기능적 요구 사항을 가장 효과적으로 충족시키는 방법입니다.이 방법이 일부 "산업 표준"과 일치하는 경우 매우 훌륭합니다. 그러나 그렇지 않으면 실용주의가 승리합니다.

현재 작업중인 곳에서 제품에 대한 새로운 웹 UI를 처음부터 작성하고 있습니다. 어떤 식 으로든 RESTful하지 않습니다. POST 만 독점적으로 사용합니다. 멀티 티어가 아니며 마이크로 서비스를 사용하지 않으며 NoSQL 데이터베이스를 사용하지 않습니다. Enterprise Java와 같은 아키텍처는 없습니다.

다시 말해, 전혀 엉덩이가 아닙니다.

그러나 Angular와 같은 데이터 바인딩, 모바일 및 데스크탑과 같은 다양한 장치 유형에 대한 자동 스케일링, Telerik의 Kendo UI와의 통합을 통해 모든 무거운 작업을 수행하고 완전히 암호화되고 안전하게 보호 되는 최신 HTML5 프레임 워크 를 통합합니다. 데이터 채널.

무엇보다도, 30 일 안에 완료 될 것입니다. 이는 엔터프라이즈 아키텍처에서 1 년에 걸쳐 Java 개발자 군대를 확보하는 데 큰 도움이됩니다. 코드는 ES6 / Typescript입니다. 내가 본 가장 깨끗한 코드 중 일부입니다.

없음 . 모범 사례는 일반적으로 시간의 99 %를 수행하는 가장 좋은 것으로 간주되지만 항상 모든 상황에 적용되는 것은 아닙니다.

개발자는 이러한 모범 사례를 알고 사용하는 것이 중요하지만 언제 제쳐두고 안전한지 알고 있어야합니다.

이것은 자체 홍보는 아니지만 최근에 Salesforce.com 플랫폼에서의 작업과 관련된 블로그 게시물을 작성했습니다 . 가장 중요한 규칙 중 하나는 "루프 내부에서 쿼리를 수행하지 마십시오"가 있지만 최근에 7 년 동안 플랫폼에서 작업 한 첫 번째 이유는 해당 규칙을 준수하지 않는 완벽한 이유가있었습니다.

요점은 플랫폼이 주어진 실행 컨텍스트에서 수행 할 수있는 쿼리 수에 제한이 있지만이 경우 힙 공간이 부족하지 않도록 루프 내부에서 쿼리해야하며 쿼리 내에 잘 있음을 알았습니다. 한도.

따라서 드물기는하지만 모범 사례가 시나리오와 관련이없는 경우가 있으므로 적합하지 않은 경우 강요하지 마십시오.

"모범 사례"란 누군가가 책에 쓴 규칙 목록을 의미한다고 가정합니다. 물론 문구를 문자 그대로 의미한다면 물론 항상 최상의 코드를 작성해야합니다.

보편적으로 받아 들여지는 하나의 "모범 사례"가 없다는 것을 지적해야합니까? 한 전문가가 승격 한 규칙에 대해 거의 동일한 자격 증명을 가진 다른 전문가를 찾을 수 있습니다.

그러나 요점 : 짧은 대답 : 일반적으로 항상 그런 것은 아닙니다.

모든 분야에는 "모범 사례"및 "교과서 솔루션"이 있습니다. 이것들은 수년에 걸쳐 많은 사람들의 축적 된 경험과 지혜를 나타내며 무시해서는 안됩니다. 그러나! 특별한 상황, 프린지 케이스 등이 항상 있습니다. 어떤 분야에서든 유능한 사람은 규칙을 준수 할시기와 위반시기를 알고 있습니다.

나는 일반적으로 말합니다 : 교과서 규칙에 따라 시작하십시오. 교과서 규칙을 따를 때 문제가 발생하면 (불필요한 복잡성, 성능 저하 등) 한 번만이 규칙을 위반하는 것이 더 좋은 아이디어가 아닌지 고려하십시오.

규칙을 무시하고 순간이 당신을 이끌 때마다 코드가 혼란 스러울 수 있습니다. 아무리 똑똑해도 세계 최초의 프로그래머는 아닙니다. 다른 사람들의 경험에서 배우는 것이 합리적입니다. 우리의 일상 생활에서 우리는 부모와 교사, 설교자를 가지고 있습니다. 그러므로 우리는 어리석은 실수라는 것을 배우기 위해 모든 어리석은 실수를 반복 할 필요가 없습니다.

그러나 시간의 100 %에 해당하는 책의 규칙 목록을 노골적으로 따르는 경우, 종종 둥근 구멍에 사각형 못을 망치는 것을 보게 될 것입니다. 규칙 집을 쓴 사람들은 당신과 같은 사건을 겪지 않았을 것입니다. 그리고 그들이 가지고 있어도, 아주 드물다면 그것을 무시했을 수도 있습니다. 시간의 80 %를 작동하는 규칙은 시간의 100 %가 아니라 80 %의 시간을 작동한다는 것을 이해하는 한 훌륭한 규칙입니다.

나는 데이터베이스 설계자에게 데이터베이스 디자이너들이 따라야 할 많은 규칙들을 포함하는 책을 썼습니다. (나는 제목을주는 것을 자제 할 것이기 때문에 나는 자기 진급에 뻔뻔스럽게 빠져들지 않는 것처럼 보이지 않는다.) 나는 데이터베이스를 디자인하고 싶은 사람들이 나의 것과 같은 책을 읽고 그것으로부터 가능한 모든 것을 배우도록 격려한다. . 그러나 과정 중에 내가 열거 한 규칙을 어겨 야 할 때가 있습니다.

한때 내가 이끄는 개발자 팀을위한 프로그래밍 표준 문서를 작성했습니다. 마지막 규칙은 다음과 같습니다. "위 규칙 중 하나를 어길 이유가 있다면, 규칙을 어긴 이유를 설명하는 주석을 코드에 포함시켜야합니다. 타당한 이유가 있다면 규칙을 따르십시오. 규칙을 따르는 것보다 의견을 쓰는 것이 더 어려운 경우 규칙을 따르십시오. " 우리는 소수의 사람들이 이유를 설명하는 데 어려움을 겪는 규칙을 어기는 것을 발견했습니다.

하여 모범 사례 , 난 당신이 특정 작업을 수행하는 문자 최선의 방법이 아닌 일종의 "소프트웨어의 품질을 향상시킬 수 있습니다 소프트웨어 개발 커뮤니티가 시간이 지남에 배운 것을 비공식적 규칙"을 의미 있으리라 믿고있어.

그렇습니다. 이유가 없을 때까지. 당신이 진지하게 고려하고 당면한 과제의 상황과 한계에 적용한 것이 합당한 이유입니다. 그것은 당신이 연습을 완전히 이해하고 적용 할 수 있다는 것을 의미합니다. 당신이 그것을 이해하지 못한다면, 그것이 가장 좋은 생각이되어서는 안된다는이 개념에 들어 가지 마십시오. 정의를 참조하십시오.

항상 최선을 다하지는 않을 것입니다. 상사가 당신에게 "이 쓰레기를 보내거나 해고 당했어요!" 당신은 그것을 선적하고 아마 다른 직업을 찾으러 갈 것이지만, 당신은 여전히 ​​그것을 선적 할 것입니다. 때때로 당신은 자신이 충분히 좋은 일을하고 있음을 알게 될 것입니다. 물론, 당신은 이것을 습관화하고 싶지 않지만 때로는 마차를 굴려야하며 말이 장님에 대해 걱정할 필요가 없습니다.

일부는 중요하지만 일부는 중요하지 않습니다.

선택한 언어와 스타일을 문제에 맞게 조정해야합니다.

예를 들어, 예외 처리를위한 "모범 사례"는 항상 예외를 잡아서 기록하는 것이지만 단위 테스트를 만들 때 단위 테스트 프레임 워크에서 올바르게보고 할 수 있도록 예외를 처리하는 것이 좋습니다.

반면에 "건조한"규칙을 고려하십시오. 반복되지 않는 코드에 대한 노력은 명백한 이유 때문일뿐만 아니라 코드가 많을수록 코더가 좋아질수록 항상 좋습니다. 코딩 / 사고 기술을 유연하게 조정할 수있는 좋은 방법입니다 타이핑 및 복사 / 붙여 넣기 기술 대신, 장기적으로는 규칙을 잘 지키면 코드를 다시 검토하는 것이 좋습니다.

요약하면, 유연하지만 읽을 수없는 정크 코드는 던져 버리는 코드라고 생각하기 때문에 코드를 작성하지 마십시오.

다른 관점에서 보려고합니다.

오늘날의 현대적인 프레임 워크는 mvc, 의존성 주입, 계층 구조 등 (기본적으로 스프링 부트 애호가)을 사용하여 기본 프로젝트를 매우 쉽게 설정할 수 있습니다. 수제 솔루션이 필요한 무언가에 부딪 칠 때까지 생성 된 기반으로 시작하고 제공된 도구를 사용한다고 말하고 싶습니다. 그런 다음 모범 사례에서 코너를 잘라낼 수 있습니다.

2 페이지 웹 앱 용 Spring Boot와 같은 것을 사용하고 자신의 서블릿, jdbc 쿼리 및 기타 것을 롤링하는 것은 어렵지 않습니다.

내 경험상 필자가 의무적으로 생각하는 모범 사례는 하나뿐입니다.

단순하고 바보처럼 유지 (KISS)

다시 말해, 어떤 툴, API, 아키텍처 등을 선택하든간에 간단하게 유지하면 향후 작업하기 쉽고 버그가 적고 메모리 효율성이 높으며 원하는 모든 것이 가능할 가능성이 높습니다.

사람들이 이야기하는 다른 모든 것 : 원리, 패턴, 관행 등-나는 내가 선택할 수있는 도구의 팔레트로 간주하고 내가 작업하고있는 프로젝트에 가장 적합한 도구를 선택한다. 모두 문제 해결을위한 기술과 아이디어를 제공합니다. 비결은 처음에 그러한 문제가 있는지 알아내는 것입니다.

최상의 "모범 사례"에는 항상 설명서의 항목이 부적절한시기를 식별하기 위해 지능과 경험을 사용해야하는 섹션이 포함되어 있습니다. 또한 그러한 예외를 검토, 승인 및 문서화하고 "최상의"관행의 일부로 만드는 섹션이 포함될 수 있습니다.

소프트웨어를 코딩 할 때 아키텍처는 항상 구축중인 애플리케이션과 관련하여 모범 사례 또는 실제 사례 여야합니까?

이론적으로는 그렇습니다.

현실 세계에서, [계속] 예, 만큼 당신은 그렇게 할 여유가 있습니다.

물론 "아니요"를 의미합니다.

시간과 비용의 압박은 고객 에게 "더 나은"가치를 제공하기 때문에 항상 "빠르고 더러운"솔루션의 길을 내리려고합니다. 그것이 어떻게 구현되는지는 고객이나 회계사에게 관심이 없습니다. 이틀 안에 또는 3 개월 안에 완벽하게 [나쁘게] 일을 할 수 있다면, 그들은 당신에게 무엇을 요구할 것이라고 생각합니까?

두 가지 모범 사례와 "피해야 할 것"의 차이를 "기술 부채"라고합니다. "상환"계획, 즉 나중에 돌아가서 개선 할 계획이있는 한 완벽하게 수용 가능합니다. 다시 말하지만, 항상 예산이 필요한 것은 아닙니다.

하나의 전술은 "빠른"수정 사항이 포함 된 초기 베타 버전을 릴리스하는 것이지만 "전체"릴리스 전에 필요한 아키텍처 개선이 우선 순위를 갖도록하는 것입니다. 다시 말하지만, 당신이 항상해야 할 일은 아닙니다.