사클의 구린음악은 들어도 알지만
좋은 음악은 왜 좋은음악인지 명확히 설명하기 어려움(내기준)
사실 다들 알고잇다.
어디가 잘못됫는지를.
하지만 아무도 이 사실을 정략적으로 수치화하기 어렵고 제대로 설득하고, 실제로 개선하기까진 매우어려운 일이다.
나역시 그랫엇지만 개선하고싶엇다.
이 늙고병든 어플리케이션을 진단하고 처방하고싶엇다
더럽고 혼란스러운 우리네 업무코드를 구원해줄 메시아가 필요햇던것이다.
결론은 oop와 ddd이다.
업무코드의 추상도는 0이다.
그렇다면 왜 추상화를 해야하는가?
왜 프론트엔드 프레임워크를 도입해야하는가?
JPA는 왜 필요한것인가?
변경의 레벨 양상 추이 가 달라서이다.
기본적으로 젤 많이 빨리, 그리고 이상하게(?) 변하는곳이 화면단이다. 이를 서버자원인 jsp와 백엔드는 따라 가기에 너무벅차다. 너무많은 데이터가 생성되고 조합되고, 소멸되는 곳이 프론트엔드이다.
프론트엔드와 백엔드의 완벽한 분리, mvc패턴의 소기목적인 뷰와 모델의 분리가 이때문에 나타난 현상이라고 생각한다.
JPA는 왜 생겻는가?
마이바티스가 구려서? 오래되서? 보안상의 큰 구멍이 생겻는가? 아니면 단순히 멋잇어보여서?
다음은 책에서 본 내용이다.
"객체지향과 SQL 간의 패러다임 불일치 문제를 해결하기위해"
훌륭한 말씀이시다.
이걸 내방식으로 재정의를 해보자면
"자바코드와 SQL(DB)간 변경의 씽크를 맞추기 위해"
도입한다고 생각한다.
마찬가지로 sql은 자바코드의 변경속도를 따라가지 못한다.
학원을 다닐 때의 일이다. 어떤 프론트엔드빠순이는 jsp가 왜 구린지도 잘모른채 그저 맹목적으로 프엔 프레임워크를 빨아댓다. 지도 모른다. 구리다햇으면 왜 그런지도 같이 설명하는게 인지상정아닌가.
예전에 봣던
프로그래머, 왜라는 질문에서 시작하라
는 칼럼을 본적이 잇다.
물론 누군가는 실무에 도움이 되지않는다 생각할(나도 가끔은) 수도 잇지만 퇴근하고나서부터는 왜라는 질문부터 시작해야한다고 개인적으로는 생각한다.
사실 어떤 코드가 좋은 코드인가에대한 질문은 그리 적절한 질문이 아닐수 잇다 그때그때 다르기 때문이다.
그렇지만 내가 생각하는 답변은 이렇다.
-> 변화(변경)에 쉽게 대비가능한 코드
카테고리 없음