프로그래머가 때때로 의도적으로 복잡한 코드를 과도하게 사용합니까? [닫은]


26

사람들 (특히 프로그래머)이 원래 문제보다 솔루션이 훨씬 더 복잡한 문제에 대한 솔루션을 지나치게 복잡하게 만드는 경향이 스택 오버플로에서 많은 것처럼 보입니다. 어쨌든 전문가는 아니지만 많은 시간 동안 작동하는 가장 간단한 솔루션을 사용하려고 시도하지만 분명히 모든 곳에서 작동하지는 않지만 사람들이 생각하는 작업에 대한 간단한 솔루션을 제안하는 데 꽤 성공했습니다. 더 복잡한 솔루션을 간과하기 위해?

이것이 프로그래머에게는 정상적인 것입니까? ... 또는 올바른 생각으로 생각하지 않습니까?


5
1. 예, 가끔 생각합니다. 2. 그렇습니다. 적어도 일부 프로그래머는 적어도 일부는 코드를 지나치게 복잡하게 만들고, 적어도 일부는 의도적으로 복잡합니다. 3. 사건 종결.
Job

3
"당신은 그 생각을 했어야 했어!" 초기 요구 사항 수집에 명시되지 않은 요구 사항을 놓친 경우 그것이 어떤 것들을 필요 이상으로 복잡하게 만드는 원인이됩니다.
JB King

답변:


18

분명히 어떤 프로그래머들은 아무도 이해할 수없는 엄청나게 복잡한 코드를 만들어서 얼마나 똑똑한 지 보여주고 싶어합니다. 다른 프로그래머들은 이러한 높은 수준에서 해고하고 있으며, 솔루션의 합병증은 자연스러운 진화입니다.

내가 본 최악의 코드 중 일부는 2000 줄 이상의 코드가있는 방법이었습니다. 의심 할 여지없이이 코드는 복잡했지만 매우 열악했습니다.

좋은 프로그래머는 지나치게 복잡한 코드를 피한다고 생각합니다. 여기에는 디자인 패턴이 실제로 필요하지 않은 솔루션에 적합하도록 유혹을 피하는 것이 포함됩니다. 또한 신 물체, 마술 단추, 조기 최적화, 조기 일반화 및 기타 반 패턴 방지를 포함합니다.

복잡성 증가는 유기적 인 것이기 때문에 끊임없이 리팩토링하고 솔루션을 단순화 할 수있는 기회를 찾고 있습니다. 다른 많은 유기물과 마찬가지로 계속 사용할 수 있으려면 손질하고 잘라 내야합니다. 복잡성이 증가함에 따라 코드가 깨질 가능성이 높아지기 때문에 지나치게 복잡한 솔루션과 상호 작용하는 것을 싫어합니다.

가독성은 코드 유지 관리의 가장 중요한 요소이며 지나치게 복잡한 솔루션은 거의 항상 가독성을 줄이고 유지 관리 비용을 증가시킵니다.


32

필자는이 세 가지 이유로 필요한 것보다 훨씬 복잡한 많은 코드를 보았습니다.

1) 조기 일반화 또는 결코 발생하지 않는 미래의 요구를 예상하여 과도하게 설계

2) 개발자는 이전에 사용하지 않았던 새로운 디자인 패턴이나 기술로 배우거나 실험하기를 원했고, 과잉 상태 일 때조차도 그 문제를 해결했습니다. 그들은 일을 더 흥미롭게 만들고 새로운 것을 배우기 때문에 그렇게합니다.

3) 기능 및 버그 수정이 추가되었지만 기존 코드가 당시에 올바르게 리팩터링되지 않았습니다. 그것은 단지 작은 조각의 복제이거나 메소드에 다른 플래그 인수를 촉발 할 수 있지만 모두 합쳐집니다. 효과적으로 해킹이 추가되고 모든 코드 냄새로 인해 모든 것이 너무 복잡해지기까지 오래 걸리지 않습니다. 이것은 가장 일반적이며 일반적으로 더 나은 시간 압력을 알지 못하기 때문에 발생합니다.


나는 2 번 유죄입니다. 경험 (및 성숙?)으로 나는 지금 자신을 자제하는 경향이 있지만 대신 집에서 실험 :)
Matthieu M.

나는 사람들이 항상 1을하는 것을 본다. 결국 그들은 5 배나 많은 일을하게된다
Ally

11

절대적으로 흔한 일입니다. 대부분의 책에서 알 수 있듯이 훌륭한 개발자는 간단하게 유지하는 방법을 알고 있습니다. 방금 찾은 새로운 기술이나 "차가운"프레임 워크로 무언가를 복잡하게 만드는 것은 너무 쉽습니다. 따라서 문제의 관점에서 생각하는 대신이를 사용하는 방법을 찾기 시작합니다.

Martin Fowler가 말했듯이, 새로운 기술을 배우는 사람들은 "기술"이 솔루션을 주도하는 단기 문제가 있습니다.


4
-1 : 대부분의 책에서 알 수 있듯이 훌륭한 개발자는 간단하게 유지하는 방법을 알고 있습니다. -당신은 이것에 대해 절대적으로 옳습니다. 그러나 신기술의 남용이 코드를 지나치게 복잡하게 만드는 가장 큰 원인이라는 것을 암시했습니다. 당신은 그것에 대해 잘못입니다. 나를 믿으십시오 . 새로운 기술의 남용과 관련이없는 지나치게 복잡한 코드 가 많이 있습니다.
Jim G.

나는 그것이 "코드를 지나치게 복잡하게 만드는 가장 큰 원인"을 어디에서 암시 했는가? 확실히 문제입니다. "저는 패턴 X를 배웠습니다. 적용 할 수있는 패턴 X를 배웠습니다."-Patternitus. 넌 정말 내 입에 단어를 넣었 어 짐.
Martin Blore

4
"저는이 편지를 더 짧게 만들 시간이 없었기 때문에 평소보다 더 길게 만들었습니다." -Blaise Pascal 여기에서도 매우 적용 가능합니다. "복잡한"은 종종 서두르거나, 게 으르거나, 무능한 코딩의 표시입니다.
Bill

@Bill 그것에 대한 흥미로운 점은 비즈니스 관점에서보다 복잡한 코드에 대한 좋은 논거입니다-무언가를 구현하기 위해 고정 된 금액을 지불하고 그것을 할 수 없다면 그것을 리팩토링하거나 더 짧게 만드는 데 시간이 더 걸립니다 처음에는 (누가 할 수 있습니까?) 이미 작동중인 코드를 덜 복잡하게 만드는 데 본질적으로 페널티가 있습니다.
Michael

10

모든 프로그래머에게 이것이 정상이라고 생각하지는 않지만 많은 프로그래머가 이것을하는 것을 분명히 보았습니다.

나는 어떤 사람들은 무언가를 '단순히 너무 쉽게'만드는 것을보고 자신의 기술을 잘 보여주지 못한다고 생각합니다. 따라서 그들은 현재의 문제에 대한 최선의 해결책이 아닐지라도 '내가 할 수있는 일을 보라!'라고 말하는 크고 복잡한 해결책을 만들어야합니다.


1
그것이 내가 보는 방법입니다. IE가 너무 쉬운 경우 사용할 가치가 없습니까?

@Mercfh 나는 그 견해를 이해하지 못한다. 솔루션의 용이성은 효율성과 어떤 관련이 있습니까?
GSto

나는 종종 프로그래머들이 "아주 너무 단순하면 좋지 않다"고 생각하는 "그렇다"라고 말하는 그의 의견에 대해 언급하고있었습니다.

7

나는 프로그래머가 종종 언어에 내장 된 것을 모르는 작업을 수행하기 위해 여러 줄의 코드를 작성하는 것을 보았습니다. 이것은 의도적 인 것은 아니지만 확실히 방지 할 수 있습니다.


모든 문자열 복사본에 대해 루프를 작성한 프로그래머를 보았습니다. 표준 라이브러리 함수에 대한 호출을 사용하지 마십시오. (더 나쁜 것은 플랫폼 사본이 한 번에 한 단어 씩 읽도록 최적화되어 있다는 것입니다.)
BillThor

7

"간단한"이라고 부르는 것에 따라 다릅니다. 코드가 많고 여러 개의 호출 그래프가 있기 때문에 리팩토링 된 코드를 더 "복잡한"것으로 보는 사람들이 있습니다. 그러나이 코드는 변경하기가 훨씬 쉽다는 점에서 "단순"합니다.

큰 함수는 변경해야 할 때까지 "간단한"것처럼 보이는 경우가 많습니다.

다시 말해서, 많은 경우에 단순한 것은 보는 사람의 눈에있다.


2
+1 : 너무 많은 프로그래머가 그것에 대해 생각하지 않습니다
Luca

5

문제는 간단한 해결책을 명확하게 볼 수 없거나 (이것은 동료와의 토론이 진행되는 곳) 또는 너무 일찍 일반화하는 경우입니다.

다시 말해, 당신은 어쨌든 다음 프로젝트에 필요할 것이라고 생각 하기 때문에 고급 라이브러리 함수에 간단한 루프를 만듭니다 (이 정확한 형태가 아닌 것을 제외하고). 이 작업을 너무 오래 수행하면 매우 간단한 코어로 매우 복잡한 응용 프로그램이 있습니다.

또한 매우 강력한 코드가 필요할 수 있으며 모든 강력 함으로 인해 기본적으로 복잡해집니다. 그래도 이것이 당신의 문제라고 생각하지 않습니다.


4

어떤 경우에는 깨끗하고 간단한 솔루션을 만드는 것이 복잡 할 수 있습니다.

기억할 수 없거나 인용 할 수없는 인용문이 있습니다. "만약 당신이 작성해야 할 모든 것을 작성한 후에는 코드가 완성되지 않았지만 제거 할 남은 것이 없으면 완성되어야합니다"

선명도가 부족하면 사람들이 초과분을 모두 제거 할 수 없게됩니다.


4
또 다른 관련 인용문은 "짧은 편지를 썼지 만 시간이 없었습니다."입니다.
user16764

3
"김정일 semble 케 라 완벽 soit atteinte 비 quand 위원장 n'Y의 플러스 리엔 à ajouter, 더보기 quand 위원장 n'Y의 플러스 retrancher à 리엔." ( "보인다, 완벽 달성되어 있지 추가 할 더 아무것도 그러나 때 더 이상 제거 할 것이 없습니다.”) – 프랑스 조종사, 시인, 엔지니어 인 앙투안 마리 로저 비코 드 생 텍쥐페리 (1939) ( Tere des Hommes ( 바람, 모래, 별 ))
Jörg W Mittag

고마워, 나는 진짜 기원을 알지 못하는 것 같다 :-) Nice.
Stephen Bailey

3

최고의 엔지니어는 정말 복잡한 문제를 해결하고 구현 및 이해하기 쉬운 솔루션으로 전환 할 수있는 엔지니어입니다. 간단하게 들리지만 존재하는 엔지니어 나 개발자는 많지 않습니다. 사실 그런 사람들은 많지 않습니다. 실제로 대부분의 사람들은 정반대입니다. 그들은 단순한 문제를 가지고 인식을 넘어서 복잡하게 만듭니다. 간단한 문제를 겪고이를 완전히 혼란에 빠뜨리는 사람들의 예를 보려면 정치인을 살펴보십시오. 프로그래머는 이와 관련하여 다르지 않습니다.


3
아야! 나는 단지 당신에게 +1을 주려고했지만 정치에 대한 당신의 비유를 보았습니다. // 사실입니다-많은 난독 화, 낭비 된 움직임, 손 흔드는 법, 정치에 특별한 관심사가있어 법안이 지나치게 복잡해질 수 있습니다. 그러나 과도한 합병증은 난독 화, 낭비 된 운동, 손을 흔들며, 특별한 관심사의 부산물입니다. 근본 원인이 아닙니다.
Jim G.

이유가 무엇이든, 많은 국가의 문제에 대한 매우 간단한 해결책이 있지만 정치인은 필요 이상으로 어려움을 겪습니다. 우리는 이것이 돈, 권력 또는 투표 때문이라고 생각하지만 나는 그것이 능력에 관한 것이라고 생각합니다. 이 경우 나의 비유는 확고한 기반에있다.
덩크

1
@JimG. 그래, 나는 너에게 동의한다 ... 정치적 해결책에 관한 많은 문제는 정말로 쉬운 해결책이없는 복잡한 문제에 대한 쉬운 해결책이 있다고 주장하는 정치인이다.
Michael

2

개인적으로 저는 의도적으로 소프트웨어를 더 복잡하게 만들려고 시도한 적이 없습니다. 그러나 나는 무언가를 끝내고 "와우, 너무 복잡하다"고 생각하고 다시 돌아가서 리팩토링했습니다. 어떤 사람들은 이것을보고 그것이 효과가 있다고 생각할 수 있으며 그것이 충분하고 리팩토링하지 않습니다.


1

현명한 사람은 가능한 한 간단하지만 간단 같은 일을 계속해야한다고 말했다 것으로 추정된다. 코드에도 동일하게 적용될 수 있습니다. 때로는 복잡한 것으로 간주되는 기술을 사용해야 할 수도 있습니다 (재귀는 좋은 예일 수 있으며 종종 주니어 프로그래머에게 무섭습니다).

그러나 일반적으로 복잡한 코드는 종종 유기적으로 발생한다고 생각합니다. 간단한 문제는 간단한 코드로 해결 된 다음 범위가 확장되고 코드가 너무 많이 생각되지 않고 수정되며 시간이 지남에 따라 새로운 문제를 다루려고하지만 실제로 다른 문제를 해결하도록 설계된 코드를 얻게됩니다. 다른 논리의 패치 워크 퀼트가됩니다. 그런 코드는 종종 문제가 요구하는 것보다 훨씬 복잡한 것처럼 보일 수 있지만, 당시에는 작은 변화가 코드를 작동시키는 가장 쉬운 방법 인 것처럼 보였기 때문에 그렇게되었습니다.

나는 대부분의 개발자가 의도적으로 코드를 복잡하게 만들기로 생각하지 않는다고 생각하지만 (어떤 기술을 사용하여 자신의 기술을 증명할 수있는 이상한 쇼를 얻었더라도) 코드는 공격적으로 유지 관리되고 리팩토링되지 않으면 코드가 그런 식으로 작동한다고 생각합니다 .


요구 사항에 거의 부합하지만 별개의 방식으로 부족한 정말 간단한 코어로 시작하는 시스템 수는 놀랍습니다. 그런 다음 약간 더 복잡한 설계로 피할 수 있었던 많은 공백을 처리하기 위해 많은 복잡성을 추가합니다. C의 정수 유형의 단순한 설계와 함께 사용되는 기괴한 복잡한 규칙을 고려하십시오. 각 유형에 대해 "이것은 승격 가능해야한다"옵션이 있었다면, 명목상 유형의 수를 두 배로 늘 volatile
렸을 것입니다 (실제로

... 프로모션 / 밸런싱 규칙을 크게 완화했을 것입니다. 승격 가능 int에 추가로 승격 할 수없는 서명되지 않은 숏을 추가하면 큼직한 지 여부에 관계없이 승격 할 수없는 서명되지 않은 숏이 생성 short됩니다 int. 프로모션 테이블에 프로모션 테이블을 unsigned short추가 int하면 int. 같은 크기의 서명 및 서명되지 않은 것을 추가하거나 크기가 다른 프로모션 불가능한 것을 추가하면 오류가 발생합니다. 약간의 복잡성을 미리 추가하면 이상한 다운 스트림 다운 스트림이 사라집니다.
supercat

1

아직 제기되지 않은 또 다른 이유는 사람들이 제공된 솔루션을 지나치게 복잡하게하여 나중에 해당 솔루션을 지원하기 위해 서비스가 필요할 수 있기 때문입니다. 다시 말해, 직업 안전을위한 것입니다.


이것이 왜 다운 보트인지 잘 모르겠지만, 한 사람이 코딩 한 매우 큰 프로젝트를 보았습니다. 고용주가 그를 화 내면 전체 제품 라인이 망가졌습니다. 다른 개발자가 코드를 완전히 이해하는 데 몇 개월이 걸렸지 만 "모두 알고있는"코더가 스파게티를 엉망으로 만드는 데 몇 분이 걸렸습니다.
SSH 이번

0

아마도 고전적인 실수의 문제일까요?

30. 개발자 금도금.

개발자는 새로운 기술에 매료되어 언어 나 환경의 새로운 기능을 시험해 보거나 다른 제품에서 보았던 매끄러운 기능을 제품에서 필요로하든 그렇지 않든 구현하기를 간절히 원합니다. 필요하지 않은 기능을 설계, 구현, 테스트, 문서화 및 지원하는 데 필요한 노력으로 일정이 길어집니다.

  • Steve McConnell, 신속한 개발.

0

그렇습니다. 때때로 우리는 자신을 즐겁게하기 위해 코드를 지나치게 복잡하게 만듭니다. 코드가 지나치게 복잡하다는 인식은 대부분 프로젝트의 무식한 또는 주니어 참가자에서 비롯됩니다.


1
-1 주니어 개발자들에게 문제를 비난하는 선임 개발자들은 아마도 자신의 일이나 다른 사람들의 일에 대한 동기를 이해하지 못할 것입니다. 주니어 개발자가 코드를 따르는 데 어려움이 있다면 IT가 너무 복잡합니다.
Brandon

Jr 개발자가 이해할 수없는 코드를 발견하면 코드 냄새가 나고 실제로 코드가 너무 복잡 할 수 있지만 브러시를 광범위하게 사용하고 있습니다. Jr 개발자가 기술 자체를 비난하는 것이 아니라 고급 기술을 이해하는 데 도움이 필요하기 때문에이 코드 냄새가 실제로 존재할 수 있습니다.
P. Roe

-1

예 ... 그리고 나는 가격을 너무 많이 지불했습니다.

내 화이트 보드는 이제 맨 위에 별표로 표시됩니다.

"간단하지 않으면 옳지 않다"

... 매번 화이트 보드에 무언가를 프로토 타이핑 할 때마다 항상 관심을 끌게됩니다.

복잡한 디자인이 훨씬 간단 해져 코드가 깨끗해지기 때문에 실제로 효과가 있습니다.

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