728x90

1. 전구를 갈아끼우기 위해서는 얼마나 많은 프로그래머들이 필요할까?

 - 0명:  고장나지 않았고 절전모드 다.

 - 1명 : 하지만 밤새 걸리고 엄청난 양의 피자와 커피가 필요

 - 20명 : 고치는데 1명, 그 결과 생긴 side-effect를 debug하는데 19명

 : 책에서는 software가 아니라 hardware로 접근해야 해서 문제가 잘못되었다는데 왠지 20명이 끌린다.

 

2. 열성적이지만 스킬이 부족한 것과 재능이 뛰어나지만 의욕이 없는것 중 어느 것이 더 나을까?

 - 누가 더 나은 코드를 작성하는가?

 - 누가 더 나은 프로그래머인가?

 - 단기간 필요한가? 아니면 장기간 필요한가?

 

3. 아래 프로그램 유형의 코드 작성 방법은 서로 어떻게 다를까요?

 A. 장난삼아 작성하는 프로그램

    - 기능을 앞에 닥친 문제를 풀 정도로만 작성하고 버림

    - 개발의 속도와 용이성이 설계의 세련미보다 중요

 B. 완전히 새로운 프로그램

    - 신중한 설계와 조심스러운 계획이 필요

    - 미래의 사용과 확장을 반드시 계산에 넣어야 함

    - 충분한 문서화가 보장되어야 함

 C. 기존 시스템의 확장

    - 기존 코드에 대한 철저한 이해가 필요

    - 기존 작업과 조화를 이루는 변경이 필요

 D. 예전 코드 베이스의 유지보수 작업

    - 남아있는 결함의 정정

    - 주변 환경이 바뀐 다음에 소프트웨어가 제대로 돌아가도록 개선

 

728x90

'Programming > 좋은습관들이기' 카테고리의 다른 글

프로그래머의 종류  (0) 2022.01.03
설계하기  (0) 2022.01.02
최적화  (0) 2022.01.01
Build 관점에서의 language 구분  (0) 2021.12.31
Comment 작성 요령  (0) 2021.12.30
.vimrc option  (0) 2011.07.22
Artistic Style : SourceInsight  (0) 2011.04.28
툴을 사용하자  (0) 2008.07.08
오류처리 - 프로그래밍 습관03  (0) 2008.06.26
오류처리 - 프로그래밍 습관02  (0) 2008.06.24
728x90

열성적인 코더

who?

더보기

추진력 있고, 빠르다. 뒤로 물러서서 생각하지 않고 바로 코드를 만들어낸다.

뛰어난 스킬에 비해 진정한 잠재력을 보여주지 않는다.

강점

더보기

코드를 많이 작성한다.(양적인 면에서 생산적)

새로운 것을 배우기를 좋아하고 열성적

약점

더보기

성급하고, 결함이 있는 코드를 만들기 쉽다.

디버깅을 잘 못한다.(코딩에 뛰어드는 것처럼 디버깅으로 곧장 다이빙)

열성적이지만 시간 추정을 잘 못한다.(예상보다 일이 오래 걸림)

해야할일

더보기

열정을 잃지 마라. 단위 test를 위한 코드를 많이 준비하라. 서두르지 마라.

이들과 일하려면?

더보기

매일같이 이들에게 무엇을 할 것인지. 그리고 앞으로의 계획은 무엇인지 물어보라.

 

코드 멍키(code monkey)

who?

더보기

기초는 튼튼하지만 독창성이 없는 코드를 만든다. 머슴처럼 일함. 유지보수에 적합

강점

더보기

일을 주면 한다.(꽤 잘하고 시간도 잘 지키고 지치지 않는다)

시간 추정을 잘하고, 체계적이고 철저함

약점

더보기

특 안에서만 생각.

잠재적인 문제점을 다루지 않고, 의문조차 갖지 않음

솔선해서 문제를 조사하거나 고치는 일이 거의 없음

해야할일

더보기

개인 프로젝트로 훈련하여 스킬을 강화하라.

적극적으로 새로운 작업에 동참시켜 달라고 요청하라.

이들과 일하려면?

더보기

칭찬해주고, 테크닉을 가르쳐서 일을 더 잘할게 해줘라.

 

권위자

who?

더보기

현실에서는 보기 어려운 전설 속의 인물

혼자서 근본이 되는 중요한 일을 처리.(프레임워크, 아키텍처,커널..)

탁월한 코드를 작성하지만 평범한 사람들과는 의사소통이 잘 되지 않음

동료들로부터 마땅히 받아야 할 존경과 경외를 받음

강점

더보기

경험이 풍부하고, 유지보수가 쉬운 코드를 작성

훌륭한 멘토로 배울 것이 많음

약점

더보기

의사소통이 약함(팀웍이나 멘토로서의 역할이 약함)

해야할일

더보기

자신의 일을 설명하기 위한 스킬

이들과 일하려면?

더보기

옆에서 배워야 함(기술 뿐 아니라 접근하는 태도)

 

되다만 권위자

who?

더보기

스스로 권위자라 생각하지만 사실은 아님.

아는 게 많은 것처럼 말하지만 쓰잘데기 없는 것만 한가득.

자만심이 강하고 자신을 권위 있는 자리에 스스로 올려 놓음

강점

더보기

없음

약점

더보기

자신에 대한 믿음이 지나침(자신을 과대평가하여 프로젝트의 성공을 위태롭게 함)

해야할일

더보기

자신의 스킬을 정직하게 평가

이들과 일하려면?

더보기

도망가

 

거만한 천재

who?

더보기

빠르고 효율적이고 고품질의 코드를 작성.

건방지고, 생색을 내며 품위가 없음

논쟁을 아주 좋아함(보통 자기가 옳기 때문) - 자기가 옳지 않을 경우 자기가 옳은 것으로 주제가 옮겨갈 때까지 계속 말을 함

강점

더보기

높음 기술적 스킬.

기술적으로 강력한 선도 역할. 촉매 역할

약점

더보기

자신의 잘못이 증명되는 것을 싫어하고, 항상 자신이 옳아야 한다고 생각

모른다는 말을 할 줄 모름

해야할일

더보기

다른 사람들의 의견을 듣고 존중

모르는 것에 대해 정직해지고 배워라

이들과 일하려면?

더보기

이들에게 존경심을 표하고, 다른 이들에게도 존경심을 표하라.

쓸데없는 논쟁은 피하되 당당히 맞서서 논쟁을 즐겨라.

 

카우보이

who?

더보기

힘든 일을 적극적으로 피해 다니는 악질

자신의 일을 빨리 끝내고 다음으로 넘어가기 위해 모든 꼼수를 사용

강점

더보기

새로운 것을 배우는 것을 좋아함(배우려고 시작하지는 않음)

약점

더보기

이 사람이 저질러 놓은 똥을 치우는 데 상당한 노력이 들어감

해야할일

더보기

일에 긍지를 갖고 시간을 투자

이들과 일하려면?

더보기

피할 수 있다면 최대한 피해라.

반드시 코드를 리뷰하고, 다른 사람과 짝을 이루어 프로그래밍 하게 하라.

(추천: 열성적인 코더, 비추천: 계획가)

 

계획가

who?

더보기

할 일에 대해 너무 많은 생각을 해서 코딩을 시작할 때 쯤 프로젝트가 끝남

많이 연구하고 많이 읽음

적절한 프로세스는 알지만 데드라인은 맞추기 어려움

강점

더보기

설계와 생각을 제대로 하고 나서 코딩

약점

더보기

지나친 설계를 할 수 있음

복잡한 시스템을 만들어 분석이 마비되도록 만들 수 있음

개발 자체보다 방법론과 모델링 쪽으로 치우침

생각을 오래하다 보니 실제로 일 할 시간이 부족

해야할일

더보기

점증적인 개발 방법과 프로토타이핑을 설계의 검증 수단으로 사용

계획과 행동 사이 균형을 맞춰야 함

이들과 일하려면?

더보기

이들과의 회의를 줄여라

작업 이정표에 설계 완료를 추가하라

 

노인

who?

더보기

보수적인 생각을 가진 고참 프로그래머

새로운 것을 배우려 하지 않고 쉽게 짜증

강점

더보기

경험과 지혜

약점

더보기

새로운 것을 배우려 하지 않음

참을성 부족

해야할일

더보기

후배를 존중

이들과 일하려면?

더보기

뒤끝이 있는 경우가 많으니 조심히 다룰 것

 

광신도

who?

더보기

BigCo를 맹신

BigCo : MS, IBM, Sun등 성공한 소프트웨어 회사

강점

더보기

제품을 잘 알고 이를 기반으로 훌륭한 설계를 함

약점

더보기

객관성이 없고, 실용주의적이지 않음. BigCo가 아닌 다른 더 나은 설계를 놓칠 수 있음

해야할일

더보기

BigCo를 버리는 것은 바라지 않지만 최소한 다른 접근 방법과 사고방식도 받아들일 줄 알아야 함

이들과 일하려면?

더보기

논쟁하려고 들지마라

중대한 설계가 아니면 그들이 맞는 경우가 많다

 

일편단심 프로그래머

who?

더보기

전형적인 Geek

프로그래밍만을 생각

강점

더보기

일을 진심으로 좋아하고, 많은 양의 업무 추가도 수용

데드라인이 다가올 때 도움이 많이 됨

약점

더보기

다른 사람들도 자신처럼 목표가 뚜렷하기를 기대하고, 그렇지 않으면 실망

업무 외의 세상에 무관심

해야할일

더보기

취미를 가져라

이들과 일하려면?

더보기

이들이 당신의 일까지 가져가게 하지 마라.(나중에 낯선 코드를 유지보수 하게 됨)

 

게으름뱅이

who?

더보기

아주 많은 일을 하는 것처럼 꾸미고 실제로는 일을 하지 않음

사교모임에 많이 나간 다음 책상 밑에서 자는 모습으로 발견 됨

강점

더보기

최소한 즐길 줄은 안다

약점

더보기

감지하기 어렵고, 정말로 게으름을 피우는지 업무가 너무 어려워서 오래 걸리는지 증명하기 어려움

해야할일

더보기

양심 좀

이들과 일하려면?

더보기

이들을 잘라낼 수 없다면 그냥 받아들여야 함

불평을 해도 개선이 어려우니 그냥 둬라

 

마지못해 하는 팀장

who?

더보기

팀장을 원하진 않지만 더이상의 진급할 자리가 없어서 팀장이 된 경우

보통 부드러운 태도를 가졌고 우유부단함

강점

더보기

프로그래머의 어려운 처지에 진정으로 공감해줌

자신이 지연이나 비난에 대한 책임 짐

약점

더보기

리더로서의 역량이 없음

임무를 위임하지 못해 배분도 못함

팀장의 역할과 프로그래밍을 같이 하려는 경우 일을 할 시간은 부족하고 자리에 오래 있으며 다 제대로 못하게 됨

해야할일

더보기

팀장 역할에 대한 훈련을 받던가, 아니면 다른 분야로 이동

이들과 일하려면?

더보기

팀장을 불쌍히 여겨, 그사람에게 도움이 될 수 있는 일을 해줘야 함

728x90

'Programming > 좋은습관들이기' 카테고리의 다른 글

[코드멍키] 생각해 봅시다  (0) 2022.01.08
설계하기  (0) 2022.01.02
최적화  (0) 2022.01.01
Build 관점에서의 language 구분  (0) 2021.12.31
Comment 작성 요령  (0) 2021.12.30
.vimrc option  (0) 2011.07.22
Artistic Style : SourceInsight  (0) 2011.04.28
툴을 사용하자  (0) 2008.07.08
오류처리 - 프로그래밍 습관03  (0) 2008.06.26
오류처리 - 프로그래밍 습관02  (0) 2008.06.24
728x90

무엇을 설계하는가?

 * System architecture

 * Module/Component

 * Class/Data type

 * Function

 

좋은 설계의 목표

 * 작성하기 쉽고

 * 이해하기 쉽고

 * 고치기 쉽고(문제를 쉽게 찾고)

 * 버그가 숨어 있을 가능성이 더 적고

 * 변경에 대해 더 탄력적인

 

어떤 코드를 만들 것인가?

 - 반복적이고, 신중하고, 현실적이고, 지식에 근거한

 

Blaise Pascal

Pascal : "편지가 길어서 죄송합니다. 하지만 짧게 쓸 시간이 없었습니다."

 

단순성

 - 잘 설계된 코드의 가장 중요한 특성이다. 단순한 설계는 이해가 쉽고, 군더더기나 오점이 없고, 구현이 쉽다. 조리에 맞고 모순이 없다. 

728x90

'Programming > 좋은습관들이기' 카테고리의 다른 글

[코드멍키] 생각해 봅시다  (0) 2022.01.08
프로그래머의 종류  (0) 2022.01.03
최적화  (0) 2022.01.01
Build 관점에서의 language 구분  (0) 2021.12.31
Comment 작성 요령  (0) 2021.12.30
.vimrc option  (0) 2011.07.22
Artistic Style : SourceInsight  (0) 2011.04.28
툴을 사용하자  (0) 2008.07.08
오류처리 - 프로그래밍 습관03  (0) 2008.06.26
오류처리 - 프로그래밍 습관02  (0) 2008.06.24
728x90

 잘못된 최적화

 

최적화란?

 Optimization : 우너래 의미는 개선을 하고 더 좋은 무엇인가를 만드는 것이지만 일반적으로 code의 실행 속도를 높이는 것으로 받아들여 진다.

* 프로그램의 실행 속도를 높이는 것

* 실행파일의 크기를 줄이는 것

* 코드의 질을 향상시키는 것

* 출력의 정확성을 높이는 것

* 기동시간(startup time)을 최소화하는 것

* 단위시간당 데이터의 처리량을 늘리는 것(반드시 실행속도와 같지는 않다)

* 저장장치의 부담을 줄이는 것(ex. database size)

** Embedded에서 최적화라 하면 Tuning의 개념도 포함된다.

 

코드를 다 만들고 나서 나중에 최적화 하는 것은 아주 위험하다.

 - 처음 시작할 때부터 성능에 대해 고민하라. 개발이 끝날 때 고칠 수 있다고 생각하면서 소홀히 하지 마라

 - 올바른 코드가 빠른 코드보다 훨씬 더 중요하다.

 

최적화를 해치는 요인들

* 복잡성

* 간접성

* 중복성

* 잘못된 설계

* I/O : 특히 입출력이 어려군데 흩어져 있으면 성능에 아주 많은 영향을 준다.

 

최적화의 필요성

 * 게임 프로그래밍 : 실행환경의 한계까지 가기 때문에 실행 속도에 대한 최적화가 필요, 특히나 delay에 민감하다

* Digital signal porocessing : 대량의 data를 빠르게 digital filtering해야 함

* Embedded platform : 자원이 제한된 환경이라 하드웨어에 맞춰 최대한의 성능을 이끌어 내야 한다

* Realtime system : 정확한 시간에 시작하고, 주어진 시간 내에 작업을 완료해야 한다. 이 환경에서는 알고리즘이 신중하게 다듬어져야 하고, 실행이 정해진 제한시간 안에 된다는 것을 증명해야 한다.

 * 금융 분야, 과학 연구에 사용되는 수치 프로그래밍(numerical programming) : 높은 성능을 필요로 함, 벡터연산(vector operation), 병렬계산(parallel calculation)

 

최적화를 할 때는..

* 가장 느린 코드를 찾아라 : 모든 코드를 고치지 말고 가장 느린(특별하게 느린) 부분만 수정

* 수정한 코드에 대해 unit test : 모든 수정은 side-effect를 유발할 수 있다

* 그럼에도 느릴 수밖에 없는 일은 ->

        1) 실행 속도를 높인다.

        2) 횟수를 줄인다

        3) 정말 필요할 때까지 미루었다가 한다(상대적으로 중요하지 않은 시간에 한다)

 

H/W의 성능은 시간이 갈수록 좋아지고 있다. 그리고 compiler단계의 최적화도 점점 더 좋아지고 있다.

이미 최적화가 되어 있는 library도 더 많아지고 있다.

==> 결론은 최적화보다는 정확하고 (사람이) 알아보기 쉬운 코드를 작석하는 것이 훨씬 중요하다.

728x90

'Programming > 좋은습관들이기' 카테고리의 다른 글

[코드멍키] 생각해 봅시다  (0) 2022.01.08
프로그래머의 종류  (0) 2022.01.03
설계하기  (0) 2022.01.02
Build 관점에서의 language 구분  (0) 2021.12.31
Comment 작성 요령  (0) 2021.12.30
.vimrc option  (0) 2011.07.22
Artistic Style : SourceInsight  (0) 2011.04.28
툴을 사용하자  (0) 2008.07.08
오류처리 - 프로그래밍 습관03  (0) 2008.06.26
오류처리 - 프로그래밍 습관02  (0) 2008.06.24

+ Recent posts