네, 실무에서 매우 잘 적용해 사용하고 있습니다. 지금까지 모든 웹 개발은 레이어드 아키텍처 방식으로 진행했습니다.
익명(118.235)2022-12-09 10:48
답글
그런데 서비스랑 리포지터리를 나누는게 왜 알아보기 어렵다고 생각했나요?
김대기(211.219)2022-12-09 10:49
답글
서비스랑 리포지터리는 왜 나눠야한다고 생각하나요?
김대기(211.219)2022-12-09 10:50
답글
컨트롤러에서 리포지터리를 직접 접근하는걸 지양해야하는 이유는 무엇일까요?
레이어드 아키텍쳐란 왜 나온걸까요?
레이어란 무엇일까요?
김대기(211.219)2022-12-09 10:50
답글
한 클래스에 있는 수천줄의 코드가 이해하기 쉬운 이유는 무엇일까요?
유지 보수는 가능할까요?
김대기(211.219)2022-12-09 10:52
답글
웹 이외에 다른 개발도 동시에 진행중이기 때문입니다. 경우에 따라 지나치게 레이어가 깊어지거나 혹은 굳이 나눌 필요가 없는 작은 프로젝트의 경우까지 레이어를 나눠 코드 복잡도만 쓸데없이 높이는 프로젝트를 현재 진행중입니다. 동료 코드와 비교해보니 굳이 계층을 나눠 발생하는 이점을 느끼기 어려운 케이스도 있더군요. 광신적인 패턴 추종이 답은 아니라느낍니다
익명(118.235)2022-12-09 10:53
답글
수천줄이라 유지보수가 어려울건 또 뭐 있나요?
익명(118.235)2022-12-09 10:54
답글
웹 이외에 다른 개발도 동시에 진행중인건 레이어와는 관련이 없습니다
오히려 도메인과 연관이 있지요
김대기(211.219)2022-12-09 10:54
답글
레이어드 아키텍처 적용하기에 구조가 적당한 개발이 아니라는 취지에서 드린 말씀입니다.
익명(118.235)2022-12-09 10:55
답글
수천줄이라 유지보수가 어려울건 또 뭐가 있냐니요 ㅎㅎ
줄이 길면 읽기가 힘들고 읽기가 힘들면 이해하기가 힘듭니다
이해하기가 힘들면 수정하기도 힘들고 수정하기 힘든건 유지보수가 어렵단 의미입니다
수천줄에서 중복 코드는 얼마나 있을지도 궁금하네요
118님은 리팩토링 서적도 읽고 클린코드도 읽으면서 발전을 더 하셔야겠어요
김대기(211.219)2022-12-09 10:56
답글
귀찮아
익명(118.235)2022-12-09 10:58
답글
저 역시 한때 광신적으로 코드품질 유지에 신경썼던 적이 있습니다만 그것만이 답이라 느끼고 따르는 것은 그만두기로 했습니다. 김대기님의 시니어로서의 경험과 역량은 존중합니다만, 저는 저 나름대로의 경험을 바탕으로 길을 개척하고자 합니다. 그게 먼 훗날 비슷한 결론으로 수렴될지는 모르겠습니다만.
익명(118.235)2022-12-09 10:58
답글
오해의 여지가 있어 말씀드립니다만, 중복코드는 반드시 최소화해서 작업합니다. ^^
익명(118.235)2022-12-09 11:01
개발자는 대장장이라고 비유합니다 철을 두들겨야 철을 다루는 법을 알죠 눈으로만 읽으면 그건 대장장이가 아니라 대장학자임
눼 다음 레포도 모르는 실무자
이새끼는 ef 쓰면서도 리포지터리 만든다에 한표 겁니다.
118.235님은 기본적인 개념이 좀 없으신거같던데요 혹시 레이어드 아키텍쳐는 아시나요?
네, 실무에서 매우 잘 적용해 사용하고 있습니다. 지금까지 모든 웹 개발은 레이어드 아키텍처 방식으로 진행했습니다.
그런데 서비스랑 리포지터리를 나누는게 왜 알아보기 어렵다고 생각했나요?
서비스랑 리포지터리는 왜 나눠야한다고 생각하나요?
컨트롤러에서 리포지터리를 직접 접근하는걸 지양해야하는 이유는 무엇일까요? 레이어드 아키텍쳐란 왜 나온걸까요? 레이어란 무엇일까요?
한 클래스에 있는 수천줄의 코드가 이해하기 쉬운 이유는 무엇일까요? 유지 보수는 가능할까요?
웹 이외에 다른 개발도 동시에 진행중이기 때문입니다. 경우에 따라 지나치게 레이어가 깊어지거나 혹은 굳이 나눌 필요가 없는 작은 프로젝트의 경우까지 레이어를 나눠 코드 복잡도만 쓸데없이 높이는 프로젝트를 현재 진행중입니다. 동료 코드와 비교해보니 굳이 계층을 나눠 발생하는 이점을 느끼기 어려운 케이스도 있더군요. 광신적인 패턴 추종이 답은 아니라느낍니다
수천줄이라 유지보수가 어려울건 또 뭐 있나요?
웹 이외에 다른 개발도 동시에 진행중인건 레이어와는 관련이 없습니다 오히려 도메인과 연관이 있지요
레이어드 아키텍처 적용하기에 구조가 적당한 개발이 아니라는 취지에서 드린 말씀입니다.
수천줄이라 유지보수가 어려울건 또 뭐가 있냐니요 ㅎㅎ 줄이 길면 읽기가 힘들고 읽기가 힘들면 이해하기가 힘듭니다 이해하기가 힘들면 수정하기도 힘들고 수정하기 힘든건 유지보수가 어렵단 의미입니다 수천줄에서 중복 코드는 얼마나 있을지도 궁금하네요 118님은 리팩토링 서적도 읽고 클린코드도 읽으면서 발전을 더 하셔야겠어요
귀찮아
저 역시 한때 광신적으로 코드품질 유지에 신경썼던 적이 있습니다만 그것만이 답이라 느끼고 따르는 것은 그만두기로 했습니다. 김대기님의 시니어로서의 경험과 역량은 존중합니다만, 저는 저 나름대로의 경험을 바탕으로 길을 개척하고자 합니다. 그게 먼 훗날 비슷한 결론으로 수렴될지는 모르겠습니다만.
오해의 여지가 있어 말씀드립니다만, 중복코드는 반드시 최소화해서 작업합니다. ^^
개발자는 대장장이라고 비유합니다 철을 두들겨야 철을 다루는 법을 알죠 눈으로만 읽으면 그건 대장장이가 아니라 대장학자임