기획을 하는 이유는 사용자에게 구매에 대한 설득력을 부여하기 위함이고

설계는 그 설득을 하기 위한 도구다

중요한건 대상이 사용자지 개발자가 아니라는거다

개발자가 자화자찬해봐야 고객이 안사면 그냥 망하는거고

개발자가 맨날 지가 짠 코드 욕해도 잘팔리면 성공하는거야

그럼 좋은 설계는 왜 필요하냐

고객만족을 위해서 소프트웨어는 크게 몇가지 특성을 만족해야해

신뢰성. 버그 있으면 쓰다가도 열받으니까 버그없이 잘 동작해야지. 버그를 쉽게 고칠수 있는 구조를 갖추는 것도 이걸 만족하는 한가지 방법인데 유지보슈성 유연성 확장성 등과 연결됨

사용성. 기능이 많아도 쓸때마다 삽질해야하면 안쓰겠지? 유지보수성 성능 보안 가용성 유연성 확장성과 연결됨

개발속도. 첫개발이면 몰라도 얼리억세스라도 사용자에게 배포한 이후에는 개발속도도 중요해. 사용자가 1년마다 겨우 마이너 업데이트하는 게임을 10년동안 기다릴거라거 생각하면 안되지. 유지보수성 유연성 확장성 이식성 테스트가능성 상호운영성이 여기에 들어가는 특징임

가격. 아무리 좋은 소프트웨어라도 고객에게 확신을 주지 않으면 만원에도 팔기 힘들다. 그리고 가격이 비싸지면 비싸질수록 그 허들이 높아지지. 가격을 떨구려면 유지보수성 유연성 확장성 이식성 테스트가능성 상호운영성이 있어야하고.

위에 사항이 이유가 아니라면 그 설계는 뻥설계야

개발자의 자기자신 위로밖에 안되지

대표적인게 디자인패턴 남용하는거

가장 좋은 설계는 무설계야

설계안하고도 위에 사항을 모두 만족하면 좋은거지

근데 그건 불가능하고 위에 사항을 만족할만큼만 작게 좁게 설계하는게 차선이다

설계를 빡빡하게 할수록 성능이나 확장성은 좋아질수 있어도 유연성이 떨어지는데 위에서 보다시피 유연성은 필수다.

프로그래머는 언제나 소프트웨어가 왜 soft가 붙어있는지를 잊으면 안된다

왜 설계충들이 매번 리펙토링에 목숨을 거느냐하면 그만큼 설계가 엉망이기 때문임

근데 뭐가 문제인지 모르기때문에 계속 고치는거지

뭐가 문제인지 알면 딱 문제있는 부분만 고치지 없는 문제를 만들어가면서까지 고치지는 않는다.

리펙토링은 딱 필요한만큼만 하는거야