hitode909の日記

趣味はマリンスポーツですの日記です

雑談

使って満足感のある、安心して使える、国産の、高級感のあるソフトウェアを作りたい。そのためには、ソースコードを最高に読みやすくて何の欠点もない状態にしなければならない。

例えば、このサッカーボールはどのようにして作られているのですかって聞いたときに、ブラジルの子供たちを学校にも行かせず労働させて作っていますみたいな感じだと、そういう感じでは縫い目のなめらかさまでこだわれなくて、転がればいいくらいの雰囲気になると思う。
ところで、このソフトウェアは古いよくわからないコードをよくわからないまま適当に書き換えて作りましたって聞くと、心配になると思う。
コードの品質が悪いと新たな機能を追加したり、不具合を修正するのが難しくなる。
コード読んでも、どこを変えれば良いか分からなくて、前に似たようなことをした人の手順を聞いて、その通りに真似して書いて動けば完成みたいになる。
実際どこでどうなって動いているのか把握せずに真似して書くと、無駄があったり、本当はより良い設計があっても、そのことに気づけなくなる。
我が家に代々伝わるレシピで肉の端を切り落として鍋に入れるけど、なんで端を切り落としてるのか分からない。母に聞いたら、母が肉の端を切ってたのは、鍋に入らないからだった。
フレームワーク使ってると、適当に真似して書いたら動くみたいになりがちだけど、似たようなところが他にできるときに真似して書くっていうのは変で、似たところがあるなら、共通化を試みるとか、設計を考え直した方が良いと思う。
全てのソフトウェアは唯一無二で二つとして同じ物はないからにたようなことを書くのは設計が手抜きということになると思う。
同じこと何度も書くというのはソフトウェアではあってはならない。
だから、ちょっとずつコードの品質を高めて、どこを見ても最高の状態にしたいと思っている。
最近、過去の変なコードを全部書き直す活動をやってて、しばらくやってみたところ、まだなんとかなるという感じだった。
本当はリファクタリングツールがあって、このメソッドをリネームとか、構文木を作ってから木を操作みたいにできると好ましいけど、そういうのはなくて、手で全部心を込めて書き換えてる。
書き換えるのは一度で、その後は変なコードと毎日出会うみたいな体験がなくなるから、けっこう良いと思う。
手で全部書き換えられるくらいの規模だから、リファクタリングの方針に反論あるならその人に託してもいいと思う。
新しいコード書くときに、気をつけることがあって、メソッド内で引数の型によって処理を分岐すると、実行時に何が入るか推測しながらコードを書き換える必要があって、リファクタリングするのが難しくなる。
あと、いろんな書き方があって、どっちでもいいとか、コードレビューで、must, should, mayを書く文化があるとして、shouldまでは分かるけど、mayっていうのが気に入らなくて、mayっていうと、直してもいいみたいな、空気を読んで直したかったら直してくださいみたいになると思う。
設計段階では自由な発想があるべきだけど、その設計を実装する時は、プランが二つあったら、そのどちらが良いかを、理由付きで述べられないといけないと思う。
そうでないと、無用なことで悩んだり、メンバーが増えると、こういう書き方の方がかっこ良くないですかみたいな話題で時間を無駄にしてしまう。
最高の書き方があるわけではなくて、いろんなことのトレードオフがあるけど、結局は、この書き方が最高ということがないといけないと思う。
まずはソースコードを最高すぎる、どこから読んでも、どこから見ても、とにかく最高みたいな形にしたい。
この記事、数日前から酔っ払ったときに書き続けていて、そろそろ高まってきたから、これで完成ということにしたいと思います。