いいコードとはなにか考える

つらつらと思っていることを書き連ねてみます

まとめ

• シンプルイズベスト
• コードがいいかわるいかよりもコードを深く理解しているかが重要
• バグがなければ何でもいいんじゃないか

メンテナンス性について

• いいコードはメンテナンスのしやすいコードなのか
• メンテナンスしやすいコードは気軽に変更できる、変更しても影響が小さいなどがあると思う
• でも結局はコードをしっかり理解しているかどうかな気がする
• コードを理解していないと気軽に変更も影響範囲もわからないので
• あとはテスト周りがしっかりしているか、ユニットテストのカバレッジやe2eテストがあるか、CDできる環境があるかも重要
• 毎回手動でテストするのは辛いし、そうなっているとリファクタリングする気も起きなくなる
• 今はいいコードだと思って書いても結局1, 2年後見たとときに理解できなかったダメなのでは
• 何も気にせずファイル1つで全部そこに上から順番に処理するようなスクリプトならどうだろうか

手法について

• 世の中にはコーディングに関するいろいろな手法や書籍がある
• いろいろあるがいろいろありすぎて困る
• 個人的には一番意識するべきは結局シンプルイズベストだと思う
• いかにシンプルに無駄なことをしていないか＝いいコードなのかも
• コードをシンプルに書くとは簡単に言えば一番上から順番に実行されていくコード
• いきなりどっかに飛んだり暗黙的なハンドラが呼び出されたりしない
• あるゴールがあるときにいろいろな書き方があるがその中から最適を選択できるかどうか
• 選択できるかどうかは経験則だと思う
• いきなり良いコードは書けないから徐々に良いコードにしていけばいいと思う
• それをできるかどうかも結局はコードをしっかりと理解しているかが重要だと思う

可読性について

• いいコードは読みやすいコードなのか
• メンテナンスしやすいコード＝読みやすいコードと言えるのだろうか
• 結局コードを知るためにはある程度学習しないとダメだとは思う
• いいコードだと学習時間が短いとは限らない
• コード把握までの時間を短くするにはドキュメントとトライアンドエラーさせることだと思う
• いいコードはしっかり抽象化できるている、重複がないというのがよくあるケースだと思うが個人的には抽象化されてすぎていても良くないと思う
• その心はコードがいろいろなところに分散しすぎていて追いづらいというのがある
• 可読性を高める最強の要素は「コメント」と「ドキュメント」なのかもしれない
• チームが日本人なら無理に英語にしないで積極的に日本語を使っていいと思う、コミットメッセージとかIssueとか

バグとの関連について

• いいコードはバグのないコードなのか
• 個人的にはこれはイコールではないと思う
• わるいコードでも全然バグを踏まないコードもあると思っている
• むしろレガシーコードのほうが安定しているケースもあると思う、いいとは思わないが
• いいコードにしようと思ってバグを埋め込んではいけない
• がバグをおそれてリファクタリングしないのもダメだと思う、難しい
• 結局バグを生み出さないこと品質を担保することが大目的なのであればレガシーコードを運用し続けるのも手だと思う
• ただ将来の技術的負債になることは間違いない
• レガシーコードにバグがいきなり発生して誰も直せないパターンとかはあるある
• レガシーコードを書き換えてモダンコードにするよりかは式年遷宮で全部書き換えるのがいいと思う
• 当然インタフェースは変えないようにしなければいけないが
• v2移行などで多少のインタフェース変更が出てしまうことはよくあるのでその場合はドキュメントやコミュニケーションでカバーするしかない

そもそも悪いコードとはなにか

• 相対する言葉の悪いコードとはなにか
• アンチパターン的なことなのだろうか
• 悪いコードを書かないようにすれば自然といいこーどになるのかもしれない
• そのコードが悪いと客観的に感じることができるかも重要
• なかなかそれは経験がないと難しいかもしれない

チームビルディングについて

• いいコードは人によって異なると思っている
• なのでチームで一つのコードを開発すると個人の思想や経験がコードに反映されてしまうことがある
• そういうときのために設計思想や開発手法やデザインパターンやフレームワークみたいなものがあるんだと思う
• がそれでも多少のブレはある
• 基本はチーム内でコーディング規約などを決める感じにはなる
• いいコードを書くためにはある程度の経験が必要だと思っている
• なので経験のある人の思想がチーム内のコーディング規約に大きな影響を与えてしまう可能性がある
• チームがそれを合意できるのであれば問題ないが押し付けるのはよくないと思う
• すでに安定しているコードに対してわざわざそれを適用するのかという判断も重要
• 将来大きな技術的負債になるのであればやるくらいでいいと思う
• 全員が全員同じレベルのコーダになるのは本当に難しい

テストについて

• テストもいいコードとして書く必要があるか
• テストも抽象化やリファクタリングをし続けたほうがいいのか
• そこまでのコストが割けるか、売上には直結しない
• プロダクトの品質には影響するかもしれない
• テストの目的はカバレッジを100%にすることではなく開発者の精神安定
• テストがしっかり書けている -> 積極的に安心して書き換えできるという意識が重要
• ただ個人的に思うのはテストはおまけでしかないので面倒だということ
• その面倒な作業を誰かがやらなければならないということ
• 分担すればいいというのもあるがそうするとテストコードの書き方がバラバラになりテストの保守性が下がってしまったりする
• 個人的にはテストコードを書くのは嫌いである

コンテキストによっても違う

• ちょろっとスクリプトを書くときには
• Webアプリケーションやスマホアプリのときには
• 一時的にしか使わない場合
• 将来的に継続的に使う場合
• どんなときでもクラスベースなコーディングが必要なのか

番外編: AIにがんばってもらう

• copilot のような自動生成にがんばってもらう
• AI が書くほうがいいコードなはず
• AIではないがコードジェネレータを作成するのもいいと思う

問題: どっちがいいコードなのだろうか

A

puts "hello"

B

require 'logger'

class Message

  @@logger = Logger.new(STDOUT)

  def initialize(title)
    @title = title
  end

  def say()
    @@logger.info @title
  end
end

Message.new("hello").say

• 用途にもよる？
• 将来どうメンテナンスしていくか？
• 経験のあるなしに影響する？