hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

■

大変だったけどなんとかなった。数百行のjQueryが活躍するコードが消えて、数十行のいくつかのオブジェクトがやりとりする形になった。jQueryはオブジェクトの設計には何も関与しないので、なんか指針がないとめちゃくちゃになる。

■

難しいことやってて疲れてた。難しいJSを触ってて、おとといはそのまま使おうとしてめちゃくちゃになって、昨日は全部消して前のを見ながら書き直すという作戦で、ちょっと進んだ。
場所によって求められる品質は違うけど、少なくとも手を入れられるくらいにはしておかないと、こっちを変更するのはそっちの一万倍大変、みたいになってると、いつ終わるか分からなくなったりして、よくない。
がんばって読めば分かるコードはよくない。適切な構造を作ると推論しやすくなったり、何が起きてるのか分かりやすくなったりする。誰もが自由にDOMにアクセスするのは、パラダイム的にはグローバル変数と同じで、どこで誰が何をやってるのか予測しにくくなる。要素間でお互いをclick()とかして通信するよりは、オブジェクト達を作ってやり取りさせるほうが、オブジェクトのパスが少なくなって理解しやすくなる。
最悪のコードは一人が書いてある日誕生したわけではなくて、みんなでジェンガみたいにちょっとずつ継ぎ足して作り上げてきた最悪のコードで、こうなってしまうのは厳しい。コードが悪くて悲しいというより、これだけ科学技術が発達したのに、このコードが読めないとか言って苦しんでる人が居るほうが悲しい。人間の営みとして品質が低い。
なんとかするために、複雑度を計測するっていうのはできそうだけど、複雑度が一定以上になったら、速やかにリファクタリングしましょうって言われても、普通の人はジェンガ置くことはできても、一人で積み直すのは難しいだろうと思う。

続きを読む

最悪の祭

f:id:hitode909:20140715230856j:plain

f:id:hitode909:20140715231047j:plain

f:id:hitode909:20140715230908j:plain

f:id:hitode909:20140715230940j:plain

我が社のすぐ近くで最悪の祭やってて、帰り道だから渋々見に行った。交差点ごとくらいの勢いでビール売ってて最悪。おかげで5杯くらい飲んでしまった。あとちまきっていう最悪の厄除けグッズを売ってて、これ買うと一年間厄除けできるばかりか、鉾っていう最悪の建造物を見学する羽目になる。1500年代に作られた月鉾の先端部分とか、鉾の内部とか、ふむふむという感じで見学できて最悪。輪をかけてひどいのが、スーパーボールすくいで、これは300円ですくえなくても3つ持って帰らされる。明日も引き続きこういう感じで、あさってはより最悪で、普通に仕事してるとオフィスの前の道を鉾が過ぎ去って行って、普通に仕事してても長刀鉾の先端などを見ることになる。

一つしかない想定で作ってあとから複数出現してめちゃくちゃになる

ソフトウェア作ってて，最初は一つしかない想定で作るけど，あとから複数出現することになって改修するのが大変，ということがある．

最悪サーバーサイド

もう終了したサービスであったのが，ユーザーは自分のアイテムを飾れる部屋を1つ持てるという仕様だったのが，複数の部屋を切り替えられるようにして，部屋ごとに置けるアイテムのシリーズが変わって，シリーズごとにグリッドの細かさも変わるとか．とにかく大変で，全部のテーブルにあとからシリーズidを持たせたり，クラスメソッドで済んでたのをシリーズidを持つオブジェクトのメソッドにしたり，ORMのItemをRoomに渡すのをやめて，その層とは別に独立した画像合成用のItemとRoomを作ってやり取りするとか，最初からそうなってるときより大変なことになる．

最悪クライアントサイド

クライアントサイドでも同じようなことはあって，HTML内に一つしか出現しない前提で作ってると，idでCSS当てたり，$("#button").clickとかidを使ったJS書いたりして，その後そのパーツが複数出現することになると大変なことになる．idは重複してはいけないので，idやめてclassとかに書き換える必要がある．最初からclassとかで要素探していればこんなことにはならないので最悪．ただidじゃなくてclassになってればいいわけではなくて，$root.find('.button')みたいに，ルートとなる要素から探していく必要がある．最初からそうなっていると良い．
最初一つだけだったものがあとから増殖するかどうか，未来のことは分からないので，一つだけっていう想定をやめないといけない．idで書いてもclassで書いても手間変わらないので，そういうところは最初から気をつけるべき．作り終わって完成して終わりならそれでいいけど，10年後も機能追加するような場所では，将来変更しにくくなるようなコードを書いてはいけない．とはいえ，一つに制限することで仕様が簡単になったり，素早く作れたりすることもあるので，どこまでめちゃくちゃにならずに簡素に作れるか，チキンレース感ある側面もある．

ちょっとまし

最近は，GitHubに倣って，JSから触るセレクタは.js-というprefixをつけるようにしてる．もともとは，JSから触ることを示して，CSS設定するためのクラスから独立させるというアイデアだけど，要素が複数になってもよいので，ちょっとまし．

Try to prefix all javascript-based selectors with js-. This is taken from slightly obtrusive javascript. The idea is that you should be able to tell a presentational class from a functional class. Most of the codebase doesn't do this, let's try and move toward it.

JavaScript · Styleguide · GitHub 

寿司(2)

f:id:hitode909:20140713232238j:plain

f:id:hitode909:20140713231900j:plain

音楽、出町柳でやってて、四条から帰れば定期あるから三条から歩いてて、先斗町たまには通るかと歩いてたら寿司屋発見してしまった。最近寿司屋ひたすら巡ってるけどそれによって良い寿司屋とか変な寿司屋とか発見できて生活水準上がってる。いま見返すととみ寿司最初に行ったのが6月の初めで、それからちまちま寿司屋を巡って金を失っている。二年間くらい通ってた寿司屋が実は周りと比べるといまいちということが分かったりする。そんなに差ないだろうから、好みの問題だと思っていて、より好みの寿司屋を発見できるのは良いことだと思う。4貫とビールで2000円くらい。年中無休で24時までやってるらしい。鯛おいしかった。値段書いてあるから安心。とはいえ築地の寿司はおまかせ3500円でめちゃくちゃおいしいので京都の寿司はコストパフォーマンス悪い気もする。京都の寿司屋そろそろ分かってきたから寿司調査のために東京引っ越したい。