최근에 프로젝트를 하면서 기존 방식이 흔한 db에 프로시져 만들고 business 로직
거의 프로시져에 두는 방식이 싫어서
ef,.Net 8.0 , 병렬처리 ,윈도우 서비스 배포 등등 최신 기술 쓰다가
실패까지는 아닌데 참 여러모로 개발 속도나 퍼포먼스나 고객 만족(?)
여러모로 쓰디쓴 실패를 맛봤네요
아 제가 부족한것도 있지만 최신기술이 개발속도와 퍼포먼스를 보장하는것 아니다라는
진리 를 알고 덤벼도 결과가 안좋아서 속상하네요
뭐 당연한 말이지만 최신 기술을 많이 안다고
일을 잘하는것 아닌것 같습니다.
개발 욕심과 일 욕심은 다른 것 같습니다
개발자의 욕심을 내려놓는 게 중요하죠
경험하지 않은 기술을 넣고 싶으면 10% 이내만
근데 그게 항상 잘 안되죠
저는 지금 같은팀 개발자들이 너무 맘에 안드는 나머지 엿먹어봐라 하고 최대한도로 최신 문법을 적용해서 개발 중입니다.
덕분에 저도 늦어지긴 하는데요. 뭐 점점 좋아지겠죠. ㅎㅎ
이것과는 별개로 리펙토링을 여유롭게 하는 경우가 아니라면 사실 최신기술 적용이 좋은것만은 분명히 아니죠.
개인적으로는 일단 개발을 하고 좀 여유롭게 리펙토링을 하면서 기술을 충분하게 익힐 수 있게 해주는 회사가 있다면 참 좋을 것 같습니다.
유명하고 많이 쓰이는 것들 대부분 직접 만든 것보다 못한 경우가 많습니다.
직접 만든 건 자기 프로젝트 특성 고려해서 최적화를 하기 때문에 기술과 경험이 충분하다면 그렇죠
최신 기술 검증하고 최적화 하는 비용이 훨씬 크다고 봅니다.
이게 어떤 의미인지 참 궁금하군요.
데이터 베이스 조작에 관해서는 프로시져의 성능을 따라 갈 게 없는 건 사실이나, 비지니스 로직까지 포함하는 것은 여전히 재고할 필요가 있다고 생각합니다.
예전에 유튜버 널널한 개발자님도 성능 보다는 유지 보수를 높게 평가한 적이 있었죠.
그분도 "남이 손 대지 못하는 코드"가 양산되는 현실의 고충을 잘 알고 계시기에 그런 것 아닐까요?
개인적으로 저장 프로시저가 아무리 좋아도, EF 의 타입 안정성은 이길 수 없다… 라고 생각합니다.
AI 가 아무리 좋은 코드를 뽑아 줘도, 그걸 유지보수할 능력이 안되면 글자에 지나지 않듯이 말이죠.
제가 등장할 차례군요 크큭…
sp에 로직을 두는게 싫다고 하셨는데 업종에 따라 다릅니다.
DBA가 계시면 sp는 DBA의 영역입니다. DBA가 단순히 DB 떨어지지만 말라고 빌고 있는 직종이 아니죠.
소켓 서버 같은 경우는 sp에 로직을 넣어야 서버를 내리지 않고 로직을 변경하거나 장애처리가 가능한 경우도 있습니다.
모든 서버가 웹 서버만 있다고 생각하시면 안됩니다. 업종에 따라 sp에 로직을 넣어서 돌리는 이유 또한 다 존재합니다.
ㅎㅎ
똑같이 ef 가 웹서버에만 쓸수있다는 것도 편견입니다
음 생각보다 필드에서 EF 를 사용하는곳은 별로 없습니다.
아마도 상담수 실무에서 RDB 에 프로시져로 비지니스 로직 두는
개발방식이 절반 이상이라고 생각합니다.
글쎼요 Linq랑 EF를 구분못하는 분들도 많아요 ;;
SP 에 로직을 둘때 일단 Unmanage 성 리소스로 분류 될수 있죠?
그 프로시져를 만든 사람에 종속되는 코드 같습니다.
프로시져가 몇개 안될때는 구분이 잘가죠 근데 어느순가
수백 수천개 될때 관리가 안되고
만들었어도 이런 프로시가 있어나 하면서 중복하면서 만들게
되고요 그리고 프로시져 무서워서 스키마 변경이나 확장에 걸리는 경우가 많죠
아마도 java mybatis , JPA 를 쓰는 이유도 이렇게 PROC 관리가 안되서
쓸것라고 생각합니다.
EF 는 DB First로 개발할때는 좀 문제가 많지만 Code First 일때는
장점이 있다고 봅니다.