zashii-1434

Stats of My Life(おいしい人生を味わうために、コツコツとチャレンジしたことを書くブログ)

「新装版 達人プログラマー 職人から名匠への道」読みました。(2017年6冊目)I read "The road from master programmers talented programmer craftsmen to masterpieces". (6th year of 2017)

 

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

 

 

❑感想

本書はエンジニアでオススメ本としてよく選出される本ですね。

 

新卒で必読を勧めている会社もありますし、知人からは本書を読んでいない人は
エンジニアではないとまで言う人もいました。

 

今まで読んでなかった私はいったい。。。(汗)

 

彼曰く、本書の内容はプロダクト開発に必要な「考え方」だそうで、本書を理解していないとチーム開発時にコーディング、テスト設計等、プロダクト開発に支障がでるそうです。

 

本書を読んで、自分自身が特に気をつけないといけないなーと思ったのは次の3点です。

 

・二重化や直交性の意識が低く、それを許容してしまっているところがソース上あった
・コーディングする際に完全に理解していないままのところがあった
(特にAPIが多いです)
・シェルを使いこなそうとはしなかったこと
GUIでいいやと思ってしまっている自分がいた。)

 

エンジニアの人は是非、読むことをオススメするのはもちろんですが
エンジニアでなくても優れたエンジニアかどうかの確認ポイントとして本書の内容について話をしてみるといいかもです。

 

<メモ>

第一章 達人の哲学
 ・割れた窓を放置するな
 ・品質要求を明確にすること
 ・知識のポートフォリオ
  ・定期的に投資を行う
  ・多角化
  ・リスク管理
  ・安く買い、高く売る
  ・見直しと再配分
  毎年少なくとも一つの言語を学習する
  伝えることがらと伝える方法は車の車輪だと考えること
第二章 達人のアプローチ
 ・DRY⇒再利用しやすいようにしておくこと
 ・直交性・・・関係ないもの同士の影響を排除すること
 ・コードの結合度を最小化する
 ・グローバルデータを避ける
 ・システムのモデル化を行う
 ・モデルをコンポーネントに分割する
 ・各パラメーターに値を与える
 ・答えを計算する

第三章 基本的なツール
 ・シェルを使いこなす。GUIではGUI以上のことはできない
第四章 妄想の達人
 ・有るルーチンにおけるすべての事前条件が呼び出し側によって満足された場合、そのルーチンは作業完了時にすべての事後条件とすべての不変表明を保証する

第五章 柳に雪折れなし
 ・モジュールの結合度を最小にすること
 ・並列性の改善にはワークフローを分析すること
第六章 コーディング段階
 ・目隠しでコーディングをしてはいけない。完全に理解していないアプリケーションを作成しては×
 ・信頼におけるものを前提とする
 ・アルゴリズムのスピード(オーダーを見積もること)
 ・見積もりの検証を行うこと

 ❏いつリファクタリングを行うべきなのか?
 ・二重化しているとき
 ・直交していない設計 より直交性の高いコードや設計ができる場合
 ・時代遅れの知識
 ・パフォーマンス

 ❏テスト設計を行う際の注意点
 ・エラーの修正を考える前に、まずエラーの発生を避ける考え方が重要
 さらにコードの実装を開始する前にテストを作成すればインターフェースのテストも兼ねられる

第七章 プロジェクトを始める前に
 ・ユーザの視点に立つには、ユーザーと働くこと

第八章 達人のプロジェクト
 ・割れた窓をなくす 品質はチーム全体の問題
 ・カエルの煮物にならない(用心を忘れない)
 ・伝達をきちんとする
 ・DRY原則
 ・直交性
 ・職務権限ではなく機能によってチーム編成する
 ・自動化
 ・絵画の制作のやめ時を知る
 ・早めにテスト、何度もテスト、自動でテスト
 
 ❏何をテストするか?
 ・単体テスト
 ・結合テスト
 ・妥当性確認および検証
 ・リソース消費、エラー、リカバリー
  ・メモリ
  ・ディスク容量
  ・CPUの処理能力
  ・実際の処理時間
  ・ディスクの処理能力
  ・ネットワーク帯域幅
  ・カラーパレット
  ・ディスプレイの解像度
 ・パフォーマンステス
 ・ユーザビリティテスト

 

❑Impression

This book is a well-elected book recommended by engineers.

 

Some companies recommend recruitment at new graduates, and those who do not read this book from acquaintances
Some even said it was not an engineer.

 

I am the one I have not read until now. . . (sweat)

 

He says that the content of this book seems to be the "way of thinking" necessary for product development. If he does not understand this book, it seems that it will interfere with product development such as coding and test design at the time of team development.

 

Three things that I thought that I should take special care when reading this book are as follows.

 

· Low consciousness of redundancy and orthogonality, and it was on the source that it allowed it
· There was a place that did not fully understand when coding
(There are many APIs in particular)
· Things that I did not try to master the shell
(There was me who thought that it was good in GUI.)

 

As a matter of course, people from engineers are encouraged to read
You may want to talk about the contents of this book as a confirmation point whether it is a good engineer even if you are not an engineer.

 

<Memo>

Chapter 1 Philosophy of Guru
· Do not leave cracked windows
· To clarify quality requirements
· Portfolio of knowledge
· Invest regularly
· Diversification
· Risk management
· Buy cheap, sell higher
· Review and redistribution
Learn at least one language each year
Thinking that the way to tell the message is the wheel of the car
Chapter 2 Master's Approach
· DRY ⇒ Keep it easy to reuse
· Orthogonality · · · Elimination of influence between non-related items
· Minimize the coupling degree of code
· Avoid global data
· Model the system
· Split the model into components
· Giving values ​​to each parameter
· Calculate answer

Chapter 3 Basic Tools
· Make use of the shell. GUI can not do more than GUI
Chapter IV Masters of Delusions
· If all pre-conditions in an existing routine are satisfied by the caller, that routine guarantees all postconditions and all invariant assertions upon completion of work

Chapter 5 Snow Falls in Yanagi
· Minimize module coupling degree
· To improve parallelism, analyze workflow
Chapter 6 Coding Stage
· Do not code with blindfolds. Creating an application that you do not fully understand is ×
· Assuming things in trust
· Speed ​​of the algorithm (estimate the order)
· Verification of the estimate

❏ When should refactoring be done?
· When duplexing
· When it is possible to design codes and designs with higher orthogonality than designs not orthogonal
· Obsolete knowledge
·performance

❏ Precautions for Test Design
· Before thinking about correcting errors, the idea of ​​avoiding the occurrence of errors is important
If you create a test before starting code implementation, you can also test the interface

Chapter 7 Before You Start the Project
· To work from the user's point of view, work with users

Chapter 8 Project of Guru
· Quality to eliminate cracked windows is a problem of the whole team
· It will not become a simmer of a frog (Do not forget your precautions)
· Transfer properly
· DRY principle
· Orthogonality
· Team organization by function rather than job function
·Automation
· Know when to stop painting production
· Test early, test many times, test automatically
In the case of
❏ What to test?
· Unit test
·Combined test
· Validation and verification
· Resource Consumption, Error, Recovery
·memory
· Disk capacity
· Processing capacity of CPU
· Actual processing time
Disk processing capacity
· Network bandwidth
· Color palette
Display resolution
· Performance test
· Usability test