오브젝트objects, 코드로 이해하는 객체지향 설계

내용이 너무 자바처럼 verbose하다

짧은 내용을 너무 길게 설명해서 지겨워서 볼 수가 없다.

ex) ch07. 객체분해 p216~217 2페이지는 대략 이정도로 표현할 수 있다

일반적으로 작업기억은 7개의 chunk를 가지고 있다. 즉, 한번에 기억할 수 있는 숫자는 7개까지로 아래 11개의 연속된 숫자를 한번에 기억할 수 있는 사람은 드물다

29689928269

하지만 아래처럼 변환하면?

2968-992-8269

한번에 인식 가능하고 외울수도 있다.
11자리 숫자를 한번에 기억했다면 아마도 무의식중에 숫자를 나눴을 가능성이 높다

이런식으로 큰 문제를 작은 문제로 분해decomposite하면 문제를 이해하기 쉽고 더 좋은 해결이 가능하다.

이거 볼 시간에 DDD, JPA를 보자.
그래도 시간이 남으면 매트릭스와 에일리언을 보자

[도서] 소프트웨어 장인

그냥 개발수필에 가깝다
코딩호러의 어쩌고 했던책이 더 재밌었던듯

이 책에서 뭔가 내용이 많이 나오긴 하는데
맞는말이긴 한데 그냥 맞는말뿐이라서 별로 뭔소린지 기억에 남지 않는다

마틴파울러나 GoF같은 유명한 책은 많이 읽은 사람인 것 같다
개발방법론이나 조직에 대해 많이 생각해봤던
10~20년쯤 소프트웨어 개발을 했던 프로그래머
대부분 그정도 근방의 이력을 가진 사람이면 해 봤을법한 생각들

아예 초년생이라면
감명받을 수도 있겠고
뭔소린가 싶을수도 있겠는데
한번 훑어보는게 도움이 되려나

이 책의 태그를 자기계발서로 넣은건…
기술서적이 아니기 때문.

[도서] 도메인 주도 설계로 시작하는 마이크로서비스 개발, 핵심 개념과 패턴, 설계, 구현으로 배우는 DDD와 MSA

깊은 지식을 얻는다기보다는 그냥 관련기술을 훑어보기 좋다

DDD 이론서 보고 어떻게 할지 모르겠는 사람들을 위한 책이라고 봐야하려나

기존에 좀 하고 있던 사람들에게는 별로 얻을건 없고

다른 사람도 같은 고민을 하고 있었구나 하는걸 알 수 있다

주요내용

아키텍처

  • 레이어드 아키텍처
  • 헥사고날 아키텍처
  • 클린 아키텍처

https://engineering-skcc.github.io/microservice%20inner%20achitecture/inner-architecture-2/

이벤트 스토밍

도메인 이벤트Orange발생한 사건 pp로 표현
커맨드Blue도메인 이벤트 트리거
외부시스템Pink도메인 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템
액터Yellow개인 또는 조직의 역할
애그리거트Yellow도메인 이ㄴ트와 커맨드가 처리하는 데이터
상태가 변경되는 데이터
정책Lilac이벤트 조건에 따라 진행되는 결정
when, then
읽기모델Green도메인 이벤트 엑터에게 제공되는 데이터
사용자 인터페이스White스케치 형태의 화면 레이아웃
핫스팟Purple의문, 질문, 미결정 사항

jhipster

추천도서

아키텍처

  • 마이크로 서비스 패턴
  • 클린 아키텍처
  • 엔터프라이즈 애플리케이션 아키텍처 패턴

개발 프로세스

  • 소프트웨어 장인

설계

  • UML 패턴의 적용
  • 도메인 주도 설계, 위키북스 2011
  • 도메인 주도 설계 핵심 이론, 에이콘 2017
  • 도메인 주도 설계 철저 입문, 위키북스 2020
  • Introducing Event Storming, Leanpub 2019

개발영역

  • 자바 ORM 표준 JPA 프로그래밍, 에이콘 2015

[기술서] 파이썬 병렬 프로그래밍 – 내용없음

리뷰 내용 말고 책 내용없음
스레드나 그 메커니즘을 자세히 설명한 것도 아니고
튜토리얼이 잘 나온것도 아니다

GIL이라던가.. 하는 파이썬에서 논란이 많은 부분에 대한 설명이있었으면 했는데
그냥 키워드만 나온다
각 기술의 차이도 비교가 상세히 되어있지 않다.

그냥 파이썬에서 병렬프로그래밍을 할 수 있는 기술과 그 샘플코드 정도만 소개 돼 있다.

내부모듈 이용

  1. threading
  2. multiprocessing

라이브러리 이용(추상화계층을 얹어서 병렬프로그래밍 구현)

  1. Celery: 표준. https://docs.celeryproject.org/en/stable/
    multiprocessing, gevent, eventlet 등 활용
  2. PP: Parallel Python 안쓰이지 않나….

파이썬 분산형 서버를 만들때 사용하는 기술

이 책에서는 참고할게 없고 그냥 일반적으로는

  • RabbitMQ, Redis 사용시에는 Celery 사용
  • Kafka와 StreamData를 다룰 때는 FaustStreams 사용

threading이나 multiprocessing은 쓸 일이 있을까
한 서버에서 돌릴수 있는 정도의 프로그램을 만들때
웹프로그램에서는 사용하지 않음

데이터 아키텍처 전문가가 되는 방법 – 최수진

DA(데이터 아키텍처) 컨설턴트에 관한 얇은 책

2021년 이후에는 조금 맞지 않을
그리고 DA편향적인 생각이 많이 적혀있다.
개발자 다음단계를 준비한다던가…

DBA,DevOps,DA,Frontend,Backend…는 직군이 되서는 안되고 직책이 되야한다.
SoftwareEngineer는 보통 이 교집합을 수행한다.
DA만 하는 IT컨설턴트가 존재 하지 않는게 최선이다.

컨설턴트의 강점은 실력이 아니다.
권한이다.
검찰이 경찰보다 뛰어난건 지능이나 개개인의 능력이 아니라
지역의 이해관계에 얽히지 않은 벽을 뛰어넘는 권한이다.
컨설턴트도 마찬가지
대기업의 특정 부서나 직급에 상관없이
궁금한 것을 물어보고 잘못된 것을 지적할 수 있는 권한이다
제 3자이고 곧 떠날 사람이기 때문에 가능한 부분이다.

LG에서 휴대폰 사업이 잘못나가고 있는것을 누가 지적할 수 있었을까
구성원 하나하나다 다 개붕신이라 문제점을 인식하지 못하고 있었을리는 없다
좆지 직원들도 갤럭시,아이폰을 좋아하니까

  • DA
  • DBA
  • BA
  • AA
  • TA
  • ISP : Information Strategy Planning

고객의 업무에 맞는 데이터 모델
vs
개발하기 쉬운 데이터 모델

보통은 개발하기 어려운 데이터 모델은 잘못된 설계의 결과물이다
기존에 잘못된 업무를 그대로 따라서 모델링을 하면 이런 결과가 나온다
1 보통은 업무 자체가 변경되어야 하는 경우
2 상태값 설계가 제대로 안 된 경우

프로젝트 시작전에 처리되서 문서화되어야 할 것들

  • 일정
  • 설계
  • 용어정의

보통 이런것들은 무시되고 바로 프로젝트가 시작된다
프로젝트 진행과정에서 지속적으로 오버헤드를 발생시키는 문제들

개발자: SI-SM
DA: 모델링-튜닝

실용주의 프그래머The Pragmatic Programmer,

자기계발서 읽는 느낌이다
다 맞는 말인데
머리에 남는건 별로 없는

  • 이미 하고 있는 것들
  • 하면 좋은 것들
  • 해야만 하는 것들
  • 할 수 없는 것들

이렇게 분류 해 볼 수 있을까

그냥 한번 읽어보고 넘어가면 될 것 같다
잠재의식 속에 남아있겠지

커맨드라인

find . -name '*.c' -newer Makefile -print
zip archive.zip *.h *.c
tar cvf archive.tar *.h *.c
find . -name '*.java' -mtime +7 -print
find . -name '*.java' -mtime +7 -print | xargs grep 'java.awt'
grep '^import '*.java |
  sed -e's/.*import *//' -e's/;.*$//' |
  sort -u > list

여기서 할 줄 아는게……압축하는거

맨먼스 미신The Mythical Man-Month, 프레더릭 브룩스

내용

  • Prototype – 두 번째 시스템
    : 첫번째 시스템은 프로토타입이다
  • 1:10 업무효율
    : 같은 조직내에서 비슷한 급여를 받는 살마들 사이에도 업무능력 차이는 10배
  • 일정 늘어짐
    : 일정은 항상 늘어진다. 일정을 너무 루즈하게 잡은게 아니라면. 돌발상황에 대비해 조금 타이트하게 업무처리
  • 문서화
    : 워크북. 요즘은 위키를 주로 사용
  • 급하다고 많은 인원 투입
    : 의사소통 비용 증가
  • 소수정예
    : 큰 프로젝트 불가
  • 핵심개발인력과 보조인력 구조
    : 아키텍트와 모듈분할
  • 구체적인 마일스톤의 정의
  • 프로젝트 관리자는 의사 결정이 아닌 의사 소통

대상

오히려 개발자보다
한국에서의 특이직군인 기획자, PM
그리고 스타트업 대표, PO, 원청업체담당자가 봐야 할 책

읽고나서

소프트웨어 공학을 모를 때도
개발 업무를 하면서 맞딱뜨리게 되는 불편한 점들과 개선점을 생각했었는데
내가 찾아낸 최선의 방법의 핵심은 빠른 프로토타이핑과 작은 개선의 반복이었다.

이 책에서는 이것을 포함해서 그리고 더 다양한 상황에서의 대응법이 잘 정리가 되어 있다. 현업을 겪어보지 못했다면 그렇구나.. 하면서 감흥없이 넘어갔을 것 같다. 어차피 한번 겪어보고 다시 읽어야 됐었겠지
소프트웨어 개발 싸이클틀 겪어 본 사람이라면 이 책을 읽으면서 자기가 겪었던 문제점이 그대로 다 써 있다는데 놀라지 않을까

1975년 초판이라는데
아직도 그대로라니

UNIX 유닉스의 탄생

그냥 옛날이야기나 써 있을 줄 알았는데
기술서적이었다

유닉스 계열을 많이 경험 해 보지 않은 사람이 보면 대부분 내용은 그냥 넘어가야 하지 않을까
awk, sed, grep, … 을 한 번도 써 보지 않았다면 내용에 몰입하기 힘들 것 같다.

자주 사용하던 기술들이 어떻게 만들어졌고 왜 생겼는지를 알게 되는것으로도
기술을 이해하는데 도움이 되니
유닉스계열(리눅스)를 자주 사용하는 사람이라면 한번 보면 좋을 것 같다

미국의 벨 연구소

kt연구소랑 비슷한 분위기일 것 같다
독점기업의 지원금에 돈 걱정없고
빡빡한 듯 하지만 자유롭고
연구 좀 실패해도 아무도 뭐라 안 하고

KT연구소도 좀

리액트 웹앱 제작 총론 2/e: 리액트와 리덕스를 이용한 웹앱 개발 가이드, 2019

그냥 간단하게 잘 나와있다

jquery, jsp, php, asp 등등 구닥다리 웹프론트 기술을 좀 알고 있고
angular, typesript, express 정도는 조금 만져본 상태의 지식수준에서
볼 때는 대충 넘기면서 한두시간 보면 되는 정도..
요약을 잘 해 놓으면 네다섯페이지도 안되는 분량

리엑트나 웹 프레임웤을 처음 접하는 사람이 볼 수 있을지는 모르겠다
난 이 책을 보기전에 리엑트로 된 어드민사이트를 며칠 살짝 만져보긴 한 상태라서 좀 더 쉬웠는지도 모르겠다.
아예 프로그래밍 초보자라면 따라하고나서 남는거 하나도 없을 듯 하고

오픈소스 비지니스: 고객을 일하게 하라

목차

  1. 일하지 말고 일하게 하라
    1. 고객은 최고의 전문가
      그들을 활용하라 오픈소스 고객은 그 분야의 전문가다
    2. 고객을 전문가로 만들리
      전문가가 아닌 고객도 전문가가 될 수 있도록 교육자료를 제공하라
      그들은 우리의 제품을 더욱 향상시켜 줄 것이다
  2. 알아서 고치게 하라
    1. 고객들에게 스스로 고쳐 쓰고 방법을 공유하도록 만들라
  3. 고객은 최고의 노예다
  4. 일하지 않으면서 일하는 척 하라
    1. 고객은 서로 일을 해준다
    2. 다른 고객에게 우리(다른고객)의 업적을 전달하라
  5. 에필로그
    1. ㅇㅇ

목차만 봐도 지리겠다
돈버는 책이나 성공하는 책같은 제목과 소제목
두꺼운 똥소리만 잔뜩 집어넣으면 쓰레기같이 잘 팔리는 책 한권 나올 것 같다.

개발 조무사라면 꼭 봐야하는 책