스트리트 코더(Street Coder)

책의 제목도 그렇고, 표지의  그림도 매우 궁금증을 일으키는 구성입니다.

개발자의 성장은 끝이 없고, 기존의 기술도 심도있는 학습이 필요하고 새로운 기술의 발전도 빠르기 때문에

"개발자 생존 가이드" 이 부분은 어느 개발자 분들이나 추구하는 방향이 아닐가요?

 

이 책에서는 어떠한 내용을 다룰까 궁금합니다.

책에서는 코드적인 내용이 있을까? 마인드 부분을 강조하는 것일까요?

 

·    저자분은 독학으로 개발자가 되었다고 합니다. MS에서 윈도우 핵심부서에서 근무를 하신 이력이 있으시고,
이책은 독학하면서 MS엔지니어가 된 저자의 경험을 바탕으로 수 많은 개발자를 위한 생존 법칙과 노하우를 담고 있습니다.

 

 

 

■ 목차 및 책 소개 살펴보기

·  목차

1장 거리로
2장 실용적인 이론
3장 유용한 안티패턴
4장 맛있는 테스트
5장 보람 있는 리팩터링
6장 조사를 통한 보안
7장 자기 주장이 뚜렷한 최적화
8장 기분 좋은 확장성
9장 버그와의 동거

목차는 이렇게 구성되어 있습니다. 

샘플코드는 C#, .NET으로 구성되어 있는데 코드를 보고 저자분의 의도를 파악하는 부분은 크게 어렵지 않게 소스를 볼수 있습니다.

특정 언어에 대한 소개 가 아니기 때문에 주요 관점을 설명하는 목적으로 사용하고, 이른적이고 내용이 더 많은 구성으로 되어 있습니다.

책의 소개 에 대해서 살펴보니, 아래 출판사의 책 소개글에서 핵심이 잘 소개 되어 있어서 여기서도 소개 하려고 합니다. 

 

아래 내용을 보면, 우리가 별도의 책으로 출간되는 항목들이 보입니다. "알고리즘", "리팩토링", "보안", "프로젝트" 등등 이러한 부분들은

우리가 매우 중요하게 생각하는 부분입니다. 저저의 입장에서 어떠한 부분을 접근해야 하는 경험 및 관점을 살펴볼수 있는 내용이라고

생각됩니다.

 

■ 2장. 실용적인 이론

·  내용을 살펴보면, 해당 내용,항목으로 java, c#, python, go등 모든 언어의 세부 기술을 적을수 있다는 생각이 듭니다. 

즉 거의 모든 언어에서 채택하고 있는 개념에 대해서 설명을 합니다.

예를 들어서, 알고르짐, 빅오에 대해서 간단히 설명하고

문자열, 배열, 리스트, 연결리스트, 큐, 딕셔너리(맵), 해시, 스택 등 우리가 모든 언어에서 사용하는 개념에 대해서 자세히 설명을 합니다.

이러한 부분에 대해서 한번 개념을 잘 잡아놓으면, 언어에 차이없이 쉽게 개념을 파악할수 있습니다.

다음에 설명되어지는 것 또한 모든 언어에서 언급되는 부분입니다. 타입에 대한 부분입니다.

변수에 대한 타입으로 인해서 발생되는 다양한 케이스, null에 대한 고민, 참조타입(메모리 저장방식)등 설명되어지는 부분이 개발 언어을

한번이라도 학습해본 개발자라면 충분히 공감이 되고 중요한 개념이라고 생각되어 집니다.

 

 

■ 3장. 유용한 안티패턴

·  제목이 매우 흥미롭습니다. 디자인 패턴등을 학습하면서, 의도적으로 적용하는 방법은 그렇게 좋아보이지 않는 경우도 발생합니다.

DB에서 의도적인 반정규화가 있는것처럼, 좋은 디자인 패턴에 대한 설명을 한것 반대의 입장을 살펴보는 것도 균형있는 방향성을 가질수 있을것 같습니다. 실제 무슨 디자인패턴은 사용하지 말아라!! 이런 관점을 설명하는 내용은 아닙니다.

 

·  사례로 기준에 구현된 "코드재작성"을 하는 것을 보통 힘들고, 해당 방식으로 진행하지 않고 기존 소스의 로직을 개선하는 방향으로 진행을 한다. 이러한 방식의 장단점은 있지만, 해당 코드를 개선하는 방식으로 진행시 어떻게 진행해야 하는지 하나하나 StepbyStep으로 설명을 합니다.

• 코드의 경직성에 맞서라
• 빠르게 옮기고 깨버리자
• 경계를 존준하라 : 추상화의 경게를 잘 파악해서 웹/비지니스/DB간의 경계를 잘 파악해야 하는 부분이다

• 공통적인 기능을 분리하라 : 우리가 새롭게 기존 조직을 개발하려고 할때, 공통으로 만드는 공통모듈에 대한 고민은 필수이다.

·  다른 관점

처음부터 다시 작성해야 하는 경우 등에 대해서 코드를 변경하는것이 위험하더면, 처음부터 작성하는 것은 훨씬 더 위험할것이다. 이럴때 어떤한 부분을 고민하고 생각해야할  기준이 제시되고 있다. 라이브러리에 대한 버전 충돌이 일어나는 부분을 고민해볼수 있는 가이드가 제시된다. 

·  새로운 것을 시도하는 입장

아래 입장은 매우 자극적이라고 보실수도 있는데, 무조건 사용하지 말라는 입장이 아니라, 열거형을 사용해라 / 구조체 등 꼭 고려해야 하는 부분을 언급하는 부분으로 내용이 구성되어 있으니 오해는 없었으면 좋겠습니다.

• 상속을 사용하지 마라
• 클래스를 사용하지 마라
• 불량코드를 작성하라
• 코드 주석을 작성하지 마라

객체 지향에 대해서 많이 알고 있는 SOLID에 대한 저자분의 의견
"P. 105 내용 소개..

약어를 만들기 위해서 억지로 만들기 위해 맞춘 느낌이 든다. ....(중략).. 이런 원칙의 가치를 아무런 확신 없이 그대로 받아들이는 것을 결단코 반대한다."

이런한 내용은 이책에서 잘 이해는 안되지만 무조건 읽어봤던 원칙에 대해서 조금더 현실적인 조언이라고 생각이 됩니다.

 

 

 

■ 4장. 맛있는 테스트

제목부터 아주 흥미로운 주제입니다. 또한 테스트를 언급하고 설명하는 것이 이 책의 완성도를 높여준다고 생각합니다.

우리는 보통 TDD를 이야기 합니다. 그런데 여기서 다루는 항목에서 TDD, BDD와 같은 용어 피하기는 어떠한 다른 시작을 제공하는 것일까요? 테스트가 누구나 필요하다고 생각하지만, 쉽게 접근하지 못하는 부분도 있는데 조금은 현실적인 조언 및 가이드로 구성되어 있지 않을까 생각합니다.

 

 

·  저자분은 어떻게 하는 테스트방법을 권장하고, 알려주려고 하시는 것일까?

수동테스트, 자동테스트 등등 우리가 이론적으로 다 알고 있는 것이다, 코드 리뷰도 어떻게 보면 수동테스트의 일환으로 볼수도 있다. 
아래 그림은 SW경력이 있는 분들이면, 누구나 생각해볼수 있는 flow입니다. 그림만 보아도 자동화된 테스트가 좋다는 것은 쉽게 알수 있습니다. 

 

· 단위테스트라는 말을 많이 사용하는데, 단위라는 기준에 대한 범위를 정하는 것도 어찌보면 단위테스트의 시작점이다.

· 단위테스트 프레임워크를 사용하는 것이 더 좋다는 입장이다. JUnit, NUnit 등등에 대해서 수동으로 테스트 로직을 작성하는 것보다, 다양한 케이스를 한꺼번에 실해야야 하는 입장에서 훨씬 편하게 접근할수 있습니다.

· 자신의 이득을 위해서 테스트를 작성하라. (보여주기 입장이 아닌, 실제 다른 변화를 검증하기 위한 코드로 구성하자)

· 테스트 전문서적을 보면 경계값에 대한 부분에 대한 검증을 많이 강조한다. 조건이 걸려있는 로직에 대해서 테스트를 이책도 강조하고 있다. 입력값 분할을 통해서 모든 범위를 커버하는 케이스를 확보하자.

· 모든 테스트를 작성하려고 하지 마라. 주요 버그는 20%의 기능에서 대부분의 버그 횟수를 커버하는 것은 8:2 파레토 법칙이다. 테스트를 현명하게 하는 방향으로 선택하는 것이 좋다.

· 컴파일러가 코드를 테스트 하도록 코드를 작성하도록 하자. (컴파일시, 오류를 체크하는것이 최고의 테스트 케이스라고 생각된다)

· 유효값을 확인하는 로직에서 중복을 제거하라

· 테스트 이름을 잘 정의하는 것이, 실제 운영코드와 테스트 코드에 모두 좋은 효과를 가지고 온다. (실제 이름이 명확하지 않으면, 그 의도를 파악하는데, 더 시간이 소요되기 때문이다)

 

 

■ 5장. 보람있는 리팩토링

리팩토링은 꼭 필요한 부분이다. 여러명의 개발자의 개발 코드를 조금더 개선하는 것은 기존의 개발자의 코드를 무시하거나, 잘못되었다고 원망하는 입장이 아닌 현재의 코드는 동작되는 것이고 시대의 흐름으로 주변 SW의 버전업, 새로운 기법등이 나와서 수행되는 자연스러운 과정으로 생각되어 질수 있다.

· 리팩토링은 왜 하는지 한번 remind를 해보면 아래와 같이 정의할수 있다.

1.  반복을 줄이코 코드 재사용을 증가시킨다
2. 여러분의 정신 모델과 코드를 더 가깝게 한다.
3. 코드를 더 이해하기 쉽고 유지관리하기 쉽도록 만든다.
4. 특정 클래스에 버그가 발생하지 않도록 한다.
5. 중요한 아키텍러 변화를 준비할수 있다.
6. 코드의 경적된 부분을 없앨수 있다.

· 한번에 큰 아키텍처를 변경을 수행하는 것은 결코 좋은 생각이 아니다. 

· 일반적으로 IDE를 통해서 메소드, 클래서, 공통요소를 추출하거나, rename하는것도 한 부분이지만, 조금더 전문적인 기준이 있어야 한다.

보통 하나의 기능을 담당하는 클래스, 모듈을 변경시에 각자 생각하는 범주가 다르다. 우선 이러한 범주를 설정하고, 작은 범위 단위로 접근하는것이 좋은 이유가 작은것을 검증하면서 확장해 나가는 구성을 가질수 있기 때문이다.

 

 

· 우리는 어떠한 기준으로 리팩토링 절차를 진행해야 할까?

1. 구성요소를 식별 : 의미적으로 다른 구성요소를 나누는것이 좋다.
2. 작업량과 위험도를 추정 : 컨트롤러, 뷰, 모델을 이용하는 작업시 업무에서 조금더 높은 위험도를 할당해서 구성하고 판단한다.
3. 움직이는 바퀴를 갈아끼는 것이라고 하는데, 기존 프로젝트와 신규 프로젝트 2개가 혼재되어서 잘 동작되는 방향으로 진행한다.
4. 더 쉽게 리팩토링 기법을 활용하자 : 인터페이스, DI 등을 통해서 종석성을 제거하는 방법을 이용한다.
5. 득보다 실이 많을때는 리팩토링을 하지 않은것을 고려해야 한다.

■ 6장. 조사를 통한 보안

앞장에서 다루는 큰 대분류에서 보안이라는 부분이 빠지면 안되는 중요한 부분이다.

SQL삽입, CSRF, XSS, 오브플로와 같은 개발시 익숙한 키워드 들이 보인다.

· 해당 부분의 내용도 단순히 주의해야 하는 부분에 대해서 간단히 언급만 하는 것이 아니라, 세부 예시를 들어서 설명해주고 

취약점에 대해서 어떠한 경우에 발생하는지 코드적으로 접근하는 부분으로 구성되어 있어서 이해를 쉽게 할수 있습니다.

· 조금 다른 관점으로 시야를 크게 생각할수 있는 항목들이 있스빈다.

1. 캡차를 사용하지 마라
2. 캐시를 구현하지 마라
3. 암호 관련하여서, 고정된 솔트를 사용하지 마라 / UUID는 랜덤이 아니다.

등에 대해서는 조금 더 다른 관점으로 우리가 놓치고 있는 보안취약점의 경험을 알 수 있습니다.

 

■ 그 이후의 내용

· 7,8,9장에서도 SW개발을 개발하는데, 고민해야 하는 부분이 어김없이 설명됩니다.

단순히 해당 시점에 개발이 완료되고 릴리즈 되었다고, 해당 서비스의 개선 및 수정이 없는것은 아니고 

서비스를 이용하는 트래픽 및 사용케이스의 변화에 따라서 고려해야 하는 경우가 설명되어집니다.

자신이 어려움을 경험하고, 비슷한 케이스에 대해서 트러블장애를 경험해보셨으면, 조금 더 현실적인 조언이라고 느낄수 있는 구성입니다.

 

 

7장에서는 최적화를 위해서 하드코어한 최적화 기술 및 성능문제를 해결하기 위한 접근방법의 내용으로 구성됩니다.

 

 

8장에서는 코드의 확장성을 높이는 방법과 병렬화 매커니즘이 성능과 응답성에 미치는 영향도를 다룹니다.

 

9장 마지막 장에서는 버그와 오류처리를 위한 모범사례을 설명하고 오류 복구 코드를 작성하는 기술에 대해서 설명합니다.

 

 

프로그래밍을 하다보면 느낄수 있는 거의 모든 사항이 담겨있다고 생각합니다. 

일반적인 이야기를 하지 않고, 조금 더 현실적인 접근법과 기존에 생각하지 못했던 부분에 대한 언급도 사고의 폭을 넓게 해주는 구성으로 되어 있습니다. 개발을 코드를 작성하고 나서 이후에 발생하고, 고민해야 하는 부분이 잘 정리되어 있어서 다양한 경험을 간접체험 할 수 있고

조금 다른 관점으로 우리를 발전 시킬수 있는 책이라고 생각합니다.

 

"길벗  <개발자 리뷰어> 활동을 위해서 책을 제공받아 작성된 서평입니다."