コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
気が狂った設計 - hitode909の日記
大きめのこととか，自信のないところを触るときは，コード書く前に，こういう作戦考えてみたけどどうですかって聞いてみたり，こういうことやりたいんだけど一緒に考えませんかって，いっしょに話して設計考えたりするとよいと思う． 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので，未然に変な設計のままコード書いてしまうのを防げる． 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う．我が社にはそんな強い言葉でレビュー書く人はいない． 我が社には，普段から強い言葉を発する人もいなくて，みんな物腰柔らかな変な言葉を話している． 言葉使いや文体は，ずっと過ごしてると同僚から移ったりするので，普段からそういう言葉を話していると，全体の雰囲気も悪くなりそ
■ - hitode909の日記
難しいことやってて疲れてた。難しいJSを触ってて、おとといはそのまま使おうとしてめちゃくちゃになって、昨日は全部消して前のを見ながら書き直すという作戦で、ちょっと進んだ。場所によって求められる品質は違うけど、少なくとも手を入れられるくらいにはしておかないと、こっちを変更するのはそっちの一万倍大変、みたいになってると、いつ終わるか分からなくなったりして、よくない。がんばって読めば分かるコードはよくない。適切な構造を作ると推論しやすくなったり、何が起きてるのか分かりやすくなったりする。誰もが自由にDOMにアクセスするのは、パラダイム的にはグローバル変数と同じで、どこで誰が何をやってるのか予測しにくくなる。要素間でお互いをclick()とかして通信するよりは、オブジェクト達を作ってやり取りさせるほうが、オブジェクトのパスが少なくなって理解しやすくなる。最悪のコードは一人が書いてある日誕生したわけ
■ - hitode909の日記
今日テストなくてめちゃくちゃに壊れてるアプリケーションのテストを一から書いてて、わりと書けてよかった。午前中セットアップに手間取ってて、午後からテスト書き始めて、小さいアプリケーションだったのでC0 90%くらいまでいけた。3年間くらいテストないせいでびくびくみんな触っててめちゃくちゃに壊れててよくなかった。テストえいって書けば書けるんだから、隙を見て書いていきたい。ずっとテストのあるWebアプリケーション眺めてるのでだんだんコツが分かって気がする。まず最初にCIに載せて、カバレッジ測れるようにする。面倒だけど、これやっておくと後で役立つ。普通にテスト書くと、実行環境までは定められないけど、CIがあれば、そこをベースに議論できる。最初は、アプリケーションのルートのモジュールをuse_okするだけ、くらいでまず通して、カバレッジも取れるようにする。たとえば、MyAppっていうアプリケーション
はてなブログ編集画面JSのページャ見どころ紹介 #pagernight - hitode909の日記
昨日，ページャNightという勉強会で，はてなブログのJSの見どころを紹介するLTをした．(昨日の日記)． 資料公開しようかと思ったのだけど，発表資料そのまま公開しても意味不明なので，エントリに書き直すことにした． たとえば，このLGTM画像は発表資料の1枚目で，もし発表資料をそのまま公開したら，こういう謎の画像を解説もないまま見ることになっていたはず． JSのページャいっぱいある はてなブログの編集画面には編集サイドバーというのがあって，写真とかAmazon検索とかTwitterとかinstagramとかあれこれ貼れるようになってる． Amazon検索しても画面遷移するわけじゃなくて，ウェブ2.0という感じで，XHRでJSONを取ってきて，HTMLを組み立てて表示，クリックすると選択，貼り付けを押すとエディタに挿入される，という仕組み． 編集サイドバーから貼れるサービスは10種類くらいあ
全自動リファクタリング君 - hitode909の日記
長年の技術的負債で，あるネームスペース以下には，このオブジェクトを渡さず，このオブジェクトのフィールドの一部だけを渡したい，みたいな話があった．コンテキストオブジェクト全部渡すと，そのメソッドが何に依存しているか分からないので，必要な分だけ渡すべきで，最近は必要な分だけもらってるけど，昔書いた分は全部もらってて，混在しててきびしい状況だった． 静的解析して安全に置き換えられることを確認して，ソースコードの定義と呼び出し元を書き換えて，変更箇所のテストが通ったらcommitしてpushする，テスト失敗したら人間を呼ぶ，みたいなスクリプトを書いた．午前中にスクリプト書いて，午後に動かして，263コミット，280ファイル書き換えて無事リファクタリング成功した．すごい． すごいけど，最初から型さえあればIDEからちまちまリファクタリングできたはずなので，2014年にこういう技術を開発してるのはつら
ドメイン駆動設計読んだ - hitode909の日記
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
高速にドッグフードを食べる方法 - hitode909の日記
はてなエンジニアブロガー祭りで「高速にドッグフードを食べる方法」という題で発表してきた． 箸でドッグフード食べるパフォーマンスの話ではなくて，もとはマイクロソフト用語である，Eat your own dog food，自社製品を使ってより良くしよう，みたいなほうの話．はてなブログ開発しながら毎日使うとか，思い付きで作ってるわけではなくて，事実や根拠にもとづいて作ってるとか，安全に作るための仕組みとか，そういう話． 普段の勉強会では僕は主に3分くらいのLTをしていて，20分も話したことなかった．資料ぜんぜんできなくて，Keynote見るだけで疲弊してた．急に長くていい話できるはずないと思って，LT5連発という形にして，ドッグフードにまつわる話を5個するという形にしたところ，なんとかなった． 東京では情報が氾濫してるから，京都でこんなのやってますとか言っても，東京では常識みたいな冷たい反応をさ
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
XHRのキャッシュするやついろいろ - hitode909の日記
JavaScriptでXMLHttpRequestの結果をキャッシュするの何度も書いてるけどまた書いてしまった． 去年の11月くらいに書いたのこんな感じ．responseTextをハッシュに入れるみたいな感じ．エラー出たらメッセージ出してあきらめるというのはアプリケーション固有のエラー処理だから，ここでやるのは変だと思う． _ajaxCache: {} _ajax: (url, callback) -> self = this if self._ajaxCache[url] callback self._ajaxCache[url] return $.ajax type: 'GET' url: url success: (res) -> self._ajaxCache[url] = res callback res error: -> alert('通信時にエラーが発生しました．時間をおい
emacsclientが便利 - hitode909の日記
emacsclientを使うと、既に開かれているEmacsを使ってファイルを編集できるので便利。 普通の使い方 .emacs.elに (server-start)しておくと，Emacs起動時にEmacs Serverが動くので，それ以後は，他の端末などから emacsclient なんたら.txtすると，なんと，先に開かれていたEmacsで，なんたら.txtが開かれる。 初回とか，２回目以降とか気にしたくない人(とにかく１個のEmacsで処理したい)という人は， alias emacs="emacsclient -a emacs"しておくとよい。-aは--alternate-editorで，サーバーにつなげなかったときに開くエディタで，サーバーに接続できなかった場合に使うエディタを指定する。 このaliasを貼っておくと，最初の１回だけEmacsが新たに立ち上がって，それ以後はそのEmac
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
