직장에서 설정된 규칙을 따르기 위해 나쁜 코딩 스타일을 따라야합니까?


102

나는 약 1 년 동안 직장에서 일했습니다. 나는 주로 C 백엔드의 메소드를 사용하는 GUI 인터페이스에서 작업하지만 일반적으로 반환 값을 제외하고는 처리 할 필요가 없습니다. 우리의 GUI는 우리의 한계를 감안할 때 상당히 합리적으로 구성됩니다.

프로그램의 명령 줄 부분에 기능을 추가하는 작업을했습니다. 이러한 기능의 대부분은 300 줄 길이이며 사용하기가 어렵습니다. 특정 알람 정보를 얻기 위해 그 조각을 모 으려고하는데 체계적으로 유지하는 데 문제가 있습니다. 하나의 긴 기능으로 테스트를 수행하여 테스트를 더 복잡하게 만들고 있음을 알고 있습니다.

기존 기능의 스타일에 따라 모든 것을 거대한 기능으로 유지해야합니까, 아니면 알람을 자체 기능으로 캡슐화해야합니까?

현재 코딩 규칙에 맞지 않는지 또는 총알을 물고 코드를 좀 더 혼란스럽게 만들어야하는지 잘 모르겠습니다.

요약하면, 나는 비교하고있다

showAlarms(){
    // tons of code
}

에 맞서

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

편집 : 모든 사람의 조언에 감사드립니다. 나는 코드를 분해하여 설계하고 원하는 것을 물어보기로 결정했습니다. 그리고 하나를 원한다면 팩터링 된 코드에서 잘라내어 다시 1로 바꿀 수 있습니다. 큰 기능. 이를 통해 하나의 정의로 모든 코드를 원하더라도 작성하고 더 쉽게 테스트 할 수 있습니다.

업데이트 : 그들은 팩토링 된 코드에 만족했으며 둘 이상의 사람 이이 선례를 설정해 주셔서 감사했습니다.


117
당신이 일하는 회사가 "우리가 항상 해왔 던 방식"이기 때문에 여러분의 기능이 300 줄 길이 여야한다는 입장은 의심의 여지가 있습니다. "코딩 스타일 규칙"이 아닙니다. 그냥 나쁜 스타일입니다.
Robert Harvey

64
이것은 다른 팀원들과 논의해야 할 것들이며, 어떤 관행이 모든 사람들이 따라야 할 중요한 관례인지, 누군가가 한 번만 한 일과하지 않은 일이 무엇인지 파악하기 위해 에뮬레이션해야합니다. 의심 할 여지없이 둘 다있을 것입니다.
Servy

17
@beginnerBinx 그것은 당신이 그것을 어떻게 표현하는지에 달려 있습니다. "X는 정말 어리석은 짓을하고 있습니다. 저 바보 같은 짓도해야 해요." "X가이 일을하고 있다는 것을 알아 차리고, 그것이 그렇게하는 특별한 이유가 있습니까? Y를 쓸 때 같은 일을하지 않으면 문제가 될까요?" 그런 다음 이전 코드를 bash로 만들지 또는 왜 그런 식으로해야하는지 설명합니다 (지루하게 또는 열성적으로).
Servy

11
좋은 스타일과 나쁜 스타일은 종종 논쟁을 일으키고 자주 동의하지 않습니다. 대학 교육은 기능이 짧아야하지만 이것이 의미를 모호하게하는 경우에는하지 마십시오. 테스트는 생각없이 규칙을 따르는 것이 아니라 명확해야합니다.
quick_now

9
인터넷상의 임의의 사람들은 팀 동료를 읽을 수 없으므로 여기에 도착하는 모든 답변은 사람들의 개인적인 취향입니다. 당신은 당신의 팀과 이야기해야합니다. 긴 기능이 의도적 인 설계 원칙입니까? 그들은 당신이 긴 기능의 스타일을 계속 유지하길 원합니까, 아니면 당신이 가장 깨끗하다고 ​​생각하는 것을 쓰길 원하십니까?
JacquesB

답변:


102

이것은 실제로 당신과 당신의 팀 동료 사이에 있습니다. 아무도 당신에게 정답을 말할 수 없습니다. 그러나, 줄 사이에 감히 읽을 수 있다면,이 스타일을 "나쁜"이라고 부르는 사실은 정보를 느리게하는 것이 좋습니다. 실제로 "나쁜"코딩 스타일은 거의 없습니다. 내가 사용하지 않는 것이 있지만 나에게는 항상 운율이나 이유가 있습니다. 이것은 지금까지 본 것보다 더 많은 이야기가 있다는 것을 제게 암시합니다. 주변에 묻는 것은 매우 현명한 전화입니다. 누군가 당신이 모르는 것을 알고있을 수도 있습니다.

저는 개인적으로 실시간 미션 크리티컬 코딩을 시작했습니다. 다음과 같은 코드를 보았습니다.

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

밝고 반짝이는 OO C ++ 개발자이기 때문에 RAII를 사용하는 대신 뮤텍스를 수동으로 잠금 및 잠금 해제하여 버그 위험에 대해 즉시 호출했습니다 . 나는 이것이 더 낫다고 주장했다.

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

훨씬 간단하고 안전합니까? 컴파일러가 당신을 위해 할 수있을 때 개발자가 모든 제어 흐름 경로에서 뮤텍스를 잠금 해제해야한다는 것을 기억해야하는 이유!

글쎄, 나중에 알게 된 것은 이것에 대한 절차상의 이유가 있다는 것입니다. 우리는 실제로 소프트웨어가 올바르게 작동하는지, 우리가 사용할 수있는 유한 도구 목록이 있는지 확인해야했습니다. 내 접근 방식은 다른 환경에서 더 좋았지 만, 내가 작업하고있는 환경에서는 RAII의 C ++ 개념을 코드 섹션으로 가져 왔기 때문에 알고리즘을 확인하는 데 관련된 작업량을 쉽게 배가시킬 수 있습니다. 그것은 C 스타일 사고에 더 잘 맞는 표준으로 유지되었습니다.

그래서 나에게 나쁘고, 똑바로 위험한 코딩 스타일처럼 보였던 것은 실제로 잘 생각되었고 내 "좋은"솔루션은 실제로 길 아래로 문제를 일으킬 위험한 솔루션이었습니다.

주위에 물어보십시오. 그들이 왜 이런 식으로하는지 이해하기 위해 당신과 함께 일할 수있는 선임 개발자가 있습니다. 또는이 코드 부분에서 리 팩터의 비용과 이점을 이해하도록 도와 줄 상급 개발자가 있습니다. 어느 쪽이든 물어보세요!


60
아마도 뮤텍스 예제에서 더 위험한 부분은 RAII를 사용할 수없는 이유를 설명하는 코드 주석이 없다는 것입니다. 이 명시 적 잠금 / 잠금 해제가 코드베이스 전체에있는 경우 각 인스턴스에 대한 설명을 추가하기가 까다로울 수 있습니다. 이 경우 새로운 개발자가 익숙해야하는 입문서를 작성해야합니다.
Kelvin

10
물론, 선배와 대화하는 것이 항상 좋으며 리팩토링은주의해서 (그리고 테스트를 통해) 이루어져야합니다. 물론 동시성 / 뮤텍스는 그 자체로 특별한 짐승입니다. 그러나> 300 줄 이상의 함수를 볼 때 이러한 함수가 너무 큰 "숨겨진 기술적 인 이유"를 찾는 데 너무 많은 시간을 투자하지 않을 것입니다. 기능이 너무 길어지는 이유는 항상 동일하며 기술적이지 않습니다.
Doc Brown

8
@DocBrown 기술적이지 않다고해서 그들이 이유가 아니라는 것은 아닙니다. 개발자는 더 큰 머신의 일부라는 것을 기억하는 것이 중요합니다. (나는 그 교훈을 다시 배워야했던 횟수를 셀 수 없습니다)
Cort Ammon

4
@DocBrown 어느 쪽이든, 그것은 이야기해야 할 선임 개발자입니다. 어리석은 코드가 어리석은 이유에 대한 수많은 인수를 쉽게 찾을 수 있기 때문에 내가 한 예제를 선택했습니다. 어리석은 것처럼 보이는 코드가 실제로 어리석지 않은 이유에 대한 인수를 찾는 것이 더 어렵습니다.
Cort Ammon

3
@DocBrown 귀하의 의견과 답변에서, 우리 의견의 차이점은 귀하가 제공 한 증거에 따라 코드가 이미 "나쁜"가정에서 시작한다는 것입니다. 코드가 "나쁜"지 여부를 탐색하는 경로를 사용하십시오.
Cort Ammon

84

솔직히 300 줄로 사용하기 어려운 기능을 갖는 것이 단지 스타일의 문제라고 생각하십니까? 따라서 나쁜 예를 따르면 일관성 때문에 전체 프로그램을 더 나은 상태로 유지할 수 있습니까? 나는 당신이 그렇게 믿지 않는다고 생각합니다. 그렇지 않으면 여기 에서이 질문을하지 않았을 것입니다.

내 사업에는 가독성, 코드 품질, 적절한 이름 지정, 단위 테스트, 리팩토링을 신경 쓰지 않고 기능보다 기능을 쌓는 평범한 프로그래머가 많기 때문에 이러한 기능이 너무 길다고 생각합니다. . 만약 당신이 그 무리를 따르기를 원하거나 더 나은 프로그래머가되고 싶다면 스스로 결정해야합니다.

주석으로 인한 부록 : "300 라인"및 "사용하기 어려움"은 잘못된 코드에 대한 IMHO 강력한 표시입니다. 필자의 경험에 따르면 이러한 코드를 Cort Ammon의 답변 예와 비교하여 더 읽기 쉬운 방식으로 구현할 수없는 "숨겨진 기술적 이유"가 거의 없을 것입니다. 그러나 Cort에 동의합니다. 코드 또는 이러한 "스타일"을 변경할 수없는 모호한 이유를 찾는 것이 아니라 문제를 해결하지 않고 코드를 안전하게 리팩토링하는 방법을 알아 보려면 Cort에 동의해야합니다. .


127
유능한 프로그래머조차도 마감 시한이 지날 때 이러한 범죄를 저지 릅니다.
gardenhead

13
@gardenhead, 시간을 절약하기 위해 300 줄 함수를 리팩토링하지 않는 것을 이해할 수는 있지만 300 줄 함수를 작성하면 시간을 절약 할 수있는 방법은 없습니다.
Dangph

39
@gardenhead : 긴급한 도움이 필요하기 때문에 외과 의사에게 갈 때, 그가 나를 위해 공연을 시작하기 전에 손을 씻는 데 시간이 걸릴 것으로 예상합니다. 이것은 실제 역량 을 달성하기 위해 많은 사람들이 우리 사업에서 배워야 할 것입니다 . 코드는 항상 이전보다 나은 상태로 남겨두고 마감일을 지키는 능력을 향상시킵니다. 300 라인 기능은 일반적으로 매일 신경 쓰지 않는 사람들에 의해 증가하며 항상 "마감"을 변명으로 사용합니다.
Doc Brown

17
@Dangph 함수를 리팩토링하는 대신 5 개의 라인 만 추가하면 시간이 절약됩니다. 그것들은 보통 초기 함수가 길면 (30 줄 이상) 자라며 다음 프로그래머는 "이것은 내 코드가 아니며, 리팩터링하지 말고, 여기 저기 몇 줄만 추가하면된다"고 생각합니다.
Džuris

7
@ Juris, 내가 이해하는 것처럼, 문제는 기존 기능을 리팩토링하지 않고 새로운 기능을 만드는 것입니다. 새로운 기능을 작성하는 경우, 하나의 몬스터 기능으로 만들어 시간을 절약 할 수는 없습니다.
Dangph

42

아니.

Pragmatic Programmer 책 에서 저자는 Broken Window Theory 에 대해 이야기합니다 .

이 이론 상태 :

깨진 창문이 몇 개있는 건물을 생각해보십시오. 창문이 수리되지 않으면 파손자가 창문을 몇 개 더 깨는 경향이 있습니다. 결국, 그들은 심지어 건물에 침입 할 수 있으며, 비어있는 경우 내부에 쪼개는 소리 나 가벼운 화재가 될 수 있습니다.

또는 포장을 고려하십시오. 쓰레기가 쌓입니다. 곧 더 많은 쓰레기가 쌓입니다. 결국 사람들은 테이크 아웃 식당에서 쓰레기 봉지를 남기거나 자동차에 침입하기 시작합니다.

이 책에서 저자는이 이론과 코드 사이의 유사점을 작성합니다. 이와 같은 코드를 찾으면 중지하고 동일한 질문에 대해 스스로에게 질문하십시오.

대답은 : 아니요.

이 깨진 창-우리의 경우 나쁜 코드-를 떠나면 모든 사람이 깨진 창을 남겨 두는 효과를 만듭니다.

그리고 언젠가 코드가 붕괴 될 것입니다.

Clean CodeClean Coder 의 사본 을 모두에게 제공하십시오.

그리고 당신이 주제에있는 동안, TDD 의 사본 도 좋습니다.


6
코드베이스가 깨진 창문 만있는 온실이라면 어떻게 될까요?
Alan Shutko

8
@AlanShutko 그렇다면 이력서가 최신인지 확인하십시오. 지금 다른 고용주를 찾으십시오 .
David Montgomery

12
코드는 거의 "축소"되지 않습니다. 새로운 기능을 추가하기가 점점 더 어려워지고 있으며 점점 더 많은 시간이 걸리며 코드 정리에 대한 추정치가 높아질 것입니다. 즉, 필요한 정리를 위해 시간 예산을 확보하기가 더 어려워집니다.
Doc Brown

8
와우, "깨진 창"이론은 어떤 비유로 보입니다.
Samthere

4
TDD는 그와 아무 관련이 없습니다. 갈지 여부에 관계없이 비즈니스 / 도메인 / 테스트 / Nothingness 드라이버 디자인은 깨끗한 코드의 기본 사항을 따르지 않습니다. 죄송하지만 주제에 포함되지 않은 모든 곳에서 인용 된 'TDD'를 보는 것은 정말 피곤합니다
Walfrat

25

그렇습니다. 구조! = 스타일

스타일이 아니라 구조에 대해 이야기하고 있습니다. 구조는 일반적으로 조직에 적합하지 않고 특정 문제에 적합하도록 선택되기 때문에 스타일 지침은 일반적으로 구조를 규정하지 않습니다.

조심해

자신에게 일어나지 않았을 수도있는 다른 영역에서 부정적인 결과를 초래하지 않는지 확인하십시오. 예를 들어

  • 기존 코드와 유사하지 않기 때문에 diff 또는 코드 병합을 복잡하게하지 마십시오.
  • 예외 흐름이 올바르게 버블 링되고 스택 추적이 읽을 수없는 넌센스 더미로 오염되지 않도록하십시오.
  • 직접 호출 할 경우 문제를 일으킬 수있는 공개 진입 점을 실수로 노출하지 않도록하십시오 (지도에 넣거나 내 보내지 마십시오).
  • 예를 들어 작은 함수에 모두 함수 로컬 범위에서 선언 된 전역 컨텍스트가 필요한 경우 전역 네임 스페이스를 어지럽히 지 마십시오.
  • 로그를 확인하고, 코드에 의해 생성 된 로그가 사용자가 건드리지 않은 코드의 로그와 섞여있을 때 혼동 될 수 있는지 여부를 지원팀에 문의했는지 스스로에게 물어보십시오.
  • 당신이 있는지 확인 그들이 구식 사용하는 경우에도 예를 들어 기존의 스타일을 고수 헝가리어 표기법을 하고 눈, 피가 일반적인 코드베이스와 일치 유지한다. 헝가리어 표기법을 읽는 것보다 더 고통스러운 것은 누가 무엇을 썼는지에 따라 수십 가지의 다른 표기법을 사용하는 코드를 읽는 것입니다.

부드럽게

당신은 팀의 일원이라는 것을 기억하십시오. 좋은 코드는 중요하지만, 팀원이 휴가를 갈 때 쓴 내용을 유지할 수있는 것도 매우 중요합니다. 구식에 익숙한 사람들에게 적합한 흐름을 고수하십시오. 방에서 가장 똑똑한 사람이라고해서 모든 사람의 머리 위에서 이야기해야한다는 의미는 아닙니다!


"구식에 익숙한 사람들에게 의미가있는 흐름을 고수하십시오." -그래서, 무능한 광대가 전에했던 것과 같은 방식으로 프로그램하라는 조언이 있습니까? 300 라인 기능을 추가해도 쉽게 만들 수는 없습니다.
BЈовић

11
나는 비슷한 흐름을 고수한다고 말하지 않았다. 나는 그들이 이해할 흐름을 고수했다.
John Wu

2
좋은 조언. 이 답변 에서 단일 명령 을 5 개의 함수로 리팩토링 할 때 원래 조건부로만 계산 된 논리 식 내부의 값을 사전 계산하여 의미를 미묘하게 변경했습니다. 검토 자들은 그것을 ;-) 잡았습니다. 진지한 조언은 철저히 검토하고 테스트하는 것입니다. 각 변경 사항은 오류를 유발할 수 있으며 이는 아무도 작성하지 않은 주요 이유 일 수 있습니다.
피터 A. 슈나이더

6

이것을 코드 규칙으로 보지 않습니다. 이해하기 쉬운 유지 관리 가능한 코드를 작성하는 방법을 이해하지 못하는 사람이라고 생각합니다. 300 줄 함수가 허용되는 이유를 이해 하면서이 작업의 이점에 대해 팀에 제안하고 교육 할 때 코드를 다른 함수로 나눕니다. 그들의 추론을 듣고 싶습니다.


1
" 이유는 없습니다. 정책

5

답은 코드 검토에 있습니다.

진짜 질문은 당신이 잘 팩토링 된 코드를 돌리면 그것으로 작업 할 수있는 유일한 사람이 될 것인가입니다.

나는 여기 대부분의 사람들처럼 300 개의 라인 함수가 혐오 스럽다고 믿는다. 그러나 Windex를 매립지로 가져가는 것은 그리 좋은 일이 아닙니다. 문제는 코드가 아니라 코더입니다.

옳은 것만으로는 충분하지 않습니다. 이 스타일로 사람들을 판매해야합니다. 적어도 읽었을 때. 당신 이이 가난한 사람처럼 끝나지 않으면 : 당신의 기술이 동료보다 너무 멀리 있기 때문에 해고

작게 시작하십시오. 다른 사람이 더 작은 기능을 선호하는지 물어보고 알아보십시오. 코드 기반을 더 잘 스누핑하고 가장 작은 코드를 작성하는 사람을 알아낼 수 있는지 확인하십시오. 그들에 대해 이것에 대해 이야기하고 당신이 동맹국인지 확인하십시오. 같은 생각을 가진 다른 사람을 알고 있는지 물어보십시오. 작은 기능을 싫어하는 사람이 있는지 물어보십시오.

이 작은 그룹을 모아서 변화에 대해 이야기하십시오. 그들에게 당신이 쓰고 싶은 코드를 보여주십시오. 그들이 읽을 수 있는지 확인하십시오. 이의를 진지하게 받아들이십시오. 변경하십시오. 코드 승인을 받으십시오. 이제 당신은 회의의 힘을 가졌습니다. 이 중 몇 가지를 추가하면 소개 한 새로운 스타일을 명시 적으로 수용하는 한 페이지의 문서를 만들 수 있습니다.

회의는 놀라 울 정도로 강력합니다. 그들은 영향력을 발휘할 수 있습니다. Clout은이 운동에 반대하는 사람들과 싸우기 위해 사용할 것입니다. 이것이 바로이 시점입니다. 운동. 현 상태를 개선 할 수있는 권리를 위해 싸우고 있습니다. 사람들은 변화를 두려워합니다. 당신은 달콤한 대화, cajole 및 자극해야합니다. 그러나 약간의 행운으로 당신은 바로 받아 들여질 것입니다.


5
300 라인 방식이 너무 길다는 것을 개발자에게 확신시키기 위해 많은 사교 모임과 여러 회의가 필요하다면 대화가 도움이 될 것이라고 생각하지 않습니다. 위의 접근 방식의 문제점은 좋은 코드를 작성하기 위해 권한을 요청하면 방어 적이라는 것입니다. 그러나 좋은 코드를 작성하고 기존 코드를 리팩토링하는 데 시간이 걸리는 경우 300 라인 방식이 좋은 이유를 설명하고 코드를 다시 넣는 시간을 정당화하기 위해 이의를 제기하는 사람이 있습니다.
Brandon

3
함수 제한 당 코드 라인을 논의하기 위해 일련의 회의에 초대 된 경우 그러한 회의를 피할 수있는 방법을 찾게 될 것입니다. 정확한 번호는 없으며 사람들이 동의하지 않을 것입니다. 때때로, 사람들은 할 필요가 보여 더 나은 방법을.
Brandon

때때로, 큰 기능을 나누는 것 (그리고 더 나은 이름을 짓고 주석과 문서 추가 하는 것이 변경을 mqking하기 전에 필요한 첫 단계 임)
JDługosz

@Brandon 당신은 아마 이런 식으로 들리는 것을 의미하지는 않지만 내가 듣는 것은 당신이 옳고 다른 사람들이 그것을 다룰 수 있다는 것입니다. 코드가 작동하는 한 팀의 나머지 부분이 이해하지 못하는 것은 중요하지 않습니다. 그들에게 아무것도 가르치지 않아도 귀찮은 시간은 아닙니다. 자신 만의 방식으로 코드를 작성하는 동안 계속 300 개의 라인 함수를 작성하는 것을 보게되어 기쁩니다.
candied_orange

1
@CandiedOrange 나는 확실히 팀을 상대하는 것을 의미하지 않았다. 내가 의미하는 바는 어떤 주제가 실제로 행동하는 것을 보면서 가장 잘 배운다는 것이었지만, 팀이 스타일에 대한 민주적 인 결정을 내 리도록 노력하는 것은 생산적이지 않을 것입니다. 읽을 수없는 코드를 작성하는 데 변명으로 사용되는 일관성을 보았습니다. 결과? 더 읽을 수없는 코드. 그것에 대해 이야기하기 위해 일련의 회의를 설정하거나 문제를 해결 한 다음 사람들에게 결과 를 보여줄 수 있습니다.
Brandon

3

때로는 흐름과 함께 가야합니다.

당신이 말했듯이 기존 작업 코드베이스에서 함수를 구현해야합니다.

혼란에 관계없이 나는 그것을 청소하고 싶은 유혹을 느낍니다. 그러나 비즈니스 세계에서는 항상 코드를 리팩터링 할 기회가 없습니다.

나는 당신이 요청받은 것을하고 계속 나아가라고 말하고 싶습니다.

리팩토링 또는 재 작성 가치가 있다고 생각되면 팀과 논의하기 위해 가져와야합니다.


2
모든 작은 리팩토링에 대한 권한을 요청하면 유지 관리 할 수없는 코드가 영원히 유지되므로 비즈니스에 위험합니다. 관리자는 변경 비용 만 보지만 변경 되지 않는 비용은 거의 보지 않습니다 .
Brandon

5
OP는 수백 줄의 코드를 수정하지 않는 함수를 작성하도록 요청 받았다
meda

2
@ 메다 정확히! 나는 거의 같은 상황에 처해 있습니다. 회사 인트라넷을위한 새 모듈을 개발 중이며 2006 년 이후로 서버 소프트웨어 및 라이브러리가 전혀 업데이트되지 않은 상태에서 "수리 할 수없는 방치 기간"으로 설명되는 항목을 찾고 있습니다. 하지만 제한 사항으로 인해 코딩하는 데 시간이 더 걸립니다. (MySQl 5.2, MySQL 5.0을 상상해보십시오). 더 이상 사용되지 않는 코드로 인해 기존 코드가 최신 버전에서 실행되지 않기 때문에 아무것도 업데이트 할 수 없습니다.
roetnig

3
"파손되지 않았다면 고치지 마십시오." 약간의 기름이 새는 20 살짜리 차가 있습니다. 돈을 쓸 가치가 있습니까? 아니요. 신뢰할 수 있습니까? 예.

3

관행이 나쁘다는 진술을하기 전에 먼저 큰 방법과 다른 관행에 대한 이유를 이해하는 방향으로 나아가 야합니다.

그런 다음 테스트 범위가 상당히 높거나 높아야합니다 (주요 리팩토링없이 수행 할 수있는 한). 그렇지 않은 경우 코드를 작성하지 않았더라도 적용 범위를 실제로 높이는 데 노력할 것입니다. 이것은 관계를 구축하는 데 도움이되며 새로운 팀이 더 진지하게 데려다 줄 것입니다.

일단이 기지를 다룬 후에는 올바른 마음을 가진 사람이 당신에게 도전하지 않을 것입니다. 보너스 아이템으로 마이크로 벤치마킹을하면 실제로 귀하의 케이스에 추가됩니다.

종종, 당신이 말한 방식은 코드 문화를 바꾸기 위해 먼 길을갑니다. 예를 들면. 또는 더 나은 방법으로, 리팩토링하고 지옥과 비올라에서 단위 테스트를 수행 할 수있는 코드 조각이 나올 때까지 기다리십시오.


현재 코드를 리팩토링하지 않고 새로운 기능을 작성하고 있습니다. '컨벤션'을 따라 300 + 라인 괴물로 코딩 해야하는지 또는 평상시와 같이 논리 덩어리로 나눌 것인지 확실하지 않습니다. 코드베이스의이 부분에서는 수행되지 않았습니다.
Justin

1
300 + 라인으로 새로운 메소드를 작성하도록 규칙이 있습니까? 그렇지 않다면, 나는 그것을 올바른 방법으로 쓸 것입니다. 그러나 나는 가지를 포함하여 테스트 할 수 있도록 절대적으로 나아갈 것입니다. 나는 비슷한 경험을 겪었고 보통 당신은 그들을 이깁니다. 트릭은 시간이 지남에 따라 그것을하고 관계를 구축하는 것입니다.
skipy dec

3

이러한 유형의 질문은 기본적으로 " 제 팀 동료들을 염두에 두십시오 "입니다. 인터넷상의 임의의 사람들은 그렇게 할 수 없으므로 코딩 스타일에 대한 사람들의 개인적인 의견입니다. 합의는 더 짧은 방법이 바람직하지만, 당신은 이미 그렇게 생각하는 것 같아서 다시 언급 할 필요는 없습니다.

따라서 현재 코드베이스는 선호하는 것과 다른 코딩 스타일을 사용하는 것 같습니다. 어떻게해야합니까? 먼저 알아 내야합니다.

  1. 현재 팀에서 지원하는 의도적 인 디자인 결정입니까?
  2. 그들은 당신이이 스타일을 따르기를 원합니까?

알아낼 방법은 하나뿐입니다. 물어보세요 .

긴 기능을 갖는 데는 여러 가지 이유가있을 수 있습니다. 팀은 긴 기능이 여러 개의 짧은 기능보다 낫다고 생각하기 때문일 수 있습니다. 레거시 코드이기 때문에 새로운 코드가 더 깔끔한 디자인을 따르는 것을 선호합니다. 따라서 팀과 이야기하지 않고 그들의 추론을 이해하지 못하면 어느 쪽을 선택해도 개발자로서 어려움에 처할 수 있습니다.


1
나는 "다른 사람들이 한 일을 따르지 않아 해고 당하거나 다른 문제를 겪을 수 있습니까?"라고 철저히 동의하고 덧붙입니다. 그렇다면 대답은 그렇습니다! 회사는 모든 나쁜 일을 겪으면서 처리해야합니다.
Rob

1

"스타일"에는 다른 수준이 있습니다.

일반적으로 코딩 규칙의 일부인 한 수준에서 공백, 빈 줄, 대괄호를 넣을 위치와 이름을 지정하는 방법 (대소 문자, 밑줄 등)을 의미합니다.

또 다른 수준에는 프로그래밍 모델이 있는데, 때로는 정적을 피하거나 추상 클래스를 통한 인터페이스 사용, 종속성 노출 방법, 일부 난해한 언어 기능을 피하는 방법이 있습니다.

그런 다음 프로젝트에서 사용중인 라이브러리와 프레임 워크가 있습니다.

때로는 기능 크기에 최대 제한이 있습니다. 그러나 최소 한계가 거의 없습니다! 그러므로, 당신은이 중 어떤 것이 중요하다고 생각되는 힘을 발견하고 그것을 존중하려고 노력해야합니다.

팀이 기존 코드를 리팩토링하는 데 불리한 지 확인해야합니다. 가능한 경우 새 코드를 추가하는 것과 독립적으로 수행해야합니다.

그러나 기존 코드를 리팩터링하지 않으려는 경우 추가 한 새 코드에 대해 추상화로 일부 레이어를 도입 할 수 있습니다. 이는 시간이 지남에 따라 더 나은 코드 기반을 개발하고 이전 코드를 다음과 같이 마이그레이션 할 수 있음을 의미합니다. 유지 보수가 필요합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.