「達人プログラマー」を読んだ

昔から気になっていた 達人プログラマーをやっと読んだ。

私の経験不足もあって、全体の５割程度しか理解できなかったように思う。 また、しばらく経ってから読み返すことで、理解が深まるのではないかと思っている。

正直、いい意味で期待を裏切ってくれた章が第一章「達人の哲学」である。プログラミングに関するテクニック的なものばかり書かれている本かと思っていたのだが、仕事をするうえで普遍的に必要となりそうな心構えが書かれていた。

その他、個人的に印象に残ったところを少し紹介したい。 

５　あなたの知識のポートフォリオ

あなたの知識の価値が低下するのと連動して、あなたの企業やクライアントがつけるあなた自身の価値も低下していくのです。 こういったことが起こるのを何とか防がなければなりません。

自分の価値を保つために様々な知識を身につけなさいということであるが、私自身新しい技術の流れに付いていけておらず、IT業界全体として見た場合に価値の低下を防ぐことができていないと思っている。今は、ほとんど１０年以上前の技術しか使っていないので何とかなっているが、そこに居たとしても新しい技術を学び自分の価値を高める活動をしていかなければならないのだと改めて感じた。

７　二重化の過ち

信頼性の高いソフトウェアを開発して、開発そのものを簡単に理解したり、メンテナンスできるようにする唯一の方法は、DRYの原則に従うことである。

同じ内容が複数の場所に書かれることが、どのように発生して、それをどのように防ぐかということが書かれている。DRYの原則はRuby on Railsでも適用されている考えだったこともあって興味を引いたが、コードとコード以外の二重化も書かれていたのは意外と考えさせられた。SIerでのプログラマは、プログラム設計書の内容をそのままコードの落とすのが仕事というような認識の場合があるが、この場合にプログラム設計書とコードはDRYの原則に反している。このあたり、今の仕事でも何か取り組める部分があるのではないかと思った。

１６　パワー・エディット

強力なエディターとあたなの指先を使えば、高い生産性を上げることができるようになるのです。

職人の道具としてエディタを使いこなす必要がある。大学時代、vimを使いこなしている先輩がいたが、その人のvimの操作は画面が流れるようで意味が分からないほどだったのを覚えている。私はエディタの操作に弱い…。

２５　リソースのバランス方法

割り当てのネスト

コードの異なった場所で同じリソースの組を割り当てる場合、常に同じ順序で割り当てるようにします。これによりデッドロックの可能性を削減することができます。

リソースの割り当ての順序が異なっていてデッドロックが発生するのを経験したことがあった。経験がなければ、理解できたとは言えなかっただろうし、印象にはあまり残らなかったと思う部分。

４２　どこでも自動化

２ページ以上にわたる何らかの一般的な作業を何度も何度も繰り返す余裕は、我々に残されていないのです。つまり、ビルドやリリース手続き、コードのレビュー作業といったプロジェクトに関する繰り返し作業を自動化する必要があるのです。

社内でも自動化、自動化と叫ばれてはいるが、全く適用が進んでいない部分である。最近言われ始めてことかと思っていたが、１０年以上も前から書かれていて、取り組めていないとは何事かと思った。

残念ながら達人プログラマーは絶版になってしまった。リファクタリングのように新装版出ればよいのに…（旧リファクタリングも積読だが）。 

達人プログラマー―システム開発の職人から名匠への道

 プログラマーとしての経験が少しついてから読むのが良いような気がした。経験があると内容の理解も深まると思う。何となく古いような記載もあったが、現代でも通用する内容が十分に書かれており、考え方の部分は非常に良いと思う。