Colin Kang

눈에 보이지 않는 적이 더욱 무섭다.

눈을 감아야 보이는 것들이 있다.

급하고 중요한 일은 없다. 

대부분 중요한 일은 급하지 않고, 급하게 하는 일은 중요하지 않다.

반드시 해야하고, 대부분이 하기 원하는 일은 시켜도 알아서 된다.

하지 않아도 되고, 대부분이 하지 않는 일은 결국 이상하게 끝이 난다.

빈수레가 요란하고, 든 것이 많은 사람일 수록 고개를 숙인다.

원인을 나로부터 찾는 사람은 다른 사람 잘 못도 내 잘 못 같고, 

원인을 밖에서 찾는 사람은 자기 잘 못도 다른 사람 탓이다.

내가 한 잘 못은 다른 사람들은 눈에는 안보일 거라고 확신하니 잘 못을 계속한다.

몰랐다고 한다는 것은 알았다는 것이다.

진짜로 모르면 잘 알고 있다고 한다.

공부는 엉덩이로하고 운동은 머리로 한다.

그렇게 말하는 것은 모르기 때문이다. 

그렇게 말하지 않는 것은 알고 있기 때문이다.

회사에서 프로젝트, task, 과제, pilot 등의 여러 이름으로 어떤 새로운 일을 개발/검증/증명 을 한다.

대부분 이런 경우 목표를 세운다.

목표는 추상적이며 많은 것을 설명해주지 않지만,

아이러니 하게 명료한 어떤 것이 되기 십상이다.

성능을 몇 % 올리기, 비용을 몇 % 줄이기, 

X 만큼 드는 시간을 Y로 줄이기, 

새로운 제품을 X 시간과 Y 비용으로 만들기

복잡한 상황에서 명확한 원인 찾아내기

그것을 하기 위해서 충분한 비용/인력/배경지식/자원 등은 주어지는 경우는 아주 드물다.

이런 프로젝트를 누가하는가?

거기에 실패에 대한 부담까지 져야 한다면 더더욱이 어려운 일이라 하겠다.

이런 프로젝트 일 수록 눈치빠른 사람은 벌써 어딘가에 가 있고, 그 간에 목소리 높고, 선두에 계시던 분들의

목소리는 침묵하며, 갑자기 맨날 욕만 들어먹는 사람이 갑자기 전문가라는 호칭을 들이며, 등 떠밀려 절벽앞에서 

손을 들라고 여러 부추긴다.

때론, 좋은 프로젝트 들이 있어, 누가 봐도 좋은 키워드와 화려한 팀으로 구성된 프로젝트도 있다.

이 2개의 프로젝트는 전혀 다른 배경이지만, 

또한 애석하게도 둘 다 성공한다는 보장은 없다.

성공에는 보이는 것보다 더 많은 측정 하기 어려운 것이 개입되기 마련이다.

이런 프로젝트의 결과에 대한 반영은 극명하다.

프로젝트에 대한 결과로 성공에 대한 경우는 이야기 할 필요가 없다. 

과정이 별로 였던, 운이었던 어찌되었던 성공했다면, 그건 좋은 결과이다. 

프로젝트에 대한 결과로 부정적인 결과인 경우에 대한 반응은 둘로 나눠진다.

첫번째는 부정적인 결과이지만, 원인 분석/결과에 대한 인정이기 보다는 포장과 덮기 등으로 갑자기 좋은 프로젝트로 등극한다.

첫번째도 문제이거니와, 이건 감독 마음이니 이에 대해서는 그럴려니 한다. 떡 주는 사람 마음이니.

문제는 두번째이다. 

두번째는 부정적인 결과에 대한 부정적인 반응으로 이어지는 경우이다.

대부분은 이를 실패라는 용어를 사용하면서 누군가는 공격의 수단으로 사용한다.

그래서 실패라는 용어가 사용된다는 것 자체가 벌써 목적성이 다분한 생각들의 언어에 대한 반영이다.

프로젝트에 대한 결과로 부정적인 결과로 얻는 이익은 적다.

결과가 기대만큼 되지 않았으니 실망과 위기의식과, 이에 대한 해명과, 리포팅과, 

이후에 결과에 다다르기 위해서는 뭘해야하는지에 대한 반성문등의 ( 이를 전문용어로 재발방지 대책 ) 나중을 위한

작업이 추가 되고, 멘탈도 많이 털린다.

여기에서 중요한 점은 반성문과 진정한 재발방지 대책의 차이가 그것을 리뷰하는 사람들의 생각에 따라 평가가 나눠진다.

아무리 좋게 표현하더라고, 받아 들이는 사람 측면에서 받아 들일 수 없게 전개가 된다면,

그건 아무리 좋은 리뷰라도 그 의도와 결과가 전달이 되지 않는다.

이런 부정적인 결과에 대한 피드백이 비난이 되지 않아야 한다는 건

수 많은 책과 가이드에 나와 있지만, 왜 이게 쉽게 된다면 누가 그렇게 많이 조언했겠나?

사람 인지라, 리뷰하고 가이드 해야 되는 위치에 있다보면, 

부정적인 결과에 대해서 민감해지는 건 어찌보면 즉각적이고 원초적인 반응일것이다.

하지만, 이를 그대로 두면 결국은 앞으로 조금 더 발을 내 디딜 수 없다.

결과에 대해서 그것을 기록하고, 기록에 신중을 가하고, 가능한 많은 자료를 남기로, 

어떠한 가설과 제한조건과, 그것을 어떻게 구현했는지, 당시 상황이 어떠했는지, 

왜 기대와 실제가 달랐는지, 그리고 그것을 진행한 사람의 회고, 

five why? poka-yoke 등의 모스트 모텀을 실시해야한다.

근데 그걸 부정적으로 본다면 그거에 대해서 잘 기록하지 않고 덮으려 한다.

나는 그것이 어떻게 평가되는 어떤 일을 할 때 자세하게 기록하고 남기고 공개하려고 한다.

왜야하는 것에 대한 대답보다는 아래의 사례가 그것을 더 잘 설명해주지 않나 싶다.

오늘 문득 SDE 책을 읽다가 그것이 생각나서 그것에 대한 과거의 사례의 기억을 기록해 둔다.

지금은 개발일을 하고 있지만, 

예전 회사에서 아주 큰 프로젝트를 할 때, 

똑같은 제안을 가지고 업계 1/2위를 다투던 세계적으로도 유명한 한국 회사 2개를 찾아갔던 적이 있다.

A 회사는 제안을 검토한 뒤, 그와 비슷한 프로젝트를 해 본 경험이 있고, 꽤 성공적인 건 아니었지만, 나름 괜찮았는데,

이런 점은 별로여서, 이 정도의 제안으로는 더 큰 성공을 이룰 수 없다며, 제안을 받아 들이지 않고, 

나중에 이 제안을 기반으로 한 유사한 과제 10개 정도를 자체적으로 했었는데, 10개 과제 모두 성공했다 ( ? ) 는 후문이었다.

여기에서의 성공은 그 걸 진행했던 사람들의 승진, 인사고가, 인정 등이라고 생각하시면 된다.

즉 이 제안은 남 좋은 일에 쓰였는게 그 때의 평가였다.

B 회사는 제안을 검토한 뒤, 그와 비슷한 프로젝트를 해 본 경험이 있고, 잘 되지 않았다고 한다.

하지만, 제안을 검토를 더 세밀하게 해서, 다시 잘 되지 않더라고, 비용을 들여서 해봐야 한다고 결과가 나왔고

나중에, 프로젝트를 했지만, 사람들이 노력해서 잘 되게 하려도 노력과 고생을 많이 하였지만, 기대 만큰 결과가 나오지 않았다.

그 때 당시에는 이 제안을 괜히 하였나? 나도 잘 모르면서 설레발을 쳤나? 여러사람 괜히 고생시켰나?

안좋은 건 결국하지 말아야 하나? 등의 사후 검증에 많이 시달리긴 했었다.

이게 2010-2012년 쯤이 었다.

꼭 이것때문만은 당연히 아니었지만, 그로 부터 3년 부터 분위기가 다르 더니 지금은 완전히 다른 결과가 나왔다.

즉 부정적인 결과를 어떻게 생각하느냐에 따라 회사의 결과가 바뀌는 건 정말 문자 그대로 교과서적인 결과였다.

현재 A 회사와 B 회사는 어떻게 되었을 까? 

B 회사는 완전히 글로벌 권에 장착했으며,

A 회사는 그 사업부가 없어졌다.

이렇듯 보이지 않는 부분에 대한 리더의 생각은

결과가 당장 나오지 않는다.

하지만, 반드시 청구서는 뒤에 오게 되어 있다.

현재에 회사에서도 이런 일이 있었지만, 

그건 이번에 쓸건 아니고, 나중에 떠오르고 마음에 정리가 되면

그 때 정리해서 써야겠다. Episode 2가 이래서 나오다 보다.

부정적인 결과에 도전하는 것에는 용기가 필요하고, 

그것을 스스로 인정하는 것에는 더 큰 용기가 필요하고, 

그것을 다른 사람에게 공개하는 것에는 더더 큰 용기가 필요하다.

그러니 엔지니어 들이어 힘들더라도 두렵더라고, 용기를 내어 도전해라, 

당장은 힘들어도, 끝이 좋다.

참고 :

https://ko.wikipedia.org/wiki/%EB%B9%84%EA%B5%90_%EC%A0%95%EB%A0%AC

대표적인 문자열 안에서 단어를 찾는 문자열 탐색 알고리즘

라빈-카프 알고리즘 : 

보이어-무어 알고리즘 : 

KMP 알고리즘 : 

아호-코라식 알고리즘 :

Suffix Array 맨버-마이어스 알고리즘 : 

LCP Array :

https://en.wikipedia.org/wiki/Rabin%E2%80%93Karp_algorithm

https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string-search_algorithm

https://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm

https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm

https://en.wikipedia.org/wiki/Suffix_array

https://en.wikipedia.org/wiki/LCP_array

https://namu.wiki/w/%EB%AC%B8%EC%9E%90%EC%97%B4%20%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98

글로벌 스탠다드 데이터 모델

RDB기반 데이터 모델링시 참조하면 도움이 아주 많이 되는 책

https://www.yes24.com/Product/Goods/60665517

잘 분리는 어떻게 해야하나? 아래의 문장이 가장 명쾌하다.

동일한 이유로 변경되는 것들은 함께 모으고, 서로 다른 이유로 변경되는 것들은 분리

https://www.oreilly.com/library/view/97-things-every/9780596809515/ch76.html

ONE OF THE MOST FOUNDATIONAL PRINCIPLES OF GOOD DESIGN IS:

- 같은 이유로 변화하는 것끼리 묶고, 다른 이유로 변화하는 것끼리는 분리하라.

- Gather together those things that change for the same reason, and separate those things that change for different reasons.

Robert C. Martin (Uncle Bob)

https://www.oreilly.com/library/view/97-things-every/9780596809515/ch76.html

https://en.wikipedia.org/wiki/Single-responsibility_principle

부분수열의합(실버2) : https://www.acmicpc.net/problem/1182
순열장난(실버1) : https://www.acmicpc.net/problem/10597
컴백홈(실버1) : https://www.acmicpc.net/problem/1189
암호만들기(골드5) : https://www.acmicpc.net/problem/1759
N-Queen*(골드5) : https://www.acmicpc.net/problem/9663
미친로봇(골드5) : https://www.acmicpc.net/problem/1405
알파벳(골드4) : https://www.acmicpc.net/problem/1987
스도쿠*(골드4) : https://www.acmicpc.net/problem/2580
좋은수열(골드4) : https://www.acmicpc.net/problem/2661
단어수학(골드4) : https://www.acmicpc.net/problem/1339
색종이붙이기(골드2) : https://www.acmicpc.net/problem/17136

> 상진 고:
다음주 스터디 문제입니다!
늦게 올려 죄송합니다!!!

> 상진 고:
(실버3) 예산 - https://www.acmicpc.net/problem/2512
(실버2) 나무 자르기 - https://www.acmicpc.net/problem/2805
(실버3) 랜선 자르기 - https://www.acmicpc.net/problem/1654
(실버1) 기타 레슨 - https://www.acmicpc.net/problem/2343
(골드5) 공유기 설치 - https://www.acmicpc.net/problem/2110
(골드4) 드래곤 앤 던전 - https://www.acmicpc.net/problem/16434
(골드2) 도토리 숨기기 - https://www.acmicpc.net/problem/15732
(골드2) K번째 수 - https://www.acmicpc.net/problem/1300

> 상진 고:
다음주 토픽은 '이분탐색'입니다!!!

> 상진 고:
(실버2)종이의 개수 : https://www.acmicpc.net/problem/1780
(실버1)곱셈 : https://www.acmicpc.net/problem/1629
(실버1)쿼드트리 : https://www.acmicpc.net/problem/1992
(실버1)Z : https://www.acmicpc.net/problem/1074
(실버1)별 찍기 - 10 : https://www.acmicpc.net/problem/2447
(골드4)별 찍기 - 11 : https://www.acmicpc.net/problem/2448
(골드2)트리의 순회 : https://www.acmicpc.net/problem/2263
(골드2)버블 소트 : https://www.acmicpc.net/problem/1377
(플래티넘5)히스토그램 : https://www.acmicpc.net/problem/1725

> 상진 고:
스터디 문제입니다! 백준 문제이고, 백준은 릿코드와는 다르게 표준입출력으로 문제 입력과 출력을 받습니다!

[Easy]
 1. https://leetcode.com/problems/valid-boomerang/
 2. https://leetcode.com/problems/isomorphic-strings/
 3. https://leetcode.com/problems/guess-number-higher-or-lower/
 4. https://leetcode.com/problems/maximum-repeating-substring/
 [Medium]
 1. https://leetcode.com/problems/longest-word-in-dictionary/
 2. https://leetcode.com/problems/container-with-most-water/
 3. https://leetcode.com/problems/longest-increasing-subsequence/
 [Hard]
 1. https://leetcode.com/problems/frog-jump/
 2. https://leetcode.com/problems/split-array-largest-sum/
 3. https://leetcode.com/problems/arithmetic-slices-ii-subsequence/

[EASY]
1. https://leetcode.com/problems/longest-common-prefix/
2. https://leetcode.com/problems/valid-parentheses/
3. https://leetcode.com/problems/is-subsequence/
4. https://leetcode.com/problems/n-th-tribonacci-number/

[MEDIUM]
1. https://leetcode.com/problems/minimum-path-sum/
2. https://leetcode.com/problems/word-break/
3. https://leetcode.com/problems/house-robber-ii/

[HARD]
1. https://leetcode.com/problems/dungeon-game/
2. https://leetcode.com/problems/best-time-to-buy-and-sell-stock-iv/
3. https://leetcode.com/problems/max-sum-of-rectangle-no-larger-than-k/

[Easy]
 1. https://leetcode.com/problems/min-cost-climbing-stairs/
 2. https://leetcode.com/problems/counting-bits/
 3. https://leetcode.com/problems/divisor-game/

[Medium]
1. https://leetcode.com/problems/longest-palindromic-substring/
2. https://leetcode.com/problems/unique-paths-ii/
3. https://leetcode.com/problems/interleaving-string/

[Hard]
1. https://leetcode.com/problems/palindrome-partitioning-ii/
2. https://leetcode.com/problems/maximal-rectangle/
3. https://leetcode.com/problems/distinct-subsequences/

Easy]
1. https://leetcode.com/problems/two-sum-iv-input-is-a-bst/
2. https://leetcode.com/problems/maximum-subarray/
3. https://leetcode.com/problems/diameter-of-binary-tree/
[Medium]
1. https://leetcode.com/problems/longest-consecutive-sequence/
(ㄴ https://www.acmicpc.net/problem/1717 문제로 대체 가능)
2. https://leetcode.com/problems/linked-list-in-binary-tree/
3. https://www.acmicpc.net/problem/11437
[Hard]
1. https://leetcode.com/problems/count-of-smaller-numbers-after-self/
2. https://leetcode.com/problems/maximum-employees-to-be-invited-to-a-meeting/

Medium 2. https://leetcode.com/problems/linked-list-in-binary-tree/
- 알고리즘 : KMP 알고리즘
- 설명 : https://m.blog.naver.com/kks227/220917078260

Medium 3. https://www.acmicpc.net/problem/11437
- 알고리즘 : LCA 알고리즘
- 설명 : https://www.quora.com/What-are-the-specifics-in-implementing-an-O-N-log-N-Lowest-Common-Ancestor-algorithm

Hard 1. https://leetcode.com/problems/count-of-smaller-numbers-after-self/
- 알고리즘 : MergeSort 또는 Segment Tree 또는 Fenwick Tree
- 설명 : Segment Tree : https://m.blog.naver.com/kks227/220791986409
- 설명 : Fenwick Tree : https://www.acmicpc.net/blog/view/21

https://blog.naver.com/gmanf77/222330154508

https://blog.naver.com/paula23/222073094639

https://brenden.tistory.com/33

https://chanhuiseok.github.io/posts/algo-14/

https://leetcode.com/problems/count-primes
https://leetcode.com/problems/add-digits
https://leetcode.com/problems/x-of-a-kind-in-a-deck-of-cards
https://leetcode.com/problems/ugly-number-iii
https://leetcode.com/problems/check-if-it-is-a-good-array

https://leetcode.com/problems/symmetric-tree/
https://leetcode.com/problems/path-sum/

https://leetcode.com/problems/surrounded-regions/
https://leetcode.com/problems/course-schedule/
https://leetcode.com/problems/maximum-width-of-binary-tree/

https://leetcode.com/problems/binary-tree-maximum-path-sum/
https://leetcode.com/problems/binary-tree-cameras/

https://enterone.tistory.com/category/Database/mysql?page=4 

https://www.fema.gov/sites/default/files/2020-07/fema_nims_doctrine-2017.pdf

https://github.com/etsy/morgue

https://jjeongil.tistory.com/1600

https://db-engines.com/en/ranking

카테고리

개발자 : 어떤 목적에 부합하는 알고리즘을 특정 언어의 코드로 개발

코드가 돌아갈수 있는 환경이 필요함.

N명의 개발자가 개발한 코드를 실행할 수 있는 환경을 만들어야함

이러한 환경 : 하드웨어, OS, DB, Memory 등을 정해진 예산 범위 내에서 구축

구축이후에도 운영/유지보수가 필요함.

엔지니어 : 시스템을 구축, 운영 하는 사람

엔지니어 : 

하나의 새로운 시스템을
(간단하던,복잡하던간에) 구상하고 기본 설계를 할 줄 알아야하고
그 과정의 문제점에 대한 어느정도의 도출과 보완사항에 대한
구상을 생각해야 제대로된 엔지니어

모든 기계및 소프트웨어는 설명서(매뉴얼)이 있지만 처음 접할때는 설명서와
매뉴얼이 매우 많은 도움이 됩니다. 그러나 개발자가 예상하지 못했던 예외의
문제는 매뉴얼로 해결할수 없었습

엔지니어는 어떤 시스템(하드웨어적이거나 소프트웨어적이거나)을 설계하
고 제작하는 사람..

프로그래머는 어떤 시스템(OS)에서 작동하는 어플리케이션을 설계/제작하
는 사람..

시스템을 설계

소프트웨어 개발자는 소프트웨어 개발 방법론을 따라야하며 클라이언트의 요구 사항을 충족하기 위해 소프트웨어 프로그램을 디버깅하고 수정하는 데 전문성

코드 작성을 담당하는 소프트웨어 개발자는 창의적이고 기술적 인 기술을 사용하여 혁신적인 아이디어를 수행 할 수 있어야합니다

요구 사항을 소프트웨어 기능과 지속적으로 비교하는 데 필요한 우수한 분석 기술도 보유

사소한 오류나 잘못된 의사 소통으로 인해 중대한 재정 및 운영 문제가 발생할 수 있으므로 소프트웨어 개발자에게는 세부 사항 지향이 필수적

효율성을 높이도록 설계된 프로그램을 수정하고 수정하기 위해 세부 사항에 눈을 사용

소프트웨어 개발자 책임

• 객과의 요구 사항에 대해 논의
• 소프트웨어 테스트 및 문제 해결
• 시스템이 가동되고 실행되면 유지 관리
• 기술 설계의 일부가 됨
• 소프트웨어 구성 요소 통합
• 효율적인 코드 생성
• 참조 및보고를위한 프로그램 코드 작성

소프트웨어 엔지니어는 전체 프로젝트 라이프 사이클에 참여합

개발자 및 비즈니스 분석가와 협력하여 제안 된 소프트웨어 솔루션에 대한 요구 사항을 논의

발해야 할 항목, 방법 및시기를 식별하기 위해 프로젝트 범위를 지정

작업에 가장 적합한 프로그래밍 언어와 개발 프레임 워크를 선택하고 다양한 플랫폼에서 솔루션을 사용할 수있는 방법을 생각

기술 및 과학 지식을 사용하여 소프트웨어를 연루시키고 가능한 문제를 예측

패턴 설계 및 자동화 시스템에 능숙

소프트웨어 엔지니어 책임

• 새로운 하드웨어에 적응할 수 있도록 기존 소프트웨어를 수정하여 오류를 수정합니다.
• 사용자 요구 사항과 소프트웨어 요구 사항을 분석하여 시간 및 비용 제약 내에서 설계를 결정합니다.
• 시스템 설계 및 유지 관리에 대해 고객과 상호 작용합니다.
• 프로그래머 및 기술자의 작업 감독
• IT 아키텍처, 대규모 데이터 및 클라우드 기반 시스템을 만들고 유지합니다.
• 혼자서 그리고 소규모 팀 내에서 효율적으로 작업하십시오.
• 운영 개선을위한 시스템 분석 수행

소프트웨어 엔지니어는 건축가로, 소프트웨어 개발자는 목수로 생각할 수 있습니다.

엔지니어는 엔지니어링 원칙을 사용하여 시스템 전체를 감독하고 개발자는 기능 소프트웨어를 만드는 데 집중합니다

Engineering Excelllence

엔지니어링 우수성은 엔지니어링 기술에 탁월함을 추구하며, 효율적일뿐만 아니라 고객에게 즐거움을 전달하는 데 효과적이며 작업과 완제품에서 자부심과 만족을 얻는 과정에서 효과적입니다. 그것은 최종 목표가 아니라 노력이며 엔지니어로서 우리는 매일 깨어나 더 나은 것을 만들고 우리의 기술을 더 잘하게 만듭니다.

엔지니어링 우수성은 엔지니어가 최고의 작업을 수행하는 데 방해가되는 장애물과 우수성을 추구하고 우수성을 위해 노력할 수 있도록 지원하고 장려하기 위해 취할 수있는 조치를 식별하는 것입니다

버그를 잡는 것만으로는 고품질의 제품을 얻을 수없는 이유

Software Engineering Excellence

Developer Velocity를 마스터 한 기업은 개발자의 역량을 강화하고, 중요한 조력자를 예상하고, 투자를 고객 가치에 맞추고, 생산성 장벽을 최소화하는 데 똑같이 집중

https://en.wikipedia.org/wiki/Software_engineer

https://en.wikipedia.org/wiki/Software_engineering

https://wikidocs.net/113738

https://en.wikipedia.org/wiki/Outline_of_software_engineering

https://www.technojobs.co.uk/info/developer-guides/the-difference-between-software-developers-and-software-engineers.phtml

https://www.geeksforgeeks.org/is-there-any-difference-between-software-developer-and-software-engineer/

https://shecancode.io/blog/software-developer-or-engineer-whats-the-difference

https://medium.com/swlh/what-is-engineering-excellence-a8aa5a1e8dc5

https://medium.com/swlh/you-cant-fix-quality-just-by-catching-bugs-ddc01d900474

https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance#

Manager 혹은 팀장, 개발팀장, 팀리더, 관리자는 모두 하나의 롤을 표현하고 유사한 용어처럼 사용되지만 전혀 다르다.

Manager는 Managing 해야하는

사람들이 성과를 낼 수 있도록

그 사람에게 정기적으로 자신의 상태와 Result에 대한 Feedback을 주고

관리를 해주는 롤이라고 생각한다.

하지만 관리자 ( Administrator) 가 되어서는 안된다. 대부분의 회사를 결국 Administrator를 원하지만..

일부는 팀장은 본인이 어른이고 시니어로서 팀원들을 캐어하고 보호해줘야 한다고 생각한다.

또 팀원도 반대로 팀장이 외부로 부터 보호해주고, 자신이 하기 힘든 부분을 해줘야 한다고 생각한다.

장이라는 표현은 한국적인 의미가 많이 들어가 있다. 

의사 결정권자라는 의미를 가지지만, 어른 혹은 상위라는 개념으로 인식하기 쉬워서 

개인적으로는 장이라는 표현을 사용하는 것을 좋아하지 않는다.

Manager는 팀원이 그러한 문제를 스스로 해결할 수 있도록

시간과 방법을 알려주고

결과를 만들어 낼 수 있도록 피드백 루프를 가지는 역할이다. 

개발팀장은 인사관리자 롤을 뺀 팀장이거나 개발을 잘 알아서 이에 대한 코칭을 많이 해줄 수 있는 팀장을 지칭할 때 사용한다.

하지만, 개발을 잘 안다고, 아니 개발을 모른다고 팀 멤버에게 좋은 코칭을 할 수 없는가?

방법/solution/막힌 부분을 해결해주는게 Manager가 아니라 그 사람에게 피드백을 주는 역할이여야 한다.

꼭 개발팀장이 개발역량 혹은 개발경험을 가지고 있어야 한다고 생각하지 않는다.

물론 있으면 개발을 하는 팀 멤버를 더 잘 이해할 수 있겠지만, 

팀원은 사람이다.

사람을 이해하는 것이 매니징에서는 더 중요하다.

사람을 잘 이해하는 가장 좋은 방법은 자기 자신을 잘 이해하는 것이다.

자기 자신을 잘 이해하는 방법은 성경의 말씀을 보면서 자기 자신을 거울로 비워보면 알 수 있다.

- 코드를 체크인 하기 전에 어떤 테스트를 실행해야 할지 여부

- 테스트 클래스와 메서드의 네이밍 룰

- 헴크레스트를 사용할지 전통적인 assert 사용할지 여부

- AAA 사용 여부

- 선호하는 목 도구 선택

- 체크인 테스트를 실행할 때 콘솔에 출력을 허용할지 여부

- 단위 테스트 스위트에서 느린 테스트를 분명하게 식별하고 막을 방법

표준 준수 

- 페어프로그래밍 리뷰 : 적극적인 리뷰 : 팀을 좌절시키는 수 많은 나쁜 방법이 있습니다. 동료의식과 충분한 설득이 필요 : 시작부터 좋은 품질의 코드를 만들자 : 짝 프로그래밍을 성공적으로 만드는 노하우 부터 익히자

- 코드 리뷰

- 아키텍처 리뷰 

- 표면 리뷰

- 사후 리뷰 : 심각한 문제, 비용 증가

Fagan inspection : 리뷰 공식화

https://en.wikipedia.org/wiki/Fagan_inspection

https://martinfowler.com/articles/on-pair-programming.html

https://dzone.com/articles/what-is-pair-programming-advantages-challenges-tut

https://medium.com/@weblab_tech/pair-programming-guide-a76ca43ff389

https://okky.kr/article/333213

A nightly build is a neutral build that takes place automatically. These typically take place when no one is likely to be working in the office so that there are no changes to the source code  during the build. The results of the build are inspected by the arriving programmers, who generally place a priority on ensuring the recent changes to the source code have not broken the build process or functionality of the software.

http://agileinaflash.blogspot.com/2012/06/simplify-design-with-zero-one-many.html

http://agileinaflash.blogspot.com/

FIRST : Fast, Isolated, Repeatable, Self-Validating, Timely

Fast : 단위 테스트의 외부 의존성 (데이터베이스, 파일, 네트워크, API 호출 등)을 줄이고 가능한 200ms 기준으로 안으로 들어오게

Isolated : 다른 단위 테스트에 의존성 없음, 순서나 시간에 관게없이 실행되어야 함, 

Repeatable : 실행때 마다 결과가 같아야 함

Self-Validating : 스스로 검증가능해야하며, 준비할 수도 있어야함. 

Timely : 바로 단위 테스트 작성

Right-BICEP : Right, Boundary condition, Inverse relationship, Cross-check, Error conditions, Performance characteristics

Right : 결과가 올바른가, 기대한 결과를 산출하는지 검증할 수 있어야함. happycase test를 알지못하면, 그 내용을 완전히 이해 못한 것

Boundary condition : 경계조건은 맞는가? conrner case : 

경계조건 : 모호하고 일관성 없는 입력 값 (특수문자 가 포함), 잘못된 양식의 데이터, (도메인이 빠진 이메일), 수치적 오버플로 계산, 비거나 빠진 값 ( "" or null ), 이성적인 기댓값을 훨씬 벗어나는 값 ( 나이 150세 ), 당번표 처럼 중복 방지, 정렬이 안된 리스트, 시간 순서가 맞지 않는 경우, 

경계조건에서는  correct  : Conformance(준수), Ordering (순서), Range (범위), Reference (범위), Existence ( 존재), Cardinality(기수), Time (시간)

Inverse relationship : 역 관계를 검사할 수 있는가 , 즉 곱셈을 나눗셈으로 검증하고, 뺄셈을 덧셈으로 검증하는 방법, 데이터 베이스에 insert 하였다면 select 해보는 방법

Cross-check : 다른 수단을 할용하여 교차 검사, 총 도서 수량 = 대출 수량 + 남은 수량

Error conditions : 오류 조건을 강제로 일어나게 할 수 있는가, 메모리 가득 찰때, 디스크 가득 찰째, 해상도 등

Performance characteristics : 단위 성능 측정 baseline을 만드는 것, 성능 측정은 반복적인 결과 시간 측정

List체크 시나리오

시작과 마지막 인덱스가 같으면 안됩니다.

시작이 마지막보다 크면 안됩니다.

인덱스는 음수가 아니어야 합니다.

인덱스가 허용된 것 보다 크면 안됩니다.

개수가 실제 항목과 맞아야 합니다.

목록의 항목이 하나도 없을 때

목록에 항목이 하나만 있을 때

목록에 항목이 없을 때 하나 추가

목록에 항목이 하나만 있을 하나 추가

목록에 항목이 열개 미만일 때 하나 추가

목록에 항목이 열개 일때 하나 추가

Right-BICEP

https://www.artima.com/weblogs/viewpost.jsp?thread=126923 

http://infinitest.github.io/

https://github.com/junit-team/junit4/wiki/Categories