持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
クリーンアーキテクチャ(The Clean Architecture翻訳)
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
テストはなぜ開発を遅くするか、テストを書かない理由はある！ない？ - Qiita
背景 スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか の記事を拝読して、思うところがあったので、まとめてみる。 考察したい分類/内容 上述の記事の、以下の「まとめ」にはものすごく賛同できる。 「テストを書く」の齟齬を解消しよう。 「テストを書く」の意味は私とあなたで全く異なる。 齟齬が生じる一番大きな理由は、 各位の「前提事項」が全く異なるからだと考える。 一方で、途中の記事内容については、 前提となるプロジェクトの状態の考慮が少なすぎて、 人によっていろいろな解釈が生じてしまい、 賛同する人、しない人に分かれそうな印象であった。 「テストを書く理由」を主張する優れた人はいっぱいいる。 が、宗教的な信仰で神が居る前提で話が始まるように、 主張時に、「テストを書く」の意味は私とあなたで全く異なる というどの点が異なるのかを相互に理解不足であるために、 「テストを書きたがら
どういう意味で品質って言ってるの？システム開発の現場で品質おじさんと建設的に向かい合う方法 - 毎日がもふもふ
「わしはシステムの品質を妥協せんぞ！」って偉い人から議題があがるって経験したことありますか？ この「品質」って言葉が少々やっかいなヤツでして、それだけ言われても何のことを指しているか分からなくなくなくないですか？ じゃあこの偉い人にどういうことが詳しく聞けばいいじゃんって話なんですが、「品質ってなんスか？」とか聞いたら、「キサマ！『品質』って言葉も知らんのか？国語辞典で読んで小学生からやりなおせぃ！」ってブチ切れられて、焼き土下座とか強制地下労働とかさせられるのが関の山。そんなリスクを考えると、なかなか言い出しづらいですよね。 そんなあなたのために具体的にこの「品質」という言葉をどう扱うべきか考えて行きましょう。 品質という言葉は何を示しているのか？ ところで、アジャイル開発にはプロジェクトの目的やゴールを明確にするための「インセプションデッキ」というドキュメントが存在します。 その中の一
アジャイル開発において「テストコードは当然」なのか？ - Qiita
https://qiita.com/aimof/items/d68bdb347283ee2dbccf を見て、Web開発現場的にはちょっともやっとしたので、書いてみます。 言いたいことを３行でまとめると テストコードを書くことの有用性そのものは疑いようがない ただし、アジャイルやWebサービスの開発においては、 「テストコードを書くことを当然」 としてしまう事は、開発スピードや品質面において選択肢を狭めてしまう可能性がある。 テストコードを特別視せず、コードレビューやE2Eテストやユーザテストなど、有限の工数の中で、 複数の手法がトレードオフにあること を前提に、プロジェクトの品質管理を考えていくべき 前提条件 スタートアップやWeb開発のように、厳密に定められた納期や開発スコープ、あるいはゴールがない新規・継続開発 筆者の属性 Web系のToCやBtoBtoCサービスを中心に手がけていま
仕様変更に弱いからテストは書かない……？(´・ω・`)＜仕様変更を想定するならテストを書いてくれ頼む - Qiita
テスト書けない人をディスったらバズりました。 「スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか」 気になる反応があったので別記事にまとめておきます。 「仕様変更に弱いからテストは書かない」 テストがあると頻繁な変更に弱い、と考える方が複数いらっしゃるようです。実際に、スタートアップの現場では、昨日の決定が今日と違うなんてことはザラにあります。 私の立場は「仕様変更が多いならテストを書いてくれ頼む」です。絶対に間違いなく一行の変更も加えず書いたコードを捨てることが決まっているのなら、テストは不要な可能性が高いです。しかし私の経験上は、プロトタイプであっても変更を加えたくなることは多々あります。その際にテストがないと困るだろう？というのが今回の主張です。 前提 フロント、特にGUIは私が無知なので対象としません。 間違いなく書き捨てるコードは対象としません。少なくとも一週間
テストを書くかどうか議論するの不毛だから、どうやってテストを書きやすくするか議論しよう - Qiita
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするかという記事がバズりました。みんなテストについて思うところがあるようだ。テストを書くべきか否かは机上の空論になりがちで不毛なので、どうやってテストを書くか、テストの書き方、について、種を巻いた私が書いておく。 もっと詳しい方からのお話お待ちしています。 書くこと テストの書きやすくするためのいろいろ（箇条書き） 書かないこと テストの基本 テストファースト 実装ありきでテストを書くのではなく、テストありきで実装を変える。 はっきり言って、テストを考慮せずに実装されたコードは、書き直さずにはテストできない。 そういう点で、テストなしで実装する選択肢は不可逆なので、初期実装では特に注意が必要。 クリーンアーキテクチャ(DDD) クリーンアーキテクチャの考え方はテストファーストを語る上で重要。私個人としてはまだクリーンアーキテクチャ
すでに生み出されて動いているレガシーコード（テストのないコード）との戦争。結局武器はテスト - Qiita
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか というという記事がバズって以降テストの記事ばかり投稿しています。この際だからテストに関するもやもやを吐き出しておきます。 上記記事にてToDoとして、 すでに生み出されて動いているレガシーコードにどう立ち向かうか と書きました。 一回レガシーコードと戦って勝利一歩手前まで行った経験があるのでその経験をまとめます。 どんなコードだったか 規模は小さめ ユニットテストなし 自動テストなし テストはデプロイしないと不可 前任者（作成者）いない UIなし やりたいこと テストがあれば一時間で終わる程度の変更を加える 格言 レガシーコードの改変について有名な格言があり、 レガシーコードのジレンマ コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。 「レガシーコード
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です。 この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。 アジャイル開発において「テストコードは当然」なのか？という記事で（私の記事をきっかけとして）テストコードの「徹底」とか「カバレッジ100%」とかを批判し、トレードオフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
VC「もしかして...」Model「私たち...」「「入れ替わってるー！？」」を前前前世から防ぐ方法
