【開発哲学3_34】〜『CODE COMPLETE第２版 第34章(下巻)』の感想〜ソフトウェア職人気質とは
感想
コードコンプリート全体をコンパクトにまとめてくれてる章。
こう書いてしまうと、
この章しか読まないでわかった気になる人が出てくるかなあと思うんだけど、だからと言って、他の章を全く読んでないと、この章に書いてる意味は理解できないかなあ、
ここだけ読んでわかった気になると却って火傷するかな。（生兵法は怪我の元）
詳細
見出しとしては、
複雑さの克服
プロセスの選択
人間が１番、コンピュータは２番
言語の中へのプログラミング
集中力を助ける規約
問題領域に立ったプログラム
落石注意
反復、その繰り返し
汝、ソフトウェアと信仰を結びつけることなかれ
まとめ
WEBで
コードを調べるだけで、本などで学ばない人に多いなあ
て思う。
WEBで書かれている、
読みにくく、複雑で、難しいコード ＝ 職人
と思い込んでる人をこれまでにたくさん見てきた。
要求が変更されやすかったシステムの変更可能性や、
チームで作業するときに、コードの解析にならないように、読めばわかるコード（第32章）を実践してるだけなんだけどね。
複雑性って結局、
自分で複雑にしてることが大半
って気づかない人ほど、やたら凝ったコードを書きたがるんだよね〜〜〜
（ネットで見たことあるようなコード丸写しなんだけど、自分で書いたと言い張るし。
その割に、単純なコードは書けないし。理解してんのかな？って感じ。
てか理解してないのバレバレ💦）
そういう人ほど、人と比較や競争ばかりして、テストもせずに１回で完璧なコードを書けるのがプロだみたいな自負心持ってる人多いんだけど。
完璧な要求が存在しない以上、
世の中に完璧なコードもプログラミング言語も存在しない。
あるのはその時の状況に応じた最適解だけ✨
人の生活や作業は常に動いていくからねー！
どこかの３大メガバンクの一角とやらの障害も
組織自体が、派閥争いで複雑
＋
それぞれが使っていたシステムを並行使用
＋
革新性を狙って、システムの構造＝コンストラクションも複雑
＋
最新のシステム構造なのに、ベースがCOBOL（いつの時代⁉️）
👉コード見なくても、すでに複雑怪奇なコードになってそうだし、そりゃ障害が頻発するわなあ。って感じ。
今時、最新のシステムで選んでるテクノロジの波にも乗っていないし、、、。
システム開発で一番重視されるものは、
海外だと
垂直的統合
なんだけど、日本では、
組織で出世するのに必要な素養＝民主主義の悪い部分
が大きく絡んで、組織の論理と力関係、信仰しているソフトウェアやプログラミング言語に対する情熱などが混ざった
妥協
だから、
システム＝妥協の産物
て言われるんだよねー。
民主主義は、
対人では有効に機能することが多いけど、
ことシステムや開発に関しては、
民主主義を過度に持ち込むとシステム間の統合が図れなくなるから、
却って邪魔になるだけー。
かと言って、独りよがりで全部だからやればいいってことを言ってるわけじゃない。
もちろん、ここの章でも書いてるとおり、プログラマ間や上司とその分、綿密なコミュニケーションを取ることが大前提。
民主主義の悪い部分を持ち込むと、
妥協の産物＝使いにくいシステムと障害
を生むだけ
生き方にしろ、業務内容にしろ、人間関係にしろ
複雑性を生み出す＝物事を複雑にしてるのは、いつだって
人
（主に、自分自身）
まとめ
やはり常に、
💃それまでの経験と思い込みを
いつでも捨て去り、
シンプルイズビューティフルで
テクノロジの波に乗っていよう🕺
いよいよ
コードコンプリートも残り1章✨
GWはゆっくり、クヌースの『文芸的プログラミング』読もっかな🕺
この記事が気に入ったらサポートをしてみませんか？