팀의 기술이 부족한 경우 코드 기술을 낮춰야합니까? [닫은]

예를 들어, JS에는 기본값을 얻기위한 공통 스 니펫이 있습니다.

function f(x) {
    x = x || 'default_value';
}

이런 종류의 스 니펫은 팀의 모든 구성원이 쉽게 이해할 수 없으며 JS 수준이 낮습니다.

이 트릭을 사용해서는 안됩니까? JS 개발자에 따르면 피어가 코드를 읽을 수는 없지만 다음보다 더 읽기 쉽습니다.

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

물론,이 트릭을 사용하고 동료가 그것을 보면, 그들은 무언가를 배울 수 있습니다. 그러나 종종 그들은 이것을 "영리한 시도"로 본다.

팀원의 레벨이 저보다 낮은 경우 코드 레벨을 낮추어야합니까?

자, 여기이 크고 복잡한 주제에 대해 살펴 보겠습니다.

코딩 스타일을 유지하기위한 장점 :

• 같은 상황이 x = x || 10자바 스크립트 개발에 관용적이며, 코드 및 사용 외부 자원의 코드 간의 일관성의 양식을 제공합니다.
• 코드의 수준이 높을수록 표현력이 뛰어나고 무엇을 얻었는지 잘 알고 있으며 숙련 된 전문가가 쉽게 읽을 수 있습니다.
• 당신은 일을 더 즐길 수 있습니다. 나는 개인적으로 예쁜 코드를 만드는 것을 소중히 생각합니다. 나는 그것이 내 일에 많은 만족을 가져다 준다고 생각합니다.
• 일반적으로 더 읽기 쉬운 스타일을 만듭니다. 언어의 관용구를 고수하는 것은 매우 귀중 할 수 있습니다-그들은 종종 이유 때문에 관용구입니다.

코딩 스타일을 유지하기위한 단점 :

• 하위 레벨 프로그래머가 계속 유지하기가 더 어려울 것입니다. 이들은 종종 코드를 관리하는 사람들과 실제로 작성한 내용을 읽어야하는 사람들입니다.
• 코드 관리자, 종종 JavaScript 코드는 다른 언어에서 온 것입니다. 프로그래머는 Java 또는 C #에서 유능하지만 JavaScript가 정확히 어떻게 어떻게 다른지 이해하지 못할 수 있습니다. 이러한 점은 종종 관용적입니다. 즉각 호출 된 함수 표현식 (IIFE)이 그러한 구성의 예입니다.

내 개인적인 의견

코드 기술을 낮추지 않아야합니다. 표현적이고 명확하며 간결한 코드를 작성하도록 열망해야합니다. 당신이 당신의 팀의 수준에 대한 의심이있는 경우 그들을 교육합니다 . 사람들은 당신이 생각하는 것보다 기꺼이 배우고 자하는 것이 아니라, 그들이 더 낫다고 확신 할 때 새로운 구조물을 기꺼이 적용하려고합니다.

그들이 당신이 '단지 영리하다'고 생각한다면, 요점을 주장하십시오. 때로는 자신이 틀렸다는 점을 기꺼이 인정하고, 어떤 일이 있어도 작업 환경에서 스타일을 일관되게 유지하십시오. 그렇게하면 적대감을 피하는 데 도움이됩니다.

가장 중요한 것은 일관성을 유지하는 것입니다.

팀의 코드는 마치 한 사람이 코딩 한 것처럼 작성해야합니다. 당신은 절대적으로해야 할 코딩 가이드 라인에 동의합니다. 해당 지침을 준수해야합니다. 코딩 지침에 따라 선택적 매개 변수 읽기를 '덜 영리한'방식으로 수행해야한다고 지정하는 것이 좋습니다.

잘 댓글

코드 기술을 낮추어야합니까? 반드시 그런 것은 아니지만 의견 의 기술을 확실히 높여야합니다 . 코드에 특히 주석이 더 복잡하다고 생각되는 섹션에 좋은 주석을 포함 시키십시오. 코드를 따르기가 어려워지는 주석을 너무 많이 사용하지 말고 각 섹션의 목적을 명확하게하십시오.

실제로는 댓글이 약간 더 장황한 것은 숙련도가 낮은 팀원에게는 유용 할 수 있지만 기술이 가장 낮은 사람은 무시하고, 특히 너무 많은 경우에는이를 무시하지 마십시오.

스타일의 문제?

제공 한 예제는 다소 기본적이지만 스타일도 있습니다. 모든 변수 기본값에 대한 주석은 유지하고 읽는 것이 지루합니다. 대신 문체 또는 반복 단축키 또는 코드 패턴을 표준으로 설정해야합니다. 이러한 매개 변수 기본값과 같은 형식을 모든 사람이 이해하고 매번 사용해야한다고 생각하면 이러한 아이디어를 적어 팀 리더에게 가져 가십시오. 팀원에게 가르치기 위해 필요한 모든 것은 제안한 표준을 논의하는 간단한 회의입니다.

다른 답변에서 이미 언급했듯이 일관성을 유지하십시오 .

물고기에게 남자를 가르치십시오 ...

팀원을 가르치는 것이 아마도 모든 사람을 도울 수있는 가장 좋은 방법 일 것입니다. 커밋 로그 또는 타임 스탬프에 사용자 이름이있는 코드 조각에 대해 궁금한 점이 있으면 언제든지 문의하십시오. 팀에 코드 검토가있는 경우, 혼란스럽고 잘 작성된 코드를 팀원 에게 설명 할 수있는 좋은 기회 입니다. 팀에 코드 리뷰가 없다면 왜 안 되겠습니까? 가져와!

하지만 조심해야합니다. 항상 사람들을 가르치기 위해 주변에 있지 않을 수도 있으며 주어진 코드 섹션에서 원래하려고했던 것을 잊어 버릴 수도 있습니다.

"영리한"트릭

팀원의 능력을 염두에 두는 것이 중요하지만 유지 관리 가능한 코드를 작성한다는 것은 종종 더 일반적인 솔루션이있을 수있는 문제에 대한 바로 가기를 사용하지 않는 것을 의미합니다. 팀원이 똑똑한 경우에도 중요합니다. 코드를 이해하거나 놓칠 수 있지만 미묘하지만 중요한 부작용을 일으키는 데 시간이 너무 오래 걸리지 않게하려고합니다. 일반적으로 적절한 대안이있을 때 "영리한"요령을 피하는 것이 가장 좋습니다. 누가 코드를 유지 보수해야하는지 모르는 경우가 종종 있습니다. 종종 이전 버전의 버전에서는 이러한 트릭의 세부 사항이나 이유를 기억하지 않습니다.

당신이 영리한 트릭을 구현해야한다는 것을 알게되면 적어도 다음 조언을 따르십시오 ...

키스

확실 하지 않은 경우 간단하게 유지하십시오 . 코드가 단순한 지 아닌지는 반드시 여러분이 생각하는 것처럼 프로그래머의 기술에 해당하는 것은 아닙니다. 실제로 문제에 대한 가장 훌륭한 해결책 중 일부는 가장 간단한 해결책이며, 더 복잡한 해결책 중 일부는 TheDailyWTF에 있습니다. 코드를 단순하고 간결하게 유지하면보다 지능적이지만 반 직관적 인 결정을보다 쉽게 ​​파악할 수 있습니다.

JS에서 함수를 만드는 데 큰 혐오가있는 것 같습니다. 이 혐오로 인해 사람들은 영리하고 함수 호출처럼 한 줄에 물건을 유지하기 위해 어리석은 속임수를 사용합니다. 물론 호출의 함수 이름은 추가 문서 역할도합니다. 우리는 까다로운 표현에 주석을 달 수 없습니다. 왜냐하면 그것은 표현의 요점을 잃어 버리기 때문에 그냥 "js 관용구"라고 부르고 갑자기 이해할 수 있습니다.

자바 스크립트는 접근성이 뛰어나 대부분의 사람들은 우리처럼 아침 식사에 대한 사양을 먹지 않습니다. 따라서 그들은 관용구의 숨겨진 가정과 최후의 사례가 무엇인지 이해하지 못할 것입니다.

x = x || 'default_value';

평균 joe는 이것을 이해하지 못하거나 그것이 기본값의 관용구임을 암기했습니다. 둘 다 해 롭습니다. 실제로 후자는 훨씬 더 해 롭습니다. 그는 여기에서 가정과 에지 사례를 이해하지 못할 것입니다. 그는 사양을 읽고 이해하지 않아도됩니다.

내가 그 코드를 볼 때 나는 그것이 있는지 "를 참조 null하거나 undefined,이 기본값으로 설정합니다. 그것은 또한 암시 적으로 취급하지만 +0, -0, NaN, false,와 ""같은 적합하지 않은 값을. 내가 기억해야 할 것이다 3개월 때 필요 지금부터 나는 아마 그것을 잊을 것이다. "

암시 적 가정은 미래에 버그를 유발할 가능성이 매우 높으며 코드베이스에 이와 같은 트릭이 가득 차면 수정이 어떤 영향을 줄지 생각할 때마다 머릿속에 유지할 가능성이 없습니다. 그리고 이것은 "JS pro"를위한 ​​것입니다. 요구 사항이 처음에 잘못된 값을 받아 들여야하더라도 평균 joe는 버그를 작성했을 것입니다.

새 스 니펫에는 더 익숙한 구문이 있지만 여전히 위의 문제가 있습니다.

당신은 함께 갈 수 있습니다 :

function f(x) {
    x = valueOrDefault(x, "default_value");
}

이제 엣지 케이스를 처리하는 매우 복잡한 논리를 가질 수 있으며 클라이언트 코드는 여전히 아름답고 읽기 쉽습니다.

이제 함수를 인수로 전달하는 것과 같은 고급 언어 기능이나 영리한 속임수를 어떻게 구별 || "default"합니까?

영리한 트릭은 항상 코드를 처음 만들 때 무시할 수있는 숨겨진 가정 하에서 작동합니다. 요구 사항이 변경되었으므로 항상 IIFE를 다른 것으로 수정하지 않아도됩니다. 어쩌면 2020 년에 실제 모듈을 사용할 수 있었을 것입니다.

| 0또는 ~~num바닥재에 사용되는 화물 컬트 버전 은 양수 및 32 비트 부호있는 정수 경계를 가정합니다.

|| "default" 모든 잘못된 값은 인수를 전혀 전달하지 않는 것과 같다고 가정합니다.

등등.

프로그래밍 기술을 낮추지 말아야 하지만 코드 작성 방법 을 조정 해야 할 수도 있습니다 . 무엇보다도 목표는 코드를 읽고 유지 관리해야하는 사람들에게 코드를 명확하게하는 것입니다.

불행히도 특정 스타일이 "영리한"것인지 아니면 고급 사용법인지에 대해서는 약간의 판단이 필요합니다. 문제의 코드는 이에 대한 좋은 예입니다. 솔루션이 반드시 다른 것보다 낫지는 않습니다. 어떤 사람들은 그것을 주장하고 어떤 사람들은 동의하지 않을 것입니다. 두 솔루션 모두 런타임 성능이 실질적으로 동일하므로 (읽기 : 사용자는 차이를 알 수 없음) 팀 전체가 가장 편한 스타일을 선택하십시오.

어떤 경우에는 더 나은 코딩 방법을 가르쳐야하지만 다른 경우에는 명확성을 위해 타협해야합니다.

이것은 이미 다른 답변으로 언급되었을 수도 있지만이 질문에 내 자신의 명령에 대답하고 싶습니다.

일반 지침

팀에서 작업 할 때 코드 조각의 대상이 아닙니다. 청중은 팀의 개발자입니다. 정당한 이유없이 이해할 수없는 코드를 작성하지 마십시오.

1. 특별한 단점이 없다면, 모든 코드는 특정 패턴이나 지침에 따라 작성해야하며이를 유지 관리하는 개발자가 쉽게 유지 관리 할 수 ​​있습니다. (주의 사항 : 현재 코드베이스에 있기 때문에 나쁜 패턴을 따르는 것은 끔찍한 연습입니다.)
2. 대상 독자가 쉽게 읽을 수없는 언어 별 관용구를 사용해야하는 적절한 이유를 찾으면 의견을 추가하십시오. 다른 모든 줄에 주석을 추가해야하는 경우, 청중이 더 읽기 쉽게 코드를 다시 작성할 수 있습니다. 관용적이기 때문에 관용적 인 것이 가치가 없다고 생각합니다.

구체적인 예

우리는 코드베이스에 많은 수의 펄 스크립트를 가지고 있습니다. 우리는 일반적으로 매우 간단한 작업에만 perl을 사용하며 대부분의 코드는 java 개발자가 작성하므로 java와 매우 유사합니다. 우리는 Perl 스크립트 세트와 회사를 떠난 'perl guru'에 의해 작성된 프레임 워크를 가지고 있습니다. 이 코드에는 더 모호한 perl 관용구가 많이 포함되어 있으며 저를 포함한 개발자 중 누구도이 노력 없이도이 perl 코드를 읽을 수 없습니다. 우리는 종종 그를 위해 저주합니다. :)

좋은 코드를 작성했지만 현재 또는 미래의 동료가 따라 가기가 어렵다고 생각되면 간단한 설명을 추가하여 설명해야합니다.

그렇게하면 개인의 지능을 모욕하거나 그룹 토론에서 누군가를 당황하게하지 않고 무언가를 가르 칠 수 있습니다.

나는 당신의 모범을 속임수가 아니라 관용적이라고 부릅니다. 당신이 그것을 사용해야하는 경우 IMHO는 팀의 현재 수준에별로 의존하지 않지만 팀 동료가 (최소한 일부) 동료가 새로운 관용구를 배우려고한다면. 물론이 주제에 대해 토론하고이 스타일을 강요해서는 안됩니다. 그리고 당신은 그들에게 매일 5 가지 새로운 것들 또는 "트릭"을 배우도록 요구해서는 안됩니다. 그러나 솔직히 말해서, 팀원들만 새로운 것을 배우고 싶지 않다면,이 관용구보다 단순하고 작더라도 다른 팀으로 바꾸는 것을 고려해야합니다.

이 질문과 그에 따른 답과 토론을 읽으면 두 가지 점이있는 것 같습니다. 첫 번째 : 고급 언어 기능을 사용해도 괜찮습니까? 두 번째 : '보여지는'것처럼 보이지 않고 어떻게 할 수 있습니까?

첫 번째 경우에는 개선 및 고급 기능을 사용하는 것이 좋습니다. 예를 들어 C #에서는 Linq 또는 Lambda 표현식을 사용할 필요는 없지만 대부분의 사람들은 실제로 수행하는 작업을 알면 코드를 더 깔끔하고 이해하기 쉽기 때문에 사용합니다. 처음에는 이상하게 보입니다.

사람들은 패턴에 익숙해지고 많은 경우 사람들은 일을 끝내기 위해 정해진 일을하는 방식을 사용합니다. 나는 다음 사람만큼 유죄입니다. 우리 모두 마감일이 있습니다. 어떤면에서 당신은 새로운 아이디어와 새로운 사고 방식을 도입하는 데 유죄입니다! 이것은 두 번째 요점이며, 가장 저항이 많은 곳일 것입니다.

웹 사이트를 사용하는 사람은 어떤 스타일을 사용하든 신경 쓰지 않아도됩니다. 빠른가요? 따라서 귀하의 방식에 성능 이점이 없다면 제시 한 예에서 올바른 방법이나 잘못된 방법이 없습니다. 당신의 방법은 코드를 더 읽기 쉽게 만들지 않습니까? 동료가 익숙해지면 할 수 있습니다.

그렇다면 이러한 변경 사항을 어떻게 소개합니까? 이 라인을 따라 동료들과 토론을 해보십시오.이 기능을 이런 식으로 작성할 수 있다는 것을 알고 있습니까? 코드 검토 및 페어 프로그래밍은 아이디어의 '교차 (cross-pollination)'를 허용하기에 좋은시기 일 수 있습니다. 작업중인 환경을 모르기 때문에 어떻게해야하는지 처방하기가 까다 롭습니다. 일부 프로그래머는 매우 방어적이고 변화에 저항 할 수 있습니다. 다시 한 번 나는 유죄였습니다. 이러한 종류의 프로그래머와 함께 일하는 가장 좋은 방법은 시간을내어 무엇이 진드기를 만드는지 배우고 배경을 배우고 자신의 스타일과 경험을 비교합니다. 시간이 걸리지 만 잘 보냈다. 가능하다면 그들을 격려하고 격려하십시오.

Royal McBee Computer Corp에서 일하지 마십시오. 경험이 부족한 프로그래머가 아닌 사람은 누구입니까?

확실하고 간결한 코드를 작성하는 것이 좋으며 자바 스크립트 환경에서 유용 할 수 있습니다 (누군가 브라우저에 다운로드 할 js 컴파일러를 생성 할 때까지는 다른 이야기입니다).

중요한 것은 코드를 작성하는 데 몇 분이 지난 후에 코드를 사용할 수 있다는 것입니다. 물론, 쉽고 빠르며 계속 사용할 수 있지만, 몇 년 후에 다시 돌아와야한다면, "어린 사람이 이것을 쓴 것"이라고 생각하고 그것이 당신이라는 것을 깨닫게 될 것입니다! (저는 그렇게했습니다. 대부분의 사람들도 마찬가지입니다. 나는 지나치게 공격적인 마감일을 정직하게 비난합니다).

이것이 유념해야 할 유일한 중요한 일이므로, 예라고 대답하는 동안-작동하고 명확하면 특정 운영자와 함께 가십시오. '불쾌한'개발자 (그러나 그들에게 경멸 적이지만) 다양한 웹 페이지 자습서 및 참조를 암기하면서 모든 연산자와 요령을 알고있는 경험이없는 개발자의 경우, 모든 작은 요령을 알고 있지만 최악의 코드를 작성합니다.

어쨌든, Mel 이야기를 읽을 수 있다면 , Mel이 첫 번째 순서의 실제 프로그래머 임에도 불구하고 코드에 넣는 것이 가장 좋은 방법은 아니라는 것을 알게 될 것입니다. 이것은 누군가가 좋은 코드를 작성할 수 있다고 말하고 다른 사람들이 계속 배우기 위해 더 많은 것을 배울 필요가 있다고 주장하는 논쟁에 돈을 지불합니다.

기본 JS처럼 보이는 초보자에게는 좋습니다.

그러나 일반적으로-당신은 영리한 핵을 사용해서는 안됩니다. "디버깅은 프로그래밍보다 두 배나 어렵다. 가능한 한 영리한 코드를 작성하면 정의 할 수 없다"고 정의 할 수있다.

그렇다고 다른 사람들이 이해하지 못해서 코드를 피해야한다는 의미는 아닙니다. 가능한 한 명확하고 일관된 방식으로 코드를 작성해야합니다. 그러나 분명한 기준은 "누구나 처음 읽을 때 이것을 이해할 수있을 것"이어야하며 "누구도 이해할 수는 없습니다".

분명한 방식으로 글을 작성하면 이해하는 데 어려움이없고 다른 사람이 자신의 기술을 향상시키는 데 일을하게 할 수 있습니다.

팀원들과 우리가 원하는 코딩 표준의 종류에 대해 이야기했습니다. 이것은 주로 코드 기반을 위해 수십 가지 방법으로 수행 할 수있는 작업을 수행하는 방법에 관한 것입니다. 컨센서스가 있다면 대답에 대한 나의 초기 시도가 될 것입니다.

그렇지 않다면 어떤 종류의 제안 된 표준이 합리적인지 고려하고 경영진과 일부 팀과 함께 표준을 클리어하면 실제로 적용하기 시작합니다. 여기서 아이디어는 경영진이이 아이디어로 문제가 없는지 확인하고 본인의 업무를 수행 한 다음 다른 사람이 강제로 취하지 않도록하는 것입니다.

코드를 평가하는 많은 방법이 있기 때문에 기술 수준이 아닌 팀이 어떤 표준 및 관행을 가지고 있는지에 대한 질문처럼 이것을 더 많이보고 싶습니다. 다른 사람들이 그것을 얼마나 잘 유지할 수 있는지는 그러한 기준 중 하나입니다.

문제는 소스의 가독성을 원하지만 가독성은 보는 사람의 눈에 있다는 것입니다.

이 문제를 해결하려면 더 나은 도구가 필요하다고 제안합니다. 복잡하지는 않지만 50 년 이상 기술을 보유하고 있습니다. 편집기에 파서를 포함시키고 편집기가 소스를 sexps (예 : lisp와 같은) 형식으로 저장하도록합니다. 그런 다음 소스를 읽은 후 편집기는 소스를 구문 및 활자체 (공백, 탭, 쉼표 등)로 구문 분석하여 사용자가 원하는 형식으로 만듭니다.

이런 식으로 입력하고 읽을 수 x = x || 10있으며 다른 프로그래머는 다음과 같이 읽습니다.

if (0 == x) { x = 10;}

emacs는 모든 것을 쉽게 할 수 있습니다.

코드를 바보로 만드는 대신 팀의 품질을 향상시키지 않겠습니까? 교육, 코칭, 교육 및 개선 된 채용 관행은 지속적인 개선을 위해 많은 일을 할 수 있습니다.
누군가가 자기 개선 작업을 원하지 않기 때문에 통계, 코드 썩음, 개선 및 혁신 거부

물론 당신이 보여주는 특정 경우에, 당신은 단지 현명하고 난독 화 된 코드를 작성하려고 노력하고 있습니다. 결코 좋은 생각이 아닙니다. 코드는 가장 읽기 쉽고 이해하기 쉬우 며 가능한 최소한의 문장으로 무언가를 창조하는 데 얼마나 영리한지를 보여주기 위해 쓰여서는 안됩니다. 에 대한).