1 of 66

今日の習慣が明日をつくる

よりよい技術者を目指して

2 of 66

自己紹介

佐藤 太一

3 of 66

Javaの鉱脈 連載中

4 of 66

Siden

https://github.com/taichi/siden

5 of 66

今日の概要

僕が習慣的に行っている訓練のうち

明文化できるものを整理してきた

6 of 66

今日の目標

技術者としての習慣を見直す

きっかけを提供したい

7 of 66

今日の目標

みんなでよい技術者になろう

技術者としての習慣を見直す

きっかけを提供したい

8 of 66

よい技術者とは?

9 of 66

技術者を評価する3つの基準

書く力

読む力

捨てる力

10 of 66

技術者の読む力の例

  • 仕様を理解する能力
  • 仕様を類推する能力
    • 暗黙の前提条件や仮定を理解する能力
  • コードを理解する能力
    • より短い時間で多くを把握する能力
    • 関数やオブジェクトの関係を把握する能力
  • コードを評価する能力
    • 設計や品質の妥当性を検証する能力

11 of 66

技術者の書く力の例

  • 仕様に対して妥当なアルゴリズムを実装できる能力
  • 書いたコードの制約事項を明らかにする能力
  • 書いたコードの最低限の品質をテストによって保障する能力

12 of 66

技術者の捨てる力の例

  • 現在のコードを作り直す能力
  • 現在のコードを厳密に再定義する能力
  • 同じ仕様を様々な方法で表現する能力
  • 日々学習し成長しているなら、自分のコードは捨てられるようになる

13 of 66

よい技術者になる方法

14 of 66

仕様書とコードを

大量に

読んで、書いて、捨てる

15 of 66

標準化された仕様書

を読む習慣、ありますか?

16 of 66

標準化された仕様書とは?

  • 標準化と言えばISO
  • 電気・電子工学の学会IEEE
  • インターネットのことならIETFのRFC
  • ウェブのことなら W3CWHATWG
  • JavaのことならJEPJCPのJSR
  • 標準化団体は他にも沢山ある

17 of 66

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

  • 高度に整理された知見から都合の良い部分だけ拾うため
    • 作り出すより改変や削除の方が簡単
  • 技術の原理・原則を理解するため
    • ワークアラウンドする前に仕様を確認する
  • アプリケーションやミドルウェアが正しく動いているのか検証するため

18 of 66

まずはHTMLから

  • 仕様書を全部通して読む必要はない
  • HTMLの要素や属性で迷ったらW3CWHATWGの仕様書を確認する
  • 仕様書特有の言い回しや分かり辛さはあるが慣れるしかない

19 of 66

RFCなら2119から読む

  • RFC2119はMUSTやSHOULDといったRFCにおける要求の程度を表す言い回しについて説明している

20 of 66

RFCの本命はHTTP 1.1

  • RFC7231を開始点にする
    • HTTPのステータスコードやヘッダの意味について定義している
  • 最初は流し読みしてボリューム感を掴む
  • 何度も流し読みして徐々に慣れる
  • より古いRFCへのポインタがあるので、それをたどっていくことで理解できる

21 of 66

読んで欲しいJSR

  • Java Transaction API
  • Java Servlet 2.4
    • 古めだが難しさの少ないServletの仕様
  • Java Servlet 3.1
    • 最先端のWeb技術に取り組んだServletの仕様

22 of 66

論文と仕様書ならIEEE

  • IEEE 754-2008
    • 浮動小数点演算に関する仕様
  • IEEEの仕様書はPDFが高額なので敷居が高い

23 of 66

網羅性が気になったらISO

  • ISO 12207
    • ソフトウェアライフサイクル全般について整理したもの
  • ISO 90003
    • ソフトウェアの品質保証に関するガイドライン
  • IEEEより高額なので個人で買うのはおすすめしない

24 of 66

仕様書を読もう

議論の起点は仕様書であるべき

25 of 66

仕様書を読もう

議論の起点は仕様書であるべき

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

26 of 66

コードを読む習慣、ありますか?

27 of 66

GitHub

最先端の技術とコミュニティがある

28 of 66

GitHubには成長の機会がある

  • 大量の良いコードがある
    • 悪いコードもある
  • 貢献の機会がある
    • 個人のリポジトリ
    • 小さいコミュニティ
    • 大きいコミュニティ
  • OSSなら無償でリポジトリを公開できる

29 of 66

まずは毎日ログイン

Trending repositoriesを見よう

https://github.com/trending

30 of 66

毎日5分トレンドを見よう

  • どんな言語が流行ってる?
  • どんな開発者が注目されてる?
  • 最初はリポジトリ自体は見なくていい
  • 惰性で見るようになるまで続けよう
  • 頑張り過ぎないことが大事

31 of 66

32 of 66

今週の流行は?

  • FreeCodeCampは無償でHTML5やJSを学習できるサイト
  • 30DaysofSwiftはSwiftを30日間学習した記録
  • hostsはスパムや広告配信で使われることで有名なホストの一覧
  • tilはToday I Learnedの略で毎日の個人的な学習記録のリポジトリ。reddit辺りが元ネタ

33 of 66

だいたい学習してる

無理のないやり方で続けた結果を見にいくのが流行り

34 of 66

GitHub以外の情報源

35 of 66

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

  • コードを理解しなくてもいい
  • 色んなコードをブラウザで眺めよう
  • トレンドに上がっていたら食わず嫌いせずに何でも眺めよう

36 of 66

「コードを眺める」とは?

37 of 66

38 of 66

コードの眺めかた

  • キーワードとそうでないものを色で区別する程度にコードを認識する
  • 単語には着目しない
  • インデントはそれなりに観察する

39 of 66

コメント

モジュールの依存性

関数の宣言

コメント

ネストは深いが

規則性がある

40 of 66

何故コードを眺めるのか?

  • 畏れを減らすため
  • 意識しないレベルでも見たことがあるものは脳に記録されている
  • コードを読むときに何となく見たことがある気がするものは挫折し辛い
  • 良い処理構造はあまり言語に関係ない

41 of 66

コードを見慣れよう

モチベーション無しに

コードを見られるようになろう

42 of 66

コードを見慣れよう

呼吸するたびに意識を高めたりはしないよね

モチベーション無しに

コードを見られるようになろう

43 of 66

読むべきリポジトリの選びかた

  • 得意な言語で書かれているもの
  • リポジトリの説明が分かり易いもの
  • READMEに目的や価値、ビルド方法、基本的な使い方が書いてあるもの
  • 半年以内にコミットがあるもの
  • CIサービスを利用しており成功が維持されているもの

44 of 66

コードの読み始めかた

  • 依存ライブラリを確認する
    • 知らないものがあるなら、そちらを優先した方が直接的に役に立つことが多いため
  • ビルド環境を構築する
  • ユニットテストを実行する
  • エディタやIDEは慣れたものを用意する

45 of 66

コードの読み方

  • まずは全部のコードを何度も眺める
    • 速度重視で15~30分区切りで休憩する
  • 広く浅く様々な部分をボンヤリ覚えている状態を目指す
  • 外部との境界面となる場所から読む
    • アプリケーションから呼び出す部分
    • main関数
  • 仮説と検証を繰り返しながら読む

46 of 66

コードの読み方

  • 抽象度の高い部分を優先して理解する
  • 難しい部分はブックマークして後回し
  • コードが荒れているように感じるならgit blameするとよい
  • UMLのような絵を使うと分かり易くなる
  • デバッガを使うとより動作を正確に把握できる

47 of 66

コードは高速に読もう

コードを読む速度は改善できる

48 of 66

コードは高速に読もう

コードを読む速度は改善できる

よい技術者は毎日コードを読んでいる

49 of 66

コードを書く習慣、ありますか?

50 of 66

年を食うとコードを書けなくなる?

  • SI系企業では実装工程を行う技術者に対する評価は低め
  • 実装が仕事の中心でも年を重ねると周囲に対するリーダーシップを期待される
  • 規模のある組織においてミドルマネジメントは重要な仕事

51 of 66

一人砂場プロジェクトをやろう

自分で全部やる、誰にも任せない

52 of 66

一人砂場プロジェクトとは

  • 一人でコードを書き、学ぶ遊び
  • 仕事ではない
    • 計画しない
    • リスクをコントロールしない
    • やりたい時だけやる
    • 飽きたらやめる
  • 公開しなくてもいい
    • GitHubに公開しておくのがオススメ

53 of 66

一人砂場プロジェクトをする意味

  • しがらみの無い自由を味わうため
  • 自身の能力を客観的に評価するため
  • 自身の価値観を少しづつ変えるため
  • 価値の不明瞭なものを評価するため
    • オブジェクト指向
    • 関数型
    • 次は?

54 of 66

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

  • 良さそうなものを何でも使ってみる
    • 新しい言語
    • ライブラリ、フレームワーク
    • CIサービス
    • PaaS
  • 今使ってる道具を点検する
    • もっと便利なエディタは無いか?
    • もっと速いビルドツールは無いか?

55 of 66

何か作りたいけどネタがない?

  • 短縮URLを生成する画面の無いサーバ
    • POSTのボディにURLを付けてリクエストすると、レスポンスボディに短縮済のURLを返す
    • bit.lygoo.glをチープにしたようなやつ
  • ブログサーバ
    • Railsのチュートリアルをやりきると動く
  • ファイルアップローダ

56 of 66

小さい車輪を再発明しよう

  • 他の言語では盛り上がってるけど、得意な言語には無いものを再実装しよう
    • xUnit以来テスティングフレームワークはそうやって様々な言語に輸出されてきた
    • 最近は新しい言語がでるとRSpecモドキが大量発生する
    • SidenはJava8でExpressモドキを作った

57 of 66

毎日少しづつ書こう

  • 最初は毎日エディタを起動して新しいプラグイン入れるだけでいい
  • 数百行書ければしめたもの、愛着が湧く
  • 思うがままに便利な機能を足したり、便利なライブラリを追加しよう
  • 品質保証?プロセス?知らんよ
  • 毎日楽しくコードを書くほうが大事

58 of 66

もうダメだ、捨てよう

いつか訪れる最高の瞬間

59 of 66

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

  • 毎日書いていれば半年くらいで大きなコードベースになる
  • そもそもが思いつきで雑に色んな物を足していくのだからコードは荒れ易い
  • 同じ事を別な方法でゼロからやり直す
  • もっと上手く、もっと速くやり直せる
  • やり直せたら大きく成長できる

60 of 66

一人プロジェクトをやりなおそう

始まりから終わりまで、そしてやりなおす

61 of 66

一人プロジェクトをやりなおそう

よい技術者は同じ仕様で何度もコードを書いている

始まりから終わりまで、そしてやりなおす

62 of 66

よい技術者になるには?

63 of 66

仕様書とコードを大量に

読んで、書いて、捨てる

64 of 66

無理せず

やっていきましょう

65 of 66

ご清聴ありがとうございました

66 of 66

CREDITS

Special thanks to all the people who made and released these awesome resources for free:

  • Presentation template by SlidesCarnival
  • Photographs by Unsplash