카놀라유
1k
2022-07-22 19:41:14 작성 2022-07-22 19:43:07 수정됨
15
1086

서비스를 개선하고 싶은데 쉽지 않아요...


새로운 신기술을 적용하여 회사 프로젝트를 개선하자는 것도 아니고


그냥 단순히 지금 사용되고 있는 것들중에 공통으로 만들 수 있는건 공통으로 만들고


불필요한 IF 분기문을 객체 지향 패턴으로 최소화 해서 프로젝트를 개선하자


지금처럼 똑같은 코드를 비슷한 다른 클래스에 똑같이 붙여넣기 하는 식으로 작업하면


나중에 서비스가 점점 커지면 커질수록 답이 없어진다.


작업 할때 화면 단위로 작업을 하는게 아니라 기능 단위로 작업을 해야한다.


아무리 주장해도 "이미 잘 돌아가고 있는 서비스는 건드리면 안된다." 로 버티니 너무 답답해요...


IF 분기문이 한눈에 들어와서 보기 편한데 왜 그걸 굳이 클래스로 찢어야 하는지 부터 이해를 못합니다...






진짜 저런 식의 분기가 수백줄씩 이어지는데 진짜 수정할때마다 퇴사 하고 싶습니다... ㅠㅠ


A1은 뭐고... A2가 뭔지....


근데 제 윗 분들은 머리가 얼마나 비상하고 똑똑한지 검색이 뭔가요???


저 코드들을 다 외우고 심지어 프로젝트 구조 까지 머리속에 통째로 넣어두고 필요할때마다


"아~ 그건 어디어디 있어~" 하면서 마우스 클릭으로 찾아들어가요... 


저 분기문을 머리속에 통째로 넣어두고 외우고 다녀요 전 1년을 봐도 모르겟는데 ㅋㅋㅋㅋ


디버깅이 뭔가요 System.out.println으로 로그(?) 찍으면 되는데요...


팩토리 패턴이나 파사드 패턴 어렵지 않은건데, 그것만 써도 저 엄청난 분기문을 보지 않아도 되는데


"그건 새로 배워야 하잖아~"


아니 당연히 배워야지 개발자가.... 아오 진짜... 사람들은 너무 좋은데...

0
  • 댓글 15

  • park~park~
    237
    2022-07-22 19:46:51

    저런 분들은 공부가 귀찮기도 할거고 

    복잡한 히스토리가 많아야 본인들이 가치가 있으니까 저런 거라고 생각합니다.

  • 하루히즘
    1k
    2022-07-22 19:49:04
    과거에 리팩토링했다가 장애 난 경험이 있어서 단기적으로 불필요한 변경을 꺼리는 경우도 있더라구요
  • 늦어도공부하자
    1k
    2022-07-22 20:06:29

    이직 타이밍이 되셨습니다.

  • tm****
    765
    2022-07-22 20:15:25

    다른분들은 어떻게 생각하는지 궁금한글이네요

  • 시인들
    2k
    2022-07-22 20:30:39
    음? 데이터 코드 잖아연;; 이름값 따로 있을 텐데연..음 작성자님을 비판하는건 아니지만 코드를 합치는건..좋은 면도 있공 나쁜면동 있어연 하핫 혹시 디자인 패턴이 답이라는 생각읕 가지공 계시다명 좀 난감하네연 
  • 프레이야
    2k
    2022-07-22 20:43:21

    공부 하시고 

    새로운곳에 적용을 하면 되지 않나요?

    이미 잘 돌아가고 있고 그것을 명확하게 이해하고 있는 분들이 있는데

    굳이 리팩토링할 필요가 있을까 저역시 생각이 드는데요..

    단순히 기술을 적용해보고 싶은건지

    정말 객체지향을 써서 변경하면 먼가 나아질지도 의문인데여..

  • fealtort
    1k
    2022-07-22 21:04:14

    금융권에서 저ㅜ짓을 많이 하죠..

  • 도미다
    200
    2022-07-22 21:07:06

    가끔 어떤 코드보면 부들부들거리는데

    그 담당자가 어깨뽕에 으쓱거리면 달려가서

    로우킥 날리고 싶습니다. 


  • 레인3
    2k
    2022-07-23 00:08:28

    말 한 번 꺼내봤으면 된 겁니다.

  • zenon8485
    535
    2022-07-23 00:10:11 작성 2022-07-23 00:10:41 수정됨
    고인물은 자기가 관리하는 코드를 남이 건들기 힘들수록 그것이 대체 불가능한 인력이 되는거라고 믿는거라서 (그리고 대부분의 비개발직들이 거기에 속죠) 솔직히 차세대로 프로젝트 만드는 상황 아니면 답이 없습니다....
  • Constant
    727
    2022-07-23 15:22:33

    초보 때 흔히 하는 착각

    "레거시는 무조건 나쁜 것이다"

    님이 코드 수정해서 개발자 전체가 생산성이 올라갈 수준으로 변경할 수 있나요?

    그에 따른 맨먼스 비용을 계산할 수 있나요?

    이러한 과정을 글쓴이님이 리드할 수 있나요?

    이 질문이 모두 YES 라면 님의 의견이 타당하고 실력이 좋은 사람이고 하나의 질문이라도 NO 라면 객기입니다.



  • 유도지
    192
    2022-07-23 21:40:44

    전략패턴 마렵네요..

  • 카놀라유
    1k
    2022-07-24 00:05:37

    Constant

    저 긴 분기문은 코드처럼 되어있지만, 정리되어 있지 않아 모든걸 일일이 찾고 다른데 어떻게 사용하는지 보고 유추해야합니다.

    레거시가 나쁜건 아니라고 생각하지만, 어떤 기능을 개발하거나 수정할때 마다 계속해서 분기문이 늘어나는 상황은 별로 좋지 않은것 같아 개선하고 싶었급니다.

    코드는 enum으로 관리하고 각 분기를 메서드나 클래스로 나누면 훨씬 보기 좋고 유연할 거라 생각했어요. 단순히 초보자의 객기로 치부하시니 좀 욱하네요....

  • Constant
    727
    2022-07-24 05:25:02 작성 2022-07-24 05:27:01 수정됨

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

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

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

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


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


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


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


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


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

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

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

  • 카놀라유
    1k
    2022-07-25 00:14:22

    Constant

    그렇게 글로 두들겨 패시면 많이 아픕니다...

    글을 읽으며 생각해 보니 기존 코드를 수정하겠다고 우기기 보다는 샘플 코드를 먼저 만들어서 보여주고 이 방법은 어떤지 의논하면서 설득해 보는게 먼저일것 같네요...

    맞아요 제가 그 회사 천년만년 다닐것도 어니고 제가 진행한 방식이 100퍼센트 맞지도 않고 모든 코드를 버그 없이 수정할 자신도 없으면서 막무가네엿던것 같습니다. 이거저거 섞여서 절반은 스파게티 절반은 뭔지모를 객체화 되버리면 제 후임들이 더 힘들어 지겠죠.

    먼저 만들어보고 의논하고 설득하고 허락맡고, 기존 개발이 아닌 신규 개발건에 한하여 적용해 보도록 하겠습니다.

  • 로그인을 하시면 댓글을 등록할 수 있습니다.