2 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有

ソフトウェア開発における優先順位

  1. ソフトウェアは 最終ユーザーにとって有用 であるべきであり、"愛せるソフトウェア" を目指す
  2. ソフトウェアは 正確(correct) でなければならない。誤作動するソフトウェアは、ユーザーが得られる効用を下げてしまう
  3. ソフトウェアは 保守可能で効率的 であるべき。ソフトウェアからより多くの効用を引き出そうとするときに、人間と計算資源の無駄を避けるための基準

優先順位が逆転したときの無意味さ

ときには気力を失うこともあり、ときには間違った道へ進むこともあり、ときには意図的に迂回することもありますが、誰であっても、私が本当の目的地をもっと低い場所だと勘違いさせることはできません。
私は自分の開発者としての経験を大切にしていますが、それは私が他の人たち、そして皆さんが楽しめるソフトウェアをより多く生み出すのに役立つ限りにおいてのみ大切なのです。

  • 究極の目標は 最終ユーザーの効用を最大化すること であり、それ以外のすべてはその目標を達成するための手段
    • これがソフトウェアを開発するうえで最も重要な原則です

1件のコメント

 
GN⁺ 3 시간 전
Lobste.rsのコメント
  • 似たようなアプローチを好む
    ドライバーのような「愛らしくない」道具でも、非常に長いあいだ信頼性を高く保てる。プラスドライバーはいつでもプラスであり、工具箱から取り出したら1%の確率でマイナスドライバーになっていて、いったん戻してもう一度取り出さなければならない、なんてことはない。持ち手のデザインが際限なく変わることもなく、買った道具を壊れるまでそのまま使える
    もっと多くのソフトウェアがそうなってほしい

    • 「ドライバーのような愛らしくない道具」とはどういう意味なのか気になる
  • 「最終目標はエンドユーザーの効用を最大化することであり、それ以外はすべてそのためにある」という基準を守る開発者は尊敬するし感謝もしているが、自分ではいつもそうはできない。ソフトウェアにはエンドユーザー以外にも、正当に責任を負うべき相手がいると思う
    仕事としては家族を養うためにソフトウェアを作っていて、かなりユーザー寄りではあるが、最終的にはお金を払う会社と家族への忠誠のほうが大きい。
    個人の作業では「これが自分にとってやりがいがあるか」が基準で、芸術的・美学的・知的な満足が重要になる。たいていはユーザー利益と一致するが、自分がユーザーの効用を見誤ることもあるし、たとえばアニメーションするハンバーガーメニューが効用を最大化すると証明されたとしても、自分の創作物では美学的な選択権を行使してその効用をあえて捨てることができると思っている

    • しかも、こうした折衷とは別に、本当のエンドユーザーが誰なのかを常に定義できるとも限らない
      ユーザーが自分の作業の利用者たちに害を与えるようなひどいことをできないようにするため、意図的にソフトウェアの一部をユーザーに不親切にする場合をどう考えるべきか、という問題もある。
      Goodhartの法則に非常に弱く、その副作用の影響範囲も大きい特定のレポート機能について、ソフトウェアの利用者が望んでいたとしても永遠に「未対応」のままにしておくため、意図的にそうした仕掛けを議論したことがある
  • この記事を見て初めて、Tiger Styleに今ではウェブサイトがあることを知った

  • 「誰にも保守できず、新機能の追加は言うまでもない」と「すべてのバグ修正」を同時に語っているが、結局のところスコープ凍結なしでどうやってすべてのバグを直すのかはよくわからない

  • 「ブロックチェーンにバグがなくてもラグプルなら意味がない」という言い方は、三つのことを一文に詰め込める
    何かの効率を上げても、新しいバグを作るなら意味がなく、それもラグプルでない場合に限って意味がある

  • ソフトウェアが必ずしも人間だけによって書かれなければならない、という要件はない点が目を引いた。KristoffがZiglangのコア開発者だと認識しているので、なおさら興味深い
    AI支援開発を使っても、この要件に合うソフトウェアは作れると考えたい。
    自分の手でコードを書くのも楽しいし、完成させるのも楽しいが、その二つは時々衝突する。
    AIの話を持ち出して申し訳ないが、KristoffとZigコミュニティの密接な関係、Zigの強い立場、そして何より自分がずっとZiglangを布教していることもあって、切り離して考えにくい

    • 3つ目の項目は、むしろそういうツールに反対する側を示唆しているように見える。そうしたツールが作るものは、たいてい保守不能なスパゲティコードのように見える
    • この記事がziglang.orgではなくLorisの個人ブログに載っているのには理由がありそうだ
      あるプロジェクトが大規模言語モデル由来のコードに対して明確な立場を持っているからといって、そのプロジェクトの全員がこのプロジェクトやあらゆるプロジェクトで同じ立場を共有していることを意味するわけではない。
      Loris個人に限った話でもなく、こうした判断はケースバイケースで考えるのが妥当だと思う