ナレッジワーカーの集団にとってのアクセルは文化、ブレーキはルール。文化は行動が作る - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
よく、「仕事の属人性を排除して、仕組みやルールで標準化すべき」ということが言われる。これは決して間違えていないと思うけど、一方で片手落ちだと思う。たしかに、労働集約型の事業においては、「人数を増やせば増やすほど利益につながる仕組みやルール」を作ることが大事になるだろう。一方、知識集約型の事業においては、これは必ずしも真ではないと思う。 言ってみればあたりまえのことだけれど、ルールや仕組みは、増えれば増えるほど労働は平準化されていく。労働集約型の事業においては、「ローパフォーマーを減らすこと」のほうが、「ハイパフォーマーにさらに高いパフォーマンスを発揮してもらうこと」よりも重要だ。だって数がたくさん必要なんだもん。そのため、ハイパフォーマーにとっては「枷」になってしまうようなルールや仕組みであっても、その仕組みを課すことでローパフォーマーでも一定のアウトプットが出ることが重要となる。つまり、
猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
