개발자 분들에게

  • #3291798
    1 220.***.158.32 997

    남이 알아보기 쉬운 코드가 좋은 코드인가요?

    데이터 사이언티스트인데
    주 업무는 알고리즘 개발이지만
    효율적인 코드 작성또한 만만찮습니다

    그냥 빠르게 돌아가는 코드면 되지않을까요

    간단한 충고 말씀도 감사히 받겠습니다

    • CS 73.***.166.92

      종합해보면 유지보수가 쉬운 코드, 즉 수정이 쉬운 코드가 좋은 코드라고 생각합니다.

      유지보수가 쉬울려면
      – 본인이든 남이든 알아보기가 쉬워야되고
      – 모듈화가 잘 되어있어야하고
      – 마지막으로 버그가 없고 속도가 빨라야 애초에 유지보수를 안하겠죠?

      추가

      회사규모가 어느정도 인 곳인진 모르겠지만, 본인의 역할이 proof-of-concept 을 만드는 것이라면 지나치게 optimization에 신경쓰지마세요. premature optimization is the root of all evil 이라는 유명한 말이 있습니다.

    • Xxx 24.***.5.245

      효율적이면서 깨끗한 코드를 짜야 겠죠. 둘 다 놓칠 수 없어요.

    • dddd 67.***.123.84

      Ocam’s razor; 최대한 단순한 방법으로 가는게 길게 봤을 때 더 좋은 경우가 많습니다. 물론 정답은 없기 때문에 계속 시도하고 되돌리는 일의 반복이죠.

    • ㅁㅁ 136.***.20.45

      알고리즘 개발이 주업무시면… 코드를 깔끔하게 짜려고 노력하시되 너무 집착하실 필요 없습니다. 빠르게 도는것도 컨셉 수준에서 다른 알고리즘보다 효율적으로 돌면 되는거죠. 아이디어를 빠르게 구현하고 검증하는게 더 중요한 업무 아닌가요. 다른 말로 하면 다른 사람들보단 코드를 막 짜고 뒤처리에 신경 안 써도 되는 직업이라는 뜻이기도 합니다. 모든걸 다 할 수 있음 좋지만, 현실에서는 시간이 없죠.

    • 1 220.***.158.32

      주신 말씀들 모두 감사합니다!!

    • 108.***.113.213

      회사에서 보통 코드리뷰 하지않나요? 그게 아니라면 별로 코드자체는 팀프로젝트가 아니라는 것이죠. 효율적인 코드를 짜는것도 많은 트레이닝을 필요로 합니다. 그런트레이닝을 제대로 못받은 사람들하고 같이 개발하는것도 ……힘들죠. 코드를 받았는데 아주 너무 개인적인 스타일이 강하거나 지나치게 보기어렵거나 하면 짜증나죠. 그리고 그것보다도 그런 트레이닝을 제대로 못받은 메니져하고 일하면 이런거 조률을 못해주니까 짜증 제대로 납니다.

    • 자나가다 174.***.5.237

      그냥 돌아가게만 짜면 처음엔 편한데 나중에 개고생함
      스칼라 확장성 그리고 은닉성 뭘 글로벌로 할지 뭘 로컬로 할지 잘 플래닝 하삼

    • a 64.***.218.106

      코드는 남이 알아보기 쉬워야 하는데 그것은 코드 자체를 손대는게 아니라 커멘트를 많이 달아야한는것이다. 코드 자체는 사실상 기계어에 가까울 정도로 짧고 효율적으로 짜는게 가장 좋다. 빅오 노테이션은 반드시 참고해야한다. 다시 말하지만 사람이 읽기 쉬운 코드란 다름아닌 커멘트를 모든 라인에 전부 달아주는게 가장 이상적이다.

    • 345345 134.***.139.75

      좀 길게 쓰더라도 모듈화
      읽기 편하게

    • ? 64.***.28.249

      혼자 평생 해먹다가 폐기할 코드면 잘 돌기만 하면 충분한데…
      그 코드를 누군가랑 같이 수정할 일이 있다면… 읽기도 좋아야 합니다.

    • 211.***.121.135

      저도 데이터 사이언티스트인데.. 코드 잘 짜야 해요. git 커밋 메시지도 명확하게 해야하고. 저는 데이터 사이언티스트에서 개발 쪽 사이드 역량 늘리기 위해서 버둥버둥 하는데.. 돌아만 가는 코드 찍는 사람꺼는 결국 새로 다 손봐야 합니다. 돌아만 가면 된다는 식으로 짜는사람은 협업할때 말 안통하고 암 걸려요.

    • ㅇㅇ 73.***.16.133

      클린코드..
      사실 좋은 코드란 어느정도 정해져있다고 봅니다. 실제 업무에서 하는 일이 따지고보면 유명 알고리즘을 벗어나는 것들이 잘 없어요. 검색, 정렬등..
      만약, 단순한 코드들이 전체 코드에서 많은 부분을 차지한다면 그건 설계가 잘못된 거고. 유명 알고리즘에 대한 클린 코드 역시 수많은 개발자들이 토론하고 발전시켜서 어느정도의 정답이 있다고 봅니다. 그런 룰을 지켜서 코딩을 하면 해당 코드를 처음 보는 사람도. 아! 이부분은 정렬, 저부분은 탐색, 여기서 DFS하고 이거는 캐싱이구나.. 한눈에 팍팍 들어오죠.

      이런 유형의 코딩을 하지않고 본인만의 스타일로 코딩을 하면 한참을 읽어야 소스가 파악되는데 별로 바람직하지 않죠.