テスト駆動開発(TDD)の一般化とGitHubの登場によって、機能追加の際にコードとテストを同時に実装する(そして、両者を一括してmasterにmergeする)という開発手法が一般化してきました。 しかし、「良いプログラム」の要素を構成するのは、コードとテストのみではありません。動作するコードと、その品質を担保するためのテストがあったとしても、適切なドキュメントがなければ、ユーザーはそのプログラムをどうやって使ったら良いかわかりません。 つまり、ユーザーに使いやすいプログラムを継続的に開発/提供しようと思うと、 コード テスト ドキュメント の3点セットを提供する必要があるのです注1。 今日のJSXが抱えている最大の課題は、ドキュメントが不足しているという点にあります。その原因は、「機能追加」の際にコードとテストのみを実装してmasterにmergeすることを繰り返す一方で、ドキュメントは
https://www.youtube.com/watch?v=-KFe5pGMFbo 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Uberは、配下のタクシーの乗車率を最大化して、かつ顧客の不満「タクシーがつかまらない!」「呼んだタクシーがくるのが遅い!」を下げるために、タクシーがつかまりづらい時間帯は動的に価格が上がる仕組みにして、需給バランスの最適化を計ってます。 最初はしばらく手動で値上がり率を入力して、データを蓄積。それからアルゴリズム化した。 都市ごとに係数は変えている。大きな都市では、空きタクシーの検索範囲は市全体でなく時間帯で適切なエリアだけをカバーするかたちに変えた。 最初はその時間に適用される値上がり率を、へりくだったお詫び的なテキストの中で表示していたが、請求されてから気づく酔
ひとまずの最終回。 今回で ユビキタス言語 モデル駆動設計 実践的モデラ と役者が出揃った。 中でも、個人的に印象深かった実践的モデラについて少し考えをまとめたい。 実践的モデラに対する僕の理解は、ドメインエキスパートと共にユビキタス言語を導き、イテレーティブなモデル設計を実施し、かつプログラミングを行う人を指している。 これは、僕だ。 僕は普段仕事でWebアプリケーション開発に携わってるけど、ドメインエキスパート(企画者、ディレクター)とモデル(仕様)を作成し共通認識(ユビキタス言語)を維持しながらコーディングしている。 モデル(仕様)が変われば共通認識(ユビキタス言語)が変わりコードが変化する。普段の風景。 ただし、モデル(仕様)も共通認識(ユビキタス言語)もなーんにも文書化されずガシガシ作るスタイルなのは問題。まぁこれはひとまず置いておいて。 全てのWebの現場がそんな風な作り方をし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く