プログラマーkkの勉強/成長ブログ@ライブレボリューション(モバイル広告代理店)

Googleエンジニアから学ぶ、ハッカーになるための勉強法

Debian Project／Google ソフトウェアエンジニア鵜飼文敏さんの講演動画を見たのでまとめ。

内容は、フリーソフトウェア、オープンソフトウェアのハッカー、Google内のハッカーがどのようにソフトウェアを作っているかのまとめ。

少し前の講演だけど、ハッカーを目指す上で非常に参考になった。

ハッカーの特徴

• 普通の人をはるかに上回る高い生産性
• 高品質のソフトウェアを作りだす

ハッカーとは

ハッカーズ大辞典によると、

• プログラム可能なシステムの細かい部分を探ったり、その機能を拡張する方法を探求したりすることに喜びを感じる人
• 熱中して、さらには取り付かれたように、プログラミングする人、またはプログラミングを単に理論化するのではなく、プログラミングを楽しむ人
• Hack valueを評価出来る人(ハッカーの価値を認める人。ハッカーはハッカーを知る。)
• 手早くプログラミングするのが得意な人（プログラミングで何が出来るか、その作り方を知っている。）
• ある特定のプログラミングのエキスパート、または頻繁にそれを使って仕事をする人

ハッカーがやるようにやっていれば、プログラミングの知識も身につき、高品質なソフトウェアを作れる

Hacker ethic

• 情報の共有が実際にとても役に立つ善であると考え、フリーソフトウェアを買ったり情報や計算資源へのアクセスを実現することによって自分の技術を分け与えるのがhackerの倫理的義務であるという信念
  • ハッカーは共有を善と考え、実践する
  • googleも社内での共有が推し進められ、どのソースコードにもアクセスできる。
  • 誰が何をしているかも等しく共有されていて、共有されることで新しいものが生まれる。

ハッカーのソフトウェアの作り方

ハッカーの開発スタイル

• 個人もしくは少人数のグループで取り組む。googleでは、せいぜい5,6人。少人数なのが、素早く行うのに欠かせない要素。

• 自ら作るものを決める
  • 自分が作りたいと思うものを作る。
  • 何が利用出来て、何を新規に作らないといけないかを判断している。普段からこういうことを考えている。
  • これがあればいいのに、というものを作っていく。

• 設計しつつ実装。ハッカーはこうしている場合が多い。

• こまめにマイルストーンを設定
  • 小さい単位で動くもの・あとで使うものから。サブシステムだけで使えるようなものをまず考え、作る。動くものを作るのは達成感が得られるし、それをベースにすれば次を作りやすい。
  • 小さいものならテストしやすい。テストしやすければデバッグしやすい。これが高品質につながる。大きいものはテストしにくい。動かすための環境が必要だとテストしにくくなる。

手順

• 要求仕様
  • 作るものを決める

• 設計
  • どのように作るか考える

• 実装
  • プログラムにする

• テスト
  • 正しく作れたか確かめる

• デバッグ
  • 間違ったら正しく動くように直す

• チューニング
  • 性能を改善する

これらを素早く行う。設計と実装は考えながら行ったりもするが、だいたいこのような手順を踏む。

要求仕様

• 目標を設定する
  • 何を作るべきか
  • どのようなものを作れば便利になるか？役立つか？
  • 既にあるものは作る必要がない。何が足りないかを知るには、既存のシステムを熟知している必要がある。
    • 何は作らなくていいか？利用出来るか？
    • 何ができて、何ができないか？限界はどこか？
    • それぞれどのように関係しているか
  • 知識、経験が要求仕様を決めるときに重要になってくる。
  • 持ち駒が多ければ、ちょっと新しいものを作るだけで「おお！」と思われる。
  • 新しい組み合わせにするだけで、ブレイクスルーのプロダクトになっていく。

• デザインドキュメント
  • ハッカーはドキュメントはあまり書かない。
  • googleではデザインドキュメントを書いている。グループで開発する場合には必要。きっちり目標をシェアし、意識のすり合わせをする。

以下のような内容を記載する。

• プロジェクトの説明
  • 何をつくるか
    • どのように使われるか
  • なぜ作るのか、その理由
  • どのように作るか、その方針
  • 用語説明

• たくさん書きすぎるのは問題。読んでもらえる分量で書く。
  • たくさん書かないと理解してもらえないような場合は、問題が複雑すぎる。もっと問題を小さくする。

設計

• 実現可能性、理解のしやすいシステムにする
  • 何を利用するか
  • どのように利用するか
    • どのようにテストするか。テストすることを前提にサブシステムを作る。
  • API、外部インターフェイス。小さい、テストしやすいインターフェイス。
  • アルゴリズムとデータ構造が重要。基本的なアルゴリズムやデータ構造を応用する。そうすれば見積りしやすいし、理解しやすい。
  • デザインパターン。わかりやすいインターフェイス。詳しい説明がなくても使えるもの。

実装

• 様々なノウハウを使いこなせるか
  • 言語のイディオム
  • アルゴリズムとデータ構造、デザインパターン。ネーミングなどもどうすればわかりやすいか。
  • 簡単なプログラムをちゃんと作れるようにする。基本をおろそかにしない。

• 読みやすいコードを書く
  • Code readingをすることが必要
  • チームでやる場合、特に読みやすいコードを書く必要がある
  • かけるためにはたくさんのコードを読む必要がある。今はオープンなソースコードがあるのでそれを読む。
  • どういうコードがわかりやすいとか、こういうのははまりやすいとかを学ぶ。
  • code reviewは良い。ペアプロより効率よい。プログラムを書いた人とは違う目で見るので気づきが多い。

• 読みやすいコードを書くための参考書籍

• 集中する
  • 頭の中にプログラムを入れる
  • 全体の構造、細かい構造を頭に入れることで素早く作れる。

• コードリーディング
  • コードを読み解く力を養う
  • 言語特有の書き方を知る
  • アルゴリズムとデータ構造の実装の仕方
  • デザインパターンを知る。
  • わかりやすいネーミング。重要。クラス名、メソッド名。いかにわかりやすくするか。分かりやすければ詳細を読まなくてもプログラムの内容がわかりやすくなる。たくさんコード読めば、こういうのが速いとか読みやすいとかわかる。
  • 参考書籍

• コードレビュー
  • 人にコードを見てもらう/人のコードを見る
  • 違う目で見ると気づくことがたくさんある
    • 細かく切り刻んで、起こりうる問題を見出す。ここ見逃してるとか、こういう場合はどうなるの？とか
    • 別実装の提案。違うアルゴリズムの方がいいんじゃない？とか
    • 明らかでない点を明らかにする
  • レビューは新しいコードを書くのと同じくらい重要とgoogleでは思われている。
  • 開発チームを育てる。皆のコードを読むことになるので新しい知識が入ってくる。

テスト

• ユニットテスト
  • テストしやすいコードを書く
  • 使いやすいAPI
  • ユニットが信頼出来ることを保証。ユニットテストを積み上げる。
• 危険なパターンをどれだけ想像出来るか？こういう使われ方をされるとやばい、というのをつぶす。
• コードを書いた時の思い込みをどれだけ捨てられるか

デバッグ

• どこがおかしいのかを調べる
  • プログラムがどう実行されているのかを知る
    • ハッカーは勘でデバッグできる。なぜなら、プログラムの流れがどうなっているかわかっているので、どこでおかしくなっているか想像出来るから。
  • 範囲を狭めるテクニックを知っていれば、素早くデバッグできる
    • 防御的コーディング
    • ユニットテスト
    • デバッガ

• 参考書籍

チューニング

• ボトルネックを知ることが重要
  • アルゴリズムと計算コスト
• 計測
  • チューニングでは、勘を働かせるよりもちゃんと計測
  • プロファイラを使いこなす
  • 確かにここが遅くなっている、ということを把握する。
  • やみくもにやるのは無駄。
• 高速化
  • アルゴリズムの改善
  • 最適化テクニック

• 参考書籍

ハッカーに近づくには

• ツールはフリーソフトウェア/オープンソフトウェアで揃う。必要経費は少ない。
• 必要なのは知識と応用力。これらをつけるための時間を確保する。
• プログラミングを楽しむ

必要な知識

• コンピュータサイエンス
  • Computer Science Unplugged
    • アメリカの小学生向けのコンピュータサイエンスの教科書だが馬鹿にできない内容。２進数とか今読んでもためになる。
    • こういうのをおろそかにしていると成長できない。理解しておく必要がある。

• 要素とその組み合わせ方
  • アルゴリズムとデータ構造、デザインパターン。こういう場合はこうすると良い、など知っていると速度があがる。
  • プログラミング言語。とりあえず１つ。できればたくさん。
  • 正規表現などの知識
  • コンパイラ、ライブラリ、OS、ハードウェア。下の方で何が行われるか知っていれば、設計する上で無駄なことをしないですむ。

知識の習得の仕方

• 良い書籍を読む
• たくさんのコードを読む
• 色々試す
  • 自分のアイディアで改善してみる
  • 限界を知る。無茶なことをして、ダメなパターンを知る。どういうことをするとシステム的に危険になるかを知る。
  • ハッカーにコードを見てもらう。自分のくせやいい方法を知ることができる。
    • コードを公開
    • コードレビュー

ハッカーと仕事をするときの問題点

• 面白い問題設定が出来るか
  • できて当たり前のことはやりたがらない
  • 夢物語のような実現不可能なことに取り組むのも無駄
  • できて当たり前の中で、何か新しい今は当たり前じゃないことは喜んで取り組む
• 情報の共有。探せば見つかるようにしておく。ハッカーなら必要な情報は自分で取り出せる。
• 競争と協力。オープンソースとかもそう。
• やる気・集中の持続
  • 割り込み・ミーティングを嫌う理由
    • 今ノってるのに、10分後にMTGとかがあると、やめとくかぁとなってしまい効率が悪い。
    • googleは4,5人で同じ部屋。皆が集中してるときは、お互い集中する。

その他に紹介されていた書籍

• 高品質のソフトウェアを作るための参考書籍

感想

とにかくたくさんのコードを読むことが大切というのはわかった。Ruby on Railsだと、社内SNS:SKIPとかRailsのコードを読むとよさそう。

また、自分のコードを人に見てもらってフィードバックをもらうことが大切。これはブログでコードをさらしていけばいいかなと思う。

書籍も今までそんなに読んでいなかったので、今回紹介されていたものを読み進めることにした。コンピュータサイエンスに関する知識がないので、特にコンピュータを使わない情報教育アンプラグドコンピュータサイエンスがきになる。

勉強することはたくさんあるけど、楽しみながら、自分の手を動かしながらやっていれば、ハッカーへ近づけると信じてこれから取り組んでいこうと思った。

コードの読み方に関してはこの記事も参考になった。

• すぐに使えるソースコードの読み方を指南 − ＠IT

ポイントは以下。

• コードは読むものではなく、理解するもの――単に文字を追うだけではなく、それが意味する内容を理解するスタンスが大切
• 4つの視点で読む
  • 細部から内容を理解する「ミクロの視点」
  • 規模や仕組みから理解する「マクロの視点」。ソースツリーの中の論理的な構造をまずしっかりと把握。
  • 文字列を読み込んで理解する「スタティックな視点」
  • ソースコードによって生じる動作で理解する「ダイナミックな視点」
• コードが大規模化している近年、まずマクロの視点でコードの全体像を理解すると効率的
• コードを読む際、コードの全体像や、コードが実現する機能のイメージをつかむことを目的に、丹念に読み込む
• 大きな構造をつかむ際にはツールを使うが、細部についてはフローを絵で書いたり、『変数が多い』『条件分岐が複雑すぎる』など気付いたことを随時メモ
• 「こういう問題があるのではないか、といった仮説を立ててレビューする視点を設定する。その中でのみ不備を考えるようにすると効率的
• 「こうなのではないか」という自分なりの仮説や予測を立てながら読んで、主体的かつ意識的に得た理解が、次のモチベーションにつながったり、良いコードを書くための基礎体力向上につながる。

読みやすいコードに関しては、以前に、本を読んでまとめたのでこれを再読しようと思う。

• きれいなプログラムを書くには

参考

• 鵜飼文敏さんの講演「ハッカーのソフトウェアエンジニアリング」の動画を公開しました：ITpro

　　

◆◆このブログのサイトマップへ◆◆

Permalink | コメント(1) | トラックバック(0) | 11:10