tttkmvd
404
2019-05-06 02:23:18
9
1189

코딩을 어떻게 해야 실력이 늘까요


제가 하는 방법은 구현하고자 하는 것을 일단 인터넷으로 검색한 다음

그 코딩으로 대충 뼈대를 잡습니다. 그러고나서 뺄건 빼고 제 입맛에 맞게 코딩을 하죠.

그 중에 구현해야 하는 것 중에 아예 제가 모르는 것은 인터넷에 쓰인 코딩을 그대로 적용시킵니다.


이게 제 스타일인데... 이러면 안되나요?

어떻게 해야 실력이 늘 수 있는지 조언 부탁드립니다.

0
1
  • 댓글 9

  • fender
    13k
    2019-05-06 08:43:14 작성 2019-05-06 08:44:06 수정됨

    실력을 쌓는데 방해가 되는 접근 방법이라고 생각합니다. 체계적으로 공부하고 기초부터 조금씩 완전히 이해하는 내용을 늘여나가다 보면 나중엔 전체를 파악할 수 있지만 이해없이 복사 붙여넣기에 의존하면 경력이 쌓여도 '통밥'만 늘게 됩니다.

    모르는 내용을 검색하고 예제를 찾는 건 좋지만 적어도 코드에 적용할 때는 완전히 내용을 이해하도록 노력하는 것이 바람직합니다.

    0
  • mirheeoj
    7k
    2019-05-06 09:28:41

    이해없이 코드를 복붙해 쓰시면.. 


    - 갖다 쓴 코드에 문제가 생겼을 경우 이를 찾아내거나 고치기가 매우 힘이 듭니다. 

    - 라이센스 면에 있어서 확신을 가지기가 어렵습니다. 무단 펌질한 코드가 워낙 많기 때문입니다. 

    - 해당 코드 안에 있는 배울만한 부분들을 싸그리 놓치게 됩니다. 

    0
  • 아이두
    77
    2019-05-06 12:49:25 작성 2019-05-06 12:51:10 수정됨

    지금처럼 구현을 하시지만 앞에 단계 하나를 추가하세요, 가장 먼저 테스트 코드를 작성하는 겁니다.

    이렇게 되면 일단 클래스 설계방식이 바뀌게 될거에요 인터페이스 작성에 신경을 쓰게 될거에요 안그러면 테스트 코드가 계속바뀌게 되니깐요, 테스트를 쉽게 짜도록 클래스가 세분화 될꺼고요 그러다 보면 클래스가 역할별로 나누어지게 됩니다. 그러다보면 자연스럽게 oop 기본 원칙을 따르게 되더라고요. 

    테스트를 먼저 작성 했으니 코드 커버리지는 당연 100%가 될거고요 그럼 내부 로직 변경이 매우 안전해 지죠 내부를 맘대로 변경해도 테르트 코드가 통과되면 로직에는 문제가 없다는 확신이 생기죠, 그럼 내부를 맘대로 리팩토링이 가능해 집니다. 자주자주 이상한 부분 발견때마다 수정하시면 되죠. 코드 가독성이 좋아지도록 마구마구 수정하세요

    결론은 테스트코드 작성 방법을 공부하시고 테스트 코드 작성을 시작하세요

    0
  • March
    2k
    2019-05-06 14:40:15

    코딩실력은 경험과 센스입니다.

    일관성있고 발생가능한 상황을 미리 예측해 구조적인 뼈대를 만드는 생각이 중요하다고 봐요

    0
  • Mommoo
    788
    2019-05-06 17:09:41

    쉽게 생각해서, 본인이 하나부터 열까지 혼자 코드를 짜보는게 실력 늘리는데 직빵입니다.

    물론, 모르는 부분을 배껴오거나 참고는 할 수 있지만 최후의 힌트처럼 사용해야 하는 부분이지 전반적인 개발을 올려주신 방법대로 하면 실력 안늡니다.

    만약 간단한 로직 자체도 아직 못짤정도로 어렵다면, 프로그래밍 언어 책 하나 골라, 연습문제를 풀면서 연습해야할 단계라 할 수 있지요.

    0
  • 키류
    249
    2019-05-06 20:06:32
    개인적으로 안 좋습니다. 어느 전도 레벨까지는 업무 상 커버가 가능하겠지만, 나중에 경력이 앃여 혼자 코어를 개발시킬 때, 식은 땀 흐를거에요. 
    0
  • zip6656
    1k
    2019-05-06 20:57:36 작성 2019-05-06 20:58:50 수정됨

    인터넷보고 구조를 잡았는데 인터넷에 상세하게 구현 되어있지 않으면 어떻하실려고....

    또한 인터넷 안되는 공공이나 일부 대기업쪽 들어가면 어떻하실려구...

    이길로 가다 안되서 설계바꿔 저길로 가다 또안되서 설계틀고 다른길로 가다 보면...

    그러니 뒤죽박죽 엉망칭창 좌충우돌 중구난방 소스산출물이 됩니다

    그리고 인수인계받은 유지보수 개발자는 SI를 욕하죠. 

    어딜가든 이와 비슷한 상황이죠

    0
  • sinho0689
    117
    2019-05-15 03:36:46

    뼈대하는게 무엇인지 알수는 없지만... 요새는 다 프레임워크 기반이니까

    적어도 프레임워크에서 무엇을 지원하고 어떤 라이브러리/api들과 연동이 수월한지 기술조사가 필요합니다.(사실 일단 가능한 범위안에 있는 프레임워크/라이브러리는 docs, 테스트 코드 돌려보면서 모조리 머리속에 쑤셔넣은 다음에 가능한지 아닌지를 재보고 설계를 해야됩니다.. 엄청 짜증나죠... 그래도 나중에 뺑이치면서 custom훼이크코드를 만들고 싶지 않다면 머릿속에 쑤셔넣어야됩니다..)


    그 다음에는 혼자 개발할수는 없으니까 A기능 시스템은 누가 어떻게 만들고 B기능 시스템은 누가 어떻게 만들고 서로 통신은 어떻게 하고 각자 개발한건 어떻게 검증하고 등등...에 대해서 ㅈㄴ 회의를 하죠... 테스트 예상 QA리스트 및 예상 문제점(지금은 다 알 수 없음. 개략적인것만), 예상 QA 케이스, 우리가 이걸 할 수 있냐없냐 얼마나걸리냐, 프로토타입-베타버전-정식버전 런칭에 필요한 최소기능 등등...


    사실 제가 지금 이짓을 해야되서 머리가 아파서 쓰고 있습니다 ㅋㅋ

    다들 초기설계개발 어떻게 하시나요 ㅋㅋ? 지금까지 개발한 것 중에서 가장 복잡한 시스템이거든요..

    개발자3명이서 쇼핑빅데이터 기반 쇼핑정보추천서비스 앱 개발중입니다..

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