개발자 원칙 (박종천 외 8인)

 

덕업일치: 본인이 좋아하는 취미와 직업이 일치된다는 뜻

GPAM: Goal, Plan, Action, Measure

 

더닝 크루거 효과(Dunning–Kruger effect)는 인지 편향의 하나로, 능력이 없는 사람이 잘못된 판단을 내려 잘못된 결론에 도달하지만, 능력이 없기 때문에 자신의 실수를 알아차리지 못하는 현상을 가리킨다.

 

쓸모 있는 사람 = 전문가 = 역량 = 전문 역량 + 일반 역량

쓸모 있는 사람 = 일의 가치 * 전문가 = 일의 가치 * (전문 역량 + 일반 역량)

 

백엔드 엔지니어의 실력은 얼마나 많은 오류와 장애를 만나고 이를 해결했는지 여부에 따라 갈린다.

1. 소스 코드 레벨에서 이해하자

2. 지식을 글로 공개하라, 결과물로 남기는 것이 중요, 사람의 기억력은 믿을 수 없고, 제대로 이해했다는 착각을 갖을 수도 있음

 

네이글 알고리즘

HashMap 성능 개선 (java7 -> java8): 선형리스트 & 트리구조

 

속도가 빠를 수록 좋다고 생각합니다.

틀렸다는 응답이 더 늦을 겁니다.

입력한 값이 어디까지 같은지 유추 가능

같은 시간에 응답을 주는 방법으로 구현

 

아무리 좋은 학습 방법이라도 나한테 안 맞으면 쓸모가 없는 거라고 생각합니다.

깃허브나 블로그에 기술 블로깅을 안 하는 분이 없을 정도입니다.

제안을 드리는 것이 뒷북일 수 있겠다 생각이 드네요.

독서백편의자현: 학문을 부지런히 갈고 닦으면 저절로 성취할 수 있다는 비유적 표현

오류를 통해 새로운 것을 배우고, 호기심을 충족시키는 학습이 즐거움이 되길 빕니다.

 

늘 시간과 사람과 돈이 부족

한번 만들어지고 나면 아주 오랫동안 사용

 

디자인이란 무엇인가

계획을 세움

실제적인 계획을 세우고 구체적으로 도면을 그려 명시하는 일

 

스티브 잡스는 소비자는 제품을 보여주기 전까지 자신이 뭘 원하는지 모른다.

 

최대한 꼼꼼하게 요구사항 기술

요구사항 명세

정확

모호하지 않음

완결적

일관적

안정성

증명가능

수정

 

표준화된 도구가 없어서 사업가/기획자/개발자가 모두 고통을 받습니다.

 

기능: 기능이 된다 안된다.

성능

유지보수

비적

 

외우고 잘 기억하는지 확인하는 게 바로 시험

암기해서 시험지에 있는 답을 찾아내고

아는것 vs 모르는것

 

아는것

익숙한 것

안다고 착각하는 것

모른다고 알게 된 것

모르는것

 

고등학교까지는 무조건 외워서 시험을 봐야하는 과목이 많았습니다.

지식을 나만의 암묵지로 만들어야 합니다.

 

분해하고, 관련 지식을 찾아서 위에서 아래로 탐색

위에서 아래로, 아래서 위로 반복해야

 

내가 무언가를 잘합니다.

나에게 맞는 방법으로 성취감

결과가 같아도 과정은 다릅니다.

 

채용과정에 코딩 테스트를 많이 활용합니다.

경험이 늘어나고 경력이 쌓일수록 시야가 넓어집니다.

 

사람이 완벽하지 않듯이 개발 과정 역시 완벽하지 않습니다.

끊임없이 실수를 합니다.

자동화하고, 도구화하고, 다음 단계로 학습하며 나아가면 되는 겁니다.

 

학습할 때도, 일을 할 때도 실수를 두려워하지 말라는 의미

누구나 실수할 수 있다고 가정하고,

최종 릴리즈 되기 전에 실수를 찾아낼 수 있는 안정적인 흐름을 만들어야 합니다.

수정하는 것도 개선이고, 협업 과정에서 개발 프로세스 병목 지점을 찾는 것도 개선입니다.

 

반복해서 하는 작업이 있다면 액션을 자동화하거나

자동화하는 방식을 개선하거나.

 

해결책을 여러 개 마련하세요.

고가용성

 

공유하기 시작과 실천은 어렵지 않습니다.

블로그에 공유하는 건 어떤가요?

 

개념+방식

코딩+사용법

알고리즘+지식

원리+패턴

스택오버플로+데모

깃허브+샘플코드

 

말로 설명하고 의견을 받는 방식도 좋습니다.

자신의 코드가 의도한 자신의 생각은 꼭 설명할 수 있어야 합니다.

 

제어할 수 없는 것에 의존하지 않기

제어할 수 없는 것에 집중하다 보면 그 무엇도 해결하지 못할 수 있습니다.

제어할 수 있는 것에 의존하고 집주애향만 어던 일과 상황을 만나더라도 앞으로 전진할 수 있습니다.

 

제어할 수 없는 것을 멀리하고,

이미 발생한 사건, 결정권이 없는 일 등은 제어할 수 없습니다.

이들에 의존해선 안됩니다.

소프트웨어를 설계한다면 제어할 수 있는 속성에 항상 의존하게 설게해야 하며,

현실 세계의 문제라면 현재의 사건과 환경을 어떻게 하면 더 유리하게 바라볼 수 있는지 고민하고 행동으로 옮겨야 합니다.

 

켄트 벡: 일단 동작하게 만든 다음 더 좋게 만들어라.

요구사항을 충족하라

더 좋게 만들어라

더 좋은 것? 더 좋은 코드? 더 좋은 설계?

가독성, 성능, 유연성

가독성이 좋은 코드는 좋은 관행을 잘 따릅니다. (규칙)

예외를 던지는 것이 좋다면 동료들을 설득해서 기존 코드도 모두 바꿔야 합니다.

단순 반복이나 중복 코드가 아닌 패턴의 확장으로 자연스럽게

 

함축적, 명시적으로

삭제해야할 코드를 코멘트로 감싸서 남겨두지 마세요.

필요하면 언제든지 복구할 수 있으니 과감히 삭제

파레토 법칙 (80/20)

 

언제나 발견했을 때보다 깨끗하게 해놓고 캠핑장을 떠나라.

바퀴를 새로 발명하는 일의 좋은 점은 둥근 바퀴를 얻을 수 있다는 점입니다.

 

개발: 달리는 기차의 바퀴 갈아끼우기

멈추는 것보다는 천천히 가는 편이 낫다.

속도를 줄이자고 요청

 

바퀴를 다시 발명하지 마라

지금의 밥값

미래의 몸값

 

논리적인 글쓰기는 훈련으로 향상할 수 있는 기능

많이 쓸수록 더 잘 쓰게 된다.

글쓰기 근육을 만드는 유일한 방법은 쓰는것이다.

여기에 예외는 없다.

유시민의 글쓰기 특강

 

책과 시간만 있으면 되지만,

온전히 이해하려면 책 속에 포함된 문장(텍스트)만으로는 부족

글쓴이의 의도와 배경을 포함한 문장 해석에 필요한 부가적인 정보인 컨텍스트를 이해해야 한다.

 

컨텍스트는 꼭 필요한 코멘트입니다.

지름길을 알려주는 것만으로도

컨텍스트를 찾아 헤매는 시간과 수고와 오해를 덜어줄 수 있습니다.

 

코드 읽기 연습을 많이 해서 안목(코딩근육)을 키우자