「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
Using nullability in GraphQL | Apollo GraphQL Blog
Like the hole in a donut, what isn’t there can be just as important as what is. Photo credit Tommy Chheng: https://www.flickr.com/photos/tommychheng/3226662528/ When you’re working with a REST API, you don’t always know exactly what fields you’re going to get back when you call an endpoint. GraphQL improves on that by having a complete schema of your available data, and giving you back exactly the
クラスなど設計するときに分けて考えるべきことのメモ - Lambdaカクテル
最近良い設計について考えているので，そのメモです． 分けて考えるべきこと どれを処理するのかという知識と，実際にそれを選別する処理 e.g. どのイベントをハンドルするかと，ハンドルするイベントをフィルタする処理 ハンドラ自体がイベントをフィルタする必要はない 車が燃料一覧からガソリンや軽油を選択するのはまちがっている．それはスタンド店員の責務であって，車はガソリンを受理することだけ知っていればよい． 同じ場所で行っている似たような処理 実は共通部分として切り出せることがある e.g. イベントハンドラで，通常のハンドリングのそばに特殊なイベントを処理する場合を書いているが，実は特殊なイベントの処理はどのハンドラでも共通なので呼び出す側で処理できた is-a関係になっていると継承できるが，子クラスが大きくなりすぎてはいけない気がする，子になんでも書いていいというわけではない is-a関係に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Nullability in GraphQL