プログラミング・スタンス

昔と違って、今はマシンリソースを節約するために奮闘する必要はなくなったが、可読性を高めて保守しやすい状態にしておくことは今でも必須なので適切なプログラミング・スタンスはとても大切。

プログラミングは目的じゃない

そもそも1番重要なことは、手段を目的にしないこと。つまりアプリは「作るため」じゃなくて「使うため」に作るはず。ゆえに、プログラミングの醍醐味は作ったアプリを使い倒すこと。

だからコードの整理や最適化は程々に。

アプリ開発の起点はデータベース

まさにこれが本質。この思想はフルスタックエンジニアの魂そのもの。

• データは「資産」
• データの形＝アプリの設計思想
• データの流れを握ってないと、アプリの本質を握ってない

だからこそ、🔐「自分のDBは自分で持つ」＝アプリの心臓をコントロールするってこと。

FirebaseとかSupabaseとか、楽なのは事実だけど、裏側のDB構造や最適化、複雑なJOIN、パフォーマンスチューニングは見えない＝ブラックボックスになる。

リファクタリング

• GPTで作って動くようになったアプリを、更にGPTでリファクタリングするのは今は厳しいらしい
• リファクタリング、つまりコードの整理と最適化は全体情報を的確に把握しているからこそできる
• ゆえにリファクタリングは、言語やアプリの全体情報や挙動をしっかりと把握してから取り組むべき作業
• GPTが書いてくれたコードを理解するには別途それなりに言語の勉強が必要
• そのアプリがちゃんと動くならそれはそれで「十分に完成品」。リファクタリングは趣味にとどめる

backup2.sh みたいに、やりたいことが一目で分かる「説明的コード」にする。「難解パズル問題コード」じゃなくて。説明的コードにするためなら多少の効率は犠牲にする。コメントもめっちゃ大切。

手続き型 vs OOP

• 手続き型は軽量で速い。OOPは大き目で遅い
• 手続き型は「脚本」的なまとめ方。OOPは「擬人化」的なまとめ方
• OOPコード(プログラム)は擬人化のために余計な記述をしなくちゃいけない
• ただ手続き型も OOP 的なまとめ方はできる。ディレクトリ構造とか
• 手続き型は「脚本的」になりがち。ゆえにスパゲッティ化に流れがち
• OOP は「擬人化」のためにディレクトリやコードの整理をいい意味で強制される
• OOP の醍醐味は「擬人化」ゆえの感情移入、把握、管理のしやすさ
• OOP と言うよりは、ROP(Role-Oriented Programing)。役割指向プログラミング

要はトレードオフ。

軽さと速さを犠牲にしてでもOOPの「拡張/再利用/保守性」の高さが欲しいならOOP。OOPでスピードも求めるなら、それなりのマシンスペックやチューニングが必要になってくる。これはコーディングじゃない部分。

ChatGPT で OOP

ChatGPT は自分のコーディングスキルを２、３倍にしてくれる感じ。そもそも一定のスキルがないと底上げされない。

• まずファイル構成や命名をしっかり練る。GPT に伝える
• それぞれのクラスたちにやらせたい動きや連携関係をしっかり把握
• それぞれのファイルにコメントで具体的な動き(処理を記述)
• ChatGPTに「コメントを参考にしてOOPで書いて」と言う
• まず手続き型でコメント付きのコードを書いてもらう。そのコメントを再利用する感じ
• Instanceの使い回し、SQLクエリの節約、キャッシュ利用など、工夫したい旨も伝える
• ChatGPT は最高のコーダーなので、彼が作ってくれた完成コードを読んで色々と勉強する

これで、うまくいく。

命名規則

1. 後になってからの変数名の変更はとても面倒なので一番最初に「永久に決定」されるものとする
2. クラスには体を表す命名を。フィールドには属性を表す名詞を、メソッドには動きを表す動詞を付ける
3. メソッドはpublicで外部利用。privateで内部利用。オーバーライドを希望する時はabstractを付ける
4. インスタンス変数名は宣言されてる型の方のクラスのイニシャルを利用（PreparedStatement: ps）
5. イニシャルだと変数名が１文字になってしまう場合に限り子音３文字にする（Connect: cnc）
6. ２体目のインスタンスから変数名の後に数字をつけ始める（ps2）
7. 自作クラスのインスタンス名は先頭３文字にする（Monster: mon）
8. 配列変数名は複数形(s)にする。配列には複数のデータが格納されているので
9. その他の変数名は格納データの内容を適切に表すものにする
10. プリミティブ型の変数名は１文字（String: s, int: i）
11. データ格納変数名は名詞。動詞はメソッドのためにある
12. Mapを格納する変数名は「tableBunch」のように内部データが分かるものにする

備忘メモ

• オブジェクト指向の真髄：コードの徹底した重複排除＋クラスの擬人化
• 似てる箇所がある → 整合整理できる。もっとまとめて再利用できる
• ただ、少し冗長でもコードの意図や分かりやすさも大切なのでバランスをとる
• 沢山のエラーが発生してカオスにならないように最小単位ずつ進める
• 全て英語。シンプルで美しく脳に正しいイメージを伝える英語を使う
• ロジックを１文ずつしっかり読み、流れ全体を完全に理解していればエラーは必ず直せる
• toString で節目節目の流れを確認しながら進めていけばエラーの原因は特定できる

クラスの整理

ファイル

• フォルダ1 (SuperClass) -> フォルダ2 (SuperClass) -> SubClassファイル群と階層整理ができる
• 階層整理をすると各クラス群の役割状況、ポリモやメソッド等の使い回し状況などがtreeで俯瞰できる

メンバ

• 静的メンバ → フィールド → コンストラクタ → メソッド → 定石オーバーライド/ゲッタセッタ

オーバーライド

• toString：自作クラスのカスタマイズ情報を手軽に参照できるようになる
• equals：自作クラスをコレクションに格納するときはオーバーライド
• hashCode：HashSetなどが上手く動作しない時にはオーバーライド
• compareTo：Comparable を実装すると、Collections.sort が使える
• clone：Cloneble を実装すると、インスタンスを複製できるようになる

＊オーバーライドの定石はObjectを参照

外部リソース

• ファイルを読み書きするときはバッファリングを併用

チェックリスト

• 等価判定される自作クラスのequalsは全てオーバーライドされているか？