見出し画像

【開発哲学3_5】〜『CODE COMPLETE第２版(上巻)　第5章』の感想〜コンストラクションにおける設計

M_Kaku堂

いよいよ第2部🕺

ここからはコーディングの作法やループなど、どんどんより具体的な話になっていくからさらに楽しみ✨

感想

タイトルに書いているとおり、

シンプルイズビューティフルが一番

だなって感じ。

詳細

見出しとしては、

  1. 設計の難題

  2. 重要な設計概念

  3. 構成要素の設計：ヒューリスティクス

  4. 設計のプラクティス

  5. 一般的な手法へのコメント

  6. 参考資料

  7. まとめ

ってな感じ。

P96は参考になるかも。

何千行も手でコードを打って覚えて当たり前と豪語する人多いなあ。
覚えきれる物ではないし、長いだけのコードは改修するときに、バグの原因にしかならないのに。

コードは分けるし、共通で使う部分は纏める。

もあるけど、設計書、コーディング規約、ファイル管理など色々な手法があるけど、どんな方法でも、共通して最大の障壁になるのは、

  • 所属するチーム内や受け手を気にせずに

  • コメントなし

  • 見にくい

  • 作った人にしかわからない

  • 本処理以外で実行してほしくない処理を隠蔽化してない

  • 縦横無尽な設計図

  • バラバラに分かれすぎて、権限がないとひらけないサブプログラム

など、

独りよがりでチームメンバーや使う人を考えてない

に尽きるなあ。（結局はデザイン思考や文芸的プログラミング）

そういう人ほど誰かがミスをすると

  • 読んでわからないのはレベルが低いだけ

  • コード読まない方が悪い

など、相手のせいにするが、いざ、自分がそのようなグチャグチャなコードの改修や解析を仰せつかると、

「なんでこんなにサブプログラムが分かれているんだ。」
「なぜ、コメントを書いていないんだ。」
「こんな短いコードだと何をしているかわかる奴いる訳ない。」
など、普段の自分を棚に上げて言い始めたり。

そもそも、ユーザーさんがソースコードを自分と同じように開ける環境かどうかも意識していない　or　読める人ばかりではないことがわかっていない。
結果、「分からなきゃコードを読めばいい」前提の不可解極まりない説明書になる。

これって本章で書いていること以前の、

チームやユーザーことを考えて、常にプログラミングしとく

が大事なんだよなあ。かと言って、グレシャムの法則でもあるとおり、

  • 細かすぎる

  • 変更がきかないくらい当初の設計が型にはまりすぎている

  • 規約が多すぎる

  • 作らないといけないコード以外の資料が多すぎる

も融通が効かないツールやシステムしか生まないから要求変更があった時に、時間がかかるだけなんだけど。

じゃあ、どうしたらいいの？

本章で書いている基本的な、コンストラクションにおける難題をざっと読んで、イエスノーみたいな二律背反で決めずに、

  • ＜自分が今直面している課題は、どれか＞

  • ＜どの段階で発生している課題か＞

  • ＜どういった解決策がとれるか＞

  • ＜そもそも解決が必要か＞

  • ＜解決のために必要な資料や規約は何か＞

といったアプローチで、

課題解決にあった最適な方法を分析する

ことかな。

全事象に共通した万能な解決策＝銀の銃弾なんざ存在しないからね。

ボトムアップとトップダウン
発見的と文脈的

みたいなキーワードが出てくるとすぐに

対立軸

とすぐに思い込む人もいるけど、別に、対立している訳ではなく、ひとつの問題のうち、

  1. こことここはどういう動きになるか分からないから、まずはテスト結果をボトムアップ

  2. そこさえ分かれば、あとは、問題がなさそうだから、全体をスケジュールも含めて、トップダウン

  3. 何かあった時用に、都度何か問題や不明点があれば、ボトムアップ

みたいに、フェーズごとにやり方を変えて、複合的にやればいいだけの話。

トップダウンやボトムアップだけで最初から最後まで上手くいくプロジェクトなんて奇跡でしかない。

言われてみれば

、

当たり前

と一蹴する人もいるけど、そうやって考え方を大事にしない人ほど、いざ自分が直面すると、解決策を導けなかったり。

プログラミングは、

正解がない＝やり方は少なくとも数十通りある世界

なのに、

正解＝ひとつの答えを導き出そうとする

or　自分には関係ないからと思っているのか、

それくらいはすぐに解決できるべき。
すぐに解決出来ない　＝　レベルが低い or 素人

とすぐに決めつけて、

思いつきでコロコロと要求を変え、
いつまでも余計な経費がかかる原因　
＝　自分達

てことに気づいていない。

そういう人たちがプロと見做している人ほど、

考え方がわかっていないから、
文句言わないでただやみくもにやろうとするだけ

だったりなんだけど。

異なる複数の作業で、共通する操作や手順は何かみたいに、共有部分を見つけること　＝　抽象化

出来ないと、自動化なんておぼつかないし、そう言った意味でも、

考え方　＝　哲学

が大事なんだけどねー！

別に会社員でもないし、プログラマ不足で困っている職場なんて山ほどあるから、優秀なエンジニアほど、会社側から要らないと言われたら、やめてもっと良い他の職場に行くだけなんだけど。

まとめ

やっぱり、

💃シンプルイズビューティフル🕺
当たり前のことを当たり前にやる

って大事だな。

この記事が気に入ったらサポートをしてみませんか？