Overengineering

The dictionary just defines it as a combination of “over” (meaning “too much”) and “engineer” (meaning “design and build”). So per the dictionary, it would mean that you designed or built too much.

Over-engineered code affects productivity because when someone inherits an over-engineered design, they must spend time learning the nuances of that design before they can comfortably extend or maintain it.

With overengineering, the big problem is that it makes it difficult for people to understand your code.

There’s some piece built into the system that doesn’t really need to be there, and the person reading the code can’t figure out why it’s there, or even how the whole system works (since it’s now so complicated).

As a consequence, the model encourages early overdesign as the programmer tries to predict every possible use the software might require, adding layers of type and abstraction just in case.

클래스 설계만 하더라도, 조기에 모든 가능한 사용을 예측해서 추상화 Level 을 높이게 되는 경우가 있다.

Ways overengineering

오버엔지니어링이 되는 방법은 많다. 그 중 두가지는 다음과 같다.

  1. 확장할 필요가 없는데 너무 확장하는 것
  2. 너무 일반적으로 만들어버리는 것

1번의 경우에는 추상화 비용 과도 연결 지을 수 있다. 확장성을 고려하다보면 추상화 레벨이 깊어지는 경우가 대다수인데, 다른 사람이 코드를 이해하는데 많은 노력이 필요할 수 있다. 참고로, 코드는 작성하는 비용보다 읽는데 드는 비용이 더 많이든다.

2번의 경우에는 "버그 추적기" 같은 특정 기능에 초점을 맞춘 시스템을 만들려고 시작을 했으나, "데이터를 관리하기 위한 일반 시스템" 을 만들기로 결정한 경우이다. 즉, 특정 기능 에 초점을 맞추는 대신 모든 사람에게 모든 것을 제공하려는 것에 초점을 맞추게 되면서 발생한다.

Away from overengineering

오버엔지니어링을 피하는 방법은 아래와 같다.

  • 너무 먼 미래를 설계하지 않는 것: Designing too far into the future
    • 프로그래밍에서 알 수 없는 가장 큰 것은 프로그램이 미래에 어떻게 변할 것 인지이다.
    • 1주, 1달의 단기간의 미래는 어느정도 예측할 수 있을지라도, 5년, 10년 .. 후에는 어떻게 바뀔지 모른다.
  • 현 시점에서 확장 니즈가 명료한가
    • 처음부터 확장성을 너무 고려하여 개발하면, 다른 사람들이 코드 분석에 어려움을 겪는다.

You Arent Gonna Need It

Always implement things when you actually need them, never when you just foresee that you may need them.

From: MartinFowler

Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".

Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.

From: Ward's Wiki

There are two main reasons to practise YagNi: Ward's Wiki

  • You save time, because you avoid writing code that you turn out not to need.
  • Your code is better, because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway

Underengineering

It doesn’t need to be there now, but you’d be underengineering if you made it impossible to add it later.