図書館に、
オライリー書籍がたくさんあるのを見つけてしまいました。
技術書は手元に置いて、コーディングの際にペラペラめくるのが一般的と思ってるエンジニアが多いようですが、リファレンス本と啓発本は分けて考えたほうがいいでしょう。
啓発本は、リファレンス本のように、あまり何度も読み返すという事はなく、一度読めば十分なものが多いため、オライリーであろうが、リーダブルコードだろうが、読んだという実績が重要な本もたくさんあります。
今回は図書館から「ベタープログラマ」という書籍を借りてきて読んだ感想文をブログに書いておこうと思います。
書籍評価
★★★★☆
この書籍のコンセプトは、「プログラムスキルを上達させたい」というプログラマ向けに書かれた書籍で、ソフトウェア開発の質を向上させるためにどの様にすべきかが書かれてあります。
リーダブルコードと同様に、世の中のソフトウェアエンジニアは、初心者からマネジメントを行っている人、テスター、それらに関わる人は、この書籍を読むと色々な学びがあるでしょう。
副題として「優れたプログラマになるための38の考え方とテクニック」と表紙に書かれていますが、「優れたプログラマ」というのはどういう事なのでしょう？
1. 見た目がキレイなコードを書くこと
2. バグの少ないプログラムを構築できること
3. 優れたチーム開発が行えること
他にもたくさんありますが、日本国内におけるソフトウェア開発チームに属していると、多くの組織でチームプレイや、組織開発などが問題になりがちですが、これは日本だけではなく、世界的にも同じ状態であるとこの本を通じて理解できます。
どこの会社も、バグは悪として嫌われているし、バグを生み出したプログラマは、評価レベルを下げられてしまうという思考で、さらにはQAチームと開発チームの敵対心など、本来開発における品質向上を目的と考えると、少しそれてしまう思考が植え付けられてしまいがちな根本理由を突っついた内容になっています。
簡単に内容紹介
非常に心に残る内容もあったので、少し深掘りして後日ブログで紹介しようと思いますが、この書籍の最も面白かった部分は、
すべての章の最後に「一万匹のモンキー」という挿絵が書かれていますが、これが非常に面白い。
僕はあまり聞いたことが無いのですが、海外ではただ何も考えずにプログラムコードだけを書く、コーダーと呼ばれている人は、「コードモンキー」って言われているらしいですね。
そんなコードモンキー達を皮肉っている挿絵になっているんですが、これがアルアルだらけで非常に面白い！
ペアプロってそんなに有効なのか？
この書籍で、最初から最後まで、プログラミングに関するオススメ手法が書かれていますが、それは「ペアプログラミング」です。
個人的にはあまり経験がないのですが、ペアプロによるプログラムコンテストや、ペアプロハッカソンなどもイベントとして数多く開催されているほどペアプロは浸透しているようです。
実際にペアプロを行うメリットとしては、自分ひとりの思考でプログラミングを進めるよりも、全く違う視点が有ることを作業しながら気がつけるというメリットや、メンターとのペアプロの場合は、より上質なプログラミングをその場で知ることができ、成長速度がグッと加速する事が大いにあるようですね。
もちろん、メンター側も、自分よりもレベルが低い人とペアを組んで何もメリットが無いかと考えがちですが、初心者などが失敗するポイントを再確認できたり、周囲が犯しがちな失敗を見ることが出来、マネジメント能力が向上することは容易に創造できます。
会社にとっては、一つのソフトウェア開発に2倍の人件費がかかるのを嫌がる組織もあるかもしれませんが、人材教育、マネージャー育成、品質向上など、個別に対応するのが、1回の工程で詰め込まれている事を考えると、非常に効率的で、組織運用に置いてはもってこいの手法だと考えられますね。
経営者がこの本を読むポイントとしては、こうした効率的な手法を取り入れることで、自社の開発部門の問題が大きく改善するという視点に立てるかどうかでしょうね。
リファクタリングと改善を勘違いしてはならない
以前勤めていた企業の開発部門で、数年前に開発完了したソフトウェアを現時点では少し改善しないと行けなかったのだが、その時に在籍していたプログラマ達が「リファクタリングしなければ」と仕切りにいっていたのを覚えていますが、僕は個人的に作り直したほうがいいと感じていたのが、そのまま書かれていました。
リファクタリングは、プログラムをより効率的に書き直す事だと勘違いしているエンジニアが多いようですが、リファクタリングは性能を変えないことが前提になります。
ということで、ソースコードがきれいになるという点では、改善と言えるかもしれませんが、ソフトウエア開発に置いて、改善と言えば機能向上を行なうことになるため、ここでは、改善とリファクタリングを同じ感覚で使っていては、開発部門のレベルが疑われてしまいます。
言葉の定義は非常に重要で、全員の認識が同じであれば、どーでもいいじゃん。と考える国語の苦手な人がいる開発部門は、コミュニケーションが二の次に考えられるケースがよくあるため、こうしたスキルも向上するために、この本を読んでちゃんとした言語を理解しましょう。
そして、エンジニア以外でも、技術が分からないと言ってこうした書籍を読まないのは、非常にもったいない。
むしろ初心者ではなく、管理者や経営者などが読むべき書籍なのかもしれません。
上質なソフトウェア開発、行ってみませんか？
0 件のコメント:
コメントを投稿