어떤 시점에서 코드에 대한 "구성 적"비판이 도움이되지 않습니까?


39

저는 최근에 주니어 개발자로 시작했습니다. 나는 팀에서 가장 경험이 적은 사람들 중 한 명일뿐만 아니라, 남성 지배적 인 환경에서 일하는 모든 종류의 도전과 함께 제공되는 여성이기도합니다. 요즘 내 작품에 대해 너무 많은 불합리한 비판을 받고있는 것처럼 느껴져서 문제가 생겼습니다. 최근에 일어난 일에 대한 예를 들어 보겠습니다.

팀장이 너무 바빠서 내가 만든 일부 지점을 밀지 못해 주말까지는 가지 못했습니다. 필자는 실제로 메일을 확인했지만 실제로는 아무런 의미가 없으며 변수 이름을 기준으로 두 가지 분기가 거부되어 오류 메시지를보다 설명 적으로 만들고 일부 값을 구성 파일로 옮겼습니다.

이 기준에 따라 지점을 거부하는 것이 유용하다고 생각하지 않습니다. 주말 동안 많은 사람들이 일하고 있었고, 나는 내가 일할 것이라고 말한 적이 없었습니다. 효과적으로 변경하고 다시 제출할 시간이 없었기 때문에 일부 사람들은 차단되었을 수 있습니다. 우리는 매우 시간에 민감한 프로젝트를 진행 중이며 클라이언트에게 투명한 것을 기반으로 코드를 완전히 거부하는 것이 도움이되지 않는 것 같습니다. 틀릴 수도 있지만 시간이있을 때 이러한 종류의 작업을 패치 유형 커밋에서 처리해야합니다.

이제 일부 환경에서는 이것이 표준 일 것입니다. 그러나 비판은 똑같이 분배되지 않은 것 같습니다. 이것이 다음 문제로 이어집니다. 이 문제의 대부분의 기초는 내가 다른 사람이 작성하고 최소한의 침입을 시도하는 코드베이스에 있었기 때문입니다. 파일의 다른 곳에서 사용되는 변수 이름을 모방했습니다. 이 말을했을 때 나는 "다른 사람들을 모방하지 말고 옳은 일을하라"고 무뚝뚝하게 들었다. 이것은 아마도 내가 들었을 때 가장 유용한 것입니다. 이미 체크인 된 코드가 받아 들일 수 없다면, 무엇이 옳고 그른지를 어떻게 말해야합니까? 혼란의 기초가 기본 코드에서 나온다면 나는 그것을 생각하지 않습니다.

나는이 상황에서 정말로 단절되고 좌절감을 느낍니다. 나는 기대되는 표준을 따르는 것에 대해 훨씬 더 잘 얻었으며, 예를 들어, 이전에 누락 된 ADD 오류 검사로 코드 조각을 리팩터링 할 때 좌절감을 느낍니다. 오류를 충분히 자세하게 작성하십시오 (이 기준으로 분기가 거부되었습니다). 처음에 추가하지 않은 경우 어떻게합니까? 그것이 잘못 되었다면 어떻게 코드에 들어갔습니까? 그렇기 때문에 필자는 이러한 문제를 해결해야합니다. 기존의 문제가되는 코드를 지속적으로 실행하여 모방하거나 리팩터링합니다. 내가 그것을 모방 할 때, 그것은 "잘못된"것이며, ​​그것을 리팩토링하면, 충분히하지 않은 것에 대해 골칫거리가됩니다 (그리고 계속 나아가면 버그를 도입하는 등). 다시 말하지만, 이것이 그러한 문제라면 코드가 코드베이스에 들어가는 방법을 이해하지 못합니다.

어쨌든, 나는 이것을 어떻게 처리합니까? 맨 위에 내가 여자라고 말한 것을 기억하십시오.이 남자들은 다른 남자의 코드를 검토 할 때 장식에 대해 걱정할 필요가 없지만 솔직히 저에게는 효과가 없다고 확신합니다. , 생산성이 떨어집니다. 관리자와 이야기하면 환경 등을 처리 할 수 ​​없다고 생각합니다.


18
저는 주니어 (이 회사의) 남자이며 비슷한 이중 표준을 느꼈습니다. 코드베이스는 종종 쓰레기처럼 보이지만 훨씬 더 높은 표준을 따를 것으로 예상됩니다. 글쎄, 과거에 만들어진 "죽음 행진"으로 인해 쓰레기가 들어갔다는 것이 밝혀졌습니다. 또한, 나는 나보다 5 년 어리게 보입니다. 동료들이 제 나이를 알게되자 밤새 훨씬 똑똑해졌습니다. 인간은 불완전한 원숭이입니다. 당신이 그들과 함께 점심을 공유하고 그들의 농담에 웃음을하지만 도움이되지 않는 경우 도움이됩니다. 남자들은 모든 것을 바람둥이로 해석합니다.
직업

4
@Job : 글쎄, 코드베이스가 엉망이라면 더 좋을 것이므로 커밋의 표준이 높아야합니다. 그렇지 않으면 훨씬 더 엉망이 될 것입니다. :)
Macke February

@Marcus, 당신 말이 맞지만, 실제로 도움이 될 것은 규칙이 명확하게 명시되어 있고 모든 사람에게 동일한 규칙이 적용되는 것입니다. 또한 언급 한 바와 같이 동일한 코드 표준으로 혼합하는 것에 대해 이야기 할 것이 있습니다. 나는 주니어 녀석이 희생양으로 가두는 것을 보았다. 경영진은 엔지니어들이 너무 많은 버그를 생성했다고 불평했다. 경영진이 정해진 기한을 정하기 때문에 엔지니어는 적절한 작업을 수행 할 수 없습니다. 따라서 무언가 잘못되었을 때, 항상 비난을 당할 가장 조잡한 주니어 선수가 있습니다. en.wikipedia.org/wiki/Dedovshchina
직업

3
나에게 눈에 띄는 한 가지는 "그들은 사람들에게 익숙해 져서 decorum을 사용하지 않는다"는 것입니다. 분명히 차별의 문제가 아니라면 당신은 그것을 빨아 들여야한다고 말하고 싶습니다. 건설 현장에 가서 나머지 프레이머와는 다른 대우를 받으시겠습니까? 강화. 남성이 지배하는 환경에서 일하는 경우 다른 사회 규범에 맞게 대처하고 적응할 수 있어야합니다. 너무 "민감하지 마십시오".
Rig

1
나는 이것이 수년이 너무 늦다는 것을 알고 있지만, 이것이 미래 독자들에게 중요한 주제라고 생각합니다. 팀장이 단순히 더 잘 알고있을 가능성을 배제하지 마십시오. 그는 아마도 더 나이가 많고 문제가있는 스타일 문제에 대한 직관을 발전 시켰습니다. 저는이 상황에 처한 사람들에게 이것을 배우고 성장할 수있는 기회로 대우합니다. 정중하게 당신이 이해하지 못하는 문제에 대한 설명을 요청, 악성으로 동료의 건조 성격을 잘못 해석하지 않도록주의.
weberc2

답변:


41

당신이 여성으로 선정되었을 가능성이 있지만, 당신은 주니어 개발자 일뿐 아니라 직장에 새로 온 사람 일 수도 있습니다.

오류 점검 및 표현 메시지가 중요합니다. 코드에 무언가를 추가하려는 경우 코드가 팀의 표준에 맞는지 확인하십시오. 마찬가지로, 다른 사람의 코드를 수정하는 경우 가능한 경우 코드를 개선하십시오. 전체 내용을 다시 작성하지 말고 찾은 것보다 조금 더 깔끔하게 남겨 두십시오.

팀이 따르는 코딩 표준의 서면 버전이 있습니까? 그렇지 않다면 모두 적어 두는 것이 좋습니다. 실수를 기록한 후 검토를 위해 변경 사항을 제출하기 전에 참조 할 수있는 점검 목록으로 작성하여 노력을 주도 할 수 있습니다. 부작용으로, 해당 서면 표준을 사용하여 향후 거부에 모순되는 경우이를 거부 할 수 있습니다.

당신과 팀장 사이에 이해가 부족한 것 같습니다. 그와 일대일 회의를 요청하고 개선을 위해 할 수있는 일에 대해 토론하는 것이 도움이 될 수 있습니다. "여전히해야 할 일에 대해 많은 뉘앙스가 빠져있는 것 같은 느낌이 듭니다. 주니어 개발자로서 성장하고 개선하고 싶습니다. 도와 드릴까요?" 그리고 어떻게되는지보십시오.


Anna의 답변은 일반적으로 매우 합리적입니다. +1. 나는 당신이 일하는 곳에서 일하는 것이 나를 혼란스럽게 할 것이라고 생각합니다. 경영진이 마감일을 맞추는 것을 신경 쓰지 않습니까? 코드가 작동하면 배송하십시오. 나중에 청소하십시오. 심지어 월요일에 정리하고 다음 릴리스에서 밀어 넣을 수도 있습니다. 귀하의 관리자의 이러한 행동은 절대 제 직장에서 날아 가지 않을 것이며, 정치 대신 마감일을 맞추는 데 집중할 수있어서 기쁩니다. 상황이 나아지고 해결책을 찾기를 바랍니다. :)
jmort253

11
감사합니다. :) 즉, "코드가 작동하면 배송"하는 것은 위험한 태도가 될 수 있습니다. 작업 코드는 항상 좋은 코드는 아니지만 (깨진 코드보다 확실히 낫지 만) 장기적으로 코드 품질이 중요합니다. 다른 마감일이 나타나고 더 시급한 일이 발생하기 때문에 나중에 청소하는 것은 거의 일어나지 않습니다. "기술 부채"라는 용어가 있습니다.
Adam Lear

@Anna, 준수 코드의 중요성에 동의하십시오. Linus Thorvalds가 Linux에 제출 된 패치를 그 자리에서 거부하기에 적합하지 않은 코드로 충분하다고 읽었지만 지금은 찾을 수 없습니다.

@ Anna / Thorbjorn-마감일이있는 경우 고객이 원하는 것을 수행해야하는 경우가 있습니다. 고객은 단순히 자본화 오류를 정리하고 싶기 때문에 15,000 달러 상당의 사업 수익을 잃어버린 경우 이해하지 못할 것입니다. 불행히도 100 %의 기술 부채를 제거하려고 시도하는 것이 항상 가능한 것은 아닙니다. 주택 담보 대출을받는 대신 꿈의 집을 사기에 충분한 현금을 절약하기 위해 40 년을 기다리는 것과 비슷합니다. 물론, 당신은 자유롭고 분명 할 것이지만, 그늘진 집주인을 다루는 데 평생을 보냈습니다.
jmort253

오픈 소스 프로젝트는 수익 프로젝트와 다릅니다. 많은 오픈 소스 프로젝트는 항상 이익 / 손실이 항상있는 것은 아니기 때문에 더 엄격한 표준을 가질 여유가 있습니다. 독점 프로젝트는 서로 다른 목표를 가지고 있으며 때로는 이러한 비즈니스 목표가 우선합니다. 코드가 맞지 않아야한다고 말하는 것은 아닙니다. 때로는 배치 해야하는 문제를 해결하고 다시 해결 해야하는 징계를 수행해야 할 때가 있습니다.
jmort253

25

이 물건을 조금 개인적으로 복용하는 것 같습니다. 하지 마십시오; 이런 종류의 일은 항상 일어난다.

체크인을 거부하는 이유 (가변 이름, 설명 품질, 구성 위치)는 나에게 매우 표준적인 것 같습니다.

그 시점은 팀장의 결정이었습니다. 제가 당신이라면 걱정하지 않습니다. 주말에 누군가가 차단되면 팀장이 체크인을 허용하고 나중에이를 해결하도록 요청할 수 있습니다. 그가 다른 개발자들을 막을 수 있다고해도 반동하는 것이 적절하다고 느꼈다면 그것은 그의 책임입니다.

팀장에게 다른 사람을 모방하지 말고 옳은 일을하도록 지시하는 것은 코드 기반을 개선하기 위해 약간의 노력을 기울이려는 것처럼 들립니다. 좋은 징조입니다. 그는 당신이 당신의 판단 을 사용하도록 믿습니다 . 그렇다고해서 다른 사람의 코드를 변경해야한다는 의미는 아니지만 작성하는 코드의 품질에 대한 책임을 져야한다는 의미입니다.


2
+1 당신은 관계와 감정에 집중하고 있습니다. 당신이 일하는 프로그래머는 매우 건조하지만 코드 문제에 집중하고 있습니다. 이것은 내가 일한 프로그래밍 환경에서 꽤 일반적입니다. 저는 성별에 관계없이 이것을 보았습니다.
Michael Durrant

14

다른 답변에 추가 :

수석 개발자 인 저는 보통 주니어 개발자들에게 더 까다 롭습니다. 왜냐하면 그들은 몇 년 동안 일해 온 사람들보다 훨씬 가단하기 때문입니다. (내 ppl 기술은 그렇게 좋지 않습니다 ... 아직.)

한동안 일하고 있고 (급당한 임금을받는) 사람을 바꾸는 것은 매우 어렵고 (품질은 향상 될 수 있음에도 불구하고) 자신의 코드 수준에 만족합니다. 그 사람들은 당신이 그들을 더 나은 / 좋은 프로그래머가되도록 안내하려고해도 상관하지 않습니다. 그들은 코드 팩토리에서 일하는 것을 기쁘게 생각합니다.

당신과 같은 새로운 사람들, OTOH는 보통지도를하고 옳고 그른 것을 아는 것을 갈망합니다. 또한, 그들은 지불 거절을 흡수하고 더 나은 방법을 변경할 수 있습니다. 그들은 그 방식으로 설정되지 않았습니다.

이러한 조언을 염두에두고 일상 생활의 일부로 만들면 기존 코드 기반보다 훨씬 우수한 코드를 곧 작성할 수 있다는 것을 알게 될 것입니다.

그래서 ...

.. 무언가를 만들 가능성이 있기 때문에 더 많은 피드백을 받고있을 수 있습니다. :)


이것은 많은 좋은 점을 제기합니다.
sevenseacat

13

당신은 주니어 개발자이기 때문에 당신이 독점 될 가능성이 있습니다.

귀하의 설명 에서 팀 리더가이를 인식 할 때 표준 따르지 않은 것 같습니다 .

해결책은 간단합니다.

  • 그것이 표준이라면 따르십시오.
  • 표준을 이해하지 못하면 설명을 요청하십시오.
  • 표준 또는 지침에 대한 해석이 팀장과 다른 경우 설명을 요청하십시오.

그것으로 싸움을하지 마십시오; 만약 당신이 팀장을 "잘못"만들려고한다면, 이길지라도 당신은집니다. 적절한 교훈을 배우고 계속 성장하십시오.


1
"T"에 대해 "표준"을 따르는 것은 그녀가 묘사 한 것처럼 독을 다루는 것은 그리 좋지 않습니다. 정의와 시맨틱에 대한 끝없는 논쟁이 될 것입니다.
MrDatabase

4
@MrDatabase 그들은 나에게 dorks처럼 들리지 않습니다. 약간 까다 롭지 만, 악마는 종종 세부 사항에 있으며 표준을 미끄러지기 시작하면 전체 앱이 빠르게 내리막 길 수 있습니다.
Adam Lear

3
표준을 준수해야한다는 것은 사실입니다. 그러나 그녀는 그것이 실제로 표준이 아님을 분명히 보여줍니다 (이전 개발자들은이를 따르지 않았습니다). 그러므로 그녀의 동료들은 그녀에게 "표준"을 강요합니다 ( "이봐 요. 동료가 이와 같이 행동 할 때는 다른 똑똑한 접근 방식을 취해야합니다.
MrDatabase

@ user15859 : 당신이 내 대답을 언급한다면, 그것은 나의 의도가 아닙니다. 나는 Anna가 그녀의 대답에서했던 것과 똑같은 말을했다고 믿습니다. 범죄가 의도되지 않았습니다. 언급 한 표준 위반은 장기적인 유지 관리에 중요하며 표준 적용 범위의 모호성은 팀장과 함께 해결해야합니다. 당신이 게으른 경우 여기에 게시하지 않았을 것입니다. 당신이 무능한 사람이라면별로 신경 쓰지 않을 것입니다. 나는 당신이 그 둘 중 하나라고 믿지 않습니다.
Steven A. Lowe

1
그녀는 Woot4Moot가 자신의 의견에서 "게으름과 무능함"을 문구로 사용했을 때의 말을 언급하고 있다고 생각합니다. OP가 실제로 진행되고있는 것에 대한 그녀의 해석에 따라 조치를 취할 수있는 수단과 방을 제공하기 때문에 귀하의 대답은 괜찮다고 생각합니다.
jmort253

10

저자의 메모

몇 년 후; 상황에 대한 느낌을보다 정확하게 반영하기 위해 이것을 편집했습니다. 이러한 상황에서 뉘앙스에 대해 더 많이 배우기 때문에 답변에 더 많은 뉘앙스를 적용하고 있습니다. '흑백'답변을 주장하는 것은 쉽지만, 우리는 그것이 간단하지 않다는 것을 알고 있습니다. 내 대답은 이제 그것을 반영합니다.

당신이 묘사 한 것에서; 겪고있는 행동은 성별과 관련이없는 것으로 보입니다. 그것은 당신이 어떤 성 관련 치료를 받고 있지 않다고 말하는 것이 아닙니다 (나는 당신이하지 않기를 바랍니다), 당신이 묘사 한 것이 성 관련이 아닌 것 같습니다.

내가 팀장이었을 때 모든 사람을 동등하게 대했습니다. 기술 때문에 성별 때문에 누군가를 심하게 대우 할 여지가 없습니다. 그것이 당신에게 일어나면 어떻게 대처 해야할지 모르겠습니다.

팀장이 남성과 여성을 동등하게 대우한다는 것을 신뢰하는 것이 중요합니다. 그가 그렇지 않다는 증거가 있다면, 이전의 말이 적용됩니다 : 환경을 바꾸거나 환경을 바꾸십시오.

마찬가지로 나는 그가 성별에 대한 지체없이 모든 사람을 동등하게 대우한다는 것을 의미합니다. 그가 자신의 일을 올바르게하고 있다면, 다른 사람을 비난하는 것을 보지 않아야합니다. 그들이 당신을 비판하는 것을 보지 않아야합니다. 다른 사람들 앞에서 팀 리더가 지난 5 분 동안 개인적으로 행동을 바로 잡기 위해 보낸 경우에도 자신감을 나타내는 것이 매우 중요합니다.

이제 제기 한 문제에 대해 :

자신이 설정 한 표준에 맞지 않는 코드를 체크인 했으므로 지점을 거부했습니다. 내가 그의 신발을 신었다면 같은 방식으로 똑같은 일을하지 않았지만 내 부하들 (홀수 단어; 나는 지도자를 사람들에게 '우수한'것으로 생각하지 않기 때문에 리드; 그러나 상황을 정확하게 (적절하게 묘사하지 않음) 설명하는 것은 올바른 일이 무엇인지 알고 있습니다. 그들이 표준이 무엇인지 모른다면 그것은 리더로서의 잘못입니다. 그것을 고치는 것은 나에게 달려 있습니다. 이 경우 실수를했을 수도 있지만 1) 옳은 일이 무엇인지 알지 못했거나 2) 제대로 멘토링을받지 않았다는 사실 만 알 수 있습니다. 당신의 잘못도 아닙니다.

프로그래머가되는 데있어 가장 중요한 부분 중 하나는 작업하는 코드베이스를 여러 사람이 유지 관리 할 수 ​​있어야한다는 점입니다. 읽기 어려운 코드의 문제를 해결하는 데 시간이 오래 걸리기 때문에 변수 엉망이나 코드를 읽을 수없는 다른 요소 는 고객에게 투명하지 않습니다 .

팀에서 코딩 지침을 작성한 경우 해당 지침을 따르십시오. 그렇지 않은 경우 사용자 언어에 대한 일종의 커뮤니티 규칙이 있어야합니다 (.NET 및 C #의 경우 Microsoft에는 많은 회사가 따르는 표준 이 있습니다).

코딩 지침이 어디에 있는지 팀장에게 문의하여 지침을 따르십시오. 다른 두 개발자가 지속적으로 지침을 따르지 않은 회의에 두 번의 체크인을 수행하십시오. 아무도 없다고 말할 때 다른 사람들도 문제가있는 것처럼 보이고 모든 사람이 혜택을 누릴 수 있음을 지적 할 수 있습니다 그 지침.

그가 당신을 공정하게 대우한다면, 그는 이것을 보게 될 것이며 이것은 그의 할 일 목록의 맨 위에 있어야합니다. 그가 당신을 공정하게 대하지 않는다면, 계속 일어나면 탄약이있는 것입니다.

"나중에 알게 될 것"이라고 말하는 것은 나쁘다. 나중에는 결코 일어나지 않습니다. 시간을내어 올바르게 수행하십시오. 프로그래밍에는 더 이상 없습니다.

주니어 개발자 일 때는 어렵습니다. 당신은 수행해야한다는 압박감을 느끼고 많은 사람들이 당신을 바라보고 있으며, 당신이하는 모든 실수는 영원히 소스 제어의 이름과 관련이 있습니다.


1
"나중에 알게 될 것"에 대한 의견을 두 번째로 설명하겠습니다. 내가 들었을 때마다 니켈이 있다면 글쎄, 나는이 의견을 여기에 입력하지 않을 것입니다. :-)
Eric King

.Net의 경우 스타일 경찰이 있습니다. StyleCop이 행복해질 때까지 코드가 작성되지 않도록 설정하십시오. 이것은 인간 주관성을 제거합니다. 기술은 Michael Phelps가 1 위인지 2 위인지 결정하는 데 도움이 될 수 있습니다. 그러나 피겨 스케이팅에서는 ... figurekating.about.com/od/famousskaters/tp/scandals.htm 팀 리더가되는 것은 파워 트립에 관한 것이 아닙니다. 팀에 [좋아요]가 없어야합니다. 그러한 인상이 형성되지 않도록주의해야합니다. 이를 수행하는 좋은 방법 중 하나는 코드를 확인하고 편견없는 답변을 제공하는 규칙을 설정하는 것입니다.
직업

3

게시물의 다른 곳에서는 다른 사람들이 어떻게 대우되는지 언급하지 않습니다. 당신은 "여자"이기 때문에 "느껴지는"느낌을 반복합니다.

나는 당신이 당신의 성별에 관계없이 주니어 프로그래머처럼 대우 받고 있다고 생각합니다. 왜냐하면 평등이 의미하기 때문입니다. 또한 5 분 길이의 사소한 코드 미적 변화를 할 일 목록에 올려 놓지 않고 지금해야하는 코드 미적 변화에 대해 큰 혼란을 겪고 있다고 생각합니다.

귀하의 게시물에서 주말에 이러한 작업을 수행하라는 명령을받은 곳은 없습니다. 월요일 아침에 수정 사항을 확인하는 것이 좋습니다.

귀하의 팀장은 내 취향에 약간 도움이 될 수 있지만 귀하의 게시물에서 나는 그의 요청에 잘못된 것을 보지 못합니다.

성별 카드 사용을 중단하십시오 . 나는 이것이 품위가없고 성 평등의 개념을 훼손한다고 생각한다.


1

이 기준에 따라 지점을 거부하는 것이 유용하다고 생각하지 않습니다. 주말 동안 많은 사람들이 일하고 있었고, 나는 내가 일할 것이라고 말한 적이 없었습니다. 효과적으로 변경하고 다시 제출할 시간이 없었기 때문에 일부 사람들은 차단되었을 수 있습니다. 우리는 매우 시간에 민감한 프로젝트를 진행 중이며 클라이언트에게 투명한 것을 기반으로 코드를 완전히 거부하는 것이 도움이되지 않는 것 같습니다. 틀릴 수도 있지만 시간이있을 때 이러한 종류의 작업을 패치 유형 커밋에서 처리해야합니다.

코드를 보지 않았거나 프로젝트 일정에 대해 알지 못하는 사람에게 유용한 것을 말하기는 어렵습니다. 그러나 만약 당신의 리드가 책임감있게 행동하고 좋은 일을한다면, 다른 사람들은 실제로 막히지 않았고 스프린트는 늦지 않을 것입니다. 따라서 걱정하지 마십시오. 아마도 당신은 당신의 커밋에 대한 영향을 과장합니다. 그렇지 않으면 : 프로젝트가 시간이 중요하고 모든 테스트를 통과하면 코드를 거부하기가 너무 까다로워서 릴리스 후에 눈을 깜박이게 될 수 있습니다.

제대로 작동하게하십시오

따라서 귀하의 리드가 귀하의 커밋을 거부하기로 결정한 경우, 전문가 로서 그가해야 할 일을 알아야합니다.

이제 일부 환경에서는 이것이 표준 일 것임을 알 수 있습니다. 그러나 비판은 똑같이 분배되지 않은 것 같습니다. 이것이 다음 문제로 이어집니다. 이 문제의 대부분의 기초는 내가 다른 사람이 작성하고 최소한의 침입을 시도하는 코드베이스에 있었기 때문입니다. 파일의 다른 곳에서 사용되는 변수 이름을 모방했습니다. 내가 이것을 말했을 때, 나는 다른 사람들을 모방하지 말고 옳은 일을하라.

주니어는 회사 코드베이스를 찾기가 어렵습니다.

최고 : 문서화 된 코딩 표준 이 있으며 표준에 대한 이해를 기대합니다.

보통 :이되어 문서화 코딩 표준 - 당신은을 통해 배울 필요가 재판오류 또는 내가 말을해야 커밋 및 _reject? 이것은 종종 고통 스럽습니다 (귀하의 경우처럼). 이것은 때때로 코드 품질 측면에서 위험 하며 , 화물 컬트 프로그래밍으로 이어질 수 있는데, 여기서 변수 이름 지정을 모방 할 뿐만 아니라 코드 기반의 구조와 패턴을 선의로 복사하여 붙여 넣어야합니다. 그거 하지마! 기존 변수 이름을 모방하지 마십시오.

깨끗한 코드고수하십시오 . 좋은 습관이며 방어하기가 쉽습니다. 읽을 수 있고 테스트 가능하며 유지 관리가 가능한 코드라면 대부분 토론에서 얻은 것입니다.

그리고 이것은 또 다른 (마지막) 조언으로 이어집니다 : 보이 스카우트 규칙을 따르십시오 !

항상 코드베이스를 상태보다 나은 상태로 유지하십시오. 작업중인 주변 코드가 거칠더라도 깨끗하게 정리하십시오. 시간이 있으면 주변 환경을 수정하십시오.


0

동료의 성격의 다양한 뉘앙스를 배우려면 약간의 시간이 걸립니다. 내 경험상 동료 직원의 문제를 해결하는 경우 비이성적이거나 불필요하거나 일관성이 없거나 평범한 가치가없는 비판을 피할 수 있습니다.

예를 들어 일부 동료는 월요일에 숙취가있을 수 있습니다. 특정 코드 분기 또는 커밋을 거부하는 것은 매우 짜증나고 지나치게 열성적 일 수 있습니다. 이와 같은 사람과 협력 해야하는 경우 월요일에 코드를 커밋하지 마십시오.

반면에, hungover 동료는 오류 메시지의 자세한 정보를 신경 쓰지 않을 수 있습니다. 그래서 월요일 아침은 코드를 커밋하는 완벽한 시간이 될 수 있습니다.

사무실이나 직장의 성격 문제는 문자 그대로 끝이 없습니다. 피해야 할 사람과 피해야 할 사람을 배울 수 있기를 바랍니다. 또한 너무 열심히하지 마십시오 :-) 당신은 항상 종료하고 다른 직업을 찾을 수 있습니다!


1
퇴직하기 전에 직장을 찾으십시오. 고용되지 않은 고용 관리자는 면담조차하지 않을 것입니다.
Woot4Moo

-2

특정 규칙을 준수하지 않아 코드가 거부되는 환경에서는 결코 작업하지 않았습니다. 내가 당신의 신발을 신었다면, 올바른 결정을 내릴 수있는 권한이있는 곳과 코드가 아닌 고객이 주요 관심사 인 곳에서 일자리를 구하고 싶은 유혹에 빠질 것입니다.

나는 깨끗한 코드와 표준이 중요하지 않다고 말하지는 않지만 비전문가, 고객 또는 경영진이 보지 못하는 철자 오류로 인해 고객과 제품 타임 라인이 어려움을 겪지 않아야합니다.

그러나 기대치가 명확하지 않거나 어떤 이유로 든 요구 사항을 완전히 이해하지 못하는 환경에서 작업하는 것처럼 들립니다.

상황에 관계없이 통제하고 명확한 질문을하는 것은 귀하의 책임입니다. 아직 그렇지 않은 경우 사전 대처하십시오. 체크인 규칙을 명확하게하기 위해 질문을하면 팀원과 팀장이 더 존경 할 것입니다. 또한 팀원과 팀장이 대신해야 할 일과 방법을 논의하는 "사후 조치 검토"를 요청할 수도 있습니다. 특정 행동을 취해야 할 때와하지 말아야 할 때까지의 차이를 알 수 있습니다.

새로운 경험이 있기 때문에 시간을내어 장애물을 극복하고 경험, 의사 소통 및 표준 학습을 통해 이러한 문제를 해결할 수 있는지 확인하십시오. 그러나 몇 달이 지나도 상황이 변하지 않고 환경이 여전히 모호함으로 인해 어려움을 겪고 있다면 다른 회사에서 일자리를 구해야 할 때입니다.

모든 조직이이 드라코 니아 인 것은 아니며, 성격, 스타일 및 커뮤니케이션 요구 사항에 더 적합한 다른 작업 환경을 찾을 수 있습니다.


2
이것은 "dracoian"처럼 보이지 않습니다. 일관성은 유지 관리의 중요한 구성 요소이고, 유지 관리는 품질의 중요한 구성 요소이며, 품질 소프트웨어는 '타협 코드'보다 적은 비용으로 적시에 배송 할 가능성이 훨씬 높습니다. 소프트웨어 회사의 80 %가 품질을 타협하고 그 결과를 겪고 싶어하는 것이 고무적 일 수 있으므로 "용적이지 않은"고용 기회가 부족하지 않은 것 같습니다. :)
weberc2

1
기본 규칙이 적용 되지 않는 환경에서 일하고 싶지 않습니다 . 만약 프로젝트가 코딩 가이드 라인 방어를 포기한다면, 장기적으로 유지 보수가 불가능해질 것입니다. 특히 변수 이름 지정은 사소한 것이 아닙니다. 기존 매트릭스가 특정 매트릭스라고 불리는 양에 관계없이 일관성을 위해 A다른 매트릭스 B를 호출하는 커밋을 허용하지 않습니다 . 물론 OP가 "다른 곳에서 사용 된 이름 흉내 내기"라는 의미가 무엇인지 정확히 알지 못합니다. 그러나 본 코드의 품질을 고려할 때 이러한 행을 따라갈 수 있습니다.
cmaster
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.