フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
サイトのデザインを変更しただけで約50％もユーザーを失った失敗例
By Wicker Paradise アイコンに関するニュースから販売まで手がけるサービス「Icons8」の中の人が、ウェブサイトのデザインを大幅に変更したところ47％ものユーザーを失ったことをブログで明らかにしました。ブログではユーザーを失うまでの経緯や、なぜ失ってしまったのかの分析結果まで書かれていて、興味深い内容になっています。 How We Lost 47% of Our Users After a Redesign | Icons8 https://icons8.com/articles/how-we-lost-47-of-our-users-after-a-redesign/ サービス開始当初、Icons8はアイコンの開発・販売を手がけるサービスでしたが、毎日新しいアイコンを作り続けるのには無理があるため、「リクエストアイコン」という機能を実装しました。リクエストアイコンとは、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
