はてなブログ5周年ありがとうキャンペーンお題第2弾「5年後の自分へ」
5年後の私
10年後の私
型を定義するためだけにインターフェースを使いなさい
インターフェースのクラスへの実装はクライアントがそのクラスのインスタンスによって出来ることをについて表現すべきである。
メソッドがなくて定数の定義だけしてるインターフェース
namespaceを汚すというのはどういうことだろう
とにかく↑みたいのはやめなさい、と
・namesaceを汚すから(わかんね)
・何出来るのか表現してないので使い方がへん(へんな使い方は混乱をまねく)
強く関連するクラスやインターフェースがあるならそっちに定数を定義しろ
enumがいけてる感じならenumにしろ
インスタンス化できないユーティリティクラスでもいいぞ
いちいちクラス名書くのだるかったらstatic importしようね
namespaceを汚す、がわからん
定数を定義するのにインターフェースを作りたくなる気持ちはあったが、「強く関連するクラスやインターフェースがあるならそっちに定数を定義しろ」もしくは「enumをつかえ」は正しいと思う
ユーティリティクラスは便利なんだけどなんか気色悪いんだよな
なんだよユーティリティクラスってってなってしまう
StringUtilを作るんじゃなくてStringにメソッドを追加したらいいんじゃないかという気持ちになるというか
追加できないんだけど
かといって継承して拡張するのはたぶん混乱をまねく
SuperStringBuilderみたいの作ってもだいたい混在してわけわからんくなる(最終的に存在を忘れられて誰も使わなくなったあげく、誰だよこれ作ったの・・・ってなる)
何かアプリケーションに不具合があったときの原因調査にて何を考えてどういった作業をすべきか
大きく以下の2つに分けて考えるべきだと思っている。
経験と直感から原因を予想する
なんだかんだでまずはこれだと思う。
が、経験と直感による想定が全部はずれた時(もしくは何も思いつかなかった場合)に、経験も直感も度外視した、純粋な「勘」による調査をする人達がいる。あんまり良い結果にならないと思うんだけど、気持ちはわかる。
MVCモデルで作られたWebアプリで画面から選択したソート項目が効いていない場合に、例えばリポジトリとサービスはしっかり試験してるけどコントローラーは怪しいな・・・みたいな経緯があればコントローラーを疑うとか。
なるべくプリミティブなところから網羅的に原因を探る
もし経験と直感から原因が判定できなかったのであれば、これをちゃんとやるべきという話をしたいだけ(そして自分でもそれを徹底しようという話)なんだけど、結構これがちゃんとできない。
MVCモデルで〜の例で言えば、まずDBに発行されたクエリを確認するべきなんじゃないだろうか。ちゃんとソートされるような発行されていたら、次にリポジトリで余計なこと(取得したデータの再ソートとか)してないかみて、サービスで余計なことをしてないか見て・・・と、一番根っこのところから一つずつ(可能性を加味した順序付けはしてもいいと思うが、網羅的であること)原因になりそうなところを潰していくべきなんじゃないだろうか。
でもこれをせずに、永遠に感覚に頼った調査をする人はたくさんいる。
今クエリログ出してないし設定かえるのめんどくさいな・・・と思って、ただひたすらにソースコードを眺めるようなことをし続けてしまうような。
効率が(おそらく)よいにもかかわらず、真面目で網羅的な調査は面倒くさい。
なんでか考えて思ったのは、普通の生活でこういうやり方をして特をすることがあまりないからなんじゃないだろうか。
テレビがおかしくなった時に、私たちは、
「経験と直感から原因を予想する」まではやると思う。わからんけど。アンテナを疑ったり、コンセントがちゃんと刺さっているか確認したり。
でも、それで解決しなかったときに私たちはテレビの構造について1から調べたり、テレビを分解して何がまずいのか調査したりはしない。
なぜなら効率が悪いから。叩いてみて、駄目だったら専門家に任せたほうが楽だし、コストもかからない。
でもアプリケーションの開発をしている以上、自分が専門家で、これは必要な作業なんじゃないだろうか。
テレビの専門家に不具合の調査や修正を任せた場合も、まず「経験と直感から原因を予想する」はやると思うけど、叩いてなおそうとはしないんじゃないだろうか。(叩いたときの挙動から原因を判断することはあるかもしれないけど)
何を言いたいのかというと、私が不具合調査をするときに、2を徹底できるようになりましょう、ということ。
4年位SEをやったけど、2を真面目にやらなくてよい結果になったことはあまりなかった気がする。(まったくのゼロじゃないところが意識を鈍らせているが、トータルで考えればうんちである可能性が高い)
Foundation Level試験/資格試験-JSTQB認定テスト技術者資格/日科技連|ソフトウェア品質|SQiP研究会
ここの 「個人」の下のオレンジのとこ(個人の場合は)
直感的にわからん ちゃんとこういうの一から全部読まないのが悪いんだけど・・・