目次
- 良いコードを書く理由
- 変数、定数、メソッド
- クラス
- モジュール
- チーム開発でのテクニック
感想・まとめメモ
良いコードを書く理由
良いコードとは？
- 仕様通りの挙動
- 可読性
- 将来の変更に強い
仕様通りの挙動
バグが無いことの証明はできない。
証明する場合は、悪魔の証明になる。
仕様通りに動いていることを証明するためのテストと、それに向けてのコーディングは、良いコードを書く上の前提だということ。
可読性
名前を適切につけて、読む人に分かりやすくする。
個人的には、理解するまでの時間が最短になるようにするってのが重要だと思う。
変更に強い
これは、簡単なようで実は難しい。
若手の頃はよくわからなかった。
どうやって変更に強くすればいいのかと、毎回疑問に思っていた。
要するに、絶対的な価値をどこに置くかの問題。
ソフトウェア開発なら、ビジネス仕様が絶対。
ビジネス的に変わらない箇所と、変わる可能性が高い箇所を判断して作る。
ビジネスを理解することが、変更に強いソフトウェアを作ることの第一歩だと思う。
絶対良感を育てよう
雑誌で言っていた意味は、良いコードを見たときに、それが何故良いのか説明できる能力のことだそうな。
個人の主観によるのでは？とも思ったが、それを身につける方法は納得。
身につけるには、OSSを見たり、フレームワークのコードを追うなど。
良いコードについて議論するのは、周囲の人の民度によるかもしれないね。。。
たまにマサカリ好きが居たりもするからね。。。
良いコードの議論となる対象は、議論する人が書いてないコードがいいと思う。
あとは、常にコードを書くこともあった。
やろうと思うんだが、なかなか題材が見つけらないんだよね。。。
家に帰ると、どうしてもアニメみたりゲームしたり、ポケモンGoやって帰りが遅くなちゃったりする。
おそらく、常日頃からコーディングする題材を探すようなマインドがないとダメなんだろうな。
なるべくそうするようにはしているが、実践は難しい。
変数、定数、メソッド
変数
悪い変数は、情報量が少なく、理解を妨げる。
良い変数は、スコープが狭く、変数名で意図が伝わる。
スコープを狭くするは、激しく同意！
たまに、クラス変数・メンバ変数を気軽に使うヤツがいるが、かなり危険。
どれくらい危険かと言うと、いろんな洗剤をバケツに入れるくらい。混ぜるな危険だ！
何でかというと、どこでどう制御しているのか、分からなくなる可能性が高い。
今は大丈夫でも、ソフトウェアが進化したら、複雑化してワケワカメになる。
だから、作る時は、なるべくスコープを狭くしてやることが大事。
定数
定数を使うのは、だいたいマジックナンバーを減らすことが目的な事が多い。
ただし、マジックナンバーを減らすためにマジックナンバーの名称そのままでネーミングするのはダメね！
マジックナンバーの定数を切る時は、そのマジックナンバーの意味を定数名にしないと意味ない。
たとえば、Javaで例をあげると下記みたいなのはダメ。
public static final int TWO = 2
これ、なんの数値なのか全然分からへんがな！ってなる。
たまに、こういう変数名をつける輩がいるので、レビュー時は注意しないといけない。
メソッド
メソッド切り分けする理由
- 関心ごとの集約
- 再利用性を高める
つまり、DRY原則に従えってこと。
過度な原則の適用は注意。
メソッド名
- 簡潔
- わかりやすい単語
- やりすぎない
詰め込まず、やりたい関心事に細かく分類して、名称をつけてやれば、基本的に上記は満たせると思う。
メソッド作って満足せず、見返して、詰め込み過ぎてないかチェックする習慣をつけないとダメだね！
テストしやすいメソッド
テストしにくいメソッドは、だいたい関心事の分離ができてないことが多い印象。
作ってテストしにくいと思ったら、そのままテストコード作るんじゃなくて、作ったコードを見直す。
あと、テストしにくいコードは、開発者に負荷がかかりやすいので、必ず見直した方がいい。
名前の付け方
自分は、codicってサイトをよく使う。
ドンピシャなネーミングをつけてくれるので、結構使う。
ネーミング規約とかある場合でも、参考にはなる。
絶対的な価値観を自分に置かないことだと思う。ネーミングは。
結局のところ、読み手がわかりやすくないといけないから、ネーミングに迷ったら、だいたい自分は近くの人に聞いて、意味が通じるかを試す。
クラス
かなり難しいんだよね、クラス分割って。。。
責務の分割
責務分割は、鬼門。
経験が浅いと、余計な分割をしまくって、クラスのメリットが薄くなる。
システム全体を見て、登場人物達がクラスにあたるハズなので、いきなりクラス設計せずに、全体の概要を掴むことを優先する。
全体像がつかめたら、あとは責務について自問自答。
下記の点について確認する。
- 責務が集中してないか？
- 責務がかぶってないか？
- 責務の境界は明確か？
デザインパターン
GoFが考えた設計のパターンのこと。
ココらへんは、ググるかwikipediaの内容を見れば大丈夫だと思う。
雑誌で紹介されていたのは、FacadeとStrategyの２つ。
Facade
複雑な手続きを誰かに代行してもらおうというパターン。
個人的な感覚ではあるが、使い方を間違っていることが多い気がする。
なんというか、別のクラスにアクセスするための通り道みたいな感じ。
直接呼べばいいやん！ってことが往々にして感じる事がある。
手順の簡略化が、たぶん主目的だと思う。
手順がないようなクラスのために、Facadeを作るんじゃねぇ！って感じかな？怒りの原因は。
日本語訳で「玄関」みたいな感じになっているから、どこかのアクセスするために通過させる場所みたいになっている気がする。
Strategy
アルゴリズムの付け替えパターン。
Stateパターンもほぼ一緒。取り替えるのが、アルゴリズムか、変数かの違い。
例ではcase文使っていたけど、そうすると値を追加する毎に検索方法変わってないよね？が必要になるから、個人的には反対。
やるならenumでキーとアルゴリズムを持たせて、while文で検索させる。
※Rubyでできるかは知らない。。。
コイツは、マジでよく使うから、覚えた方がいい。
だいたいビジネスは、決まった値のときに挙動を帰ることが多い。
それを安全にするためにも、Strategyの習得は必須。
拡張性も高いしね！
モジュール
モジュールの概念に深く関わってないから、あんまり個人の考えはないんだよね。。。
Java9を見ていると、依存関係の解決が主目的かな？ 時期的に、今見てもふ～んで終わりそうなので、サラッと見て終わり
チーム開発でのテクニック
チームで開発するから、改修しやすいように作ることが重要。
コードレビュー
- 他人に説明できるように作る
- 見通しの良さ
- 属人化防止
相手の理解を助けるコードを書いていくことに重点を置くことが大事。
あとは、メンバーと対話して、チームの価値が何なのかを決めにいく行為も大事。
システム開発
結論としては、ゴールの共有が重要って感じだったかな？
XPについて触れられていた。
あんまりXPって理解してないんだよね。。。
今度、勉強してみよう。
ソフトウェアアーキテクチャ
アーキテクチャは超重要。
なにも考えないで作ると、小手先でなんとかできない問題にぶつかることは必ずある。
最初から考えろは無理だと思うので、問題の都度、どれがいいアーキテクチャなのか、よく考える必要がある。
アーキテクチャでやることは、大きな単位での役割分担を考えること。
関連書籍
この内容読んでたら、やっぱり脳裏には「リーダブルコード」がよぎるわ。。。
あれ、かなり良書だったと、今でも思う。
今後の自身のタスク
- XPを学ぶ
- コーディングを習慣化する
- コーディング題材を探すクセをつける
