「〜性」について考える
和田 卓人 (a.k.a @t_wada)
Press → key to advance.
Slides controls, press:
- ← and → to move around.
- Ctrl/Command and + or - to zoom in and out if slides don’t fit.
- T to change the theme.
- H to toggle syntax highlight.
自己紹介
自己紹介
- 名前 : 和田 卓人(わだ たくと)
- hatena : t-wada
- twitter : @t_wada
- github / facebook : twada
プログラマが知るべき97のこと
SQLアンチパターン
よろしくお願いします
「〜性」について
「〜性」について
簡潔性、利便性、直交性、透明性、開示性などについて、 書籍を読んで学んだこと、コードを読んで学んだこと、 設計時に考えたこと、使う/使われることによって学んだことなどを話したいと思います。
@m_seki さんに煽られた とはいえ、とんでもないことを書いてしまったものだ……
たくさんの "ilities"
$ cat ilities | wc -l 70 $ head ilities Usability Security Portability Interoperability Testability Reliability Maintainability Availability Stability Scalability $
これらの話はしません。
「〜性」について(再び)
簡潔性、利便性、直交性、透明性、開示性などについて、 書籍を読んで学んだこと 、コードを読んで学んだこと、 設計時に考えたこと、 使う/使われることによって学んだこと などを話したいと思います。
今日考えるもの
- シンプルさ
- 簡単さ
- 簡潔性
- 直交性
- (透明性)
- (開示性)
シンプルさ(Simplicity)
"Simplicity is prerequisite for reliability"
"シンプルさは信頼性の前提条件である"
– Edsger W. Dijkstra
シンプル(Simple)
- ひと折り、ひとより
- ひとつの役割
- ひとつのタスク
- ひとつの概念
- 一次元
- 客観的
簡単(Easy)
- 近くにある、手近にある
- 理解度、スキルセットに近い
- 能力に近い
- 主観的、相対的
違い
シンプルさと簡単さの主な違いは、シンプルさは客観的、簡単さは主観的であるということ
- シンプルさ → 客観的
- 簡単さ → 主観的
github
作ったものと学び
- twowaysql
- qunit-tap
- org-html5presentation.el
- power-assert (NEW!)
それは何?
- twowaysql
- SQLのためのテンプレートエンジン
- qunit-tap
- QUnit 用の TAP 出力プラグイン
- org-html5presentation.el
- いまご覧になっているこれです
- power-assert
- Power Assert の JavaScript 実装
twowaysql
template = TwoWaySQL::Template.parse(<<-EOS
SELECT * FROM emp
/*BEGIN*/WHERE
/*IF ctx[:job]*/ job = /*ctx[:job]*/'CLERK' /*END*/
/*IF ctx[:deptno_list]*/ AND deptno IN /*ctx[:deptno_list]*/(20, 30) /*END*/
/*IF ctx[:age]*/ AND age > /*ctx[:age]*/30 /*END*/
/*END*/
EOS
)
merged = template.merge(age: 35, deptno_list: [10,20,30])
merged.sql #=> "SELECT * FROM emp WHERE deptno IN (?, ?, ?) AND age > ?"
merged.bound_variables #=> [10,20,30,35]
qunit-tap
<script type="text/javascript" src="path/to/qunit.js"></script>
<script type="text/javascript" src="path/to/qunit-tap.js"></script>
<script>
qunitTap(QUnit, function() { console.log.apply(console, arguments); });
</script>
# module: math module # test: add not ok 1 - expected: 7, got: 1, test: add, module: math module not ok 2 - with message, expected: 7, got: 1, test: add, module: math module ok 3 ok 4 - with message 1..4
power-assert
var assert = require('power-assert');
describe('Array#indexOf()', function(){
it('should return index when the value is present', function(){
var ary = [1,2,3], zero = 0, two = 2;
assert(this.ary.indexOf(zero) === two);
});
});
1) Array#indexOf() should return index when the value is present:
AssertionError: # /path/to/examples/mocha_node.js:10
assert(ary.indexOf(zero) === two);
| | | | 2
| -1 0 false
[1,2,3]
学んだこと
- 使われ方は多様
- 探し方も多様
- 組み合わせ方は委ねる
- 簡単さを委ねられるように作る
探し方も多様
いつものパターン
- いつも「簡単」側から作り始める
- 途中で直交性違反に気付く
- 「シンプル」と「簡単」の部分に分ける
- 依存を逆転させる
→ シンプルで直交性のある層と、簡単さを提供する層とを分けたくなる
The Art of UNIX Programming
モジュール化の原則
"ぶざまな姿をさらさずに複雑なソフトウェアを書く唯一の方法は、 全体としての複雑さの度合いを下げること だ"
"つまり、 適切に定義されたインターフェイスで結び付けられた単純な部品からシステムを作り上げる のだ。 こうすれば、ほとんどの問題は局所化されるし、全体を壊さずに部品だけを改良することも不可能ではなくなる。"
簡潔性、小ささ(Compactness)
"簡潔性とは、 設計が人間の頭のなかに入る程度のものかどうか ということだ"
"簡潔だということは「簡単に学べる」ということとも 違う。 簡潔な設計のなかには、基礎にある難解な概念モデルを習得するまでは理解することかきわめて難しいものがある。 しかし、その 慨念モデルを習得したときには、世界の見方ががらりと変わり、簡潔が単純に変わる のだ。 多くの人々にとってそのように感じられるものの古典的な例としては、Lisp言語が挙げられる。"
直交性(Orthogonality)
ある種の 独立性、分離性 と言い換えても良い。
"副作用を起こしたり、他のコードからの副作用に依存したりしていないコードは 簡単に動作を確かめられるので、テストと開発のために必要な時間が短縮される。 テストすべき組み合わせが減るのだ。 直交的なコードは、エラーを起こしたとしても、システムの他の部分に影響を与えずに簡単に置き換えられる。 そして、直交的なコードはドキュメントを書きやすく、再利用しやすい"
透明性(Transparency)
"ソフトウェアシステムは、よくわからない部分や隠されている部分がなければ透明である。 つまり、透明性は 受動的な性質 である。 プログラムは、実際に行われていることを外から見通すことができ、 すべての、あるいはほとんどの条件のもとで動作が予測でき、頭のなかで動作かイメージできるなら、透明だといえる。"
開示性(Discoverability)
"プログラムが何をどのようにするのかについて人が正しいイメージを持てるようにする機能を組み込んでいるソフトウェアシステムは、 開示性を持っている。
たとえば、優れたドキュメントは、ユーザーに対する開示性を上げる。 適切に選ばれた変数、関数名はプログラマに対する開示性を上げる。開示性は、 能動的な性質 だ。
開示性のあるソフトウェアを実現するためには、単にわかりにくい部分を作りそびれるだけではなく、 プログラムを理解しやすくするために積極的な努力を払わなければならない。"
透明性と開示性
Linuxカーネルのソースは、(していることの本質的な複雑さを考えるなら)驚くほど透明だが、開示性はない。 コードのなかを自由に動き回り、開発者のイディオムを理解するために必要な最小限の知識を獲得するのは難しいことだが、 それができれば、すべてがはっきりとわかる。
それに対し、Emacs Lispライブラリには、開示性はあるが、透明ではない。 1つのことを変えるために必要な知識を獲得するのは簡単なことだが、システム全体を理解するのはとても難しい。
エレガント
Elegance is a combination of power and simplicity.
エレガントは、力と単純性が結合して生まれる。
Elegant code is not only correct but visibly, transparently correct.
エレガントなコードは、ただ正しいだけではなく目に見える透明な形で正しい。
シンプルさを提供し、簡単さは委ねる
power-assert の場合
- file to file の方が簡単
- でも AST to AST の方がシンプルで直交している
- 途中のファイル隠さないことで透明性を確保する
gruntespower
powercoffee
empower
The Art of UNIX Programming
Unix思想
- モジュール化の原則
- クリーンなインターフェイスで結合される単純な部品を作れ。
- 明確性の原則
- 巧妙になるより明確であれ。
- 組み立て部品の原則
- 他のプログラムと組み合わせられるように作れ。
- 分離の原則
- メカニズムからポリシーを切り離せ。エンジンからインターフェイスを切り離せ。
Unix思想(2)
- 単純性の原則
- 単純になるように設計せよ。複雑な部分を追加するのは、どうしても必要なときだけに制限せよ。
- 倹約の原則
- 他のものでは代えられないことが明確に実証されない限り、大きなプログラムを書くな。
- 透明性の原則
- デバッグや調査が簡単になるように、わかりやすさを目指して設計せよ。
- 安定性の原則
- 安定性は、透明性と単純性から生まれる。
Unix思想(3)
- 表現性の原則
- 知識をデータのなかに固め、プログラムロジックが楽で安定したものになるようにせよ。
- 驚き最小の原則
- インターフェイスは、驚きが最小になるように設計せよ。
- 沈黙の原則
- どうしても言わなければならない想定外な事がないのなら、プログラムは何もいうな。
- 修復の原則
- エラーを起こさなければならないときには、できる限り早い段階でけたたましくエラーを起こせ。
Unix思想(4)
- 経済性の原則
- プログラマの時間は高価だ。マシンの時間よりもプログラマの時間を節約せよ。
- 生成の原則
- 手作業のハックを避けよ。可能なら、プログラムを書くためのプログラムを書け。
- 最適化の原則
- 磨く前にプロトタイプを作れ。最適化する前にプロトタイプが動くようにせよ。
- 多様性の原則
- 「唯一の正しい方法」とするすべての主張を信用するな。
- 拡張性の原則
- 未来は予想外に早くやってくる。未来を見すえて設計せよ。
まとめると
- KISS
- Keep It Simple and Small
- Keep It Small Stupid!