어디서 어설프게 디자인패턴 지식 들고와서
여기저기 쫙쫙 찢어발겨놓고
도메인이 어쩌고, 비즈니스 로직이 어쩌고저쩌고, 무슨 패턴이니, 무슨 서비스니...
찢으려면 좀 잘 찢던가
유닛테스트랍시고 해놓은 꼬라지 보면 그냥 웃음만 나옴
이틀이면 짤 코드를 그지랄하면서 한달내내 들쑤시고
막상 요구사항 조금 변경되면 오만상을 찌푸림ㅋㅋ
추상화의 애초 목적이 테스트, 유연성, 확장성인데
막상 테스트는 동어반복 코메디 수준이고
유연성과 확장성이 필요한 순간이 오면 궁색해지며 스스로를 변명하기 급급해짐
개똥같은 쓰레기 추상화라는게 원래 그렇지
추상화는 아무나 하는게 아니다
평범보다 약간 뛰어난 너와나같은 사람들이 하는게 아니라
존나 똑똑한 사람들이 하는거다
프론트/템플릿/뷰 이쪽에서는 고객이 원하는거 하고싶은거 맘껏 다 하고
디비 스키마도 자기 주장 강하게 튼튼하게 지어놓고
그 사이에서 온갖 더러운일 다 하면서 돌아가게 만드는게 백엔드가 하는 일인데
나르시시즘에 빠져서 코드를 예쁘게 짜려고 하는 모습 보면 좀 안타깝다
코드 예쁘게 안 짜면 코드 리뷰 때 혼남
원래 추상화는 함부러 하는게 아닙니다 B는 A인 관계가 성립돼야 A를 상속한 B를 만들 수 있는데, 현실세계에 이런 관계는 별로 없고 있다손 쳐도 비즈니스의 개념을 그대로 쓸순 없습니다(잘게 쪼개야함) 그래서 보통은 컴포지션이 이득이 되는 경우가 많죠
잘 다듬고 쪼갤 시간도 주어지지 않고 주니어들은 실력이나 경험까지 부족하고요 문제는 그런 주니어가 계속 시간 없는채로 커서 시니어가 된다는 점입니다
개인적인 생각으로는 시니어가 시간을 좀 투자해서 우리 프로젝트에서 추상화할만한 영역과 아닌 영역을 예시를 들어 알려주고 실제 코드를 리팩토링 하는 과정을 보여주면 참 좋을텐데.. 일반적인 기업의 시니어가 그렇게 하지는 않죠
추상화 할때는 이것만 지켜도 반은 먹고 들어갑니다 1. 비즈니스 로직을 통째로 추상화 할 생각 하지 말것, 같아보여도 상황이 바뀌면 얼마든지 변할 수 있음 2. 비즈니스 로직에서 변하는 부분과 변하지 않는 부분을 나누고 변하지 않는 부분을 추상화 할 것 3. 추상화를 해서 얻을 이득이 명확하게 느껴지기 전까지는 추상화 하지 말것
개발 좀 해 본 느낌이 나는글이네