소프트웨어 개발자의 저기능

이번에는 내가 다른 개발자들에게 발견한 기능들을 이야기하고 싶었다. 나는 이 기능들이 매우 중요하다고 생각했지만 과소평가되었다.
하나씩 살펴보겠습니다.

유산에 대한 동정

이것은 매우 명백한 것 같지 않습니까?
초보자로서, 내가 새로운 코드 라이브러리에 접촉했을 때, 나는 의식적으로 반응할 것이다.나는 다음과 같은 사고방식에 근거하여 판단하고 사고할 것이다.

그들은 왜 이걸 사용합니까?ugh

왜 여기서 이 프레임을 사용합니까?

너무 복잡해 보이는데?

너는 대의를 이해했니?하지만 사실 내가 최초의 개발자 자리에서 그것을 만들었다면 더 잘하지 못했을 것이다.시간과 장소의 제한이 이런 코드 라이브러리를 초래할 수도 있다.
소프트웨어 개발에는 커다란 인적 요인이 있다.코드를 읽거나 이해할 때 자주 이 점을 소홀히 한다.예를 들면 다음과 같습니다.

예산 및 시간 제한 고객

선호도가 다른 개발자

문제를 어떻게 해결하는지에 대해 서로 다른 견해를 가진 팀

서로 다른 기술 스택

비교

건설 프로젝트에 사용되는 도구

아마도 더 많은 소프트웨어 개발 프로젝트가 있을 것이다.
TLDR:

Don't judge too quickly.

코드 읽기 및 이해

나는 코드를 실제로 작성하는 것이 아니라 코드를 읽고 이해하는 데 대부분의 시간을 쓴다.
잘 쓰기 위해서는 코드 라이브러리를 잘 읽고 이해해야 한다.왜 그런지 알고 싶겠지?
모든 코드 라이브러리는 자신의 리듬/풍격을 가지고 있다.그리고 기존 코드 라이브러리에 존재하는 스타일을 따라야 합니다.
다음 예를 살펴보겠습니다.

function createUser({ username, password }) {
  return {
    getUserName: function() {
      return username;
    },
    getPassword: function() {
      return password;
    },
  };
}

class User {
  constructor(username, password) {
    this.username = username;
    this.password = password;
  }

  getUserName() {
    return this.username;
  }
  getPassword() {
    return this.password;
  }
}

둘 다 서로 다른 균형으로 비슷한 목표를 실현했다.최초/주요 개발자는 상술한 어떤 것도 더 좋아할 수 있다.우리는 대국을 명심하고 풍격을 견지해야 한다.
만약 이렇게 하지 않는다면, 가독성의 차이는 매우 크다.
TLDR:

Measure twice, cut once.

코드의 기능을 이해하는 것이지 그것의 외관이 아니다

프로그래밍을 할 때, 많은 때에 네가 본 것은 네가 얻은 것이 아니다.
JS가 좋은 예다.

function User(username) {
    this.username = username;
}

만약 당신이 JS에 익숙하지 않다면, 이것은 함수 성명이라고 생각할 것이다.실제로 ES6 문법이 등장하기 전에 우리는 이렇게 정의class했다.
그것은 보기에는 함수처럼 보이지만 실제로는 구조 함수이다.이런 오도는 언어 차원에서도 나올 수 있고 실현 차원에서도 나올 수 있다.한 사람은 반드시 양자를 잘 이해해야 한다.
TLDR:

if it looks like a duck, doesn't mean it is a duck.

언제 행동할지 알다

분석 단계에 빠지기 쉽다.한 문제를 해결하는 데는 여러 가지 균형 방법이 있다는 것을 감안하면 이 함정에 빠지기 쉽다.
이것이 바로 리더십이 작용하는 곳이라고 생각합니다. 왜냐하면 일이 최종적으로 문제가 발생할 때 누군가가 결정을 해야 하고 책임을 져야 하기 때문입니다!

“You can never know everything, and part of what you know is always wrong. Perhaps even the most important part. A portion of wisdom lies in knowing that. A portion of courage lies in going on anyway.”
—The Eye of the World, Robert Jordan

간단하기는 어려워요.

혼란은 사물의 자연 상태다.만약 네가 내가 앞서 언급한 모든 것을 고려한다면, 시간의 추이에 따라 복잡도가 얼마나 증가할지 상상할 수 있을 것이다. 특히 소프트웨어에서 소프트웨어에서 변경하는 비용이 무고하게 줄어든 것 같다.
만약 우리가 이 함수에 변수 하나만 추가한다면 어떤 문제가 있습니까?
대답:

그렇다면 당신의 코드 라이브러리에는 당신이 빠르게 읽고 이해하며 정상적으로 일할 수 있는 것이 있습니까? -이것은 매우 지루하지만, 이것은 네가 방금 목격한 가장 멋진 일이다

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Edsger W. Dijkstra”

소프트웨어에서 단순성이 언급될 때마다 Rich Hickey의 연설에 참여하려고 합니다.
Simple Made Easy

구조보다는 공작물에 더 관심이 많아요.

위의 강연에서 나는 다시 리치 히키에게서 이 점을 배웠다.Mattias Peter의 트위터 게시물이 있습니다.

mpj💛

당신은 프로그래머의 관건적인 품질이 무엇이라고 생각합니까?10배가 넘거나 뭐가 되기 위해서가 아니라 기분이 좋아지기 위해서, 직업적으로 잘하기 위해서다.
2017년 4월 22일 오전 7:55
나는 대답했다.

발렌시아
@ 발렌시아 90

누가 구조가 아니라 인공제품에 더 관심이 있겠는가.
2017년 4월 22일 오전 11:14
그는 나의 대답을 선택하고 완전한 영상을 만들었다. 나는 이것이 내가 할 수 있는 것보다 더 좋다고 생각한다.
읽어주셔서 감사합니다!나는 더 많은 사람들이 이런 것들을 이해할 수 있기를 바란다.
나는 항상 이런 품질을 어떻게 테스트하는지 알고 싶다깊이 생각할 만하다😀.