그러한 접근 방식으로 더 분명하거나 나쁜 것이 있습니까?

물론입니다. 불필요하고, 예상치 못한, 쓸모없고, 우아하지 않습니다. 그것은 클래스 디자인 (응집력, 결합)의 현대 개념을 위반합니다. 메소드 계약을 위반합니다 (생성자가 정의 된 작업을 가지고 있으며 임의의 메소드가 아닙니다). 확실히 유지 보수가 쉽지는 않지만 미래의 프로그래머는 무슨 일이 일어나고 있는지 이해하고 그 이유를 추측하려고 많은 시간을 할애합니다.

코드가 작동하지 않는다는 점에서 이것은 “버그”가 아닙니다. 그러나 코드를 유지하기 어렵게 (즉, 테스트를 추가하기 어렵고, 재사용하기 어렵고, 디버깅하기 어렵고, 확장하기 어렵게하여) 장기적으로 막대한 2 차 비용 (코드를 처음 작성하는 비용과 관련하여)이 발생할 수 있습니다. ).

소프트웨어 개발 방법의 많은 / 가장 현대적인 개선은 소프트웨어의 실제 작성 / 테스트 / 디버깅 / 유지 보수 프로세스를보다 쉽게하기 위해 수행됩니다. 이 모든 것은 “작동”하기 때문에 코드가 무작위로 배치되는 다음과 같은 것들로 우회됩니다.

불행히도, 당신은 정기적 으로이 모든 것을 완전히 모르는 프로그래머를 만날 것입니다. 작동합니다.

유추로 마무리하려면 (다른 프로그래밍 언어, 여기서 당면한 문제는 계산하는 것입니다 2+2) :

$sum_a = `bash -c "echo $((2+2)) 2>/dev/null"`;   # calculate
chomp $sum_a;                         # remove trailing \n
$sum_a = $sum_a + 0;                  # force it to be a number in case some non-digit characters managed to sneak in

$sum_b = 2+2;

첫 번째 접근 방식에 어떤 문제가 있습니까? 상당히 짧은 시간이 지나면 4를 반환합니다. 맞습니다. 반대 의견 (개발자가 반박 할 수있는 모든 일반적인 이유와 함께)은 다음과 같습니다.

• 읽기가 어렵습니다 (그러나 좋은 프로그래머는 쉽게 읽을 수 있으며, 항상 이렇게 읽었습니다. 원한다면 메소드로 리팩터링 할 수 있습니다!)
• 느리게 (그러나 이것은 중요한 시점에 있지 않으므로 무시할 수 있으며, 필요할 때만 최적화하는 것이 가장 좋습니다!)
• 훨씬 더 많은 리소스를 사용합니다 (새로운 프로세스, 더 많은 RAM 등-그러나 서버는 충분히 빠릅니다)
• 에 의존성을 소개합니다 bash(그러나 어쨌든 Windows, Mac 또는 Android에서는 실행되지 않습니다)
• 그리고 위에서 언급 한 다른 모든 이유들.

답변