이 프로그래밍 스타일 문서 에는 일반적인 규칙이 있습니다.
규칙에 대한 강한 개인 이의가있는 경우 규칙을 위반할 수 있습니다.
이것은 내가 생각하는 방식과 충돌하며 코딩 스타일이 실제로 중요하다는 많은 기사가 있습니다. 예를 들어 다음과 같이 말합니다.
코딩 표준 문서는 개발자에게 코드 작성 방법을 알려줍니다. 각 개발자가 선호하는 스타일로 코딩하는 대신 모든 코드를 문서에 요약 된 표준에 작성합니다. 이를 통해 큰 프로젝트는 일관된 스타일로 코딩됩니다. 부품은 프로그래머마다 다르게 작성되지 않습니다. 이 솔루션을 사용하면 코드를보다 쉽게 이해할 수있을뿐만 아니라 코드를 보는 모든 개발자가 전체 응용 프로그램에서 기대할 사항을 알 수 있습니다.
그래서이 문서 의 내용 과이 질문의 맨 위에있는 인용문을 오해하고 있습니까? 사람들은 코딩 스타일을 실제로 무시할 수 있습니까?
어쩌면 나는 충분히 명확하지 않았 으므로이 편집을 통해 조금 명확하게 설명 할 것입니다.
팀의 코딩 스타일 문서를 작성 중이며 일부 정적 분석기를 사용하여 스타일을 확인하고 싶습니다. 실패하면 Jenkins가 이메일을 보냅니다. 스타일이 일치하지 않으면 코드 검토에 실패하고 싶습니다. 이것은 첫 번째 인용문과 분명히 충돌합니다.
그러나 인용문이 옳다면 누군가가 원하는 것을 할 수 있다면 코딩 스타일 문서의 사용법은 무엇입니까?
답변
내가 알 수있는 한, 당신을 혼란스럽게 한 진술은 가이드 라인을 가능한 한 많은 사람들에게 제공하기 위해 만들어진 실질적인 타협입니다. 특정 상황에 따라 (아래에 자세히 설명되어 있음) 상황을 조정하고 지침을보다 효율적으로 사용할 수있는 옵션이있을 수 있습니다.
알다시피, 지침은 위반을 정당화하기위한 수단으로 “강력한 개인 이의 제기”를 참조합니다. 이러한 이의 제기는 특히 숙련 된 개발자가 제공하는 경우 가볍게 무시할 것이 아닙니다.
이러한 반대 의견 은 틀릴 수도 있습니다. 그러나 여러분은 생각하지만 (매우 큰 것입니다) 일반적으로 또는 특정 프로젝트의 맥락에서 특정 규칙이 잘못되었음을 나타낼 수도 있습니다 (규칙 불일치의 한 예는 성능이 중요한 코드에 대한 자세한 로깅).
현명한 스타일 가이드는 위의 내용을 고려해야하고 스스로 조정할 필요를 수용해야한다고 생각합니다. 이제 여러분을 혼란스럽게했던 가이드가 효율적이고 매끄러운 프로세스와 환경을 갖춘 성숙한 팀 만을 대상으로한다면 다음과 같이 명확 하게 설명 할 수 있습니다.
챌린지가 제기 될 때까지 규칙을 엄격히 준수해야합니다.이 경우 챌린지 된 규칙은 챌린지를 거부하거나 수락하고 규칙에 맞게 조정하여 해결 될 때까지 무시해야합니다.
당신은 위의 내용을 더 좋아할 수도 있고, 모든 사람에게 그런 식으로되기를 원할 수도 있지만, “도전이 제기 / 지속적으로 무시 / 조정”되는 부분을 자세히 살펴보고 구현 방법을 스스로에게 물어보십시오. 프로젝트와 팀에 따라 시간이 얼마나 걸릴 수 있는지 자문 해보십시오 . 한 시간이 걸리면 괜찮습니까? 하루, 일주일 또는 한 달이 걸리면 어떻게 되나요?
도전과 무시까지 해결 된 접근법은 프로젝트의 지침으로 제시 될 경우 남용의 폭이 넓어 질 수 있습니다. “그렇습니다. 우리는 여러분의 의견을 듣고, 가이드가 말한대로하겠습니다. 먼저,이 챌린지 양식을 작성하고 CEO / CFO / CTO 승인을 받으십시오. 1 ~ 2 주 정도 걸릴 것으로 예상됩니다. 그 후 코드 검사가 업데이트 될 때까지 기다리십시오. “일주일 또는 2 주가 소요될 수 있습니다. 한편, 성능 결정 코드는 모든 레지스터 이동에 대해 올바른 형식의 로깅 명령문을 구토해야합니다.”
가이드 작성자의 마음을 읽을 수는 없지만 위에서 설명한 것처럼 혼란을 정당화하기 위해 가이드를 사용하지 않으려한다고 가정하는 것이 합리적입니다. 이러한 관점에서 본 가이드가 어떠한 시행도하지 않는다고 명확하게 진술하는 것이 더 안전합니다. 그러나이 방법은 서툴지 만, 여전히 광범위한 팀과 프로젝트에 사용할 수 있습니다. 이러한 넓은 허용 범위는 더 성숙하고 효율적인 팀이 개발자의 생산성을 손상시키지 않고 합리적으로 범위를 좁힐 수있는 기회를 제공 할 것으로 예상됩니다.
특정 사례에 적용하여 팀의 코딩 스타일 문서를 작성하고 스타일이 일치하지 않으면 코드 검토에 실패합니다. 개발자가 특정 규칙에 이의를 제기하고 무시하는 데 걸리는 시간을 계산해야한다고 생각합니다. 해결하고 해상도에 따라 변경하거나 복구하십시오.
개발 워크 플로우에 많은 장애를 유발하지 않고이 프로세스를 작동시킬 수있는 방법을 알아 내면, 혼란스럽고 “충분히 울면 위반”대신 공식화되고 추적하기 쉬운 도전 / 해결 방법을 고려해 볼 가치가 있습니다.
부수적으로, 나는 당신이 다른 의견 에서 “코딩 스타일이 이상적이라고 가정하고 그렇지 않은 경우”라고 쓴 것을 언급하고 싶다 .
이것은 실제로 위험한 가정입니다. 나는 광대 한 경험을 가지고 그것에 대해 모든 것을 알고 있다고 생각하는 곳에서 두 번의 프로젝트로 내 코를 부러 뜨 렸습니다. 나는 그것을 떨어 뜨릴 것을 강력히 권장합니다. 스타일 가이드에 실수가있을 수 있다고 가정하고 그러한 실수가 발견 될 경우 어떻게해야할지 생각하는 것이 더 안전합니다.
답변
개인적인 취향 때문에 사람들이 코딩 스타일을 무시하도록 하는 것은 나쁜 생각입니다.
귀하의 질문에 인용 된 것은 모든 개발자가 단순히 “이 스타일을 좋아하지 않기 때문에 사용하지 않을 것”이라고 말할 수있는 것 같습니다.
이것은 모든 요점을 거스 르므로 팀의 모든 사람이 일관성과 가독성을 위해 동일한 방식으로 작업을 수행하게합니다.
나는 그러한 진술을 한 스타일 문서가 무의미하다는 데 동의합니다.
그럼에도 불구하고 스타일 가이드 라인을 준수 할 때 약간의 유연성이 권장됩니다.
- 가이드 라인을 따르지 않으면 특정 코드를 작성하는 가장 좋은 방법을 막을 수 있습니다 . 개발자는 지침을 무시하고 자신이 한 일이이 경우에 무언가를 달성하기위한 가장 읽기 쉬운 방법이라고 주장 할 수 있어야합니다.
- 레거시 코드를 사용하려면 유연성이 필요할 수 있습니다. 기존의 큰 코드 기반을 다시 스타일링하는 데 시간을 잘 사용하지 않는 것이 좋습니다. 특정 섹션을 크게 다시 쓰면 선호하는 스타일로 다시 포맷 할 수 있습니다. 그러나 약간만 변경하면 코드의 기존 스타일을 사용하는 것이 좋습니다.
- 스타일 가이드를 조금만 위반해도 시간을 잘 사용할 수는 없습니다. 코드 검토는 팀의 스타일과 크게 다른 코드를 강조하기에 좋은시기입니다. 그러나 작은 스타일의 “실수”를 포착하고 고치는 것은 잘못된 일에 초점을 맞춘 바쁜 일이 될 것입니다. 스타일이 명백히 무시되면 코드 검토에 실패합니다. 그러나 나는 분석기를 실행하고 잘못 배치 된 모든 괄호 또는 들여 쓰기를 지적한다는 아이디어가 마음에 들지 않습니다.
결론 : 팀의 요구를 가장 잘 충족시키기 위해 스타일 가이드 라인을 유연하게 준수 할 수 있지만 개인 취향과 같은 임의의 이유는 아닙니다.
답변
코딩 스타일 및 스타일 가이드는 코드를 더 읽기 쉽게 만드는 데 도움이됩니다. 그리고 가독성은 복잡성을 돕기 위해 존재합니다.
따라서 궁극적으로 조직의 요구에 맞는 코딩 스타일을 위반할 것인지 (적용이라고 부를 것인지) 여부는 사물을 이해하기 쉽게 만드는 데 도움이됩니다.
OO 프로그래밍에서 기능적 패러다임, 다양한 동시성 모델에 이르기까지 모든 것, 그리고 모든 스트레스는 사람들이 복잡성을 다루는 데 도움이되는 유일한 이유 때문에 존재한다는 것을 기억하십시오.
어떤 바보라도 컴퓨터가 이해할 수있는 코드를 작성할 수 있습니다. 훌륭한 프로그래머는 인간이 이해할 수있는 코드를 작성합니다. -마틴 파울러, 2008
답변
조직의 코딩 스타일은 선택 사항입니까?
조직은 코딩 스타일을 선택합니다. 우선 코딩 스타일이 필요하지 않습니다.
그래서 당신이 읽고있는 인용문은 코딩 “스타일”과 실제 슈퍼 스타 “해커”와 관련하여 가장 큰 문제를 다루고 있습니다. 당신은 새로운 사람을 데리고 와서 좀비를 떨어 뜨리고 오래된 서버를 빠르게 비명을 지도록하는 코드를 작성합니다. .. 그러나 그의 코딩 스타일은 “허용되는 조직 스타일”과 다릅니다. 그는 변화를 거부하고 모든 사람이 자신의 특정 스타일 을 따르도록하는 과정은 시간이 많이 걸리고 비싸다. 이제 뭐?
내가 알고있는 슈퍼 해커의 대부분은 자신의 능력으로 대형으로 자아와 함께, 그들은 조직에 적응하려는 그들 , 다른 방법은 주위에. 따라서 코딩 스타일 표준 은 코딩 스타일 지침 과 비슷해야 하므로이 킬러 해커가 스타일 이탈을 사용하여 타오르는 빠르고 놀라운 코드를 계속 작성할 수는 있지만 다른 사람들이 자신의 서사적 해커에 도달 할 때까지 다른 사람들이 이해해야합니다. 상태에 따라 규칙을 준수해야합니다 (또는 그를 정리하는 데 도움이 됨).
물론 이것은 관리의 악몽이지만 일반적으로 기술 인력을 관리하는 것은 어쨌든 고양이를 방목하는 것과 같습니다. 따라서 대부분의 회사에는 “스타일 표준”이 아닌 “스타일 지침”이 있습니다. 또한 모든 회사의 스타일 위반으로 인해 빌드가 실패하지 않고 코드 검토가 자동으로 실패하지 않습니다. 수퍼 스타 해커를 허용하고 “지침”을 갖거나 수퍼 스타를 잃어 버리고보다 일관된 코드 스타일을가집니다.
답변
그래서이 문서의 내용 과이 질문의 맨 위에있는 인용문을 오해하고 있습니까? 사람들은 코딩 스타일을 무시할 수 있습니까?
따라 다릅니다.
내가 현재있는 곳에는 스타일 가이드가 없으며 별거 아니에요. 프로그래머간에 약간의 차이가 있지만 의미있는 방식으로 가독성, 검색 가능성 또는 일관성에 영향을 미치지는 않습니다. 그리고 우리는 팀의 새로운 구성원이 모두 줄을 서도록 강제 할 수있는 충분히 큰 그룹과 강한 문화를 가지고 있습니다.
이전 회사에서는 빠르게 성장하고 있었고 언어와 관용구에 익숙하지 않은 사람들이있었습니다. 그 회사에서 사람들의 유입은 글을 잘 쓰는 문화가 없다는 것을 의미했습니다. 그리고 언어에 익숙하지 않은 사람들은 조정할 것이 많았습니다. 이 자동화 된 스타일 체커는 조정을 가장 효율적인 방법이었고, 실제 작성 가이드는 우리의 기대에 새로운 사람들을 훈련하는 가장 좋은 방법이었다.
개인적으로 스타일 가이드는별로 신경 쓰지 않고 자동화 된 스타일 적용은 그다지 중요하지 않습니다. 사람이 기본 관용구를 집어들 수 없다면 왜 프로그래머로 고용합니까? 그리고 그들이 나쁜 팀 플레이어라면 다른 사람들이 다루기 어려운 코드를 지속적으로 작성한다면 왜 그 사람들을 고용하고 있습니까?
답변
이것은 코딩 스타일을 관리하는 가장 좋은 방법에 대한 문자 적 해석 대신 심리적 공헌입니다. 팀 / 회사 / 관리자 / 리더가 권위를 떨어 뜨립니다. 나는 개인적이 아닌 상황 적 예외에 더 집중할 것이다. 코딩 문서에 관계없이, 목표는 사물을 쉽게 읽을 수 있도록하는 것입니다. 필요한 경우 혼란스러운 코드를 해결하고 변경해야합니다. 작은 지루한 것들을 처리하는 많은 도구가 있으므로 사용하십시오.
모든 규칙에는 예외가 있습니다. 사람들에게 “일부”흔들기 방을 제공하십시오. 코딩 스타일 규칙 (환영하는 새로운 사람)을 받아들이는 사람이 적을수록 더 많은 사람들이 반격하기를 원합니다. 많은 것들이 흑백이지만, 일부는 해석에 개방적입니다.
모든 세부 사항과 해석에 대항하는 대신 모든 사람이 코딩 지침의 정신에 참여하도록하는 것이 목표입니다.
그렇습니다. 코딩 스타일 문서가 사용하기에 합리적이지 않을 때가 있으며 전문 개발자와 성인 개발자가 그 차이를 알아야합니다.
답변
수정 한 내용을 바탕으로 올바른 목표를 목표로합니다.
스타일 가이드를 사용하면 많은 이점이 있지만 제 생각에 가장 중요한 두 가지는 팀 구성원 간 코드의 가독성과 “어리석은”커밋 (공백 만 또는 추가 줄 등)이 없다는 것입니다.
목표를 달성하려면 선택한 스타일 가이드가 간단하고 준수하기 쉬워야합니다. 실제로 필요한 것에 집중하십시오. 린터를 행복하게하기 위해 거대 코드 견본을 다시 작성하는 것을 좋아하는 사람은 없습니다. 그러나 여전히 이점이있을 수 있습니다.
팀원이 스타일 가이드를 승인하도록하십시오. 당신이 그들을 붙잡을 것입니다, 그들이 동의하는지 또는 그것이 영원한 투쟁이 될 것입니다.
스타일 위반이 “실패”가 아닌 “경고”인지 확인하고 위반이 실패에 해당하는지 사람이 결정하도록합니다. 그 이유는 간단합니다. 나는 간단한 작업 흐름을 믿습니다. “테스트”단계에서 “실패”가 발생하면 프로덕션으로 푸시 할 수 없습니다. 나는 안전으로 사용합니다. 핫픽스도 테스트 단계를 거쳐야합니다 (더 짧아도). 누군가가 ‘대신’를 사용했기 때문에 중요한 버그 수정을 프로덕션에 적용하지 않을 것이라고 말할 수 있습니까? 각각 대신에 for 루프를 사용하는 것은 어떻습니까? 기계 (리터)가 내릴 수없는 결정이므로, 사람이 있는지 확인하고 경고를 판단하고 기계가 고장 나지 않도록하십시오.
스타일 가이드를 무시하려면 사례별로 판단해야합니다. “편차”에 실제 이유가 있는지 확인하십시오. 그들은 올 것이다. 검토 자의 임무는 사소한 것이 아니라 편차에 대한 정당한 이유가 있는지 확인하는 것입니다.