Archive

Archive

한번 읽고 끝나는 것이 아니라, 꾸준히 읽으며 자신을 돌아보려 할 때, 자신을 돌아보기 위해 읽으면 좋은 글 혹은 강의

Stay Hungry. Stay Foolish.

• Stay Hungry. Stay Foolish.

Stop thinking, Just Do

• Stop thinking, Just Do

Make Good Team

• 90년대생의 퇴사를 막고 싶다면

Growth

• Stack Overflow, 개발자의 성장과 경험 포인트

Self Arranged (Keep in Mind)

My Role in MIDAS

• Research and Development of In Memory Database(Pluto) and UI Framework(Phase, Alice UI), a dedicated engine within the company

개발자로서의 실력의 정의

• 알고리즘/하드웨어 최적화를 통해 느리지 않고 최대한의 퍼포먼스가 나올 수 있는 코드를 짜는 것

• 알고 있는 지식이 많아 최소한의 레퍼런스를 참고해서 빨리 코드를 짜는 것

• TDD/DDD를 적용해서 리팩토링 잘 하고, 군더더기 없이 깔끔한 코드를 짜는 것

• 객체지향적인 설계 개념을 적용해서 패턴이 잘 적용되어 있는 클래스를 설계하는 것

• 프레임워크 및 DB 세팅 잘 해서 DI/AOP/IoC등의 개념이 잘 들어 있는 코드를 짤 수 있는 것

• 어느 정도 실무 경험이 있어서 프로젝트 분석/설계 잘 하고 프로젝트가 잘 마무리 할 수 있게 가끔 코딩도 해서 프로젝트를 진행하는 방법을 아는 것

• 최신 기술 동향에 대해 잘 파악해서 기술 분석 및 장단점을 파악해서 내 프로젝트에 적용할 줄 아는 것

• 같이 일하는 사람과 문제 일으키지 않고 커뮤니케이션을 잘 해서 기간내에 일정 지연 없이 프로젝트 진행하는 것

• 기술 블로그 꾸준히 잘 쓰고, 내가 잘 아는 기술을 컨퍼런스에서 남들이 이해할 수 있게 발표 하는 것

Clean Code

마음가짐

다른 사람이 내 코드를 봤을 때 깨끗하다고 감탄했으면 좋겠다.

문학적인 코드를 작성해라. 마치 소설처럼 위에서 아래로 읽혀야 한다.

리팩토링을 해라(절대 미루지 말고), 테스트 코드를 짜라

개발의 시간은 돌아가는데 까지의 시간이 아니라, 리팩토링하는 시간을 포함해야 한다.

함수를 짜는 방법

논문을 쓰는 것과 같다. 먼저 생각을 하고 기록한 후 읽기 좋게 다듬는다. 함수도 마찬가지다. 처음에는 길고 복잡하다. 이름은 즉흥적이고 중복된다. 하지만 그 서투른 코드를 빠짐없이 테스트 코드를 작성한다. 그런 다음 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메소드를 줄이고 순서를 바꾼다. 때로는 전체 클래스를 쪼개기도 한다. 이 와중에도 코드는 계속 테스트 케이스를 통과한다. 최종적으로 함수가 만들어진다. 처음부터 딱 짜내지 않는다. 그게 가능한 사람은 없으니까.

문서화 및 공유(발표)

죽은 문서를 만들지 말라.

1. 어떤 개발자가 문서를 만드는 부서에 가고 싶겠는가?

   　-> 하지만 정말 필요하다.

   -> 그림이 들어간 논리적인 설명이 필요하다.

2. 좋은 문서를 작성하기 위해서는 구조적인 좋은 소스가 필요하다.

3. 나중에 시간나면 고쳐야지 – 절대 못 고친다.

   -> 항상 개발 할 때 모든 시간을 고려해서, 개발 + 문서화 + 리팩토링 3배의 시간을 잡아라

기획

기획시 끊임없이 나에게 해야할 질문

• 자신이 변하는데 관행적으로 하고 있는 것은 없는가?

• 꼭 이 일을 해야 하는가?

• 이 일을 하지 않는다면 어떤 일이 발생할 것인가?

• 지금 하고 있는 일을 또 한다면, 똑같이 할 것인가?

• 이 업무의 성과는 무엇인가?

• 이대로 하면 목표를 달성할 수 있는가?

• 이 단계를 몇 단계로 줄일 수 없을까?

• 이 방법 말고 다른 방법은 없는가?

• 고객이 원하는 것은 무엇인가?, 고객이 만족할 것인가?

리더쉽

개발팀에는 조악한 테크닉 보다는 팀웍이 중요하다.

객체지향은 업무를 분배하거나 팀원들 모두가 절대 규칙으로 여길 때 진정한 가치를 가진다.

끊임없이 문제 상황에 적합한 구조를 찾고 리팩토링 함으로써 올바른 길로 갈 수 있도록 노력하자.

요구사항을 어떻게 모든 개발자들에게 잘 분배하느냐?

1. 어떻게 문제를 분석할 것인가?

2. 어떻게 업무를 나눌 것인가?

3. 어떻게 업무를 전달하고 설명할 것인가?

4. 어떤 방법으로 개발자가 일하길 원하는가?

5. 어떻게 결과를 확인할 것인가?

6. 어떻게 통합할 것인가?