Webナイト宮崎 Vol.8 ～てげ良いコード書きたい～ に参加しました
宮崎で8回目のLT大会に登壇してきました。 仕事で遅れ、発表順を最後にしてもったあげく、ギリギリの参加となってしまい、他の方のLTが聴けなかったのが残念。
スライドはこちら
制限時間5分のところ、10分喋ってしまいましたが、喋り足りなかったので(!?)、こちら少し補足します。
なぜを考える大切さ
冒頭では、なぜ良いコードを書きたいのか?ということを考察しています。
自然と誰もができるだけ良いコードを・・・と特に勉強会に参加する方などは考えていることでしょう。
しかし、やはりどの現場に行っても、少しぐらい悪くてもまず動けばいいという派はいるものです。
なので、チーム内でそういう話はしないといけないですし、共通認識を持っておく必要があるでしょう。
そういう中で漠然と良いソースを、、、と言っても説得力がありません。
まずはどうして良いソースを書く必要があるのかを自問する必要があるでしょう。
自分の動機づけにもなりますよ。
動機づけということに関してはかのKentBeckもこのように言っています。
誇りのもてない仕事で無駄にする時間はない。よいコードを書くこと自体が喜びであり、 そのコードを他の人が理解し、評価し、使用し、拡張してくれればさらに喜びは増す。
(「実装パターン」まえがきより)
ベストプラクティスを学ぶ大切さ
なぜがわかれば次はどうすれば良いソースが書けるのか？です。
自分の現場や、しごとの範疇だけで全てを理解し、生涯それだけで行けるほど甘い世界ではありません。
人生で携われる現場など数えるほどしかなく、そのほとんどの時間は保守に当てられるはずだからです。
ソフトウェアのコストは
コスト(合計) = コスト(開発) + コスト(維持)
コスト(維持) = コスト(理解) + コスト(変更) + コスト(テスト) + コスト(デプロイ)
です。
その中で一番高いコストは 「理解」コスト です。 (「実装パターン」第4章動機より)
つまり、理解するために良いコードを書く必要があるが、良いコードを書く時間はそれほどないということになります。
となれば、良いコードについて学習するためには現場だけでは時間が足りず他の方法を模索する必要があるということです。
そこで、本で学習したり、外部のコミュニティと情報交換したりすることが必要になるわけです。
自分はこれらのメタファとして、「ハンガーフライト」という言葉が好きでよく引用させてもらってます。
もっとハンガーフライトしたいですね。
現場での提案のためにも
同じ現場で同じソースコードを保守し続けるだけの仕事であれば、今のアーキテクチャに沿って適切な良いコードを書いていればいいでしょう。
しかし、世の中は驚くほどのスピードで変化しています。
自分はエンジニアになってわずか10年ほどですが、なりたての頃はまだドメイン駆動設計などそれほど広まってはいませんでしたし、もう少し前なら、メモリ不足で大量のオブジェクトを生成することなど考えられなかったはずです。
メモリが少なかった当時であれば、変数名はメモリ節約のため省略することが奨励されてきましたが、今は理解のしやすさを重視して省略しないことがベストプラクティスです。
変数名の頭に型の省略形を乗せるってのもありましたよね(intのiを取ってiCountとか)。
今であれば短いメソッド、クラスがベストプラクティスなので、そんなことをする必要はありませんよね。
テクノロジーの変化でできることが増えればソースコードの書き方だって変化していくものだと思います。
それを現場で提案できるのはやっぱり中にしかいない人ではなくて、外を見てきた人。ハンガーフライトしてきた人ではないでしょうか。
飛行機を飛ばすことは難しい。だからこそ知識を共有して現場に活かしていきたいですよね。
ということでLTの補足記事でした。