Frudy
6k
2020-10-09 20:27:02 작성 2020-10-20 13:14:30 수정됨
15
1332

정석을 이기는 방법은 없을거에요


저는 스타트업에서 react 프로젝트 웹개발을 혼자 맡고있어요.


react기초를, css기초를, typescript기초를,

중복코드를, 더 좋은 구조의 코드를 단련해서 개발시간을 줄이지


절대로 복붙해서 개발시간을 줄이진않아요.


복붙하고 제시간에 퇴근할바엔

야근해서 퀄리티를 높여요.


그렇게 근무한지 4개월이 지난지금, 만족스러워요.


이대로 의미있는 경력이 쌓이면

인생이 필거같은 느낌...


기초에 집중하니 남들처럼 고급기술(?)에 대해 아는게 없네요.


GraphQL나온지가언젠대...

NextJS는 또 뭐에요,


그래도 눈에보이게 코드퀄리티가 올라가고있으니

나중에는 분명 여유시간을 확보할수있을거에요.


저는 빨리만드는개발자보다,

잘만드는 개발자가 되고싶고,


빨리못만들어서 복붙만 평생하는 악순환겪을바엔 잘만들어서 빨리만들래요.


다들 즐거운주말보내세요.

0
  • 댓글 15

  • ISA
    3k
    2020-10-09 20:37:27

    화이팅 전 복붙을 하는 편이긴 하지만 (템플릿화 된 것들을

    빨리보다 잘만드는게 중요한거 맞아요.

  • Frudy
    6k
    2020-10-09 20:49:57

    근데사실 애매해요.

    저도 파일탬플릿, 자동완성은 또 애용해요.


    근데 로그인폼 만들때 아이디 비번 유효성검증하는 로직을

    게시글작성폼 만들때 복붙해서 고쳐서 쓰진않아요.


    대체로 더 작게 분리해보는 편이에요.

  • 라이라
    2k
    2020-10-09 20:55:04

    비슷한 프로그램이면 그누보드처럼 대부분의 기능은 찍어내고, 특별한 기능만 커스터마이징 하는 게 좋지 않을까요?

  • Frudy
    6k
    2020-10-09 20:57:59

    그러고보니 생각난건데~~


    로직을 복사하다보면,


    회원가입폼에 이름을 저장하는 변수 이름이 막

    title로 되어있기 쉽고


    불필요한 로직이 실행되기 쉽고,

    불필요한 주석이 붙어있기 쉽고, 그런거같아요.


    그것보다, 로직자체를 꿰고있어서

    직접 로직을 빠르게 짜는게 더 빨리만드는 경우도 있었어요.


    근데 뭔가 사내 코딩컨벤션같은거라던가,

    공통된 규칙을 준수하기에는

    파일탬플릿이 좋은거같아요.

  • Frudy
    6k
    2020-10-09 21:00:38

    음 저희는 그누보드안써요.

    직접 웹사이트를 만들어요.

  • ISA
    3k
    2020-10-09 21:18:46 작성 2020-10-09 21:19:25 수정됨

    잘 만든 코드 라는 건 결국 패턴화 되기 때문에 결국 수준이 오르기 전까지 복붙하기 마련이라...

    보일러 플레이트가 생기면 어지간해서는 그 구성대로 가죠.

    캡슐화 잘 된 코드면 결국 재사용성이 높기도 하니까요.

    글고 정형화 된 설계대로 모든 규모에 적합하진 않으니 그에 맞게 짜고나서는 거의 대부분 그 형식 그대로 유지하는거 같아요.

    쓸데 없다는게  정말 쓰잘데기 없는 부분들이 덜 분리 되고 제네릭 하지 못한건지 아니면 확장성이나 가독성 같은거나 최적화를 고려한 부분인지는 잘생각해야하는 듯

  • Frudy
    6k
    2020-10-09 21:38:50
    아무튼! 
    깔끔한 코드는 그만큼의 가치가있었어요
    결국 덕을 보게되더라구여
  • zepinos
    20k
    2020-10-10 00:21:39

    음...정석대로 하는게 가장 좋긴 한데, 지나쳐도 좋지 않다고 생각합니다.


    실제 제 주위에서...비유를 하자면 타언어 개발자에게 스프링으로 웹페이지 만드는걸 개발할테니 MVC 부분을 보라고 했더니 Servlet 명세부터 보는...그런 식의 너무 지나친 정석(?)을 추구하는 분이 계시더군요. 옆 섬나라 개발자들이 이런 성향에 가깝다고 들은 바가 있어서...좀 식겁했습니다. 물론 Servlet 부터 보는게 나쁘다는건 아닌데, 기업에서 일정이 촉박한 상태에서 그러면 안된다고 생각해서요. 뭐든 상황에 맞는 것도 필요하다고 생각합니다.

  • 돈까스
    4k
    2020-10-10 01:20:20 작성 2020-10-10 01:29:23 수정됨

    복붙도 개발의 정석 가운데 하나입니다. :)

    기존에 만들어 놓은 것을 재사용하는 아주 좋은 방법입니다.

    그 다음 단계를 안해서 문제에요.

    중복 제거, 코드 일관성 유지, 의도를 명확하게 드러내는 코드 등의 기준을 적용해서 정리하는 일을 안해서 문제인거죠.


    복불하는 행위 자체를 미워하지는 마세요.

  • Frudy
    6k
    2020-10-10 07:51:38

    우려하시는부분은 괜찮아요.

    실제로 비슷하게, api경로 고민이생겨서


    (uri는 전부 소문자만써야되?! path만? 아님 전부?!)


    uri공식문서를 찾아본적이 있었어요.

    RFC xxxx가 공식문서? 느낌이었던거같은데

    한 30분을 봐도 안적혀있는거에요


    그래서 보류하기로했어요.


    ㅜㅜㅜㅜㅠㅠ


    CSS도... 좀더 구체적인 지식이 필요해서 명세를 한번씩 도전해보는데

    언제나 결과는 좋지않아서 보류됬어요.


    로이필딩 선생님이었나 REST API 논문쓴거 찾아보려다 보류하고...


    생각보다 그렇게 제가 실력이좋지않으니

    찾아볼수있는것도 많지않아요...

  • Frudy
    6k
    2020-10-10 07:53:46
    돈까스


    넵 알겠습니다.
  • seokjoon2
    486
    2020-10-10 09:53:26

    전반적으로 논지는 맞지만, 모든 사례에 맞다고 장담할수는 없죠. 개개인이 초점을 맞추는 부분이 다를 수 있습니다.

    프로젝트 단위 계층에서 코드에 집중하는 사람 관점에서는 다릅니다. m개 모듈을 조합해서 n개 구현을 만드려고 하려고 하지 구현 개수와 모듈 개수가 동일한건 공산품으로 볼수 없죠.

  • 만년코더
    8k
    2020-10-10 23:01:16

    뭐라그래야되지 케바케가 심한 부분이긴한데요.

    레고로 배를 만드는데 레고 블럭까지 다만들필요는 없지 않을까요?

    심지어는 레고로 완성된 선체를 가져다가 고쳐서 만들 수도 있구요.

  • Frudy
    6k
    2020-10-10 23:12:29

    그부분은 상황에 맞게 판단해요.


    제가 실력있었으면 react라는 프레임워크를 직접 만들어보거나,

    못해도 프레임워크 원본소스를 살펴봤을거에요.

    (블로그 보면 react 원본소스 분석한거 올리는 정말똑똑하신분들 가끔 보여요)


    근데, react 원본소스를 이해하면서 기간안에 제품을 제출할 가능성이 현재 없어요.

    그래서 이건 포기했고, react에서 제공하는걸 사용하되

    그들의 의도에 맞게 사용할 수 있도록 공식문서를 보고있죠.


    그대신에, react 프레임워크로 구현된 UI들은, 직접 구현하고있어요. 남이 만든거 최대한 덜써서요.

    왜냐하면 기간안에 제품을 제출할 가능성이 높아보였기 때문이에요.


    물론 그중에서도 차트 그리는 것은, 어쩔수없이 차트라이브러리 사용합니다.

    제가 직접 수학기초부터 통계까지 다 배우고, svg 애니메이션을 전부 이해해서 차트를 직접 그려서

    기간안에 제품을 제출할 가능성은 없으니까요.


    판단 기준은 제출 기한과 제품 퀄리티에요.


    저는 그 안에서, 최대한 직접 만드는 방법을 택하고있습니다.

  • Frudy
    6k
    2020-10-10 23:15:06

    여기 회사에서 요구하는건 대체로 이래요.

    개발자 가 어떤기술을 써서 만들던 상관하지않아요. 아래의 조건만 맞는다면요.


    1. 기한안에 만들고

    2. 기능이 버그없이 돌아가며,

    3. 너무 느리지않고,

    4. 추가 요청기능이 있을 때 확장이 가능해야하고,

    5. 유지보수가 가능해야해요. (= 시장에서 널리 쓰이는 기술일 경우 개발자가 나가더라도 새로 유지보수할 사람 뽑기가 쉬운데, 제가 막 한국에서 안쓰는 기술로 만들면 이부분이 문제가 되요)


    이것도 판단기준에 포함되요.

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