  |
要件・動きを理解し、分解・標準化して部品を作り、それらを適切に組み合わせて実現する。
デキのいいプログラムとは、理にかなった構造で、処理が適切に切り分けられており、再利用しやすく、構造的バグが少なく、修正リスクが低い。そういったものを書けることがプログラマとしての技量だと考えている。
私は、流れが読みやすい分岐、引き渡すデータの考え方、不必要な状態の保持、切り分けるべき箇所、機能の標準化、例外を受け止める適切な位置、などを教えるのだがあまり気に入っていないようだ。ちゃんと動いている（ように見える）コードの書き方をごちゃごちゃ言うのは、無駄なこだわり（例えば会議資料の誤字脱字や送り仮名を子細に調べるような）に感じるらしい。
彼にとって技術力というのは「～～を使えば〇〇ができる」ということであり、より多くの新しいフレームワークやライブラリのサンプルを動かせるようになること。私の教えは勉強熱心な彼のスキルの足しにはならないのだ。
でも仕方ないのかもしれない。
より良いプログラムを書いたところで、評価してくれるのは共同作業の同僚か、私がいなくなった後でそれを引き継いだ誰かぐらいだ。場合によっては簡単だったと思われて評価が下がりさえする。
一方で沢山のフレームワークを触っておけばSNSのプロフィール欄が華やぐし、次の仕事を探すときの選択肢も広がるかもしれない。たとえそれほど良いものができなかったとしても
プログラムはその規模や目的によって思想ががらりと変わる。 増田の思想が役に立つのは大きなプログラムを書く時の話だ。 サンプルいじってる規模では恩恵は受けられない。 増田の...
7
