분류 기타

모든 개발자가 조기에 배워야 할 것

컨텐츠 정보

  • 조회 191 (작성일 )

본문

개발자는“코드 라인”이 무엇을 의미하는지에 대한 많은 미친 이론을 들을 수 있습니다. 그들 중 누구도 믿지 마십시오. 코드 라인은 의사 결정을 기반으로 하는 어리석은 지표입니다. 아주 드문 경우지만 그것은 당신에게 무언가를 말하고, 다른 모든 경우에는 아무것도 말해주지 않습니다. 코드 라인을 사용하여 결정을 내리는 것은 페이지 수별로 책의 품질을 평가하는 것과 같습니다.


https://stackoverflow.blog/2019/08/07/what-every-developer-should-learn-early-on/ 


일부는 응용 프로그램에 코드 줄이 적을수록 더 읽기 쉽습니다. 이것은 부분적으로 만 해당되며, 읽을 수 있는 코드에 대한 내 메트릭은 다음과 같습니다.

  • 코드는 일관성이 있어야 합니다
  • 코드는 자기 설명적이어야 합니다
  • 코드는 잘 문서화 되어야 합니다
  • 코드는 안정적인 최신 기능을 사용해야 합니다
  • 코드는 불필요하게 복잡하지 않아야 합니다
  • 코드가 성능이 좋지 않아야 합니다 (의도적으로 느린 코드를 작성하지 마십시오)

코드 라인 수를 줄이면 그중 하나를 방해하는 것이 문제가 됩니다. 실제로, 그것은 거의 항상 간섭 할 것이고 따라서 거의 항상 문제입니다. 그러나 위의 기준을 충족하기 위해 노력한다면 코드는 계산할 필요 없이 완벽한 라인 수입니다.


언어는 "나쁜"반드시 "좋은"또는 아니다


disliked 


PHP를 제외하고 농담입니다. 출처


나는 사람들이 항상 이런 말을 하는 것을 본다 :

  • 성능 때문에 C가 X보다 낫습니다.
  • 간결함 때문에 파이썬이 X보다 낫습니다.
  • 하스켈은 X보다 낫다.

언어 비교가 한 문장으로 줄어들 수 있다는 생각은 거의 모욕적입니다. 그들은 포켓몬이 아닌 언어입니다.


오해하지 마십시오. 언어마다 분명히 차이가 있습니다. 단지 "사용할 수 없는 "언어가 거의 없다는 것입니다 (구식 / 죽은 언어는 많지만). 각 언어마다 고유 한 장단점이 있습니다. 이와 관련하여 언어는 도구 상자의 도구와 유사합니다. 드라이버는 망치로 할 수 없는 일을 할 수 있지만 망치보다 망치가 더 좋다고 말할 수 있습니까?


(분명히 망치가 더 낫다)


언어 평가 방법에 대해 이야기하기 전에 무언가를 명확하게 하고 싶습니다. 언어 선택이 실제로 중요한 경우는 거의 없습니다. 일부 언어에서는 분명히 할 수 없는 일이 있습니다. 프론트 엔드 코드를 작성하면 언어를 선택할 수 없습니다. 성능이 중요하고 X 언어가 그다지 중요하지 않은 특정 상황도 있습니다. 이러한 상황은 매우 드믑니다. 일반적으로 언어 선택은 일반적으로 프로젝트에서 가장 중요한 문제 중 하나입니다.


여기에 당신의 언어 선택을 지시해야 한다고 생각하는 핵심 측면 (순서대로)이 있습니다 (포켓몬 통계).

  • 사용 가능한 온라인 리소스 밀도 (StackOverflow 밀도)
  • 개발 속도 (vroom vroom)
  • 버그 발생 가능성 (eeek)
  • 패키지 생태계의 품질과 폭 (예 : npm, 품질이라고 함)
  • 성능 특성 (더 많은 점)
  • 상속 가능성 (죄송합니다)

손에서 벗어난 강력한 커플 링도 있습니다. 데이터 과학 분야에서 일하는 경우 현실적으로 Python, R 또는 Scala (아마도 Java)를 사용해야 합니다. 취미 프로젝트 인 경우 가장 행복한 것을 사용하십시오. 내가 협상 할 수 없는 규칙은 하나뿐입니다. StackOverflow에서 직접 해결되는 대부분의 문제가 없는 언어는 사용하지 않습니다. 내가 해결할 수 있는 것이 아니라 시간의 가치가 없습니다.


다른 사람의 코드를 읽는 것은 어렵다 


다른 사람들의 코드를 읽는 것은 어렵습니다. Robert C. Martin은 "Clean Code"에서 이에 대해 이야기합니다.


“실제로 읽고 쓰는 데 걸리는 시간의 비율은 10 대 1을 넘습니다. 우리는 새로운 코드를 작성하려는 노력의 일환으로 오래된 코드를 지속적으로 읽고 있습니다. … [그러므로 읽기 쉽게 만들면 더 쉽게 쓸 수 있습니다. "


오랫동안, 나는 다른 사람들의 코드를 읽는 것에 빨랐다 고 생각했다. 시간이 지남에 따라 거의 모든 프로그래머가 매일 어려움을 겪고 있음을 깨달았습니다. 다른 사람의 코드를 읽는 것은 거의 외국어를 읽는 것처럼 느껴집니다. 작가의 프로그래밍 언어 선택에 익숙하더라도 다양한 스타일과 아키텍처 선택에 맞게 조정해야 합니다. 또한 저자가 일관되고 신뢰할 수 있는 코드를 작성했다고 가정합니다. 이것은 극복하기가 정말 어렵습니다. 내가 찾은 몇 가지가 LOT에 도움이 되었습니다.


다른 사람들의 코드를 검토하면 코드 읽기 기술이 엄청나게 향상됩니다. 지난 2 년 동안 저는 Github PR을 상당히 검토했습니다. 각 PR마다 다른 사람들의 코드를 읽는 것이 조금 더 편안하다고 느낍니다. Github PR은 이러한 이유로 특히 훌륭합니다.

  • 언제든지 연습 할 수 있으며, 기여하고 싶은 오픈 소스 프로젝트를 찾으십시오.
  • 범위가 지정된 컨텍스트 (구동 특징 또는 PR 버그)에서 읽기 연습.
  • 필요한 세부 사항에 주의를 기울이면 각 라인을 평가해야 합니다.

다른 사람들의 코드를 읽는 데 도움이 되는 두 번째 해킹은 조금 더 독특합니다. 그것은 내가 고안 한 기술이며 외국 코드베이스에서 편안하게 느끼는 데 걸리는 시간을 실제로 줄였습니다. 읽고 싶은 코드의 스타일을 살펴본 후 먼저 vi를 열고 프로젝트에서 사용하는 스타일로 코드를 작성하기 시작합니다. 새로운 스타일로 코드를 작성하면 읽기 능력도 향상됩니다. 실제로 경험 한 것처럼 스타일이 덜 외로워집니다. Github에서 임의의 프로젝트를 탐색하는 경우에도 신속하게 수행하겠습니다. 사용해 보십시오.


"완벽한"코드를 작성하지 마십시오 


팀 작업을 시작하기 전에 4 년 동안 "고독한 늑대"개발자였습니다. 그 당시 대부분의 경우 업계의 모든 프로그래머가 완벽한 코드를 작성했다고 가정했습니다. “완벽한”코드를 작성하기 전에 시간과 노력의 문제라고 생각했습니다.


내가 정말로 염려했던 느낌이었습니다. 팀에 합류 한 후에는 아무도 "완벽한"코드를 작성하지 않았다는 것이 분명해졌습니다. 그러나 시스템으로 들어가는 코드는 거의 항상 "완벽했습니다". 답은 코드 검토입니다.


저는 정말 훌륭한 엔지니어 팀과 함께 일합니다. 이들은 돈을 살 수 있는 가장 유능하고 자신감 있는 프로그래머 중 일부입니다. 우리를 포함한 모든 팀원 (나 포함)은 검토되지 않은 코드의 커밋을 제안한 경우 완전히 공황 발작을 일으킬 것입니다. 당신이 다음 빌 게이츠라고 생각하더라도 실수를 할 것입니다. 나는 논리적 인 실수 조차 하지 않고, 오타가 있거나, 문자가 빠졌습니다. 당신의 두뇌가 조율 되고 결코 들리지 않는 것들. 또 다른 눈이 필요한 것들.


세부 사항에 주의를 기울이고 자신의 작업을 비판하려는 다른 사람들과 함께 일하도록 노력하십시오. 청각 비판은 처음에는 어렵지만 개선을 위한 유일한 일관된 방법입니다. 코드 검토 중에 방어 적이 지 않도록 최선을 다하고 절대로 개인적으로 의견을 말하지 마십시오. 당신은 당신의 코드가 아닙니다.


코드를 검토 할 때 저자가 내가 잘 모르는 선택을 한 경우 Google에서 해당 선택이 강력한 대중 의견과 다른지 즉시 확인합니다. 대중의 의견이 항상 옳다는 것이 아니라 대중의 의견이 기본 선택이라는 것입니다. 누군가가 대중적인 선택을 채택하지 않기로 결정했다면, 그것이 정당하다는 것을 알고 싶습니다. 코드를 검토 할 때는 결정을 내린 근거를 이해하는 것이 중요합니다. 또한, "초보자 마음"으로 동일한 문제를 살펴보면 결코 다시는 보지 못했던 것들을 포착 할 수 있습니다.


프로그래머로 일한다고 해서 하루에 8 시간의 프로그래밍 시간을 의미하는 것은 아닙니다 


이것은 매우 일반적인 질문이지만 사람들은 결코 명확한 대답을 하지 않는 것 같습니다. 평범한 개발자 또는 "훌륭한"개발자는 매일 코드를 작성하는 데 얼마나 걸립니까?


하루에 4 시간 이상 코드를 작성하는 사람은 거의 없습니다. 


이에 동의하지 않는 사람들은 규칙의 예외이거나 더 잘 대우해야 하는 회사에서 일합니다. 프로그래밍은 정신적으로 소모적이고 집중적 인 작업입니다. 누구나 하루에 8 시간, 일주일에 5 일 동안 코드를 작성하는 것을 기대하는 것은 전적으로 비합리적입니다. 마감 시한을 맞추거나 스트레칭을 위해 약간의 추가 시간을 가져야 하는 경우는 드물지만 그 사이는 거의 없습니다. "희귀"라고 할 때, 나는 거의 결코 의미하지 않습니다. 나쁜 계획 / 부족으로 인해 자신을 학대하고 초과 근무를 하는 직장을 용납하지 마십시오.


기록 상으로는 하루 8 시간 동안 적극적으로 프로그래밍 하는 것이 회사에 가장 큰 도움이 되지 않습니다. 상사는 그 경우라고 생각할 수도 있지만, 근시안적이며 생산성과 정신 건강에 대한 장기적인 영향을 무시합니다.


명확하게 말하면, 하루에 네 시간 만 일하라고 제안하지는 않습니다. 다른 4 시간은 일반적으로 가장 잘 소비됩니다.

  • 업무 관련 주제와 비업무 관련 주제 연구
  • 동료와 작업에 대해 토론
  • 자신의 일로 어려움을 겪고 있는 동료를 돕기
  • 향후 작업 계획
  • 코드 리뷰
  • 회의

또한 낮에는 규칙적인 휴식을 취하고 운동을 하십시오 (잠깐만이라도). 정신 피로에 대한 운동의 이점은 잘 문서화 되어 있습니다. 개인적으로 초점을 맞추기 어려운 경우 운동이 특히 도움이 된다는 것을 알게 되었습니다.


이것들은 그들이 순수한 이론 대신에 대학에서 가르치고 싶은 것들 중 일부입니다. 이 글을 쓰는 과정에서 나는 다른 많은 항목을 생각해 냈지만 다음 게시물에 올 것입니다!