dimeizaのブログ

興味のある技術(IoT/VR/Smart Speaker)とか、資格試験の話とか、日常で出会ったTechな話について書いています。

Developer's Summit 2016 【19-C-3】今日の習慣が明日をつくる～よりよい技術者を目指して～ 聴講メモ

Developers Summit セミナー聴講メモ

講演資料

https://docs.google.com/presentation/d/1nWhQxxexCpv31WsNdQ3NNkrIxIT1udIZ5ty3yIueYYI/edit#slide=id.g35f391192_00

概要

　良い技術者の基準を定義した上で、『仕様書とコードを大量に読んで、書いて、捨てる』という技術者の成長のための指針を、自身が行っている習慣を通して語る。

スピーカー

佐藤さん。某SIerのR&D部門の人らしい。 githubやツイッターなどで活動。 WebDBPressで連載。

詳細

  • 今日は、自分の習慣のうち、明文化して効果を説明できるものを持ってきた。
  • 技術者としての習慣を見直すきっかけを提供したい。

よい技術者とは

　3つの基準がある。

読む力

  • 仕様理解、類推
    • 暗黙の条件や仮定を理解する能力。
  • コードを理解する能力
    • 短い時間で多くを把握する力。
    • 関数やオブジェクトの関係性を把握する力。
  • コードを評価する能力
  • 設計や品質の妥当性を評価する力。
    • 書きっぱなしでは良い技術者ではない。
    • 自分の過去を評価するのも力。

書く力

  • (当然だが)仕様に対して妥当なアルゴリズムを実装できること。
  • 書いたコードの制約事項を明らかにする力。
    • こういう条件、環境では動かないよ。
  • 最低限の品質をテストによって保証する。
    • 個人的にはQAは独立した能力と考えていて、開発者にそれを要求するのはどうかと思っている。
    • ただ、QAテストする最低限の品質を確保することは必要。
    • ユニットテストを想定しているが、結合テストぐらいまではやってほしいと思う。

捨てる力

  • 作り直す力。
  • 厳密に仕様を再定義する力でもある。
  • 同じ仕様を様々な方法で表現する力とも言える。
  • ただし、実際、動く既存のものを捨てて作りなおすのはそう簡単ではない。
    • 能力に大きく左右される。
    • ただ、日々成長しているなら捨てられるはず。

良い技術者になる方法

　仕様書とコードを『大量に』読んで、書いて、捨てる。

標準化された仕様書を読む習慣

  • ISO,IEEE,IETF、W3Cなどなど。
    • 自分の業務に近い標準化団体はウォッチしてほしい。

標準化された仕様を読む意味

  • 高度に整理された知見から都合の良い部分だけを拾う。
    • 0からモノを作り出すには労力が必要だが、変更したり削除するのは遥かに楽。
  • 原理、原則の理解
    • 原理、原則を理解するのはエンジニアリングの根幹。
    • とりあえず動いたからいいやを避ける。
  • アプリケーションやミドルウェアの正しい動作確認

普段から読む習慣がない人は、HTMLがおすすめ

  • HTML5は大きいので全部通して読む必要はない

  • が、仕様上どうなっているかを、グーグル先生に雑に聞くのではなく、仕様書に当たること。

  • RFCなら2119から読むとよい。

    • 要求の程度を表す言い回し(Must,Shall…)を説明している。
    • これを踏まえて、日本語の言い回しとしても一定になるように仕様書を書けると良い。

  • RFC7231(HTTP1.1)を開始点にする。

    • HTTP2が最新だが、HTTP2は1.1の理解を前提にしている。
    • ステータスコードやヘッダの意味について記載されている
    • 量が多い。
      • 何度も流し読みして慣れる。
    • 古いRFC、関連するRFCへのリンクが多い。
      • 辿って理解する。

JSR

  • 仕様書として非常に良く出来ている。オススメは以下。
  • Java Transaction API
  • Java Servlet 2.4
    • 古めだが難しさが少ない
  • Java Servlet 3.1
    • 最先端の技術

論文と仕様はIEEE

  • IEEE754.2008
    • 浮動小数点演算に関する仕様
    • Javaで浮動小数点演算を始めたら実は負けなのだが、何故負けなのか、これを読めば分かる。

ISO

  • どこかのタイミングで、必ず網羅性を気にする時がやってくる。そんな時はISO。
  • ISO 12207
    • ライフサイクル全般
  • ISO 90003
  • ISOのプロセス系は、各プロセスがモジュール化されている
    • 一部分だけ取り出すことに利便性が高い

仕様書を読もう。

  • 良い技術者はこまめに仕様書を確認している。

コードを読む習慣

GitHubには成長の機会

  • 大量の良いコードがある。
  • が悪いコードもある。
  • 貢献の機会がある。

  • OSSなら無償でリポジトリを公開できる。

  • 毎日ログイン

    • 毎日5分トレンド(Trending Repositories)を見る。。
    • 惰性で見るようになるまで続ける。
    • 頑張り過ぎない。

  • 最近のGitHubのトレンドは"無理のない学習のやり方"。最近は"Til(Today I Learned)"がバズっている。

    • 学習を続けた成果が共有されている。
    • これを見ても分かる通り、GitHubの技術者たちは常に学んでいる。

  • GitHub以外だとTech Blogが情報源。

毎日30分コードを眺める。

  • 理解しなくても良い。
  • ソースコードを絵画的に鑑賞する。キーワードとインデントを認識できる程度。
    • なぜ？
      • 畏れを減らすため。
      • 意識レベルになくても脳に記録されている。
      • よりたくさんのコードを見た時に挫折しないようにするため。
      • 良い処理構造は言語にあまり関係ない。
  • コードを見慣れよう。
    • モチベーションなしにコードを見られるようにしよう。
    • 呼吸するたびに意識を高める必要はないはず。

読むべきリポジトリ

  • 得意な言語
  • 説明がわかりやすい
  • Readmeがしっかりしている
  • 半年以内のコミット
  • CIサービスによって成功が維持されている

読み始め方

  • 依存ライブラリを確認
    • 先に見たほうが役に立つ。
  • ビルド環境、ユニットテスト環境を作る。
    • ローカルでやるとこける。
      • が、それが勉強になる。
  • 全部のコードを何度も眺める。
    • 広く浅く。
    • 境界面となる場所から読む。
    • 仮説と検証を繰り返しながら読むと記憶に定着しやすい。
    • 抽象度の高い部分から読む。
    • 難しければブックマークして後回し。
    • git blameを見ると、開発者たちの苦労がわかる。
    • コードを動かしながら読む。

コードは高速に読もう

  • コードを読む速度は改善できる。
  • 良い技術者は毎日コードを読んでいる。

コードを書く習慣

  • SIer企業では実装者に対する評価は低い。
    • 30代後半になるとリーダーシップを求められる。
      • 結果、コードを書いている時間は短くなる。
    • ただ、一定規模のミドルマネジメントは重要。
      • 中企業でミドルマネジメントがコケると会社が傾く、とかはしょっちゅうある。

一人砂場プロジェクト

  • GitHubでやろう。
  • 一人でコードを書き、学ぶ遊び
  • 計画しない。
  • 飽きたらやめる。

  • 公開しなくてもいいが、公開しておくのがオススメ。

    • 見られると恥ずかしいと思うかもしれないが、実際誰も見てないので大丈夫。

  • 意味は？

    • 自由を味わう。
    • 自身の能力を客観評価する。
    • 自身の価値観を変える。
    • 価値の不明なものを評価する。

  • 何すれば？

    • 良さそうなものを何でも使ってみる。

  • ネタがない

  • 小さい車輪を再発明する。

    • 他の言語にはあるけど得意な言語にはない。
      • XUnitとかはそうやって広まってきた。

  • 毎日少しづつ書く。

    • 最初はエディタ起動とプラグインだけで良い。
    • 毎日楽しくコードを書くほうが大事。

コードを捨てる体験

  • 続けていると『もうこのコードに耐えられない』となる。
    • 最高の体験。
    • 別な方法で0からやり直すことで成長できる。
  • 一人プロジェクトをやりなおそう。
    • 始まりから終わりまで、そしてやりなおすこと。

まとめ

  • 良い技術者になるには？
    • 仕様書とコードを大量に、読んで、書いて、捨てる
    • 無理せずやっていきましょう。