728x90
반응형

「 네이버 그린팩토리는 24시간 멈추지 않는다 」

서점에서 어떤 책이 재밌을까하고 보다가 제목에 네이버라는 글자가 보여 읽어보게 되었다.

 

처음에는 그냥 몇 장 읽고 다른 책도 보려고 했는데 의외로 흥미진진한 전개에 책을 놓을 수 없었다.

 

그래서 책을 사서 마저 다 읽어보니 네이버라는 회사가 어떻게 일하는지를 어렴풋이나마 알 수 있었다.

 

총 5 챕터로 구성돼있으며 네이버의 역사부터 시작하여 흥미를 더 했던 것 같다.

 

네이버의 과거, 회사가 커지면서 발생한 문제를 어떻게 극복했는지,

 

대부분의 IT 회사에서 중요하게 생각하는 AI의 미래를 어떻게 그려나가는지로 마무리 지었다.

 

이해진 의장에 대해서는 많이 알려진 게 없어 잘 몰랐는데 책을 읽어보니 굉장히 도전적이면서 욕심이 없는 사람 같았다.

 

같은 IT 직종에서 일하다보니 현재 있는 직장과 비교해보기도 했다.

 

책을 통해 본 네이버는 굉장히 재밌을 것 같으면서도 힘들지도 모르겠다는 생각이 드는 회사였다.

 

직원들이 업무에 몰입할 수 있는 환경을 만들어주는 것은 매력적이지만 업무량은 상당할 것 같다.

 

IT 회사에 다니는 사람이라면 한 번은 읽어보면 좋을 거 같다.

반응형
728x90
반응형

Part 6 소프트웨어 이해하기

  1. 컴퓨터란 무엇인가?

    1. 인간이 설정한 목표를 달성하기 위해 일련의 기호 명령을 수행하고 데이터를 비교할 수 있는 모든 물질

  2. 소프트웨어 구성 요소: 구조, 동작, 결과

  3. 소프트웨어 개정판:(I)SAR 구별하기

    1. 구조: 프로그램의 구성 요소

    2. 동작: 일종의 동사

    3. 결과: 프로그램이 생산한 것

  4. 지식으로서의 소프트웨어

  5. 기술의 목적

  6. 간략하게 살펴보는 프라이버시 문제

  7. 단순성과 보안

    1. 보안을 지키는 최고의 방법은 단순성을 유지하는 것이다

  8. 테스트 주도 개발과 관찰 주기

  9. 테스트 철학

    1. 테스트의 전반적인 목표는 시스템에 관해 유효한 지식을 얻는 것이다.

6장에서는 소프트웨어가 무엇인가에 대해 설명한다.

 

단순히 소프트웨어가 어떤 구성으로 돼있는지부터 어떤 방향으로 나아가는 것이 옳은 것인지를 이야기한다.

 

또한, 테스트를 통해 소프트웨어 작동 방식을 이해하고 유지 보수할 수 있어

 

테스트 방법을 정확히 이해하고 제대로 활용해야 한다고 말하고 있다.

Part 7 나아지기

  1. 성공의 비밀: 나아지기

    1. 소프트웨어가 성공하려면 새 버전을 출시할 때마다 꾸준히 나아지면 된다

  2. 개떡 같은 부분을 찾는 방법

    1. 나아지고 싶다면 우선 가장 명백한 큰 문제를 찾아라 그리고 아무리 큰 수고가 들어도 꼭 해결하라

  3. '아니요'의 힘

  4. 프로그래머가 개떡 같은 이유

  5. 빠른 프로그래밍의 비결: 생각하지 않기

  6. 개발자의 자만심

    1. 진정한 겸양의 미덕을 갖춘 개발자라면 사용자의 세계에 자신의 정체성을 드러내지 않는다

  7. '일관성'과 '획일성'은 다르다

  8. 사용자는 문제를 알려주고 개발자는 해결책을 만든다

  9. 즉각적인 만족감 = 즉각적인 실페

    1. 소프트웨어는 언제나 장기적인 관점으로 보라

  10. 성공은 혁신이 아니라 실행에서 온다

  11. 훌륭한 소프트웨어

    1. 사용자의 명령을 정확하게 따른다

    2. 사용자가 예상한 대로 작동한다

    3. 사용자의 의도 전달을 막지 않는다

7장에서는 소프트웨어가 나아지기 위한 방법을 알려준다.

 

그리고 무엇이 소프트웨어를 나쁘게 만드는지를 이야기하면서 개발자가 알아야 할 것들을 말하고 있다.

 

총평

이 책을 읽기 전에도 다른 많은 책들을 읽어서 소프트웨어 설계를 할 때 무엇을 고려해야 하는지 대강은 알고 있다고 생각했다.

 

하지만 여전히 배움이 부족하다는 것을 한 장씩 읽어가면서 느꼈다.

 

책 초반에 뛰어난 프로그래머가 되고 싶다면 자신이 하는 일을 제대로 이해하라라고 한다.

 

이것과 같은 의미에서 나아지기프로그래머가 개떡 같은 이유에서 무엇을 배워야하는지 말하는데

 

돌이켜 생각해보면 시간을 투자해서 뭔가를 익히는데 노력을 쏟은 적이 잘 없었던 것 같다.

 

이제부터라도 책에 나온 대로 실행에 옮겨 더 나은 프로그래머가 될 수 있을 것 같다.

 

반응형
728x90
반응형

Part 3 단순성과 소프트웨어 설계

  1. 설계는 프로젝트 초반에 하라

    1. 미래를 고려하지 않으면 코드가 엉망으로 설계되고 너무 복잡해진다.

  2. 미래 예측의 정확성

    1. 미래 예측의 정확성은 시스템이 복잡해질수록, 예측하고자 하는 시점이 멀어질수록 낮아진다.

  3. 단순성과 엄격성

    1. 엄격한 애플리케이션일수록 더 단순하게 작성할 수 있다.

  4. 둘은 너무 많다

  5. 분별있는 소프트웨어 설계

3장에서는 올바른 소프트웨어 설계에 대한 방법을 알려준다.

 

첫째 미래에 무슨 일이 일어날지는 모르겠지만 언제나 안정적으로 동작할 수 있도록 설계한다.

 

둘째 변화를 고려해서 설계한다.

 

셋째 작은 범위에서만 변경하고 항상 단위 테스트를 한다.

 

넷째 규격화하고 작고 간단하게 유지하여 작업을 단순화한다.

Part 4 디버깅

  1. 버그란 무엇인가?

    1. 프로그램이 프로그래머의 의도에 따라 움직이지 않는다

    2. 프로그래머의 의도가 사용자의 평범하고 합리적인 기대를 충족시키지 않는다

    3. 의도한 방식에 따라 정확히 수행하는데도 사용자의 기대에 못미친다면 새로운 기능이 필요하다는 말이다

  2. 버그의 원인

    1. 버그는 복잡성을 줄이지 못할 때 발생한다.

    2. 코드가 단순할수록 버그가 줄어든 것이다

    3. 프로그램의 모든 것이 단순해지도록 늘 노력하라

  3. 재발을 방지하라

    1. 소프트웨어에서 가장 신경 써야 할 부분은 미래다

    2. 문제가 제대로 해결괬는지 확인하는 일반적인 가이드라인: 아무도 그 문제에 다시는 주의를 기울일 필요가 없을 정도가 되어야 한다

  4. 디버깅의 기본 철학

    1. 디버깅은 본인이 아직 담을 모든다고 자각하는 데에서 시작해야 한다

    2. 정상 시스템의 작동 방식 기억하기

    3. 더 많은 데이터를 모을 수 있는 방법 알아내기

    4. 정상 시스템이 어떻게 작동하는지 알아낸다

    5. 문제의 원인을 아직 모른다는 사실을 인정한다

    6. 문제를 일으키는 원인이 무엇인지 알아낼 때까지 데이터를 살펴본다

    7. 증상이 아닌 원인을 고친다

4장에서는 버그가 무엇인지 그 버그를 어떻게 찾을 것인지를 알려준다.

 

디버깅을 할 때 항상 생각해야할 것은 문제의 원인을 모른다는 것을 인정하는 것이다.

 

그래서 원인이 무엇인지 알아낼 때까지 데이터를 살펴보고 원인을 수정해야 한다.

 

다음 문장은 본인이 저런 식으로 했던 적이 많아 공감이 가서 발췌했다.

내가 겪은 프로그래머 **대부분**은 버그가 생기면 자리를 잡고 앉아서 버그에 관해 생각해보거나 원인이 무엇일지 이야기하고 싶어 한다.

- p79

Part 5 엔지니어링 팀에서 일하기

  1. 엔지니어링 생산성을 효과적으로 개선하기

    1. 개발자가 생각하는 문제가 무엇인지 알아내라

    2. 팀의 신뢰를 얻어라

    3. 친절한 태도를 갖추고 인내심을 발휘하라

    4. 자기 눈에만 보이는 문제 말고 사람들이 인지하고 있는 문제를 해결하라

  2. 개발자 생산성 측정하기

    1. 개발자의 생산성을 측정하려면 그 사람이 생산한 제품을 측정하라

  3. 소프트웨어 회사에서 코드 복잡성을 다루는 법

    1. 문제 목록 작성

    2. 팀 회의

    3. 버그 리포트

    4. 우선순위 선정: 제일 많이 괴롭히는 문제부터

    5. 과제: 각 작업자에게 버그 할당

    6. 계획: 언제 고칠지 결정

  4. 리팩토링할 때는 기능에 주목하라

    1. 일단 시간이 지날수록 시스템이 더 나빠지지 않고 더 나아지는 상태로 만드는 걸 첫번째 목표로 삼아라

    2. 리팩토링 한계를 설정하고 그 한계 내에서 제대로 작업하라

    3. 리팩토링 시 해당 코드의 제작 목적에 부합하지 않는 부분을 목적에 부합하게 바꿔라

  5. 친절과 코드

    1. 개발자 말고 코드에 대해 이야기하는 게 중요하다

    2. 친철한 태도로 다른 이와 협력해서 더 나은 소프트웨어를 만들어라

  6. 간략하게 살펴보는 오픈 소스 커뮤니티

    1. 기여자 유지하기

    2. 장벽 없애기: 문서 작성 및 소통 채널 생성

    3. 관심 유도하기

    4. 아주 인기 있는 제품이 되라

    5. 인기 있는 프로그래밍 언어로 만들어라

5장에서는 생산성을 효과적으로 개선하기에서는 팀원들과의 소통이 중요하다는 것을 알려준다.

 

저자가 참여했던 버그질라 프로젝트를 바탕으로 오픈 소스 프로젝트를 기획할 때 어떻게 하는게 좋은지 보여준다.

 

이는 오픈 소스에만 국한되는 게 아니라 회사에서 프로젝트를 수행할 때도 같다고 생각한다.

 

문서나 안내가 없다면 중간에 들어와 일하는 경우 어려움을 겪을 것이다.

 

그리고 잘 안 쓰는 언어로 돼있다면 그 언어를 배우는데 시간을 허비해 업무 생산성이 떨어질 것이다.

 

반응형
728x90
반응형

페이스북에서 "심플 소프트웨어"라는 책이 나왔다고 해서 어떤 내용인지 궁금해서 읽어 보았다.

 

책 표지에 다음과 같은 문장이 눈길을 끌었다.

 

100년 뒤에도 유용할 소프트웨어 설계 원칙 & 프로그래머의 바른 길!

코드의 단순성, 가독성, 안정성, 유지보수

단순함을 추구하라! 더 나은 프로그래머가 될 것이다!

 

뒷면에는 할 거면 잘 해라라는 문장이 맨 처음 크게 쓰여 있어

 

책이 무엇을 말하고자 하는지 대강 눈치챌 수 있었다.

 

파트는 총 7개로 나눠져 있는데 각 파트의 내용을 간략하게 정리해봤다.

 

Part 1 프로그래머를 위한 원칙

  1. 할 거면 잘하라

  2. 엔지니어의 자세: 나는 이 문제를 올바른 방법으로 해결할 수 있다

  3. 자신이 하는 일을 제대로 이해하라

  4. 소프트웨어 설계

    1. 구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 게 더 중요하다

    2. 유지 보수에 드는 수고는 시스템의 복잡성에 비례한다

1장에서는 능력자 프로그래머가 될 수 있는 방법을 알려준다.

Part 2 소프트웨어의 복잡성과 원인

  1. 복잡성의 단서

  2. API 분리

    1. 나쁜 API는 공개하지 않는다

    2. 공개한 API는 망가뜨리지 않는다

  3. 유용하고 중요한 새 기능을 추가할 때 하위 호환성이 방해된다면 하위 호환성을 무시해도 된다

  4. 복잡성은 감옥이고 단순성은 자유다

2장에서는 어떤 소프트웨어가 복잡한 것인지와 어떻게 복잡해지는지를 설명한다.

 

그리고 그 복잡성이 본인을 가두어버릴 수 있기에 단순성을 추구해야한다고 말하고 있다.

 

반응형

+ Recent posts