소프트웨어 개발자의 저기능
하나씩 살펴보겠습니다.
유산에 대한 동정
이것은 매우 명백한 것 같지 않습니까?
초보자로서, 내가 새로운 코드 라이브러리에 접촉했을 때, 나는 의식적으로 반응할 것이다.나는 다음과 같은 사고방식에 근거하여 판단하고 사고할 것이다.
소프트웨어 개발에는 커다란 인적 요인이 있다.코드를 읽거나 이해할 때 자주 이 점을 소홀히 한다.예를 들면 다음과 같습니다.
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
그는 나의 대답을 선택하고 완전한 영상을 만들었다. 나는 이것이 내가 할 수 있는 것보다 더 좋다고 생각한다.
읽어주셔서 감사합니다!나는 더 많은 사람들이 이런 것들을 이해할 수 있기를 바란다.
나는 항상 이런 품질을 어떻게 테스트하는지 알고 싶다깊이 생각할 만하다😀.
Reference
이 문제에 관하여(소프트웨어 개발자의 저기능), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/varenya/under-appreciated-skills-of-a-software-developer-39jn텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)