「リファクタリング」にみるコードの不吉な匂い
以下は「リファクタリング」Martin Fowler、に出てくる コードの不吉な匂い である。これらを感じるコードは不具合の温床になりやすい、ということらしい。
これらを眺めてなぜいけないのか、どう修正したらいいか。時々思い出そうと思う、思い出せなかったら読み直すのだ。
- 重複したコード
- 長過ぎるメソッド
- 巨大なクラス
- 多すぎる引数
- 変更の発散
- 変更の分散
- 属性操作の横断
- データの群れ
- 基本データ型への執着
- パラレル継承
- 怠け者クラス
- 早すぎる一般化
- 一時的プロパティ
- メッセージの連鎖
- 中間者
- 仲が良すぎるクラス
- 暮らすのインターフェース不一致
- 未熟なクラスライブラリ
- データクラス
- 相続拒否
- コメント
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- 作者: Martin Fowler,児玉公信,友野晶夫,平澤章,梅澤真史
- 出版社/メーカー: オーム社
- 発売日: 2014/07/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (11件) を見る
「ＵＳＪのジェットコースターはなぜ後ろ向きに走ったのか？」を読んで
USJのジェットコースターはなぜ後ろ向きに走ったのか? (角川文庫)
- 作者: 森岡毅
- 出版社/メーカー: KADOKAWA/角川書店
- 発売日: 2016/04/23
- メディア: 文庫
- この商品を含むブログを見る
最近USJ行ったので、前から気になっていた「ＵＳＪのジェットコースターはなぜ後ろ向きに走ったのか？」を読んだ。
ハリーポッターが当たるのは間違いない、だがそのためには売上の半分をつぎ込む設備投資をする必要がある上に、なによりも完成までの３年間をいかにして持たせるか。そのためにお金を描けずに客を呼ぶ方法は？ということについて頭をひねった経緯がえがかれている。とてもおもしろい。
実際行った感じたしかにUSJはよくできていて、ハリーポッターの世界がここにあるということに関してはあふれんばかりの努力を感じ取れたし、そもそも私はジェットコースターには乗れない方だけども、ここでしか買えないグッズなどを大量に買い込んだりして楽しめた。
とはいえ、フィールドは思ったよりこじんまりしているしお城はスケール感が小さいし、雨の日でも楽しめるようにしたというが実際は屋根がある場所がほとんどなく最悪の体験だったし、やはりこんなものかと思ってしまったのである。楽しかったからこそ、気に入らない部分が目につくとかそういったことだと信じたい。
この人のアイデアの考え方は、解決しなければいけない問題を正しく前提におくことでそれを埋めるアイデアをひねり出す、というものだ。これはつまり、宮本茂が言うところの「アイデアというのは複数の問題をいっぺんに解決することだ」ということの目的を逆算して実行していることになる。
宮本茂が山内や横井から受け継いだ天性の嗅覚で答えを嗅ぎつけていたのに比べ、この人はアイデアを閃かなければ行けない状況、というものを作ることでその問題を解いていたのである。またそれをただのひらめきで済ませないために、数字の裏付けを必ずとっていたというのは理想的と言える。
この人にプログラミングをやらせたらきっといいプログラマになるだろうと思った。
ところで、
アイデアの発想法についてはみな色々一家言あるようで様々な人が触れている。たとえば以前読んだもので言えば、「アイデアのつくり方」などは森岡氏が言っている手順ほぼそのものと言っていい。
- 作者: ジェームス W.ヤング,竹内均,今井茂雄
- 出版社/メーカー: CCCメディアハウス
- 発売日: 1988/04/08
- メディア: 単行本
- 購入: 91人 クリック: 1,126回
- この商品を含むブログ (378件) を見る
また森岡氏が言うところの、「リアプライ」という概念はこれはつまりすでにあるものを形を変えて実行するということであるが、それは星新一が実践していたところの「アイデアは異なる同士の組み合わせ」のことであるし、そもそもそれはアイザック・アシモフの言葉である。
このようにアイデアとその実践ということについては、多くの人がみな色々な方法を試し実践していたのである。幸い私はそのようなことをしなければ打破できない状況に置かれたことはほとんどないのだが、にっちもさっちもいかなくなったのならこのような偉大な先人のことを思い出したいと思う。
2016年を振り返って
去年立てた目標
フロントエンドは諦めたので、サーバー側の勉強をしていく。いかしたAPIはどういうものか？そのための適切な設計は？テストの書き方は？そういう感じのこと。 品質について体系的なことを知りたい、というのは諦めない。 ブログをちゃんと書く。ちゃんと普段から勉強してれば月に１つくらいは書くことあるというのは経験上わかっている。それができるくらいには学習を怠らないようにしなくてはいけない。 やらない言い訳のために自分でハードル上げてしまっている気がするので、もっと気軽にアプリケーションを作りたい。ライブラリだか、ゲームだかはわからないけれど、とりあえず３日くらい勢いで書いて公開方法はあとから考えるくらいの気軽さで取り組めるメンタルに変えていきたい。 あと漫画かけるようになりたい。
目標を達成したか
- サーバー側の勉強
- 明確にこのために取り組んだものはない
- 品質について
- やっていない
- ブログ書く
- 去年よりも減った
- 気軽にアプリ作る
- pkmn-tool.appspot.com とか作った
- 漫画書く
- 例大祭にサークル参加してた
所感
全然やれてないなぁと自分で思った。プログラミングがうまくできなくてとにかくプログラミングができるようになりたいと思っているのだが、だいぶ迷走しているのだと思う。１つには基本的なことを何も知らないのだということについてちゃんと受け入れて勉強するべきだと思っている。
そこで、コンピューターサイエンスをちゃんと勉強したいと思う。とはいえ、じゃあ仕事で目の前のコードを書くときにその価値があるのか？というと多分そんなに差はない。知っていれば役に立つことも万が一ある、程度でしかない。でもだからこそそういう部分の積み重ねで差がついてしまっているのだと考えている。
勉強なくちゃいけない、プログラミングできるようにならなくちゃいけない、と思っていてもじゃあ何をしたらいいのかというのはよくわかっていなかった。そんな中例えば Google Tech Dev Guide こういうページがあって、一人前のソフトウェアエンジニアになるために勉強することが並んでいる。これはとてもありがたくて上から順番にやっていこうと思った。
そして挫折したのだ。私は学生がやるようなこういったものを学ぶことのできるレベルにさえ至っていないということだった。だからそこにいたるまでを１つずつ丁寧に積み上げ直すしかないだろうと思っている。それで仕事ができるようになるかというと多分関係ない。そこまでわかっていてもやるしかない。他にやり方はわからないからだ。
仕事でやるプログラミングをうまくやれるようになるための方法として、いろんなコードを読むようにすることを考えている。これは薄々感じていたのだが、私が今まで読み書きしたコード量はいわいるすごい人と比べたら圧倒的に少ないのだ。そこに問題の本質があるように思う。仕事で使っているdjangoとか、pythonらしいコードとして評判だったGAEのPython SDKとかを読んでみたいと思う。
漫画を書きたいと思って例大祭で同人デビューした。やりたいやりたい言いながら手を付けなかっていなかったことに挑戦したのはがんばったと思う。あとこっちは趣味なので当然だけど、プログラミングの勉強をするよりもずっとずっと楽しいのだ。今後もやりたい。
来年の目標
思考する機械コンピューターを読んで
思考する機械コンピューターを読んだ。とてもおもしろいのでみんな読んだほうがいいと思う。 コンピューターサイエンスを勉強してみたくてやろうと思って講座みたいなやつを眺めていたんだけどまず何言ってるかわからないみたいなことになって困った。そもそもどういうことを考えるのがコンピューターサイエンスなのだろうかと知りたいなぁと思ってたらこれがおすすめされていたので買った。特にCPU、というか演算装置っがいったい何なのかがよくわかっていなくて、読んでも全部わかったわけじゃないけどなんとなくとっかかりがつかめたのが良かった。
- ブール代数
- AND
- OR
- NOT
- ビット
- 違いを表す最小の単位
- 論理回路の実装
- ビットを表現できれば物はなんでもいい。木と棒、電流、水流、1と0。
- 複雑な入力や出力を持つ論理関数も論理回路の組み合わせで表現できる
- コンピューターの基本部品
- 有限状態機械
- ブール論理で表現されたルックアップテーブルと記憶装置で表現される。
- シーケンス(連続した処理の手順)を認識できる
- チューリングマシン
- アルゴリズム
- 計算可能なものを計算する手続き。
- 計算量に基づく処理時間が大きく変わる。
- ヒューリスティクス
- アルゴリズムで解くと現実的ではない時間がかかってしまうような問題で、答えの精度は下がる代わりにだいたいの場合に正しい回答を得るような方法
- データ圧縮
- グループ化
- 意味のある情報だけを残す
- 並列コンピューター
- 優れた並列処理はデータの違う部分をそれぞれのプロセッサが担当する
- 人工知能
- フィードバック方式
- ニューラルネットワーク
- 工学的手法以降
- 進化論的シミュレーション
- 作者: ダニエルヒリス,W.Daniel Hillis,倉骨彰
- 出版社/メーカー: 草思社
- 発売日: 2014/06/03
- メディア: 文庫
- この商品を含むブログ (7件) を見る
P8H67-V REV 3.0をWindows10でスリープから復帰しない話
困ったこと
ASUS P8H67−V Rev3.0がWIndows10でスリープから復帰できない、ブルースクリーンになる。
対応方法
Station-Drivers - X99 OC Formula から Intel Chipset Device Software Driversをダウンロードしてインストールしたら直った。
経緯
ASUSのマザーボード、P8H67−V Rev3.0を使用している。これをWindows10にアップグレードしたときに、スリープから復帰できなくなったり、メモリー系のエラーを出してブルースクリーンを吐いたりするようになった。この異常の直後はUSB周りのドライバが死ぬことは知っていた。 しかし何をすれば解決するのかがわかならなかった。
これを書いた前日の深夜、とうとうあらゆる操作を受け付けずに起動できなくなった。新しいメディアからクリーンインストールしてもうまくいかない、そしてデバイスマネージャーからドライバを更新しようとして、OSに対応するバージョンがありませんという趣旨のエラーメッセージを見た。これで原因がわかった。
マザーボードのドライバがWindows10に対応していない。
ならばと思ってASUSのサポートサイトを見に行ってもサポート対象？がWindows8.1までしか用意されていない。これはどうしたものかとおもいきや、すでに同じことで悩んでいた人がいた。
価格.com - 『Windows10 64bit使用でのエラーについて』 ASUS P8H67-V REV 3.0 のクチコミ掲示板
これによるとStation-Drivers - X99 OC Formula が型番違いだがこのチップセットドライバを使うことができるようだ。このままでは動きやしないしし、いちかばちかいれてみた。結果うまくいった。
しかし困難は続いた。Windos10は足りていないドライバを勝手にインストールしてくれる機能がある。動作を確認しているうちにこれが働いたようでグラフィックドライバが入った。しかしすでにnvidiaのドライバがインストール済みであった。深く考えずに再起動した。そして画面は暗黒のまま沈黙した。
それを見て気づいた。ドライバが競合して死んだらしい…。
セーフモードですら暗黒を保った。散々調べ続け試し続けた結果、ビデオだけが問題であったので、低解像度起動すると操作できることがわかった。グラフィックドライバを改めて入れなおし事なきを得た。
これで直ったと信じたい…。
＜次の日に追記＞
直ってなかった。
再起動したら再び黒い画面。
上記で入ったマザーボードのドライバとビデオカードのドライバが競合状態にあり、うまく表示されない。マザーボード側のビデオドライバを無効にすることでちゃんと表示されるようになった。
appengine ja night #33 に行った話
行ってました。
今年に入ったあたりから職種を変えて私自身もapp Engine上での開発をするようになりました。のでapp engineの勉強中です。
弊社プロダクトはpythonで作ってるですけど、みんなgoかjavaばかりで結構悲しい気持ちになりました。まあstandard環境でpython3が使えないからしょうがないね…早く使えるようになってほしいですね
資料はこのへん。
appengine ja night #33 - 資料一覧 - connpass
面白かった箇所
「メルカリ アッテ」を支える Google App Engine と Golang // Speaker Deck
DAU 100万人で 課金額が200万くらい
GoogleクラウドとApp Engineで実現したドローン業務利用
資料見当たらないけど、これは話自体が面白かったやつです。
ドローンを使って建築現場の撮影をしてそれを地図に重ねてあわせてWeb上で見えるようにするところまでをひとまとめとして提供という。
3D詳しくないので、ポリゴンではなく点群なんですって言われても凄さがよくわからなかったり、地図に詳しくないのでGoogleMapはWebメルカトル図法と呼ばれる形式で、国土地理院地図はXYZ形式？だかいう名前のらしい、とかいうのを聞いてもあんまりピンと来ないわけです。
もちろん本業でない以上別に自分で作れるくらい把握できる必要はありません。とはいえせめてどんな話をしてるかくらいはわかるように、浅く広く勉強しておきたいなぁと思いました。
Endpointよりもswaggerの方がいいのか！というのが伝わってきた
GAEレスポンスの1桁ms化
これも資料見当たらないんですけど、興味深い話。
GAEはいままではUSにサーバーがあったわけで、通信が海を超えるわけです。そうするとどんなに簡易な通信でも必ず300ms程度のオーバーヘッドが存在する。ここがgaeが遅いとか言われる１つの原因になっています。
解決法の１つはAsiaにリージョンができることです。これはやっと2016/7にTokyoリージョンができるという話があります。でもすでにUSで動いてるアプリは移動できません、それに今すぐ早くしないとまずいんだということもありえます。
じゃあ東京リージョンをまたずにCDNを使ってしまえということでFastlyを使った話をしていました。
Fastlyは日本にDCがあるので、海を超えずとも通信ができます。物理的に近いというのは強みになりえるのです。
値段も、想定される東京リージョンと比べてもそんなに遜色ないようなので、こっちでもいいんじゃね？というのは興味深いところでした。
pythonを書く話
今年になってからpythonを書くことになって復習がてらなんか書いたりしてました。
こんなのとか。
https://github.com/arvelt/weather-python
これはちょっと時間はかりたいって時に書いた関数を外に出しただけ。
https://github.com/arvelt/measure-time
Pythonはなんというか、変な癖がなくて結構わかりやすくてとてもいいと思いました。ただ2系と3系の断絶がかなりつらいですね。仕事ではGAEと使うので2系を覚えるんですけど、最近3系も使えるっぽいようになりましたが、既存の資産をいきなり差し替えることはできないので、今後も2系とは長く付き合うことになりそうです。
