현재버전

전 위의 코드가 잘났다 못났다 말하고 싶은게 아니라 님께서 충분히 장단점 고려해서 이끌어 나갈 수 있냐고 여쭤본겁니다.

님이 이해하는 디자인 패턴과 공통화, 모듈화가 타당하고 너무 효율적이라면 만들어서 설득하세요. 거기까지가 실력이라고 보는 겁니다. 누가봐도 명확하고 쓰기 쉬워보인다면 안 따라할 이유가 없습니다.

님이 Enum이든 뭐든 뭔가가 좋아보여서 만들었다고 칩시다.

1. 처음 들어온 사람들은 당연히 Enum으로 만들어진걸 보는게 더 직관적으로 이해되겠지만 현재 직원들은 원래 이해하고있던 변수들을 새롭게 대체된 단어로 매칭시켜야 하는 상황이 생기는데 해당 문제에 대한 생산성 저하를 님께서 어떻게 설득 시킬건가요? 미래에 코드가 더 유연해져서 생산성이 올라가니까요? 만약에 더 좋은 방식의 기술이 나와서 서비스를 리뉴얼해야한답시고 님이 이미 익숙해져버린 코드들을 드러내야한다라고 하면 다시 익히는 한이 있더라도 몇번이고 갈아치울 의향있으신가요? 


2.  "이미 잘 돌아가고 있는 서비스"라고 하셨는데 이미 돌아가는 서비스 객체지향화해서 트러블 100% 안나게 할 자신있으신가요? 어떤 서비스인지 모르겠지만 그게 만약 중요한 고객서비스라면요?


3. 이미 하고 있는 일도 있을텐데 전사적으로 객체지향화 해야될 돈은 누가 마련해주나요? 


4. 전체가 아니더라도 조금씩이라도 고쳐보는 것도 문제입니다. 어정쩡하게 만들다가 퇴사해서 절반은 객체지향화, 절반은 스파게티 코드로 남아버리면 그 뒤에 들어온 사람은 더 헷갈리지 않을까요?


5. 말씀하신대로 A1, A2는 클린코드스럽지 않습니다. 변수는 그 의미가 명확해야 합니다. 다만 분기처리된 코드들을 도메인 주도 패턴, 추상화 등을 이용해 캡슐화, 기능, 모듈화 처리를 하는 것도 해당 도메인을 전반적으로 아는 전문가가 꼭 필요합니다. 도메인 주도 패턴을 쓰는 회사는 항상 도메인 전문가가 존재합니다. 누가 할건가요 그건? 그래서 오히려 추상화를 통한 캡슐화는 더 알아먹지 못할 코드가 되는 경우도 많습니다.


제 생각엔 단순히 글쓴이님께서 "좀 더 세련되고 보기 좋고 우아한 방식이니까"라고 생각하시는 것 같습니다. 그런 방식들이 좋은거 누가 모를까요

회사든 어디든 무언가를 요구하려 할 땐 해결 방법과 이끌어나갈 방법까지 같이 생각하는게 좋습니다. 그래야 리누즈 토발즈처럼 아무데나 가서 욕하고 다녀도 타당해보이죠. Rest Api가 세련됐다해서 Rest Api가 굳이 필요한 프로젝트일지 고민해보세요. 리액트, 뷰, 앵귤러가 최신 기술이라해서 모든 프로젝트를 다 그걸로 만들어야되는 건 아닙니다. 단순히 인터넷, 책에 나뒹구는게 가장 최신기술이라해서 무조건 써야되는 지식은 아닙니다.

작은 것부터 만들어서 설득하고 깨져보고 해보세요. 님 글이 만약에 "내가 이런 주장을 했고, 이 기술을 사용해서 만들었고, 설득을 해봤다." 총 3단계가 들어가있었으면 오히려 대단하다고 말씀드렸을 것 같습니다. 1단계가지고는 나무만 보는 신입의 패기어린 한마디 같습니다. 뭔가 제가 개떡같이 욕나오는 코드 두둔하는것처럼 보이는데 저도 그런 코드 극혐합니다. 적어도 해결하려는 자세가 그런 방법은 아니라고 말씀드린 것 뿐입니다.

수정이력

2022-07-24 05:27:01 에 아래 내용에서 변경되었습니다.

전 위의 코드가 잘났다 못났다 말하고 싶은게 아니라 님께서 충분히 장단점 고려해서 이끌어 나갈 수 있냐고 여쭤본겁니다.

님이 이해하는 디자인 패턴과 공통화, 모듈화가 타당하고 너무 효율적이라면 만들어서 설득하세요. 거기까지가 실력이라고 보는 겁니다. 누가봐도 명확하고 쓰기 쉬워보인다면 안 따라할 이유가 없습니다.

님이 Enum이든 뭐든 뭔가가 좋아보여서 만들었다고 칩시다.

1. 처음 들어온 사람들은 당연히 Enum으로 만들어진걸 보는게 더 직관적으로 이해되겠지만 현재 직원들은 원래 이해하고있던 변수들을 새롭게 대체된 단어로 매칭시켜야 하는 상황이 생기는데 해당 문제에 대한 생산성 저하를 님께서 어떻게 설득 시킬건가요? 미래에 코드가 더 유연해져서 생산성이 올라가니까요? 만약에 더 좋은 방식의 기술이 나와서 서비스를 리뉴얼해야한답시고 님이 이미 익숙해져버린 코드들을 드러내야한다라고 하면 다시 익히는 한이 있더라도 몇번이고 갈아치울 의향있으신가요? 


2.  "이미 잘 돌아가고 있는 서비스"라고 하셨는데 이미 돌아가는 서비스 객체지향화해서 트러블 100% 안나게 할 자신있으신가요? 어떤 서비스인지 모르겠지만 그게 만약 중요한 고객서비스라면요?


3. 이미 하고 있는 일도 있을텐데 전사적으로 객체지향화 해야될 돈은 누가 마련해주나요? 


4. 전체가 아니더라도 조금씩이라도 고쳐보는 것도 문제입니다. 어정쩡하게 만들다가 퇴사해서 절반은 객체지향화, 절반은 스파게티 코드로 남아버리면 그 뒤에 들어온 사람은 더 헷갈리지 않을까요?


5. 말씀하신대로 A1, A2는 클린코드스럽지 않습니다. 변수는 그 의미가 명확해야 합니다. 다만 분기처리된 코드들을 도메인 주도 패턴, 추상화 등을 이용해 캡슐화, 기능, 모듈화 처리를 하는 것도 해당 도메인을 전반적으로 아는 전문가가 꼭 필요합니다. 도메인 주도 패턴을 쓰는 회사는 항상 도메인 전문가가 존재합니다. 누가 할건가요 그건? 


제 생각엔 단순히 글쓴이님께서 "좀 더 세련되고 보기 좋고 우아한 방식이니까"라고 생각하시는 것 같습니다. 그런 방식들이 좋은거 누가 모를까요

회사든 어디든 무언가를 요구하려 할 땐 해결 방법과 이끌어나갈 방법까지 같이 생각하는게 좋습니다. 그래야 리누즈 토발즈처럼 아무데나 가서 욕하고 다녀도 타당해보이죠. Rest Api가 세련됐다해서 Rest Api가 굳이 필요한 프로젝트일지 고민해보세요. 리액트, 뷰, 앵귤러가 최신 기술이라해서 모든 프로젝트를 다 그걸로 만들어야되는 건 아닙니다. 단순히 인터넷, 책에 나뒹구는게 가장 최신기술이라해서 무조건 써야되는 지식은 아닙니다.

작은 것부터 만들어서 설득하고 깨져보고 해보세요. 님 글이 만약에 "내가 이런 주장을 했고, 이 기술을 사용해서 만들었고, 설득을 해봤다." 총 3단계가 들어가있었으면 오히려 대단하다고 말씀드렸을 것 같습니다. 1단계가지고는 나무만 보는 신입의 패기어린 한마디 같습니다. 뭔가 제가 개떡같이 욕나오는 코드 두둔하는것처럼 보이는데 저도 그런 코드 극혐합니다. 적어도 해결하려는 자세가 그런 방법은 아니라고 말씀드린 것 뿐입니다.

2022-07-24 05:25:31 에 아래 내용에서 변경되었습니다.

전 위의 코드가 잘났다 못났다 말하고 싶은게 아니라 님께서 충분히 장단점 고려해서 이끌어 나갈 수 있냐고 여쭤본겁니다.

님이 이해하는 디자인 패턴과 공통화, 모듈화가 타당하고 너무 효율적이라면 만들어서 설득하세요. 거기까지가 실력이라고 보는 겁니다. 누가봐도 명확하고 쓰기 쉬워보인다면 안 따라할 이유가 없습니다.

님이 Enum이든 뭐든 뭔가가 좋아보여서 만들었다고 칩시다.

1. 처음 들어온 사람들은 당연히 Enum으로 만들어진걸 보는게 더 직관적으로 이해되겠지만 현재 직원들은 원래 이해하고있던 변수들을 새롭게 대체된 단어로 매칭시켜야 하는 상황이 생기는데 해당 문제에 대한 생산성 저하를 님께서 어떻게 설득 시킬건가요? 미래에 코드가 더 유연해져서 생산성이 올라가니까요? 만약에 더 좋은 방식의 기술이 나와서 서비스를 리뉴얼해야한답시고 님이 이미 익숙해져버린 코드들을 드러내야한다라고 하면 다시 익히는 한이 있더라도 몇번이고 갈아치울 의향있으신가요? 

2.  "이미 잘 돌아가고 있는 서비스"라고 하셨는데 이미 돌아가는 서비스 객체지향화해서 트러블 100% 안나게 할 자신있으신가요? 어떤 서비스인지 모르겠지만 그게 만약 중요한 고객서비스라면요?
3. 이미 하고 있는 일도 있을텐데 전사적으로 객체지향화 해야될 돈은 누가 마련해주나요? 
4. 전체가 아니더라도 조금씩이라도 고쳐보는 것도 문제입니다. 어정쩡하게 만들다가 퇴사해서 절반은 객체지향화, 절반은 스파게티 코드로 남아버리면 그 뒤에 들어온 사람은 더 헷갈리지 않을까요?

5. 말씀하신대로 A1, A2는 클린코드스럽지 않습니다. 변수는 그 의미가 명확해야 합니다. 다만 분기처리된 코드들을 도메인 주도 패턴, 추상화 등을 이용해 캡슐화, 기능, 모듈화 처리를 하는 것도 해당 도메인을 전반적으로 아는 전문가가 꼭 필요합니다. 도메인 주도 패턴을 쓰는 회사는 항상 도메인 전문가가 존재합니다. 누가 할건가요 그건? 


제 생각엔 단순히 글쓴이님께서 "좀 더 세련되고 보기 좋고 우아한 방식이니까"라고 생각하시는 것 같습니다. 그런 방식들이 좋은거 누가 모를까요

회사든 어디든 무언가를 요구하려 할 땐 해결 방법과 이끌어나갈 방법까지 같이 생각하는게 좋습니다. 그래야 리누즈 토발즈처럼 아무데나 가서 욕하고 다녀도 타당해보이죠. Rest Api가 세련됐다해서 Rest Api가 굳이 필요한 프로젝트일지 고민해보세요. 리액트, 뷰, 앵귤러가 최신 기술이라해서 모든 프로젝트를 다 그걸로 만들어야되는 건 아닙니다. 단순히 인터넷, 책에 나뒹구는게 가장 최신기술이라해서 무조건 써야되는 지식은 아닙니다.

작은 것부터 만들어서 설득하고 깨져보고 해보세요. 님 글이 만약에 "내가 이런 주장을 했고, 이 기술을 사용해서 만들었고, 설득을 해봤다." 총 3단계가 들어가있었으면 오히려 대단하다고 말씀드렸을 것 같습니다. 1단계가지고는 나무만 보는 신입의 패기어린 한마디 같습니다. 뭔가 제가 개떡같이 욕나오는 코드 두둔하는것처럼 보이는데 저도 그런 코드 극혐합니다. 적어도 해결하려는 자세가 그런 방법은 아니라고 말씀드린 것 뿐입니다.

cat-footer