エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

【書評】プログラマが知るべき97のこと

プログラマが知るべき97のこと

プログラマが知るべき97のこと

目次

  1. 分別のある行動
  2. 関数型プログラミングを学ぶことの重要性
  3. ユーザが何をするかを観察する(あなたはユーザではない)
  4. コーディング規約を自動化する
  5. 美はシンプルさに宿る
  6. リファクタリングの際に注意すべきこと
  7. 共有は慎重に
  8. ボーイスカウト・ルール
  9. 他人よりまず自分を疑う
  10. ツールの選択は慎重に
  11. ドメインの言葉を使ったコード
  12. コードは設計である
  13. コードレイアウトの重要性
  14. コードレビュー
  15. コードの論理的検証
  16. コメントについてのコメント
  17. コードに書けないことのみをコメントにする
  18. 学び続ける姿勢
  19. 誰にとっての「利便性」か
  20. すばやくデプロイ、こまめにデプロイ
  21. 技術的例外とビジネス例外を明確に区別する
  22. 1万時間の訓練
  23. ドメイン特化言語
  24. 変更を恐れない
  25. 見られて恥ずかしいデータは使わないこと
  26. 言語だけでなく文化も学ぶ
  27. 死ぬはずのプログラムを無理に生かしておいてはいけない
  28. 「魔法」に頼りすぎてはいけない
  29. DRY原則
  30. そのコードに触れてはならない!
  31. 状態だけでなく「ふるまい」もカプセル化する
  32. 浮動小数点数は実数ではない
  33. オープンソースプロジェクトで夢を実現する
  34. API設計の黄金律
  35. 超人の神話
  36. ハードワークは報われない
  37. バグレポートの使い方
  38. 余分なコードは決して書かない
  39. 最初が肝心
  40. プロセス間通信とアプリケーションの応答時間の関係
  41. 無駄な警告を排除する
  42. コマンドラインツールを使う
  43. プログラミング言語は複数習得すべき
  44. IDEを知る
  45. 限界を知る
  46. すべきことは常に明確に
  47. 大量のデータはデータベースで
  48. いろいろな言葉を学ぶ
  49. 見積りとは何か
  50. Hello, Worldから始めよう
  51. プロジェクト自身にしゃべらせる
  52. 「その場しのぎ」が長生きしてしまう
  53. 正しい使い方を簡単に、誤った使い方を困難に
  54. 見えないものを見えるように
  55. 並行処理に有効なメッセージパッシング
  56. 未来へのメッセージ
  57. ポリモーフィズムの利用機会を見逃さない
  58. テスト担当者はプログラマの友人
  59. バイナリは常に1つ
  60. 真実を語るはコードのみ
  61. ビルドをおろそかにしない
  62. プリミティブ型よりドメイン固有の型を
  63. ユーザの操作ミスを防止する
  64. プロのプログラマとは?
  65. バージョン管理システムを有効に使う
  66. いったんコンピュータから離れてみる
  67. コードを読む
  68. 「人間」を知る
  69. 車輪の再発明の効用
  70. シングルトンパターンの誘惑に負けない
  71. パフォーマンスへの道は地雷コードで敷き詰められている
  72. シンプルさは捨てることによって得られる
  73. 単一責任原則
  74. 「イエス」から始める
  75. 面倒でも自動化できることは自動化する
  76. コード分析ツールを利用する
  77. 偶然の仕様ではなく本物の仕様のためのテストを書く
  78. テストは夜間と週末に
  79. テストのないソフトウェア開発はあり得ない
  80. 1人より2人
  81. エラーがエラーを相殺してしまう
  82. 他者への思いやりを意識したコーディング
  83. UNIXツールを友にする
  84. 正しいアルゴリズムとデータ構造を選ぶ
  85. 冗長なログは眠りを妨げる
  86. WETなシステムはボトルネックが見つかりにくい
  87. プログラマとテスターが協力してできること
  88. コードは生涯サポートするつもりで書く
  89. 関数の「サイズ」を小さくする
  90. コードを見る人のためにテストを書く
  91. 良いプログラマになるには
  92. 顧客の言葉はそのまま受け取らない
  93. エラーを無視するな
  94. リンカは魔法のプログラムではない
  95. ペアプログラミングと「フロー」
  96. テストは正確に、具体的に
  97. ステートに注目する
  98. 命を吹き込む魔法
  99. ロールプレイングゲーム
  100. ルーチンワークをフローのきっかけに
  101. プログラマが持つべき3つのスキル
  102. 快適な環境を追求する
  103. 見知らぬ人ともうまくやるには
  104. 不具合にテストを書いて立ち向かう
  105. 育ちのよいコード
  106. Noといえることの大事さ
  107. 名前重要

感想

まとめと感想。個人の主観が入ってるので、注意。

分別のある行動

技術的負債は、先送りしていると負債は大きくなる。
返済計画を立てないと、返済しきれなくなって破産する。

付け加えるなら、資産も持つべきかな?
作ったコードは、たぶん負債だらけってわけじゃないと思うんだよね。
よく作られているコードは、資産と捉えて、増やす・維持する努力もやるべきだと思う。

関数型プログラミングを学ぶことの重要性

関数型プログラミングオブジェクト指向は、相反する存在ではない。
注力しているものが違うだけ。

実際にやっていると分かるが、どうしても状態を持たなければいけないところが発生する。
使い分けができるようになっておく必要がある。
前までは、オブジェクト指向素晴らしいと言ってきて、今度は、関数型プログラミングが素晴らしいって世の流れは、かなり違和感を覚える。
結局は、使いどころを見抜く力が必要なのだよ。

ユーザが何をするかを観察する(あなたはユーザではない)

考え方や味方は、ユーザと開発者では違う。
同じだと思ってはいけない。
解決するには、観察するしかない。

コーディング規約を自動化する

規約が存在することで、コードの私物化を防止できる。
なるべく強制的・自動的に守らせる。
規約を作っても、忠実に守ってくれるとは限らない。

規約は、プロジェクトと一心同体。
プロジェクトで求められるものが変われば、規約も変わる。
見直すタイミングを考える必要がある。

だいたい規約作って終了の現場は多い。
維持するために覚えるのは、ものすごく辛い。
自社サービス作るのに100%自社社員ならいいが、協力会社が入っているなら、規約のチェックは自動化しないとやってらんない。

美はシンプルさに宿る

シンプルなコードは、責務を最小化し、関連をすくなくし、テストしやすく、長期保守ができるようになる。

リファクタリングの際に注意すべきこと

リファクタリングは、必要なときに必ずする。

むやみやたらにやっても、確認で破綻する。
ご利用は計画的に!

リファクタする際の注意点

  • 既存コードの良い点・悪い点を見定めてから実姉
  • ゼロから作り直したい衝動を抑える
  • 大幅な変更より、小さな変更をたくさんする
  • デグレ確認必須
  • エゴを入れない
  • 新技術を使いたい衝動を抑える
  • 人間はミスすることを忘れない

共有は慎重に

共有=再利用
再利用させたい場合、目的や役割を考えてライブラリ化する。

共有したら情報漏えいのリスクも上がるしな!

ボーイスカウト・ルール

来たときよりも美しくする。
少しづつ改善する努力が、ソフトウェア開発には必要。
ただし、不要な修正は禁止しなければならない。

他人よりまず自分を疑う

コンパイラ・OSは、いろんな人がチェックしているので、バグは少ない。
他者に原因がある前提で動くより、自分が作ったものにバグがある前提で探した方が、効率的。

これは、あるあるネタ
だいたい他人を疑う前に、自分に否がないように論理武装してから挑まないとダメ!
自分に否がないと分かったら、他者を徹底的に痛めつけられない!
俺って結構クズ人間?

ツールの選択は慎重に

ツールに依存する=ベンダロックイン状態になる。
ツールは必要最低限にしておき、分離可能なように設計する。

たまに、ツールのために設計している現場があるからな。。。
そう言った現場は、だいたい汎用性がなくて、顧客要求に対応できず、協力会社の教育にも時間がかかり、炎上する。

ドメインの言葉を使ったコード

データ構造は、時間の経過とともに複雑化していく。
ビジネスに合わせてコードを書かないと、変化したコードの内容は、すぐに分からなくなる。
ドメインとともに、コードも成長させる。

たまにあるのが、データ構造が永久に変更無いと思っているやつ。
そういうやつに限って、自動生成がどうこう言い出して、ドメインが成長してもコードが成長しないような環境を作り出す。
なんか、愚痴ばっかだな、俺。

コードは設計である

建築コストのゼロ化→早く設計したもの勝ちになる。
早く設計したはいいが、その妥当性は、素人に判断できない。
最終的な品質は、低下する。

ソフトウェア開発にも同じことが起きる。
優れた設計には、人間が必要。
その妥当性の確認作業は、人間にしかできない。

この考えはAIにも当てはまる気がする。
AIでなんでもできるようになったって、それが妥当かどうかは、素人には分からない。
やっぱり、専門家が必要なんだと思う。
これからは、企業が優秀なエンジニアを持ってないと、AI時代が来たときに、出遅れる気がしないでもない。
作戦立案はAIにまかせて、その妥当性を吟味して意思決定するのが人間になりそう。
やっぱり、仕事へらないじゃん!
AIだからこそ、最終的な意思決定が重要になりそうだ。

コードレイアウトの重要性

コーディング<リーディング
リーディングを効率化しないと、時間がかかる。
既存コードを読んで、発想を真似るのはよくあるからね。(コピペはダメ!絶対!)
リーディングを効率化するためにも、見ただけで何をしているか分かる状態にしておく。

コードレビュー

コードレビューは、質を上げ、欠陥を減らす。
チーム知識の共有と規約の確率も含まれている。
やる際は、建設的であるべき。
辛辣な批判は避ける。
そうしないと、レビューがボトルネックになり、プロセスが瓦解することがある。

続けるには、レビューを楽しくする事が大事。

知的な話術で場を和ませるスキルが必要なのだ。
そのためにも、漫画やアニメ、映画に小説をよんで、面白い語録を身につけることは、仕事に役立つ気がしてきた。

コードの論理的検証

コードが正しいことを証明する=事前条件・事後条件・不変条件を決めること。
ただし、難しい。

注意点

  • gotoは避ける。
  • 変更可能な変数は避け、スコープは狭くする。
  • インデントを使って読みやすくする。
  • 名前で機能が分かるようにする
  • パラメータは減らす
  • インタフェースの適用箇所は減らす。

コメントについてのコメント

コメントとは、有用なもの。
どういう目的で書いたのかを残す。
多く入れるのは、かえって分かりづらくする。

1行1コメントが許されるのは、教育目的まで。
たまに書かなすぎなやつもいる。
コードは万能ではないことを理解しておくことも必要。

コードに書けないことのみをコメントにする

書かなくても良いものを見極めることが重要。
コードに付加価値を加えないコメントは、ノイズでしかない。
書いてしまうのは、構造や宣言方法に欠陥がある。
なるべくコードに語らせて、コードに書けないことをコメント化する。

学び続ける姿勢

どこでも必要。
会社は当てにしないほうがいい。
自らの力で実施することが大切。

誰にとっての「利便性」か

作る側の利便性<使う側の利便性
APIを作る時は、使うほうが自由にできることを増やす。

開発者の利便性は糞。
最終的に使われないと意味がない。

すばやくデプロイ、こまめにデプロイ

デプロイ作業後に顧客が利用するので、デプロイがスムーズにいかないのは、不信感を持たれる。
なるべく早く使えるようにして、不確定要素を減らす。

精神衛生的にもいい!

技術的例外とビジネス例外を明確に区別する

区別しないと、問題の切り分けが難しくなる。
なるべく切り分けできるように設計して、障害対応の初動を早くする。

たまに、例外がビジネス的な例外なのか分からない時がある。
例外禁止している現場は、だいたいビジネス例外とシステム例外を見分けられていない。

1万時間の訓練

1万時間経過したら、急にエキスパートになれるわけではない。
やっていく中で、徐々に専門知識がつく。
だけど訓練は、厳しくする必要がある。
楽なものでは意味ない。

温室育ちの花が、アスファルトで生きているハズがない。
才能あれど、常に厳しい環境に身を押して無いと、生存競争に勝てない。
続けることも大切だが、それと同じくらいに、厳しい環境に身を置いて、厳しい訓練をすることも大事。
だから、山ごもりって文化があるのだろう?

ドメイン特化言語

どの分野にも専門用語はある。
一度作れば、技術的な詳細はブラックボックス化し、一般の人にも使えるようになる。

警察とかは、ドメイン用語の宝庫。
デカとか、普通伝わらんやろ。

変更を恐れない

変更を恐れるのは、病気。
システムの健康を保つためにも、変更を恐れずに日々リファクタリングすることは、必須。
健康と同じ。

見られて恥ずかしいデータは使わないこと

恥ずかしいデータの露呈は、いつ発生するか分からない。
常に公になったときのことを考えて作業する。

プリキュア名をテストデータにしたら、いつかバレるから、慎重に!
これは、俺のことじゃないからね!

言語だけでなく文化も学ぶ

複数の言語を学ぶことは、新しい発想を得たり、デザインパターンの理解が深まる。
同じ問題に対して、違った解決方法を身につけることが大事。

多様性は大事!
自分が偏ってると思ったら、反対の言語を学んで見る。

死ぬはずのプログラムを無理に生かしておいてはいけない

例外を無理矢理処理するのは、後で首を締める。
適切な場所で、適切な処理をする。

例外をそもそも導入しないのは、糞野郎。

「魔法」に頼りすぎてはいけない

プログラミングしただけで、プログラミングは語れない。
素人に見えないだけで、データ構造・概念化など、重要な部分が隠れている。
関与してない箇所は、簡単に見えてしまう。
どんなことであれ、仕事している人は尊重する。
問題が起こると、簡単に見えていたことが、実はそうでなかったと気付く。
対応する必要があるので、簡単になったからと言って、対策を怠ってはいけない。

経営、カールと一緒。
なくなってから欲しても、もう手に入らないからね!

DRY原則

重複は無駄である。
作業の重複は、自動化で防ぐ。
ロジックの重複は、抽象化で防ぐ。

そのコードに触れてはならない!

システムを治すからといって、本番に直接修正してはいけない。
決められたプロセスを、権限を持った人がやらないと事故るだけ。

決められたプロセスを無視して実行すると、プロセス通りにやっていれば問題なかった問題を踏み抜いて、余計に時間がかかることが多い。
プロセスの見直しは定期的にするべきだが、急いでいるときほど、いつもやっている手順を重視する。

状態だけでなく「ふるまい」もカプセル化する

振る舞いがカプセル化できてないと、呼び出し元でif-elseが多くなる。
カプセル化することで、保守性が格段に上がる。

浮動小数点数は実数ではない

精度には限度がある。
金融で使うべきではない。

オープンソースプロジェクトで夢を実現する

OSSの参加

  • 希望するものが作れる
  • 個人の時間を削る必要がある
  • 他人の問題解決手法を学べる

貢献方法

  • ドキュメントを書く
  • テストコードを書く
  • コーディング

API設計の黄金律

APIは、公開したら修正するのは難しい。
APIを作る時は、利用する側のテストコードも書く。
テストの難しさを設計課題として捉える。

超人の神話

超人はいない。
ただ、問題解決能力が高いだけ。
超人神話を作るより、エキスパートを育てることに注力する。

超人作るのはいいけど、その人が居なくなるリスクがでかくなるから、企業は超人を作らないほうがいい。
均一なスキル保持者を量産すべき。

ハードワークは報われない

仕事は、短い時間で終わらせる。
長時間労働は、プロ意識の欠如。
効率化と日々の反省を忘れない。

バグレポートの使い方

バグレポートには、感情を入れない。
情報の入れ過ぎは、重複が増えてわかりづらくなる。
情報を増やしたい場合、入力欄を増やすことで対応できないか、一考する。

余分なコードは決して書かない

ない方がいいが、作ってしまう。
作る際に、本当に必要なのかよく考える。

最初が肝心

最初の導入で躓く=もう使われないと思ったほうが良い。

意外と人間って、成功体験がないとすぐ諦めるんだぜ!

プロセス間通信とアプリケーションの応答時間の関係

応答が遅い場合、データ構造・アルゴリズムよりも、プロセス間の通信量に注目する。

無駄な警告を排除する

無意味な警告は、邪魔なだけでなく、必要な警告を隠す。

syslog見てみろ!
いらねぇログばっか出していると、障害解析が辛いんだよ!クソが!

コマンドラインツールを使う

IDEは、裏で何かをしている。
その何かをしることで、もっと効率的にできる。

プログラミング言語は複数習得すべき

1つしか習得してないと、問題の解法が限られる。
未知の問題に対応できないリスクがある。

IDEを知る

簡単に使えるけど、上達はしない。

限界を知る

リソースには限界がある。
どこが限界なのかをしることで、最適なやり方を知ることができる。

限界を決めるなとかいうやつがいるけど、許容限界を決めて、限界に達したら他の効率的なやり方を探したほうが、有意義だと思いますけどね。
経営もそうしているはずだろう?

すべきことは常に明確に

目標がないと、時間を浪費しがち。
やることに期限をきめるだけでも、効率的になる。

大量のデータはデータベースで

RDBMSで管理することで、大きなメリット享受できる。

いろいろな言葉を学ぶ

人との会話は大事。
チームで働くので、職人仕事より、人と協力して作業する。

見積りとは何か

見積もりとは、何かの価値・量・程度についての概算。
ある程度以上の精度は期待できない。

見積もり・目標・約束の認識が違うと炎上しやすい。

Hello, Worldから始めよう

物事をシンプルに考える。

ごめん、、、これ以上のことは読み取れなかったよ、パトラッシュ。。。

プロジェクト自身にしゃべらせる

CIを適用して、プロジェクトを自動監視する。

プロジェクトの状況を教えてくれるAIがあるといいかも。
個人的には、有名声優の声で、異常を教えてもらいたい!

「その場しのぎ」が長生きしてしまう

暫定対応は、意図せず発生してしまうが、放置しておくと後で修正が難しくなる。
修正するには、修正を暫定に加えず、新規で正当なものを作る。

正しい使い方を簡単に、誤った使い方を困難に

使いやすいインタフェースは、正しい使い方が自然とできる。
開発者の利便でUIを決めないようにする。

見えないものを見えるように

目に見えるものについては考えるが、見えないものは放置しがち。
ソフトウェア開発は、常に目に見える証拠を維持してないと、状況は把握できない。

並行処理に有効なメッセージパッシング

問題は、だいたい共有メモリ
解決するには、メッセージ交換でできないか検討してみる。

未来へのメッセージ

コードは時間が立つとわかりにくくなる。
未来の自分へのメッセージだと思ってコードを書く。

分かるぜ。3時間前の自分が回たコードを、自分で貶していると知った時の衝撃は、計り知れなかった。。。

ポリモーフィズムの利用機会を見逃さない

if-elseはバグの混入率が高い。
ポリモフィズムが適用できないか検討する。

テスト担当者はプログラマの友人

QA・QCからの指摘は、恥だと思ってはいけない。
顧客の目に触れる前に見つかったことを喜ぶべき。

顧客の目に触れてからだと、仕事もらえなくなるからな!

バイナリは常に1つ

コナン君に影響されたのか?
環境も含めてバージョン管理するようにしないと、ビルドに振り回される。

真実を語るはコードのみ

コメントを書かないとわかりにくいコードは、コードを改めるべき。
実行されるのは、コードであってコメントではない。
わかりやすくするために、なるべく依存関係は減らす。

ビルドをおろそかにしない

理解が深まれば、ビルド労力・時間の減少になる。

プリミティブ型よりドメイン固有の型を

強い型付けは、問題の発声を防げることが多い。
ビジネスロジック固有のデータ構造を定義すれば、問題の防止が容易になる。

ユーザの操作ミスを防止する

ミスする側が悪いで話を終わらせるのは簡単。
ミスがでるのは、ユーザとソフトウェアの間に誤解が生じている。
ユーザがどう考えて解釈しているか、知ることが大切。

プロのプログラマとは?

やったことへの責任感の強さ。
最善の努力を尽くす姿勢を持つ。

キャリアに責任を持つ

自分の価値は自分で高める

コードに責任を持つ

バグの原因を特定するまで安易な対応はしない。

チームプレイヤーであることの自覚

チーム全体のアウトプットに責任を持つ。
チームのミスはカバーする。

バージョン管理システムを有効に使う

プロジェクトの構成要素は、すべてバージョン管理すべき。
バージョン管理することで、意図しない自己を防げる。

いったんコンピュータから離れてみる

論理的に考えて行き詰まるのは、視点を変える必要がある。
一旦休憩を入れてみる。

コードを読む

コードを書くよりも、リーディングの方が力がつく。
読む場合、何が読みやすいのか考えながら読む。

「人間」を知る

ユーザに分類された要件を求めるのは、無理がある。
理解した上で接しないと、苦労する。

車輪の再発明の効用

車輪の再発明はコストがかかる。
しかし、知識をつけるには、価値がある。

シングルトンパターンの誘惑に負けない

シングルトンの問題

  • 暗黙的依存ができる
  • 永続化される
  • インスタンス削除のタイミングがない

シングルトンを使う際は、上記問題を考慮する必要がある。

パフォーマンスへの道は地雷コードで敷き詰められている

パフォーマンスは、複雑度と依存性の戦い。
事前にメトリクスを計測しておく必要がある。

シンプルさは捨てることによって得られる

リビジョンが上がっても、よくなることは少ない。
既存のコードの質が一定以下なら、捨てる覚悟を持つ。
捨ててシンプル化することを考える。

単一責任原則

同一の変更理由によって変わるものは、一箇所に集める。

「イエス」から始める

顧客要望は、肯定的な立場から受け止める。
そして、理由を追求する。
理由が明確になることで、ストーリーが生まれ、人を動かしやすくなる。

面倒でも自動化できることは自動化する

自動化できるものは、できるだけ自動化する。

コード分析ツールを利用する

品質向上は、テストだけではない。
コード解析を使って、テストで見つけにくいものを発見する。

偶然の仕様ではなく本物の仕様のためのテストを書く

細部に至るまでの厳密なテストは、テストコードと強結合になる。
細部に至るテストは、実装上そうなっただけで、偶然の私用に過ぎないものをテストしている可能性が高い。
やるなら、ブラックボックステストで、本来の要求をテストする。

テストは夜間と週末に

テストは、夜間と週末に実施して、リソースを効率的に使う。

テストのないソフトウェア開発はあり得ない

建築と違って、作った後にテストできる。
テストは、ソフトウェア開発固有の作業で、重要度が高い。
開発者は、責任を持ってテストを行う。

1人より2人

システム開発は、一人ではできない。
ペアプログラミングで得られる効果は大きい。
確信が持てないなら、実施してみる。

エラーがエラーを相殺してしまう

問題が相互作用で発生することがある。
問題が発生したら、曇りなき眼で、思い込みを捨てて、冷静に対応する。

他者への思いやりを意識したコーディング

ただ質の高いコードを書くだけではダメ。
他人へ影響を与えるコードを書く。

UNIXツールを友にする

拡張性が高く、効率的に使える。

正しいアルゴリズムとデータ構造を選ぶ

適切なアルゴリズムを選ぶことは、適切なデータ構造を選ぶこともセットでついてくる。
アルゴリズムを使えるシーンについて、理解を深めておかないと、失敗することがある。

冗長なログは眠りを妨げる

ログに不要なものがあると、問題が発生しているかも分からない。
必要最低限のものだけ出す。

WETなシステムはボトルネックが見つかりにくい

DRY原則に反しているもの=WETシステム
保守性だけでなく、ボトルネックの発見も困難化するので、DRY原則は守る。

プログラマとテスターが協力してできること

設計が悪いと、テスト項目が多くなり、テスターの負荷が増える。
設計を改善するためにも、テスト項目を理解しておく必要がある。
テスターとプログラマーのチームワークを良くすることが、成功の鍵。

コードは生涯サポートするつもりで書く

コードを適当に書いてはいけない。
生涯サポートするくらいの気持ちで真剣に書く。

関数の「サイズ」を小さくする

問題領域はなるべく狭くする。
扱いやすくなるだけではなく、障害調査もしやすい。

コードを見る人のためにテストを書く

テストコードをただ書いているだけではダメ。
テスト対象を補完するようなテストコードを書く。

良いプログラマになるには

一朝一夕ではなれない。
努力を続けた人だけがなれる。
善意だけではなれない。
善意が役立っているか、確認して今後に活かす。

顧客の言葉はそのまま受け取らない

言っていることが正しいとは限らない。
意図を読み取ることが大切。

エラーを無視するな

エラーを放置しない。
放置すると、コードベースが不安定になり、バグを生みやすくなる。

リンカは魔法のプログラムではない

難しいことはしてないが、簡単なことが積み重なると、難問ができあがる。

ペアプログラミングと「フロー」

相手の方が格上:気後れせずに接する。
相手の方が格下:忍耐強く接する。
ペアプログラミングのメリットは、早期問題の抽出と新人育成。

テストは正確に、具体的に

テストは正確に書くだけでは不十分。
わかりやすくテストの目的が分かるようにする。

ステートに注目する

状態が処理に与える影響は大きい。
だから、状態には注目しておく。

命を吹き込む魔法

コードネームをつけると、当事者意識がまして、震源に取り組むようになる。

ロールプレイングゲーム

理想のプログラマを演じる。
仕事と割り切れば、できること。

ルーチンワークをフローのきっかけに

ルーチンワークは、無駄になっていることがある。
自動化して、他のことに集中する。

プログラマが持つべき3つのスキル

スキルをあげるには、OSS開発か、師となるべきエンジニアを見つけるしかない。

快適な環境を追求する

環境を改善することで得られる時間は、投資した時間より多くの物が返ってくる。
コーディングで食っていくなら、環境改善は必須。

見知らぬ人ともうまくやるには

できないことは、できないまま。
できることは、できるようにしておく。
無駄な論争をせずに済む。

例えばユーザ情報の更新。
QAテストで使うユーザのIDとパスワードを全員知っているせいで、意図せず変えてしまってテストで混乱するのは、避けないといけない。
あと、環境もね。知らない人から、ディスられるから、やれないことはやれないようにして置くのは、超絶大事!
俺がディスられたわけじゃないいだからね!

不具合にテストを書いて立ち向かう

不具合修正は、不具合再現コードを書いてから行う。
遠回りのようだが、一番合理的。

育ちのよいコード

成長するに連れて、まとまりの悪さがでる。
リファクタリングと機能追加のパッチを使い分けるようにして、まとまりの悪さを回避する。

Noといえることの大事さ

ソフトウェアの公開は、機能追加要望が増える。
そうすると、いらない機能が増えて使いにくくなってしまう。
だから、Noと言えることが大切

名前重要

設計の基本は、ネーミング。
ネーミングにはこだわる。

読了感想

本当はもっと早く読むつもりだったけど、結構先延ばしになっていた。
読書スピードが落ちているってのもあるかも知れない。

Visual Studio CodeのターミナルをGit-bashに変更する方法

きっかけ

powershellとか、cmdだと、業務で覚えたLinuxの知識が活かせない。
別ウィンドウでgit-bash起動すればとも思うが、使うツールは少ないほうがいい。
職場で設定したが、やり方忘れやすいので、メモ。

設定方法

ファイル -> 基本設定 -> 設定から、setting.jsonを開く。
もしくは、Ctrl+Commaでショートカットで起動してもいい。

起動したら、terminal.integrated.shell.windowsの内容を変更する。

Git-bashを設定したい場合、Git\\bin\\bash.exeを指定する。
※指定するのはフルパス。

ここで注意したいのは、bin配下のbash.exeを指定すること。

git-bash.exeだと、VisualStudioCodeとは別ウィンドウで、git-bashのターミナルが起動するので、注意!
予期した動きと変わるので、かなり困惑した。

参考サイト

qiita.com

Typescriptと依存関係

起きた事象

クラスが相互参照になって、実行時にエラーになった。
エラーの内容が、相互参照によるエラーだとわかりにくくて、結構悩んだ。
※俺が起こしたわけではない。むしろ巻き込まれたほう。

どうやって

どうやって検出すればいいんだ。。。
型付け言語なのに、相互参照が解決できないのは痛いな。

クラスが増えれば、発生する可能性は高いし、検知する方法を持っておかないとキツイ。
どうにかして回避したいが、なんかいい方法ないのかな?

いや、まぁクラス設計ちゃんとすれば済むんだろうけど、正直難しいだろ。。。

httpとhttps

なんなのこれ。
なんで一文字しか違わんの?

定義でURLを持っているんだが、httpとhttpsを書き間違えて、かなり迷った。。。
これで半日使ってたと思うと、アホらしくてしょうがない。

マイクロサービスってバズワードに釣られてはいけない

きっかけ

下記の記事を見て、自分なりにまとめとメモ。
なんというか、自分も釣られる側な気がして、考えが足りてなかったなと反省の念も込めてる。

マイクロサービスはもう十分 | プロダクト・サービス | POSTD

マイクロサービス

下記サイトから引用

個別に開発された小さなサービスを組み合わせて、一つのサービスを提供するというものです。

マイクロサービスとは何か? デジタル変革の時代を生き残るための、テクノロジー入門 - Customer Success

マイクロサービスへの準備

マイクロサービスが全知全能の銀の弾丸ではない。
正と負、どちらの効果も持っており、状況次第では負の側面が多く出ることもある。

サイト内で言っていた前提条件

  1. ラピッドプロビジョニング
  2. ベーシックモニタリング
  3. ラピッドデプロイメント

上記条件をすべて満たしていたとしても、本当に負の側面がないか考慮する必要がある。
処理を分散することの問題は、マイクロサービスにも存在しうるので、目をそむけてはいけない。

ラピッドプロビジョニング

スケールアップ・ダウンに耐えられる人材がいるかどうか。
それも一人だけでなく、複数人が各チームに散らばっていること。

ベーシックモニタリング

パフォーマンス計測手法が確立しているか?
確立してない場合、マイクロサービスで分断することによって、どこの何が原因なのか分からなくなるだけ。

ラピッドデプロイメント

迅速なデプロイ方法が確率されているか?
すべて手動の場合、マイクロサービスで分断されたサービスをすべて手作業でした場合、事故る確率は高い。

記事を読んでの感想

存在している問題点から目を背けていたかもしれない。
まだ、本格的にマイクロサービスを適用している現場に言ったことがないから、夢見てたかもしれないな。
結構、バズワードって魅力的に見えるから、飛びつきたくはなるけど、用心しなければいけない。
新手の詐欺かもしれない心持ちで、検討する必要があるなと思う。

Java9 Reactive Streams 試し実装

きっかけ

Java9のリリースが迫っているのと、ITproの記事見て試したくなったから。
あとは、Typescriptで非同期の処理を書くことが非常に多いので、Javaでもやりたくなった。

Reactive Streams

非同期処理を実現するための仕様。
非同期処理を採用しているライブラリとして、RxJava/Akka Streamsが有名。

データの流れに着目したプログラミングスタイルで、Publish-Subscribeモデルの実装ができる。
※Publish/Subscribeは、Observerパターンの発展系みたいなもんだという認識でいる。

非同期にしなければいけないってものでもないが、データを作る側と使う側が疎結合になるので、非同期処理に移行しやすくなる。

java.util.stream.Streamインタフェースとは別ものってことには、要注意。

Publish-Subscribeモデルの処理の流れ

http://itpro.nikkeibp.co.jp/atcl/column/15/120700278/061900041/sequence01.png

このフローは、RxJavaも同じ。
※Akka Streamsは知らない。。。

そして、定義されているインタフェースは、下記の通り。

  • Flow.Publisher
  • Flow.Subscriber
  • Flow.Subscription
  • Flow.Processor

実装

とりあえずITproの奴を真似して作った。

import java.util.concurrent.Flow.Subscriber;
import java.util.concurrent.Flow.Subscription;

public class SampleSubscriber<T> implements Subscriber<T> {

    private Subscription subscription;
    private final String name;

    public SampleSubscriber(String name) {
        this.name = name;
    }

    @Override
    public void onComplete() {
        System.out.println(name + ": " + Thread.currentThread().getName() + ": Complete.");
    }

    @Override
    public void onError(Throwable arg0) {
    }

    @Override
    public void onNext(T item) {
        // 配布されたデータを出力する
        System.out.println(name + ": " + Thread.currentThread().getName() + ": " + item);

        // データの要求
        subscription.request(1);
    }

    @Override
    public void onSubscribe(Subscription subscription) {
        this.subscription = subscription;

        subscription.request(1);
    }

}
import java.util.concurrent.Flow.Subscriber;
import java.util.concurrent.SubmissionPublisher;
import java.util.stream.IntStream;

public class Sample {

    public static void main(String[] args) {
        SubmissionPublisher<Integer> publisher = new SubmissionPublisher<>();

        // Subscriberの生成と登録
        Subscriber<Integer> subscriber1 = new SampleSubscriber<>("Sub1");
        publisher.subscribe(subscriber1);

        Subscriber<Integer> subscriber2 = new SampleSubscriber<>("Sub2");
        publisher.subscribe(subscriber2);

        Subscriber<Integer> subscriber3 = new SampleSubscriber<>("Sub3");
        publisher.subscribe(subscriber3);

        // データの登録
        IntStream.range(0, 5).forEach(publisher::submit);

        // 非同期で処理が終わってしまうので、実行終了するまで一時的に待つ。
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        publisher.close();
    }

}

実行結果

Sub2: ForkJoinPool.commonPool-worker-1: 0
Sub2: ForkJoinPool.commonPool-worker-1: 1
Sub2: ForkJoinPool.commonPool-worker-1: 2
Sub2: ForkJoinPool.commonPool-worker-1: 3
Sub2: ForkJoinPool.commonPool-worker-1: 4
Sub3: ForkJoinPool.commonPool-worker-2: 0
Sub3: ForkJoinPool.commonPool-worker-2: 1
Sub3: ForkJoinPool.commonPool-worker-2: 2
Sub3: ForkJoinPool.commonPool-worker-2: 3
Sub3: ForkJoinPool.commonPool-worker-2: 4
Sub1: ForkJoinPool.commonPool-worker-3: 0
Sub1: ForkJoinPool.commonPool-worker-3: 1
Sub1: ForkJoinPool.commonPool-worker-3: 2
Sub1: ForkJoinPool.commonPool-worker-3: 3
Sub1: ForkJoinPool.commonPool-worker-3: 4
Sub2: ForkJoinPool.commonPool-worker-2: Complete.
Sub1: ForkJoinPool.commonPool-worker-3: Complete.
Sub3: ForkJoinPool.commonPool-worker-1: Complete.

最初、全部表示されへん!なんでや!って思ったら、非同期処理だから終わってるから表示されないやん!って事に気づいた。
Thread.sleep入れてるのは、そのため。
なんか全部見れる上手い手ってあるものかが気になる。

感想

Filterまで紹介されていたけど、今回は基本的な部分のタッチのみ。
非同期は覚えておいて損はないと思う。
そのうち、ビルドシステムもJavaで書くようになるだろうね。
Gradleは、ピュアJavaじゃないけど、非同期での実装がやりやすくなると、効率的なビルドが実現できるのではなかろうかと、ココロの中で思ってる。
※もしかしたら、知らないだけで、もう出来てる?

ForkJoinPoolって、たしかスレッド管理のやつだったよね。
あんまり使われてるイメージはないんだけど、裏の仕組みで必須なのかな?
どっかでキャッチアップしないとダメだな。

参考サイト

最新Java情報局 - Java SE 9の非同期処理ライブラリ、新概念の「Reactive Streams」を学ぶ:ITpro

タスク

ForkJoinについて理解しておく

【書評】Being Geek

Being Geek ―ギークであり続けるためのキャリア戦略

Being Geek ―ギークであり続けるためのキャリア戦略

目次

  • 第1部 キャリアの形成
  • 第2部 マネージメント
  • 第3部 日々の仕事に必要なスキル
  • 第4部 変化

読書日

2016.03.22

感想

いつもの内容まとめ。
個人の意見もメモってるので、書いてないことも書いてある。

第1部 キャリアの形成

キャリアのための行動

システム思考

ギークな人とは、世界を明確に区別できる信条を持っている人。
システム思考を絶対と考える。
通用しないときは、もろい物ができあがる。
特に人間は、システム思考に当てはまらない要素を多く含んでいる。

キャリアの青写真

キャリア > 目の前の仕事
今していること、これからすべきことを考えることは重要。
キャリアは、人事・上司の評価で充実するものではない。
ゴールを決めることで、道中にある決断をしやすくする。

大切なことは3つ

なぜか分からないが、「3」には力がある。
経済は、社会・共産・資本。勉強は、やる気・根気・暗記。
キャリアも同じく3つ。
方向性、成長、成果。

成長

成長するには、戦略が必要。
なんでも勉強するのは、時間がかかりすぎる。
また、成長しない人は、死でいるも同然である。

死んでいないかは、下記の内容をチェックする。

  • 失敗を経験したか?
  • 意義を唱える人がいるか?
  • 学びの内容を説明できるか?

失敗から学び、恐れないことが成長することになる。

成果

他人からの評価を高めるには、有言実行しかない。
ただ、有言実行は難しい。
頼まれたことを、相手が認めるまでやりきる必要がある。
または、できないことには「No」を言う。
安易な「Yes」は、信頼を得られないだけでなく、疲弊する。
いわゆるデスマーチが起こる。

Noを言う場合は、Noといったときの評価の低下と、Yesを言ってできなかったときの評価の低下を、天秤にかける。

複雑なことを簡単に

成長は、今日が昨日の繰り返しになってはいけない。
成長の判断基準は、知識。
以下に工夫して新しいものができるかが重要。
知識を使いこなせるかが、大事。
クイズ番組は、知識を使いこなせてない人の集まりな感じ。
なぜそんなに分かるのに、それを使えないのか考えると、大した人ではないのだと感じる。
教授もそういう人が多い印象。
論文述べるのはいいけど、現場適用はあなた達が考えてくださいって姿勢に、ものすごく苛立ちがある。

転職にあたって考えるべきこと

会社が嫌いという理由では、転職するのに十分な理由ではない。
怒りは、まともな物事を考えられなくなる。
冷静なときに、出した答えが転職かどうか、よく考える。

面接での答え方

質問の種類

  1. 背景を尋ねるもの
  2. 問題解決能力
  3. 自由回答

いづれにせよ、質問の意図を正しく理解することが大切。
とりあえずしゃべるは、悪手。
いい加減なことをいうより、「わかりません」の方がいい。

自分という人間を知らせる

質問の意図が分かって、答えが出ているなら、話すだけ。
その場合、簡潔に述べなければいけない。

面接官のボタン

面接とは、相手の情報を引き出す儀式。
面接官の情報も引き出す。

面接を担当するのは誰か

構造化された面接であれば、面接準備済みで、目的に沿って進む。
流れを読んで、質問の兆候を予測し、何を欲しているのか理解する。
構造化されてない面接の場合、面接官が準備不足。
面接が長くなりやすいが、その分、相手の情報を得られるので、攻略方法も発見しやすい。

第2部 マネージメント

企業文化

知るには、人と話すしかない。
文化は、人が作るもので、人を理解できなければ、文化を知ることはできない。
会社の文化は、行動の結果できていることが多い。
会社の核になっている可能性が高いので、常に注意している必要がある。
キャリアの形成にも影響してくる。
転職=キャリアではない。
転職する理由が、キャリアアップって言っている人は、だいたいおかしい。
形成するキャリアの方向性が合わなかったなら分かる。

第3部 日々の仕事に必要なスキル

ナードハンドブック

ナードとは、日本でいうところのオタクに近い。
何かに熱中して、物事に精通している人間。

マネジメントのシステム

マネージャとは、他人に干渉されながら仕事する人。
扱うものが、ビットから人に変わる。
やるべきことは、戦略的に考えて忘れること。
意図的に忘れても、問題が起きないような仕組みを作ることが仕事。

タスク管理は、大まかに把握しておく。
維持に手間をかけすぎない。

プレゼンテーション

ダメなプレゼン

  • スライドが多い。(MSの寺○さんかな?)
  • 文字が多い(海外エンジニアに多い。漢字があるって、こういうときに役立つ)
  • 1スライドに条法が多い

良いプレゼンをするには

絶え間ない練習と、機転の良さ。
失敗は、よくあること。
複数の目を持った人と話して、可能な限り一般論に近づける。
沈黙を意図的に入れて、内容に区切りを入れる。
沈黙を恐れていると、早口になって何も分からないってことがよくある。

第4部 変化

査定

  • 業績の良し悪しより、仕事内容を焦点にする
  • 議論であり交渉である
  • 予想外なら、一旦冷静に考える

評価よりも中身を重視する。
期待されていることと、それが実際にできているかを見る。

マネージャとコミュニケーション

マネージャになるパターン

  • 意志をもってなる
  • 小さな選択の結果、なってしまった
  • 命令でなった

すべてリスタート

エンジニアとして培ったスキルは、あまり通用しない。
今までと違うスキルが必要になる。
ミーティングの増加、抽象化のフィルタリング、変化球への対応。。。

空白

重要な人の退社

膨大な知識と技術を持っている人の場合、いれば安心だけど、実際はいなくても問題ない。
正答なのか判断しにくくなる。
不測の事態が、発生したときに問題になる。
それを乗り切れれば、後人が育ってくる。

権力・影響力が強い人の場合、文化が変わるだけ。

情報痛が辞めた場合、情報伝達が悪くなる。

全体感想

ギークになりたきゃ、戦略持って物事を学んでいくしかないってのが、読んだ感想。
何も考えずに仕事をこなしているだけでは、ギークにはなれないと感じた。
※この本だけから学んだわけではないが。。。

あと、ギークになろうと思ったら、組織にいると意外と障害があるのではないかとも思った。
それを避けて、楽してやりたいことをやるためにも、組織的な役割と問題の回避方法を知っておいて損はないだろうとも感じた。