フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
選定した技術が1年で死んだ話 | そど
今年の夏頃から、特にサービスとして出すわけではなく、社内で使っているシステムのリプレースを行う事になりました。主な目的はレガシーすぎる設計をある低度モダンにする事、そして他のシステムと連携出来るようにする事、です。 対象のシステム 見積書や請求書などを管理・発行している。機能はそれなりに多いがUI操作はFormベース、テーブルタグで諸情報を表示するシンプルな物。ノンフレームワークで1画面1PHPファイルな古き良き時代のコード。おそらく10年ぐらい？稼働している。当初はPHP 5.1、PostgreSQL 8.x系だったが、現在はPHP 5.6とPostgreSQL 9.6で稼働しています。 その他の社内システム かつてはノンフレームワークだったり、太古のバージョンのCakePHPだったり、PHPが4系だったりしたが、概ねCodeIgniter 3系最新版 + PHP 5.6～7.1 + P
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
