파이썬 코딩 표준과 생산성


18

저는 식량 보급을 가속화하여 긴급 상황에서 생명을 구하는 데 도움이되는 프로젝트 구축 소프트웨어에서 대규모 인도주의 단체를 위해 일하고 있습니다. 많은 NGO가 필사적으로 소프트웨어를 필요로하며 일정보다 몇 주 뒤늦습니다.

이 프로젝트에서 저를 걱정하는 것은 코딩 표준에 지나치게 집중하는 것입니다. 우리는 파이썬 / 장고로 작성하고 PEP0008 버전을 사용합니다. 예를 들어 줄 길이는 최대 160 자까지 가능하며 모든 줄은 가능하면 길어야합니다. 가져 오기 사이에 빈 줄이 없어야합니다. 특정 종류에만 적용되는 줄 바꿈 규칙 문제 등을 해결하는 가장 좋은 방법은 아니지만 클래스, 많은 템플릿을 사용해야합니다.

한 핵심 개발자는 새로운 코딩 표준을 충족시키기 위해 시스템의 주요 부분을 재 작성하는 데 일주일을 보냈습니다. 재 작성이 '유효하지 않음'을 의미하는 과정에서 여러 테스트 스위트를 버렸습니다. 우리는 잃어버린 모든 기능을 다시 작성하고 버그를 수정하는 데 2 ​​주를 보냈습니다. 그는 수석 개발자이며 그의 말은 무게를 지니고 있으므로 프로젝트 관리자에게 이러한 표준이 필요하다고 확신시켰다. 하급 개발자들은 지시대로 행동합니다. 나는 프로젝트 관리자가이 모든 것에 대해인지 적 불협화음에 대해 강한 느낌을 가지고 있지만 그럼에도 불구하고 그가해야 할 일이 확실치 않다고 느끼면서 이에 동의합니다.

오늘 나는 키워드 논쟁에서 쉼표 뒤에 공백을 넣는 것을 잊었 기 때문에 심각한 문제에 봉착했습니다. Skype 통화 중에 다른 두 명의 개발자와 프로젝트 관리자가 문자 그대로 소리 쳤다. 개인적으로 나는 코딩 표준이 중요하다고 생각하지만 우리는 그 표준에 집착하는 데 많은 시간을 낭비하고 있다고 생각합니다. 나는 실패한 희생양을 찾고있는 팀에서 문제를 일으키는 사람으로 여겨진다. 코딩 표준이 도입 된 이후, 팀의 생산성은 크게 떨어졌지만, 이는 단지 강박 관념을 강화시킵니다. 즉, 선두 개발자는 진전이 없다는 표준에 대한 우리의 비준수를 단순히 비난합니다. 그는 우리가 협약을 준수하지 않으면 서로의 코드를 읽을 수 없다고 생각합니다.

이것은 끈적 거리기 시작합니다. 이제 다양한 스크립트, autopep8, pep8ify 및 PythonTidy를 수정하여 규칙과 일치 시키려고합니다. 또한 소스 코드에 대해 pep8을 실행하지만 표준에 대한 암시 적 수정이 너무 많아서 모두 추적하기가 어렵습니다. 간단한 개발자는 다음 스탠드 업 회의에서 pep8 스크립트가 가져 오지 않은 결함을 골라냅니다. 매주 코딩 표준에 새로 추가되어 기존의 작동하고 테스트 된 코드를 다시 작성해야합니다. 우리에게 여전히 시험이있는 하늘에 감사하십시오 (나는 커밋을 되돌리고 그가 제거한 많은 것을 고쳤습니다).

마감 시한을 맞추기위한 압력이 계속 증가하고 있습니다.

근본적인 문제는 수석 개발자와 다른 핵심 개발자가 다른 개발자가 자신의 작업을 수행하는 것을 신뢰하지 않는다는 것입니다. 그러나 어떻게 처리합니까? 우리는 모든 것을 다시 쓰고 너무 바빠서 일을 할 수 없습니다.

소프트웨어 엔지니어링 팀에서 이런 역동적 인 경험을 한 적이 없습니다. 코딩 표준을 준수하는지 의심하는 것이 잘못 되었습니까? 다른 사람이 비슷한 상황을 경험했으며 어떻게 성공적으로 처리 했습니까? (나는 사람들이 찾은 실제 솔루션에 대한 토론을 찾고 있지 않습니다)


4
코딩 표준은 장기 생산성을 높이기위한 것입니다. 기존 프로젝트가 오랫동안 표준을 따르지 않으면 단기 생산성 비용이 발생합니다.
Arseni Mourzenko

1
코딩 표준에 따라 코드를 자동 형식화하도록 Eclipse 및 PyDev를 프로그래밍하십시오. 몇 개의 대화 상자를 채우는 문제입니다.
user16764

1
@DemianBrecht-모든 코더 정의하고 동의 한 공동 작성 코딩 표준 은 좋은 것이며 장기적인 생산성을 향상시킬 수 있습니다 . 의 팀으로부터의 매입없이 부과 된 권위 주의적 코딩 표준 은 시간을 낭비 하고 코드를 리팩토링하기 때문에 소위 수석 개발자 가 테스트를 포기하는 소위 수석 개발자 의 사례처럼 프로젝트가 정체되거나 심지어 퇴보 될 수 있습니다. 새로운 표준은 이러한 테스트에 실패했습니다. 솔직히 WTF?
Mark Booth

1
@MarkBooth : 모든 사람을 기쁘게 할 수는 없습니다. 위에서 언급 한 것만으로 다른 회원들로부터 구매하기가 더 어렵지만 여전히 "거대한 시간 낭비"는 아니라는 데 동의합니다. 표준을 마련하면 코드의 일관성이 훨씬 높아야 하므로 프로젝트 전체에서 코드의 다양성이 줄어들어 가독성이 향상됩니다. 하지만 그렇습니다. 표준으로 인해 테스트를 폐기하면 더 큰 문제가 있다고 생각하게됩니다.
데미안 브레히트

1
@ Demian Brecht :이 질문의 기본 요점은 코딩 표준이 아니라고 확신하지만 코드의 외관 문제가 기본적으로 늦고 중요도가 높은 프로젝트의 다른 것보다 우선 순위가 높다는 사실 .
Buhb

답변:


27

코딩 표준은 문제가되지 않습니다. 문제는 경영진이 문제가 무엇인지 파악할 수 없다는 것입니다. 이것은 "무엇을합니까… 무엇이든!" 방법. 합리적인 솔루션을 찾고 있지만 비이성적 인 문제입니다. 당신이 할 수있는 최선은 :

  • 그들의 아이디어에 대해 건설적인 비판을 제공하지만 일단 결정이 내려지면 계속 그것에 대해 울리지 않습니다.
  • 재 작성을 더 쉽게하기 위해 할 수있는 모든 것을하십시오.
  • 스트레스를 중지하십시오. 누락 된 마감일은 관리자의 문제가 아니라 관리자의 문제입니다. 최선을 다하되 열악한 결정에 대해서는 책임을지지 않습니다.
  • 도움이 될만한 것을 알고 있다면 알려주십시오. 스탠드 업에 대한 언급은 민첩하게 행동하는 것처럼 들리지만 나머지는 매우 민첩하게 들리지 않습니다. 모든 것에 대해 한 가지 큰 기한을 맞추려고하는 대신 제한된 기능을 더 일찍 제공 할 수 있는지 확인하십시오. 재 작성에 대한 사용자 스토리를 작성하여 백 로그에 미치는 영향을 명확히하십시오.
  • 다른 직업을 찾기 시작하십시오. 진심으로. 그러한 주에있는 회사는 사람들을 해고하기 시작하는 데 그리 멀지 않습니다.
  • "당신에게 그렇게 말해"티셔츠를 인쇄하십시오 :-)

좋은 지적입니다. 실제로 저는 코딩 표준에 반대하지 않습니다. 예를 들어 마지막 회의에서 표준에 새로 추가 된 것은 모든 클래스와 기능에 대한 문서화 문자열을 명령하는 것이 었습니다. 돈은 다른 직업을 찾기에는 너무 좋은 방법입니다. 나는 코드 재 포맷을 시도했지만, 팀이 리드 개발자의 사용을 금지하도록 제안했다. 나는 원격 작동하고 코드를 만들기 때문에 내가 pep8ify를 찾는하고있어 사용에 하나 그래서이 규칙은 시행 할 수없는 단지 그것이 인간의 편집처럼 보이는, 그래서 표준을 전달합니다. 즉, 최소한의 수정 만 수행합니다.
Shroatmeister

1
거의 마감일 놓칠 것이라고 덧붙였다. 이것은 죽음의 행진이며 누군가 당신을 비난하려고 시도 할 것입니다. 모든 작업을 문서화해야합니다. 각 작업에 소요 된 시간을 추적하고 모든 메일 및 / 또는 채팅 로그를 보관하여 자신을 방어 할 수 있습니다.
coredump

7

코딩 표준에 대한 선적 또는 노예 준수가 진정한 우선 순위인지 결정해야합니다. 나는 나의 선호도가 무엇인지 안다. 그것이 단위 및 합격 시험을 통과한다면, 나는 배를 말한다. 배송이 완료되면 회사는 기술 부채를 해결하기 위해 시간과 돈을 소비할지 여부를 결정할 수 있습니다.

쉼표 뒤에 공백이있는 문제는 코드 사전 도구로 쉽게 해결할 수 있습니다. 모든 코딩 규칙을 적용하는 도구를 찾고 빌드 및 테스트를 수행하기 전에 수정 된 모든 코드에서 해당 도구를 실행하십시오. 괜찮은 IDE는 이미 코드를 작성 하면서이 작업을 수행 합니다.


pep8ify가이 재 포맷에 유용하다는 것을 알았습니다. 표준을 충족시키기 위해 최소한의 수정 만하는 것으로 보이며 명령 줄 구성 기능이 다소 제한되어 있지만 코드를 쉽게 수정할 수 있습니다.
Shroatmeister

4

코딩 표준을 준수하는지 의심하는 것이 잘못 되었습니까?

그룹에 따라 다릅니다. 개인적으로 , 나는 모든 것에 의문을 제기해야한다고 생각합니다. 어떤 사람들은 그 질문을 외면으로 생각합니다. 나는 그들을 믿지 않는다.

다른 사람이 비슷한 상황을 경험했으며 어떻게 성공적으로 처리 했습니까?

이러한 표준이 어떻게 생산성을 향상시키는 지 물었습니다. 나는 표준과 '일을 끝내는 것'으로 조이는 데 걸린 시간을 측정했습니다. 결국, 표준에 충실하기로 결정한 힘. 일어난다. 나는 그들이 일을 끝내지 않는 원인이었을 때 평소보다 더 크게 불평했지만 그렇지 않으면 내 일을 끝내는 데 집중했습니다. 지속적으로 일하는 것에 대한 싸움은 생산성에도 좋지 않습니다 ...

당신이 말했듯이, 표준으로 인해 상황이 상당히 악화되면 표준을 준수하면 리드의 주장을 무효화하고 당신의 입장을 떠나야합니다. 사람들이 표준 구현과 생산성 저하 사이에 (거의) 객관적인 상관 관계를 볼 수 없다면 더 이상 할 수있는 일이 없습니다. 그것을 다루는 법을 배우십시오. 그렇지 않으면 관료적이지 않은 곳을 찾으십시오.


3

표준은 마감일이 다가오는 프로젝트 후반에 놓아서는 안되는 것입니다. 프로젝트 초반에 또는 잠재적으로 큰 문제 코드 리팩터링을 위해 프로젝트 일정 (초기 배송 후)을 따로 떼어 놓아야 할 때가되어야합니다.

이것이 실제로 프로젝트 후반에 투입된 경우, 귀하의 리드 (IMHO)가 실수 한 것입니다.

그러나 , 이것은 당신이 당신의 리드에 동의하지 않는 경우 당신은 그냥 반란으로 미리 충전해야한다는 것을 의미하지 않는다. 이것은 당신의 입니다. 당신은 팀으로 일 합니다. 당신은 리드가 있습니다. 팀에는 어느 정도 수준의 민주주의가 있어야하지만 결국에는 독재자가 리드입니다. 그가 뭔가를하라고한다면 그렇게하세요.

결국, 그의 요청과 표준을 준수하면서 마감 기한이 지남에 대한 쉬운 희생양을 제공하지 않습니다.

또한, 나는거야 거대한 (팀의 크기가 증가 특히) 표준 코딩의 옹호하지만 의미가 때 구현해야합니다.


1

귀하의 질문은``코딩 표준을 준수하는지 질문하는 것이 잘못 되었습니까? ''였습니다. http://c0x.coding-guidelines.com/Introduction.pdf(C 프로그래밍 언어의 경우)에는 코딩 지침의 가치에 대한 몇 가지 참조 된 연구가 있습니다. 39 페이지에서 시작하는 섹션 9를 참조하십시오.

코딩 표준은 이유 때문에 구현됩니다. 원래 질문에서 누락 된 것 중 하나는 특정 프로젝트 (또는 특정 조직)에서 이러한 특정 표준의 이유에 대한 이해입니다. 기존 코드로 구현하기로 한 결정은 몇 가지 논리를 기반으로했습니다. 논리를 알지 못하면 해당 결정의 '좋은 점'에 대해 언급하기가 어렵습니다.

두 번째로 코드의 유지 관리 성과 같은 문제인 '장기 생산성'에 대해 표준이 구현되었다고 말한 것입니다. 혼란과 오해로 인해 프로젝트를 심각하게 되돌려 놓은 일부 이벤트가 발생했을 수 있습니다.

그것은 양쪽에 많은 감정이있는 것처럼 들립니다-합리적인 토론을 시도하십시오.


1

다른 답변과 의견에서 알 수 있듯이 프로젝트에는 큰 문제가 있으므로 제안 할 것은 큰 성공 기회는 없지만 너무 큰 위험없이 시도 할 수있는 것입니다. 당신의 피부.

수석 개발자와 네 눈 사이에 회의를 요청하십시오. 코딩 표준을 엄격하게 적용함으로써 얻을 수있는 이점과 도입하기 전에 코드베이스가 왜 그렇게 나쁜지 이해하는 데 관심이 있다고 가정하십시오. 이 토론을하는 동안 매우 개방적이고 "배우려고합니다"태도를 유지하는 것이 매우 중요합니다. 귀하의 수석 개발자는 아마도 귀 하나 귀하의 팀원 중 누구보다 스트레스를 많이 받았으며, 약간의 악취를 느끼 자마자 매우 방어적일 것입니다.

일반적인 목표를 달성 할 수있는 방법을 찾으려고하는 방향으로 토론을 밀어 내십시오. 작동 및 유지 관리 가능한 소프트웨어를 신속하게 제공합니다.

예를 들어, 일부 매달린 과일은 코딩 지침에 더 이상 아무것도 추가하지 않는 것입니다. 이러한 상황이 발생할 때마다 이전에 지침을 준수한 코드는 더 이상 수행하지 않으므로 코드를 다시 작성해야합니다. 추가 된 규칙이 그의 관점에서 가치를 추가하더라도 이미 늦은 프로젝트의이 단계에서 재 작성 동기를 부여하는 것만 큼 좋지 않을 수 있음을 잘 알고 있기를 바랍니다.

이것이 작동하면 일부 도구로 자동 서식을 지정할 수없는 임의의 규칙을 제거하도록 할 수 있습니다.


-2

코딩 표준이 좋습니다. 코딩 표준을 변경하는 것은 비용이 많이 듭니다 (잘 허용하지 않으면 비용이 많이 듭니다. 표준을 변경하면 기존 코드가 모두 호환되는 경우 문제가되지 않습니다). 반드시 필요한 경우에만 수행해야합니다.

어쩌면 기존 툴 체인이 자동으로 확인할 수없는 것처럼 보이기 때문에 커밋 / 병합 / 표준을 준수하기 전에 모든 코드를 리드가 확인해야합니다.


-3

식품 유통 속도를 높여 응급 상황에서 생명구할 수있는 소프트웨어

나는 좋은 코딩 표준을 믿지만 생명구하는 것이 훨씬 더 중요하다고 생각합니다.

가장 우선 순위는 사람들의 생명을 구하는 것 입니다. 이 소프트웨어가 가족이나 팀에게 음식을 배포한다고 가정 해보십시오. 다른 것은 다음에 올 수 있습니다.

좋은 소식 : 테스트가 있습니다. 테스트를 수행하면 기능을 중단하지 않고 코딩 표준을 준수하는 데 도움이되지만 , 출하 후가 아니라 출하 후에 발생해야합니다 .


1
배송 후 어떻게됩니까? 기능을 중단하지 않고 코딩 표준을 준수합니까? 시험 있어요?
Martijn Pieters

선적 후, 그는 코딩 표준을 따라 작업해야합니다.
Mohammad Tayseer
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.