デブサミ2016再演『今日の習慣が明日をつくる~よりよい技術者を目指して~』参加レポート #devsumi

発表スライド

docs.google.com

概要

  • 習慣的に行っている訓練のうち、明文化できるものを伝える
  • 言っても問題が無いもの
  • 技術者の週間を見直すきっかけを
  • 1年で成長することはない。4,5年かけて成長する

良い技術者とは

  • 読む力
  • 書く力
    • コードを書けるのは評価されない
    • ドキュメントを書くのも重要
  • 捨てる力
    • 自分や組織が作ったものを捨てる、再実装する

読む力

  • 仕様を理解する
  • 仕様を類推する
    • 「地球上で動作する」なんて前提条件は書かない
    • 今暗黙のものが未来永劫変わらないとは限らない
  • コードを理解する
    • ゴミのようなコードが数十万行ある中で、新機能を探したりとか
    • 3個先の呼び出し状態を暗記した状態とか
  • コードを評価する
    • 設計や品質の妥当性を検証する
    • 沢山読めても、良い物が分からなければ読む力があるとはいえない

書く力

  • 仕様に対して妥当なアルゴリズムを実装できる能力
  • 書いたコードの制約事項を明らかにする
    • CPU heavyなのかメモリheavyなのか
    • 技量が足りないエンジニアは、1種類の書き方しか分からなかったりする
  • 書いたコードの最低限の品質をテストによって保証する納涼
    • QAエンジニアは品質に対して特殊な人達

捨てる力

  • 現在のコードを作りなおす能力
  • 厳密に再定義する能力
  • 様々な方法で表現する能力
    • 多種多様な言語とか
  • 自分のコードは捨てられるはず

良い技術者になる方法

  • 仕様書とコードを大量に書いて読んで捨てる

標準化された仕様書

  • 読んでおけば網羅性が増える
    • ISOとかIEEEとかIETCとか
    • JavaならJEPとかJCPとか
  • 高度に整備された知見から都合の良い部分だけ拾うため
    • 1から作るより簡単
  • 原理原則を理解するため
    • 何となく動かないから頑張るのではなく、仕様を確認する
    • 仕様通りだけど動きが気に入らないというのはあまり良くない
  • アプリケーションやミドルウェアが正しく動いているかを検証するため

まずはHTMLから

  • W3CWHATWGの仕様書を確認する
    • ググった最初のページを参考にするとか止めよう

RFC

  • RFC2119は要求を表す言い回しについて理解する

HTTP1.1

  • RFC7231を開始点にする
  • 最初は流し読みしてボリューム感を掴む
  • 関連のRFCのポインタがいっぱいあるのでオススメ

JSR

IEEE

  • IEEE754-2008
    • 浮動小数点演算に関する仕様
    • 如何に不安定か分かる
    • 仕様書が2万円ぐらいかかる
      • 会社の金で買いましょう

網羅性が気になったらISO

  • ISO12207
    • ソフトウェアのライフサイクル
    • 自分がやったことと全体との違いが分かる
  • ISO90003

仕様書を読もう

  • 仕様書によって決まるべき
  • 誰かのフィーリングではなく

コードを書こう

  • 大量の良いコードがある
    • 個人のやってみたみたいな悪いコードもある
    • Gitみたいな巨大なプロジェクトの悪いコードもある
  • 貢献の機会がある
    • 個人のリポジトリ
    • 小さいライブラリのコミュニティ
    • 大きいライブラリのコミュニティ

まずは毎日ログイン

  • Trending repositoriesを見よう
  • 言語のトレンドとかを見るだけで良い
  • 惰性で見れるように

Github以外の情報源

  • Tech Blog
    • AWS(Security)
      • Linuxのことはだいたい分かる
  • VOXXED

毎日30分コードを眺めよう

  • トレンドに上がっていれば食わず嫌いせずに眺めてみよう
  • ネストが深いけど、Goなので深くなるし、規則性がある

なぜコードを眺めるのか

  • 恐れを減らすため
  • デジャブ感のあるものは挫折しづらい
  • 良い処理構造(ネストが深いとか)はあまり言語に関係ない

  • モチベーション無しにコードを見られるようになろう

  • 集中しないと読めないとか無いように

リポジトリの選び方

  • 得意な言語のリポジトリ
  • リポジトリの説明が分かりやすい
  • READMEがしっかり書かれてる
    • ビルド方法が書いてないものは読むに値しない
  • 基本的な使い方が書いてある
  • 半年以内にコミットがある
  • CI(TravisCI)とかで成功が維持されているもの

コードの読み始め方

  • 依存ライブラリを確認
    • 依存ライブラリで知らないものはそっちを優先した方が良いかも
  • ビルド環境構築
    • Windowsだとビルド環境辛い
    • 色んなことが分かる
      • 如何にWindowsがクソかとか
  • Unitテストを実行する
    • Windowsのみ動かないことも
  • エディタやIDEは慣れたものを
    • コードとエディタ同時に新しいものをするのは良くない

コードの読み方

  • 全部のコードを何度も眺める
    • 20000ステップを30分ぐらいで読めるようになる
  • 外部との境界面となる場所から読む
  • 仮説と検証を繰り返しながら読む
    • 関数名から動く内容を想定する
      • rubyは関数名をガンガン変える
      • Javaは関数名が長くなりがち
      • Hasskellは数学的に完璧な名前を付けたがる
  • 抽象度の高い部分を優先して理解する
    • Javaだったらインタフェースとか
  • 難しい部分は後回し
  • コードが荒れているならgit blameすると良い

    • 色んな人が理由あって沢山触っているはず
  • コードを高速に読もう

コードを書く習慣

  • 規模のある組織においてはミドルマネジメントは重要な仕事
    • 100人ぐらいいて、ミドルマネジメントがいなくて好き勝手書いている企業はブラックになりがち

一人砂場プロジェクト

  • しがらみの無い自由を味わうため
  • 自身の能力を客観的に評価するため
  • 自身の価値観を少しずつ変えるため
    • 企業内では味わえないもの
  • 価値の不明瞭なものを評価するため

一人砂場プロジェクトで何する?

ネタがない?

  • 短縮URLを生成する画面の無いサーバ

    • groovyだったら15行ぐらいで書ける
  • 小さい車輪を再発明しよう

毎日少しずつ書こう

  • 最初は毎日エディタを起動して新しいプラグイン入れるだけで良い

コードを捨てる体験をしよう

  • 捨てることでもっとうまくもっと早くやり直せる
  • 始まりから終わりまでやり直す
  • 良い技術者は同じ仕様で何度もやり直す人が多い

質問

  • ISOはPDFだけ?
  • 紙もある
  • 図書館にある?
  • ある
  • 解説本も良いけど、原文も読もう