上巻、第４部ステートメントがこれで終わりー！

感想

上巻全体も踏まえた感想としては、

シンプルイズビューティフル
文芸的プログラミング

だねえ〜〜〜〜〜〜🕺

詳細

見出しとしては、

1. 論理式

2. 複合文（ブロック）

3. null文

4. 危険なほど深いネスト

5. プログラミングの基礎：構造化プログラミング

6. 制御構造と複雑さ

7. まとめ

て感じ。

やるかやらないか

はもちろん、個人の裁量。
ただし、以前の記事にも書いたとおり、

３日後のコードは他人

どこの職場にも

よくいる人で、
「書いている本人だからわかっていて、半年後も1年後も、ずっと一度書いたコードの構造を忘れないから、どんな複雑なコードを書いても問題ないし、それができるのがプロ＝職人だ」

で、関数にしろ、コードにしろ複雑怪奇なものを書こうとする人が多いけど、

本章の制御構造と複雑さで書いているとおり、
「有能なプログラマは自分の脳みそがほとんどちょっとしかないことを十分承知している。だから、とても謙虚な姿勢でプログラミングに臨む」
し、いくら自分の記憶力と技術力のアピールの場所として、コーディングを行なったとしても、

• 同じチームで一緒に働くメンバー

• 納入先の顧客側の保守メンテをするエンジニア

• 日々納入されたシステムを使うエンドユーザー

などの全てのステークホルダーが自分と同じほど天才的な記憶力を持っていない限り、結局、独りよがりなシステムを作るし、そんなもん作って、誰にも使われなければ、

次回から依頼も来ない
そういうシステムを作っただけの人

で終わり。
そんな人に限って、ステークホルダーとかデザインとかユーザビリティとかゆーても、

「自分はエンジニアだから関係ない。」

でコーディングの作法すら学ぼうとせずに、そのまま年数が経つとエンジニア不足な炎上案件以外からは干されて終わり。

まとめ

結局は、

開発とは、自分以外の全ての人への思いやり
（読みやすさ、使いやすさ、わかりやすさなどなど）

と、口ではゆーてるのに、

• 複雑なことばかりやろうとする自称プロ

• 詳しいコードはわからないし読めないのに、機能や操作画面が複雑でないと気が済まない上司、管理者、経営者

が、複雑なことをして今日もどこかで障害を起こしたり、DXや自動化が進まなかったりなんだよなあ。

上巻のまとめ

コードを書く準備から実際にゼロから書いていく作法をまとめてる感じ

いよいよ下巻💃
超楽しみ〜〜〜〜〜🕺