프로그래머란..

1. 꾸준히 한다.

.프로그래밍언어도 언어(?)라서, 하루에 몰아서 하는 것보다 매일 꾸준히 하는 것이 중요하다. 경력이 많은 프로그래머들도 몇달만 코딩을 안해도 감이 많이 떨어지는 것을 느낀다. .특히 프로그래밍을 처음 배우는 사람이라면, 꼭 컴퓨터 앞에 앉지 않더라도 책을 항상 가까이해서 문법 및 표현에 익숙해지도록 하는 것이 중요하다. 자주보는 것이 중요하다.

2. 반복해서 한다.

.단지 태권도교본을 잘이해했다고 해서 멋진 발차기를 기대할수 없는 것처럼, 책의 내용을 잘 이해했다고 해서 하루아침에 프로그래밍을 잘할수 있는 것은 아니다. .이해한 내용을 바탕으로 수많은 반복연습을 통해서만 지식을 진정한 자신의 것으로 만들 수 있다. (같은 예제를 공부하더라도 이리저리 조금씩 변경해서 공부하는 것이 좋다.) .처음 2~3번은 자세히 보고, 그 다음 부터는 하루에 10분간 10페이지를 훑어보는 식으로 반복하자. 몇달안에 책에 있는 모든 목차와 예제의 위치와 주요내용을 모두 파악할수 있을 것이다. (적어도 언어책 한권, 데이터베이스책한권 정도는 이렇게 할 필요가 있다.)

3. 좋은코드를 많이 보고 따라한다.

.이미 수많은 선배들이 여러문제들에 대한 코딩을 다 작성해 놓았다. 새로운 방법으로 문제를 풀겠다고 도전하는 것은 별 의미가 없다. "이럴때는 이렇게 하는 구나..."라는 것을 배우고 유사한 상황에서 활용하면 되는 것이다. 여러분들이 해야할일은 이러한 경험들을 많이 쌓아 나가는 일이지, 기존과는 다른 새로운 코딩방식을 만들어 내는 것이 아니다. .좋은 코드는 보기에도 좋다. 잘정리되어 있고, 별로 특별한 것이 없다. 프로그래밍의 각요소들을 잘이해하고, 각 요소들을 적재적소에 바르게 사용하면 되는 것이다. 단지 소스의 라인수를 줄인다고해서 좋은 코딩이 아닌것이다. 로직이 소스코드에 잘드러날수있게 쉽고 평범하게 작성하는 것이 좋은 코드인 것이다. 이창호의 바둑이 평범하듯이...

4. 기본에 충실한다.

.빨리 프로그래밍을 배워서 뭔가 해보고 싶은 여러분들의 마음을 이해하지 못하는 것은 아니다. 그러나, 프로그래밍 하루이틀 할 것도 아니고... 처음에 기본을 잘배워놓지 않으면, 그 이후에는 기회가 잘 없다. 실무에서는 매일 개발하기 바쁘고, 새로운 기술 배우기 바쁘고... .배울것이 많다고 생각할지 모르나, 실제로 원리는 모두 같다고 해도 과언이 아니다. 하나를 깊이있게 파고들면 나머지는 다 여러분 손에 있을 것이다.

5. 코드를 작성하기전에 순서도를 그린다.

."프로그래밍 = 코딩"이 아니라 "프로그래밍 = 로직설계 + 코딩"이다. 필자가 생각하는 로직설계 와 코딩간의 비율은 8:2정도이다. .포토샵만 잘한다고 디자이너가 아니라는것은 여러분들도 잘알고 있을 것이다. 새로운 기술이나 프로그램을 공부하는 것도 중요하지만,  어떤 과제가 주어졌을때 이를 잘 분석하고 설계하는 능력을 장기적으로 키워나가도록 노력해야할 것이다.(다양한 주제에 대해서 문제를 풀어보고 다양한 종류의 책을 읽자.) .문제를 구성하고 있는 주인공들을 찾아서 나열해보라. 그리고 이들간의 관계는 무엇이고, 규칙은 무엇인지 적어보라.(머릿속으로만 생각하지말고!!!)

6. 주석을 가능한한 많이 적는다.

.주석은 매우 유용하고도 중요한 요소이다. 그럼에도 불구하고 많은 사람들이 이를 소홀히 한다. 자신이 작성한 코드도 몇일만 지나면 이해가 안되는 경우가 많다. 적어도 이해하는데 시간이 걸린다. 주석은 이러한 시간들을 절약해줄것이며, 보다 에러가 적은 코드를 작성하는데 도움을 줄 것이다. 특히 여러사람이 공동작업을 하는 경우에는 더욱 더 중요하다. 서로를 위해서... .작업과 관련된 가능한한 많은 정보를 주석에 담도록 하자.

7. 작업일지를 작성한다.

.과학자들이 매일 연구한 내용을 일지로 적듯이 여러분들도 일지를 적어보자. 오늘은 이렇게 저렇게 해봤는데 잘안되었다... xxx.java의 코드를 이렇게 바꾸었다. 몇시몇분에 xx로 백업받아 놓았다... 라는 식으로 가능한한 자세히 적도록 한다. 이렇게 함으로써 여러분들의 경험을 기록 으로 쉽게 보관할수 있으며, 문제해결에 많은 도움이 된다.

8. 자신의 소스를 가꾼다.

.보통 코딩을 마치고 나면, 모든 것을 덮어두곤 한다. 원하는 결과를 얻었다고 거기서 그치지말고 이제 로직과 코드를 보다 효율적으로 개선할 방법이 없는지 고민해보자. 글을 써놓고 좋은 글로 만들기 위해 읽고 또 읽고 다듬듯이 코드를 다듬어보자. 여러분들의 코드를 구사하는 능력이 보다 향상되어가는 것을 느낄 수 있을 것이다. .여러분들을 위한 제안은 작은 프로그램을 만들어서 오랜기간동안 점차 발전시켜 나가는 것이다. 새로운 기능들을 하나씩 추가해가고, 기능을 발전시켜나가보자. 이과정을 통해서 여러분들의 실력 은 몰라보게 향상될 것이다.

9. 생각하라.

.항상 머릿속에 한 가지 문제를 준비하라. 지하철을 기다리거나, 화장실에서 볼일 볼때 문제를 풀어 보자. 유레카를 외치고 뛰어나올지도...^^;

10. 좋은 책을 선택한다.

.공부를 시작할때 제일 먼저 하는 일은 아마도 책을 고르는 일일 것이다. 보통 책하나에 수십시간을 학습하게 되는데, 책을 잘못선택한 경우 수십시간과 노력을 허비하는 셈이다. 바른 책을 고르는 일은 쉬운일이 아니지만, 최소한 몇시간을 투자해서 최선의 선택을 하도록 노력 해야 수십시간을 허비하는 일이 없을 것이다. .책을 고르는 법은 여러가지가 있겠으나, 가장 중요한 것은 본인이다. 서점에서 같은 종류의 몇가지 책을 놓고 서로 비교해보면, 시간을 들인 만큼 보다 나은 선택을 할 가능성이 높아진다. .많은 컴퓨터 서적이 독자들의 선택을 어렵게 하고, 컴퓨터 업계 특성상 좋은책을 만들기 보다 빨리찍어서 파는 것이 더 중요해진 요즘. 독자들의 바른 선택이 보다 나은 책이 출판되는 것을 가능하게 한다는 것을 알았으면 한다

코드잘 짜기

1. 설계는 프로그래밍에 있어 가장 중요하다.
2. 만들려는 것을 그림으로 그려라
3. 80%의 머리를 쓰면 20%의 비용이 절약되고 20%의 머리를 쓰면 80%의 추가 비용이 들어간다.
4. 프로그램 개발 속도를 좌우하는 것은 사람수도 잡다한 지식도 아닌 기본적인 문법이다.
5. 모듈적(Component)으로 개발하고 다른 시스템에 대한 영향은 최대한 줄여라
6. 메모리 문제는 메모리 관리를 고려해야 발생하지 않는다( pool, smart_ptr )
7. 기본적인 규칙은 지켜라. 특히 CQS(command query separator)는 특히 중요하다.
8. NVI(non virtual interface)는 매우 유용하다.
9. 개발을 위한 개발 환경을 만들어라. Log System, Bug Traps(LIB X), Reload 등의 기능들은 유용하다.
10. 버그의 85%는 잘못된 읽기와 쓰기 그리고 알고리즘에서 나온다( 트랩을 설치하자 )
11. C++ 에서 meta programming(template), pure programming(functor - pure function)은 능률을 높이고 버그를 줄여준다.
12. 데이터와 컨트롤 객체(interface)는 분리하라.
13. 다양한 프로그램들이 사용하는 기법은 언제든지 내가 만드는 프로그램에 적용될 수 있다. - 이벤트 드리븐, 데이터지향 드리븐, 파이프라인, 메세지드리븐 아키텍쳐, 가비지컬렉션 등
14. 버그를 유발할만한 데이타라면 코드가 아닌 데이터로 만들고 내가 아닌 다른 사람이 컨트롤하도록 하라.
15. 라이브러리를 사용하라.
16. 자기자신이 만든 코드를 기억하기 힘들고 사용하기 힘들다면 남들이 이해할 것이란 확신을 가지지 마라.
17. 파이프라인, 컴포넌트 레이아웃 등의 기법은 버그를 보다 쉽게 찾을 수 있도록 도와준다.
18. 코드는 반드시 재사용하도록 만들고 고려한다.
19. 코드가 주석이며 코드로는 이해하기 힘든 곳은 반드시 주석을 남긴다.

[동기부여]적절한 난이도란 무엇인가?

 

출처 : 김창준님의 "당신이 제자리 걸음인 이유: 지루하거나 불안하거나(http://agile.egloos.com/5749946)" 글을 필요할 때 마다 매 번 읽으면 좋겠지만, 보다 수시로 볼 수 있도록 책상 주변에 붙여놓기 위해 아래 이미지를 한 장 만들어본다.

[동기부여]일잘하는법!!!

1. 한 번에 하나씩 하라. 2. 문제가 뭔지 알아라. 3. 듣는 법을 배워라. 4. 질문하는 법을 배워라. 5. 합리적인 것과 합리적이지 않은 것들을 구별하라. 6. 피할 수 없을 때는 변화를 받아들여라. 7. 실수를 인정하라. 8. 간단하게 말하라. 9. 침착하라. 10. 웃어라. 11. 한단계 높은 사고를 하라.

– 항상 본인이 하는 일의 전략적인 의미를 음미 – 큰 그림없이 큰 성과 없다. – 입체적이고 복합적인 사고는 당장의 성과에도 영향을 미치지만, 장기적인 업무역량개발에 분명히 필요하다.

12. Output 중심의 업무를 하라.

– 최종 Outcome 도 중요하지만, Process Output 이 더 중요하다. – 단위 업무의 추진 로드맵을 그리고, 중간 Process 에서 어떤 Output 을 생성해 낼지를 미리 그려보아야 함.

[동기부여] 적절한 난이도

김창준님의 "당신이 제자리 걸음인 이유: 지루하거나 불안하거나(http://agile.egloos.com/5749946)" 글을 필요할 때 마다 매 번 읽으면 좋겠지만, 보다 수시로 볼 수 있도록 책상 주변에 붙여놓기 위해 아래 이미지를 한 장 만들어본다.

[동기부여] 좋은 습관이 이끄는 힘!!

탁월함은 어디서부터 올까? 천부적인 기질? 생각? 행동? 3년 전에 받은 리더십 교육에서 강사가 탁월함을 이끄는 것에 대해 대해 언급을 했었는데, 그 중에 중요한 것으로 꼽았던 것이 바로 '습관'이다. 물론, 좋은 습관을 가졌다고 해서 탁월할 수 있는 것은 아니겠지만, 좋은 습관만으로도 이전보다 더 좋은 결과물을 만들어낼 수 있다고 생각한다. 그리고, 프로그래머에게도 이것이 적용된다고 생각한다.   프로그래머가 가져야 할 좋은 습관 중의 하나로 (요즘 필자가 초식 수련중인) "TDD"를 들 수 있다. TDD는 테스트 코드를 먼저 작성하고, 테스트를 통과 시키고, 그 다음에 리팩토링을 하는 간단한 흐름으로 구성된다. 이 간단한 흐름을 지키는 작은(?) 습관만으로도 다음의 결과물을 얻어낼 수 있다.

• 테스트 시간을 줄여준다. 손과 눈으로 하는 테스트보다 컴퓨터가 실행하는 테스트가 훨씬!! 빠르다.
• 테스트를 할 수 있도록 노력하는 덕분에 나름의 좋은 설계가 유도될 가능성이 높아진다.
• 회귀 테스트를 만들어주기 때문에, 코드 수정에 대한 자신감을 갖게 된다.
• 반복적인 리팩토링을 함으로써 더러워진 코드를 일정 부분 청소해준다.
• 결과적으로 전반적인 코드의 가독성이 나빠지는 것을 방지해주거나 가독성을 향상시켜준다.

처음부터 TDD를 잘 하기는 어렵겠지만, TDD를 지속적으로 시도하는 것만으로도 위의 장점 중 몇 가지를 얻어낼 수 있으며, 이는 곧 개발 생산성의 향상으로 연결될 수 있다. TDD라는 (어떻게 보면 작은) 습관이 (TDD를 하지 않는 경우와 비교해서) 생산성을 올려주는 것이다!   작은 습관이 더 나은 결과물로 연결되는 경우의 또 다른 예로 단축키를 들 수 있다. 단축키가 별 것 아닌 것 같지만, 단축키를 잘 활용하는 개발자와 그렇지 못한 개발자의 코드 입력 속도는 많은 차이를 발생시킨다. 마우스를 잡고 이동하고 클릭하고 선택하는 시간보다 단축키를 눌러서 처리하는 시간이 빠르다. 이 시간이 쌓이면 쌓일수록 같은 기간 동안 더 많은 코드를 만들어내고 더 많은 생각을 할 수 있게 되고, 이는 곧 더 나은 품질의 결과물을 더 빠르게 만들어낼 수 있도록 만들어준다.   이 외에 좋은 습관으로 꾸준한 리팩토링, 일을 작게 나누기, 체크 리스트 만들기 등이 있을 것 같다.   좋은 습관. 좋은 습관이 우리를 탁월하게 만들어주진 않겠지만, 좋은 습관을 가진 것만으로도 탁월해 질 수 있는 가능성을 열어준다. 우리 모두 좋은 습관을 가져보자.   출처 : http://javacan.tistory.com/entry/%EC%A2%8B%EC%9D%80-%EC%8A%B5%EA%B4%80%EC%9D%B4-%EC%9D%B4%EB%81%84%EB%8A%94-%ED%9E%98