OOP의 과도한 합병증에 대한 용어가 있습니까?

내가 미숙 한 개발자가 코드의 두 개 또는 세 줄의 간단한 콘크리트 로거의 진행을 보여 주었다 OOP (자바), 그리고 이론적 과도한 사고 과정에 대한 훌륭한 기사를 보았다 ~ 2 년 전 기본적으로 말했다 오, 내가해야 우리가 원하는 경우에 이것을 추가하십시오! 기사가 끝날 무렵이 간단한 로거는 원래 개발자가 자신을 거의 이해할 수 없었던 엄청난 쓰레기였습니다.

이러한 유형의 과다 합병증에 대한 일반적인 용어가 있습니까? 이 기사 (다시 찾을 수 있기를 바랍니다)는 격리 된 사례에 대한 개념을 훌륭하게 보여 주지만 개발자가 패턴, 프레임 워크, 라이브러리 및 라이브러리를 과도하게 사용하여 본질적으로 매듭으로 프로그래밍 한 전체 프로젝트를 보았습니다. 다른 문제. 자체적으로, 이것은 우리가 대체를 위해 상속받은 레거시 VB6 스파게티 앱보다 나쁘거나 더 나쁩니다.

내가 정말로 찾고있는 것은 인터뷰 할 때 이것을 제시하는 것입니다. 누군가가 아키텍처 / 사전 계획이 부족하여 (그리고 그들이 올바른 균형을 유지하고 있는지 아닌지에 빠지는) 얼마나 쉬운 지 알고 있고 알고 있는지 알고 싶지만 실제로는 그렇지 않습니다. 많은 정보를 찾을 수 있습니다.

내가 그런 디자인을 묘사한다고 들었던 가장 빈번한 용어는 과도한 엔지니어링 입니다. 그러나이 단어 의 원래 의미 는 소프트웨어 개발과 관련이 없으며 소프트웨어 개발 이외의 용어는 그다지 나쁜 톤이 아닙니다.

보다 일반적인 수준에서 Joel Spolsky는 건축 설계를 지나치게 복잡한 설계자에게 " 건축 우주 비행사 " 라는 이름을 부여했습니다 .

그러나, 특히 인터뷰의 경우, 실제로 필요한 설계에만 적용하고 건강에 해로운 "경우에 따라"접근 방식을 잊어 버리는 것을 반대하는 것이 무엇인지 아는 것이 더 중요하다고 생각합니다.이를 YAGNI 원칙 이라고합니다 .

그렇습니다. 오버 엔지니어링은 이것을 설명하는 가장 간단한 용어입니다. 나는 수년 동안 기억할 수있는 것보다 과도하게 엔지니어링되고 불필요하게 복잡한 디자인을 여러 번 보았습니다. 몇 년 전 강사는 Microsoft GWBasic 과정을 수강 할 때 KISS 방법을 반복적으로 망치고있었습니다 (Keep it Simple Stupid). 이것은 오늘날과 마찬가지로 오늘날에도 마찬가지입니다.

그래서 나는 항상 KISS를 기억하고 항상 SOLID 원칙 을 염두에두고 설계 합니다. 그러나 SOLID 원칙을 완전히 고려하여 설계를 오버 엔지니어링하는 것은 여전히 ​​가능합니다. 순수하고 일반적으로 수용 가능한 OOP 지침을 준수하려는 욕구와 상식, 실용적인 접근 방식의 균형을 유지해야합니다. 충분한 시간이 주어지고 복잡한 솔루션을 만드는 것을 좋아한다면 스케이트 보드 엔진을 설계하는 길을 결국 끝낼 수 있습니다. 다행히도, 저는 수년 동안 이것을하지 않을만큼 훈련을 받았지만 여러 번 보았습니다.

요약하면 코드의 복잡성을 방지하기 위해 :

1) 키스 (간단한 바보 유지)

2) 실용성을 염두에두고 SOLID 원칙을 따릅니다.

3) 모든 상황에 맞게 설계하지 마십시오. 때로는 작고 새는 추상화 가 고립되고, 의도적이며, 그것들을 막기위한 노력이 그것들을 유지하는 효과보다 훨씬 크다면 끔찍한 것이 아닙니다.

4) 솔루션을 디자인하면서 구현하는 것을 고려하십시오. "구체적인 세부 사항입니다"라고 말할 수 없으며 디자인이 실용적이라고 가정하십시오. 나는 이것을 자주하는 건축가와 일 했었고, 아아, 그의 디자인은 결코 작동하지 않았기 때문에 더 이상 거기서 일하지 않습니다.

5) 유지하려는 사람인 것처럼 코딩하십시오.

그래서, 당신은이 인터뷰를 할 것입니다 그리고 당신은 후보자가 소프트웨어 공학에 대해 알고있는 것을 표시하도록 속이려고합니다. 그리고 "아, 당신은 아마 당신의 첫 과제에서 당신이 알고있는 모든 것을 적용하고 싶을 것입니다. , 당신은 금도금 과잉 엔지니어링 비 사업 가치 창출 자입니다!

구체적인 사례를 제시하고 특정 패턴을 적용하는 장단점을 논의하는 것이 더 안전하다고 생각합니다. "의지하고, 빨리하고 싶습니까? 이것이 전부입니까? 문제가 얼마나 복잡합니까? 어떤 패턴이 이미 존재하고 있습니까?"와 같은 응답을 요청하는 것보다 스스로 배울 수 있습니다. 이것은 또한 후보자가 자신의 맥락에 대한 감각을 증명할 수있게 해주지 만 더 열린 질문이 될 것입니다. 특정 답변을 기다렸다가 원하면 가장 큰 관심사를 가진 사람을 얻는 것이 좋습니다. 당신이 당신의 대답을 얻지 못하면 후보는 단지 그것을 생각할 필요가 없다고 생각할 수 있습니다.