신입개발자 부터 주니어 개발자들을 위한 마스터 개발자 즉 숙련공이 되기 위한 조언들이다. 제목 그대로 프로그래머들의 길을 선택한 이들에게 멘토가 자신의 조언을 아낌없이 전해준다. 그것은 개발적인 영역부터 비개발적인 영역까지 좋은 개발자로서 나아가는 방법을 알려준다. 물론 기계적으로 적용하기 보다는 각자의 삶과 환경에 지혜롭게 적용하라 말한다.

총 7개의 챕터로 구성되어 있다.

1. 들어가는 글
2. 잔을 비우다
3. 긴 여정을 걷다
4. 정확한 자기 진단
5. 끊임없는 학습
6. 학습 과정의 구성
7. 맺는 글

여기서 가장 기억에 남는 조언들을 정리하였다. 삶의 모든 영역이 그렇지만, 좋은 개발자가 되기 위해서는 속도만큼 방향에 대한 깊은 고민도 필요한 것 같다. 이 책을 통해 좀더 옳은 방향으로 성장하는 개발자가 되기를 희망한다.

들어가며 좋은 커피를 대접하려고 해도 상대방의 찻잔이미 가득 찾다면 커피를 따를 수 없을 것이다. 견습생의 입장에서는 이러한 잔을 비우는 마음가짐이 필요하다. 이러한 마음가짐은 구체적으로 '나쁜 습관을 떨쳐내는 것', '자기 역활에 대한 자부심을 접어 두는 것', '경험 많은 동료들이 직관에 반하는 듯한 방식에 마음을 열어두는 것'들이 포함 될 수 있겠다. 즉 우리는 흰 띄를 매야한다. 그리고 나의 무지를 드러내야 한다. 동시에 무지에 맞섬으로 지식을 습득해 나가는 보습을 우리의 팀과 동료들이 지켜보게 해야하한다.

첫 번째 언어 언어를 하나 선택하고, 그 언어에 능숙해져라. 이 언어가 앞으로 몇 년 동안 당신이 문제를 해결할 때 쓸 주력 언어이며 실제로 쓰면서 마하는 기본 기술이 될 것이다. 그리고 그 언어를 잘 사용하는 멘토나 커뮤티니를 찾아야 한다. 그 언어에 대해 열정을 가진 공동체를 통해 단순히 언어의 문법적 구조를 넘어서 더 관용적인 방식의 언어의 미묘한 표현 방식을 배울 수 있다. 요즘은 좋은 도서를 통해 해당 방식을 학습할 수 있다. 가령 'Effective Java' , 'Effective C++' 같은 책들의 도움을 받을 수 있다. 그리고 주기적으로 일방적인 범위를 벗어나도록 언어를 사용해보라. 관습에 구해됨 없이 자유롭게 언어를 사용함으로, 언어의 강점과 약점을 파악할 수 있다.

그러나 그 언어에 너무 익숙해 져서 다른 언어를 배우지 못하면 안된다. 다양한 언어를 학습하는 편이 좋다. 다른 언어를 배울 때는 "급진적일 정도로 상이한 접근 방식을 취하는" 언어를 찾아야 한다. 가령 객체지향 언어를 안다면, 함수형 언어를 공부해보고, 서버 프로그래밍을 했다면 프론트 공부를 해봐야 한다. 즉 특정한 기술에 집착하지 말고 광범위한 배경 지식과 겸헝을 쌓아두어야 한다.

흰 띠를 매라 학습에 얻은 자신감을 그대로 두고, 얻은 지식은 한편으로 밀어두라. 즉 배웠던 것을 잊어버려라. 습관적인 프로그래밍을 방식을 잠시 보류하도록 자신을 훈련시키면 새로운 가능성을 발견된다. 바보 같을 수 있는 자유가 좋은 개발자가 되기 위한 핵심적인 요인이다. 새로운 지식을 받아들이려면 과거의 경험과 선입견을 한 켠으로 밀어 둘 수 있어야 한다. 새로운 지식이 충분히 흡수 될 때까지 새 지식과 옛 지식이 섞이는 것일 피해야 한다. 때로는 당분간은 생산성이 다소 저하되는 것일 감수해야 할 때도 있다.

특정 프로그래밍 패러다음으로 작성했던 프로그램을 하나 골라서 다른 패러다임에 속한 언어로 다시 구현해 보라. 그리고 해당 언어를 잘아는 멘토나 커뮤티니를 통해 검증하는 과정도 필요하다.

열정을 드러내라 전반적인 이해는 여러 수준의 경험이 상호 연관될 때 더욱 높아 질 수 있다. 그 무엇도 당연하게 여기지 않는 신참들과, 알 것은 다 안다고 생각하는 고참들이 더 자주 밀접하게 소통할 때가 거기에 해당한다. 심도 있는 지식이나 엄청난 생산성으로 기여하지 못하더라도, 팀에 열정을 불어 넣고 모든 것에 대하여 질문하는 것이 주니어 개발자의 본분이다.(물론 팀의 상황과 분위기가 고려되어야 한다)

구체적인 기술 구체적인 기술을 습득해서 유지하라. 당신을 채용한다면 출근 첫 날 회사에 어떤 기여를 할 수 있을지에 대한 답변에 해당 기술은 좋은 대답이 될 수 있다. 물론 숙련공으로 옮겨가면서 이런 기술들에 점차 덜 의존하게 되고 당신의 평판, 포트폴리오, 자질을 바탕으로 채용이 이루어 질 것이다. 그 때 까지는 구체적인 기술에 대한 당신의 장점을 명백하게 드러낼 필요가 있다.

무지를 드러내라 내일 나는 더 어리석게 보일 필요가 있다. 물론 어떤 기능을 끝내려면 얼마나 걸리냐고 물어보는 질문에 정확한 날짜를 말하며 안심시키는 일은 엄청난 부담이다. 그 사람이 듣고 싶은 이야기가 아니라 진실을 이야기 하라. 그리고 그들이 무엇을 원하는지 이해했고 당신은 그것을 배워가는 중이라고 말하라. 당신의 본능은 당신에게 무지를 숨기고 아는 척하라 시키지만 이는 당신의 성장을 방해할 뿐이다. 그리고 전문성은 우리의 여정에서 생기는 부수적인 결과이지 우리의 목적이 아니다. 장인이라면 익숙하지 않은 기술 분야나 새로운 업무 영역을 배울 때 자신의 전문 기술을 밀어 두고 흰 띠를 매는 용기와 겸손을 가질 필요가 있다. 즉 장인에게 가장 중요한 특성 중 하나는 학습하는 능력, 즉 무지의 영역을 파악해서 그 영역을 줄이는 것이다. 즉 무지를 드러내고 그 무지들을 하나씩 지워 나가라

능력의 폭을 넓혀라 구글 리더같은 블로그 모아보기 사이트에 가입해서 소프트웨어 관련 블로그들을 구독하기 시작하라. 그리고 자신의 블로그에게서 포착한 주제를 성찰하는 것도 고려해 보면 좋다. 최근 만들어진 신기술에 들떠 있는 로컬 유저 그룹에 참여하라. 이러한 학습의 과정은 단지 지식 뿐만 아니라 그 자체의 과정이 우리가 학습해야 할 기술이기 때문이다.

연습 연습 연습 실수해도 괜찮은 환경을 만들고 끊임 없이 연습하라. 그리고 당신의 연습 시간에 짧은 피드백 루프를 같이 짜 넣을 필요가 있다. 연습이란 이론적으로 좋은 것이지만 주기적인 피드백을 받지 못한다면 오히려 나쁜 습관을 드리옥 있는 것일 수도 있다. 연습이 완벽함을 만든다는 말은 틀렸다. 중요한 것은 무엇을 연습하는지 주의를 기울이고 진부함으로 빠지지 않도록 끊임없이 연습에 대한 평가를 해 나가야 한다. 매일 연습할 것을 올바르게 선택하는 것은 반복되는 수련 행위 그 자체만큼이나 중요하다.

부셔도 돼는 장남감을 만들라 토이 시스템을 설계하고 구현하여 실패해 볼 수 있는 여지를 만들어라 경험이라는 것이 성공 뿐 아니라 실패로부터도 얻어진다고 하면 당신에게는 실패해 볼 수 있는 다소 개인적인 공간이 필요하다. 그리고 중요한 것은 그것들은 본시 장남감이며 그러므로 재미있어야 한다는 점이다.

소스를 활용하라 연습,연습,연습 패턴은 스스로 자가갛지 못하는 나쁜 습관을 더욱 굳히는 결과만 가져올 것이다. 주변에 좋은 코드와 나쁜 코드를 구별한 만한 사람이 업슨 환경에서 당신이 짜 놓은 코드가 제대로 짠 것인지 어떻게 알 수 있을까? 다른 사람들의 코드를 찾아서 읽어라. 당신이 매일 사용하는 도구나 애플리케이션부터 시작해 보라. 가장 최신 버전의 소스를 다운로드해서 과거 이력을 조사한다. 소스 트리의 구조를 살펴보고 파일들이 왜 그런 식으로 배치되었는지 알아내 보라. 그리고 리팩토링이 필요한 경우인지 고민해 보고 그 기능을 당신이 장난감으로 구현해서 통합해 봤을 때 교육적 가치가 있을지 생각해보라.

다른 사람들이 작성한 갖은 종류의 좋거나 나쁜 코드를 읽음으로써 당신은 그 코드로 부터 의도를 꿰뚤어 보는 능력을 키울 수 있다. 그렇게 되면 당신은 다른 사람들의 코드에서 얻어낸 미묘함과 요령으로 채워진 도구상자를 갖게 된다. 오픈소스를 통해서 프로젝트에 속한 개발자들이 학습하고 새로운 요구사항에 대응해 가능 과정을 추적할 수 있다. 코드가 진화해 가는 과정을 공부하면서, 수백 개의 프로젝트를 직접 구축하지 않고도 설계 단계에서 내리는 결정의 영향을 잘 이해할 수 있다. 빌게이츠는 이렇게 말했다. "프로그래밍을 테스트하는 가자 좋은 방법중 하나는 30페이지 정도의 코드를 던져 주고 얼마나 빨리 통독하는지 보는 것이다" 알고리즘이 복잡한 오픈소스 프로젝트를 하나 골라 보라(git). 그 프로젝트의 소스를 둘러보면서 생소한 알고리즘이나 자료구조 설계 사상을 기록해라.

일하면서 성찰하라 당신 팀의 당연하게 여기는 것들에 대해 스스로 질문을 전져 보라 만약 괴로운 것이 있다면 그것을 개선할 방법에는 무엇이 있겠는가. 매일 쌓는 경험을 낱낱이 분해한 다음 새롭고 흥미로운 방법으로 재조립하여 그런 일상의 경험으로부터 최대한의 교육적 가치를 얻어 내는 것이다.

배울 것을 기록하라 쓰는 행위 자체가 가진 힘 역시 과소평가해서는 안된다. 배울 것을 기록하라. 그러나 배운 것을 기록만 하고 그냥 잊어버리는 덫에 빠지지 않게 노력하라. 당신이 쓴 글을 정기적으로 다시 읽어라.

배운 것을 공유하라 장인으로서 자신의 발전에만 집중해 왔다. 하지만 숙련공이 되려면 의사소통하며 다른 사람들의 속도를 내도록 이끄는 능력을 갖출 필요가 있다. 익힌 새 지식을 겸손하게 공유해라. 하지만 다른 사람들이 당신의 공유하는 방식이 겸손하다 느끼지 못한다면, 오히려 동료의 신뢰가 깨질 수 있다.

오름차순

List<Map.Entry<String,Integer>> entryList = new LinkedList<>(map.entry.set()); entryList.sort(Map.Entry.comparingByValue());

내림차순

List<Map.Entry<String, Integer>> entryList = new LinkedList<>(map.entrySet()); entryList.sort(Map.Entry.comparingByValue(Comparator.reverseOrder()));

import java.util.Arrays;

public class Sort{ public static void main(String[] args) { int arr[] = {4,23,33,15,17,19};

    //내림차순         
   Arrays.sort(arr);

   //오름차순
   Arrays.sort(arr, Collections.reversOrder())

}

}

1. 변수 초기회 오류 찾기

2. 반복문에서 인덱스 범위 지정 오류 찾기

3. 잘못된 변수 사용 오류 찾기

4. 자료형 범위 오류 찾기

   팁! 코딩 테스트에서 되도록 자료형은 처음부터 int가 아닌 long을 사용하자

시간 복잡도 => 문제를 해결하기 위한 연산 횟수 (1억번 연산 -> 1초로 계산)

-시간 복잡도 정의하기 빅-오메가 : 최선일 때의 연산 횟수 빅-세타 : 보통일 때의 연산 횟수 빅-오 : 최악일 때의 연산 횟수

-코테에서는 어떤 시간 복잡도를 사용해야 할까? 빅-오를 기준으로 수행 시간을 계산해야 한다.

빅-오 표기법 기준으로 수행 시간 O(n!) > O(2^n) > O(n^2) > O(nlogn) > O(n) > O(logn)

• 오른쪽으로 갈 수록 효율적이라고 할 수 있다.

시간 복잡도 활용하기

-연산 횟수 계산 방법 : 알고리즘 시간 복잡도 x 데이터의 크기

-시간 복잡도 도출 기준

1. 상수는 시간 복잡도에 계산에서 제외한다.
2. 가장 많이 중첩된 반복문의 수행 횟수가 시간 복잡도의 기준이 된다.

해당 도서는 총 12개의 목차로 구성되어 있습니다.

1. 어떤 알리리즘으로 풀어야 할까

2. 코드의 논리 오류를 어떻게 잡을까

3. 자료구조

4. 정렬

5. 탐색

6. 그리디

7. 정수론

8. 그래프

9. 트리

10. 조합

11. 동적 계획법

12. 기하

    그럼 start!