タグ

programmingに関するakisei67のブックマーク (2)

  • 状態設計から「なんとなく」を無くそう

    ウォンテッドリー株式会社の社内イベント "Tech Lunch" で話した発表です。 プログラムには大小さまざまな粒度の「状態」が存在します。 状態の設計を工夫することで、コーナーケースの発生を抑止し、ユーザー体験を最適化することができます。 発表では、私が普段どのように「状態」について考えているか、言語や環境を問わずできるだけ普遍的に使える形での言語化を試みます。発表を通じて、「状態」をなんとなくではなく合理的に設計するためのヒントを提供します。 GoogleスライドのURL: https://docs.google.com/presentation/d/1PNzz69UV05HlKPuWGlooemnPslLbLKsyLwl3R4U_XqE/edit

    状態設計から「なんとなく」を無くそう
    akisei67
    akisei67 2023/12/08
    状態変更について分かりやすくまとまってる。個人的には「個(≒Entity)の状態=ステート(=state)と「集合(≒AggrigationRoot)の状態=ステータス(=status)」を必ず分けて設計する。そしてステータスは関数になることが多い。
  • プログラミングの原則:enumの比較はすべてバグ - Uzabase for Engineers

    こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 この記事は NewsPicks アドベントカレンダー 2023 の3日目の記事です。 昨日は@J_Nakagawa(隼佑 中川)さんによる『LambdaレスポンスストリーミングとAWS-SDKを使ってSlackに進捗バーを表示させる』でした! 世の中には再現が難しく一見してバグがありそうに思えないコードもありますが、一方でプロダクションコードの中にはひと目見てバグが有りそうなコードもまた多いものです。いくつかの特定のパターンをとる文字列(環境名など)やenum(以下どちらもenumと表現します)に関する条件分岐もその一つです。プルリクを見てこのようなパターンがあれば、バグの疑いが強くなります。周囲を見渡すと、大抵すでにバグっているか潜在バグを含むコードが見つかります。すべてバグというのは言い過ぎにせよ、わかりやすさと変

    プログラミングの原則:enumの比較はすべてバグ - Uzabase for Engineers
    akisei67
    akisei67 2023/12/03
    タイトルは強いけど納得できる内容。どちらかと言うと「今は上手く動くけど変更に弱い(修正漏れてバグる)」という印象。こういう実装はステートマシン図とかバリエーション図みたいな設計と一致させたい。
  • 1