ilovegp
2k
2017-10-19 14:44:23 작성 2017-10-19 14:45:48 수정됨
12
2981

어렵네요 조절의 딜레마에 빠진거 같습니다.


속도 위주로  코딩을 했더니

꼼꼼하지 못하다고 중요 업무에서 밀려났습니다.

혹은 밀려난거 같습니다.(추측)

중복 소스가 많은게 문제입니다

좀더 소스를 줄이도록 노력을 안한거죠 

한번더 생각하는 행위나 노력을 안했습니다 곰곰히 생각해보니 말이죠


내가 왜 이런 식으로 코딩을 했나 생각해보니

전에 업체에서 일정을 못맞추는것에 대해서 안좋은 습관이 있었던것 같습니다.

일반적인 우리나라 si 스타일에 맞추다 보니 그렇게 된것  같습니다.

큰 프로젝트로 올수록 빨리보다는 정확히 꼼꼼히가 중요한데 말이죠.


원인 분석은 맞는데 왜 내가 부끄러울까요? 씁쓸 합니다. 가짜 개발자가 된 느낌입니다.

그리고 참 어렵습니다 조절의 딜레마에 빠진거 같습니다. 


물론 큰 차이는 아니지만 경쟁구도로 가다보니 디테일 한부분이 결국 경쟁에서 밀립니다.

그래도 평타를 위해서 퍼퍼먼스를 고수해야 할까요? 


0
  • 댓글 12

  • Overboost
    1k
    2017-10-19 14:54:11

    저도 한때는 빨리한다. = 잘한다. 라고 생각했었어요.

    그게 아님을 깨닳고 설계에 대하여 생각, 고민이란걸 좀 더 하게 되었어요.

    그러면서 프로토타입, 싱글톤, 프로미스, 자바스크립트를 객체지향화 시키고..

    유리창에 그림도 그려보고 담배피러갈때 a4용지랑 연필도 들고가서 생각도 좀 해보고..

    많은 고민을 해보셔요. 고민을 해봐야 답도 나온답니다.

    그러다보니 개발시간보다 분석/설계시간이 비슷해지고 두번 손 안가고.. 좋네요.

  • ggawa4030
    267
    2017-10-19 14:55:50

    저도 이런부분에서 조금 어렵습니다.

    저같은 경우에는 주어진 기간이 여유가 있다면

    정해진 기간보다 1~2틀정도 먼저 개발을 완료하고

    1~2틀동안 리펙토링 하곤합니다.


    만약 여유가 없다면

    코딩부터 하지 않습니다. 설계단부터 차근차근 따져가면서 공통모듈을 정의합니다.

  • 독거소년
    3k
    2017-10-19 14:56:16 작성 2017-10-19 14:56:40 수정됨

    ppt로 구조 그리는 연습부터 해보시는게... 

    저는 일단 그림(구조)부터 그리고 시작합니다

  • ktsedd
    6k
    2017-10-19 15:00:46

    개발하다가 

    썻던소스를 비슷하게 쓰는 느낌이 들때

    아 이건 공통모듈로 빼보면 어떨까 메모해놓고

    이러면 어떨가요 

    가끔은 실제로 개발할때 생기는 소스남용이 있는거같아서

  • 가난디지털단지
    152
    2017-10-19 15:02:24

    속도를 위해 코드 퀄리티를 포기했다는게 참...

    흔히말해 퍼포먼스가 뛰어나다는 말은 기본적인 퀄리티가 보장 되어야 합니다.

    쓰레기 같은 코드로 쌓아올린 퍼포먼스가 뭔 필요가 있나요 ?

  • 잘부셔지는쿠쿠다스
    194
    2017-10-19 15:06:02
    여기서 속도는 개발 속도이지 퍼포먼스가 아닙니다. 뭔가 주제를 잘 못잡고 계신것 같네요
  • 구구구구우
    1k
    2017-10-19 15:11:15

    기본적으로 함수를 정의할때 작은 단위의 기능으로 함수를 정의 하라고 하죠

    이것은 재사용을 가능케 하고, 중복되는 코드를 줄여줍니다.

    중복되는 코드의 단점은 코드 변경이 이뤄질때 문제가 발생합니다. 최초의 코드를 작성하였을때는 같은 기능이 필요한곳에 동일한 코드를 Copy해서 붙여넣는게 편하겠죠. 하지만 처음부터 수정이 필요없는  완벽한 코드를 작성하는것은 정말 어렵습니다. 프로젝트를 진행하면서 수십번도 넘게 코드를 고치게 되죠

    이때 동일한 코드를 Copy해서 이곳 저곳 붙여 놓았을때, 해당 코드를 변경해야한다면 어떨까요? 아마 해당 코드가 붙여진 곳 이곳저곳 찾아다니면서 코드를 고쳐야 할겁니다. 아주 쓸데없는 시간을 많이 소모하게 되죠. 

    함수가 많은 기능을 담당하고 집약되어 있을수록, 중복은 더 늘어나고, 유지보수(유지보수는 개발이 완료되고 나서만 있는게 아니라 위에서 언급했듯이 개발 전 과정에서 항상 일어나게 됩니다.)에 아주 많은 시간을 쏟아 붓게 되어  결국에는 더욱더 많은 시간이 소요될겁니다. 

    함수를 최대한 작게 정의하고, 재사용하고, 중복되는 코드를 항상 리펙토링 하세요. 프로젝트 진행 중 전반에 걸쳐서 일어나는 유지보수의 시간을 더 단축 시켜줄겁니다. 즉 이게 더 빠르다는 겁니다. 그리고 더 안전한 소프트웨어를 만들어 줍니다. 불안한 소프트웨어는 개발기간을 더욱 늘릴 뿐입니다.

    그러니까 말씀하신 속도 위주의 코딩은 실제로는 더욱 느리고, 불안한 소프트웨어를 만드는 코딩 방식이라는거죠


  • javaland
    615
    2017-10-19 15:14:41 작성 2017-10-19 15:16:14 수정됨

    일정 맞추기에 급급한 환경하에서는 님이 하시는 방법이 맞습니다..

    당장 내일 산출물 내야하는데 구조 설계 생각할 틈도 없고 기존에 잘되던 소스 Copy Paste하는 수밖에 없죠.

    그럼 관리자는 이렇게해서라도 되니 다음에도 역시 일정 촉박하게 진행합니다.

    따라서 이러한 개발 방식에 따른 문제점이 무엇인지 충분히 설명하고 개발 기간을 정할 수 있도록 어필해야 합니다.

    어필 안되는 회사에서는 백날 있어봐야 개발 실력도 늘지 않을 뿐더러 장기적으로는 회사 차원에서도 좋은 현상은 아닙니다.

    물론 충분한 개발 일정의 기준이 개발자의 능력마다 틀릴 수는 있겠죠.

    일반적인 경우를 말씀드린거고, 본인이 다른 개발자보다 좀 더 분발해야한다고 생각되시면 시간을 따로 내서라도 노력하는 부분은 분명 필요할 수도 있습니다.

    어쨌든 Copy Paste 방식의 습관은 지양하시고 시간 날때마다 리펙토링을 해보시고 요령이 생기면 후자가 더 빠른 시점을 경험하실 수 있습니다.


  • 피부탄
    2k
    2017-10-19 16:45:25 작성 2017-10-19 16:46:25 수정됨

    윗분들 얘기처럼 이건 현재 내 프로젝트 상황에 맞쳐서 유도리 있게

    속도나 퀄리티에 초점을 맞쳐 하는게 정답이라 생각합니다. 


    혹은 속도가 필요한 곳인데 괜히 소스가지고 까고 소스에 초점 맞쳐서 개발하면

    느리다고 까고 이런건 그냥 상대방이 날 싫어한다고 생각하시면 됩니다. ㅎㅎ


    아니면 내가 정말 노답으로 일하고 있거나 혹은 상대방이 노답이거나 

  • Thek
    212
    2017-10-19 16:54:47

    찍어내는것 보단...

    고민해서 만드는게 더 빠르다고 봅니다..

    자사 솔루션이면 두말할거 없고

    si성 프로젝트,국가과제도

    결국 만들어 놓으면 커스텀,기능추가 거의 무조건 요구하게 되어있는데

    스파게티 만들어놓으면 뒤로갈수록 겉잡을수 없어서...

  • ilovegp
    2k
    2017-10-19 17:13:09 작성 2017-10-19 17:15:05 수정됨

    그런데 중요한건 처음에 어느정도 속도와 퀄리티를 조절해야 하는지 처음에 딱 알아보기 힘듭니다 아무래도 책임자 성향도 영향을 줍니다 기획 피엠이면 빨빨리  뽑아라 개발 피엠이면 소스질을 더 따지는거 같습니다 지금은 방향을 바꿔서 소스질을 올렸습니다만 처음 단추를 잘못 낀 느낌입니다 


    이부분은 고민을 더 해야 겠습니다 근데 현실에서 단타성 에스아이는 일정 못지키는 것이 더 위험하다는 생각이 듭니다

  • zip6656
    1k
    2017-10-19 18:01:41

    si에서 pm이 좋아하시겠어요

    매일퇴근전 wbs에 진척률 마킹하고 일일보고, 주간보고에 금주차주실적/계획 보고하고 통합테스트 일정 잡아놓고 회의실 잡아 현업들 다 불러모으는데...분석, 설계할 시간이 어디 있겠어요 ㅋ

    오류는 고치면 되고 무조건 빨리나와야 그걸로 만족하는거죠

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