2019年7月31日水曜日

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

いろいろいいことが書かれている。
章ごとに良い上司悪い上司を上げるなどして対比でわかりやすく解説してくれるので良い。
そんなにたくさんの章があるわけではないので章ごとにまとめていく。

マネジメントの基本

1on1は、多少は私生活に触れること、また、検討事項を定期的に議論すること。定期報告ならメールとかでもよいかも。
フィードバックを求めよう。また、アドバイスを求めるのはおだての効果もあるので聞くのは悪いことではない。
上司は、トレーニングや社内の人を紹介する必要がある。

メンタリング

傾聴するのは当たり前。明確に何を期待しているのか?何を成果としてだしてほしいのか?を伝達する。
人脈づくりの一環でもある。
アルファギークがメンターや上司になると最悪。アルファギークは、簡単にいうと自分が一番頭がよくて他はみんなおろかで、愚か者は公然と侮辱しても許されると思っている人。実際にいるので、人の管理などにはかかわらせないことが大事。
メンターをつけるのであれば、その目的とゴールを明確にしよう。

テックリード

テックリードは、会社によっても違うけどEMみたいな感じもある。ただ、人の管理はしない可能性もある。
テックリードに求められるものは、各メンバーとの1on1、各メンバーのキャリアアップや作業状況のsyncと改善を行う、各メンバーの能力開発に協力する、である。
テックリードは、システムアーキテクト、ビジネスアナリスト、プロジェクトマネージャーなどの役割も担うことがある。
プロジェクトの管理の簡単なコツは
・複数の工程に分割すること
・細部への引っ掛かりや道の要素にくじけない。
・プロジェクトは調整しながら進める
・変化に対応する
・プロジェクトの終盤では最後の詰めをする(premortemとか)
プロセスは、チームのニーズや目的を満たさなければならないという前提をきちんと理解する必要がある。
プロセス警察みたいなことはしてはならない。

人の管理

信頼関係や親近感を構築するために1on1は行おう。
新しい部下には1ヶ月、2ヶ月、3ヶ月の計画を建てさせる。
オンボーディングのドキュメントはきちんと整備して新人に更新してもらう。

1on1では、ドキュメントできちんと記録をとろう。
部下から、話し合いたいtopicを上げてもらう。
四半期ごとにフィードバックを行おう。
管理職どうしなら、経過報告もあり。

管理職を育てるのであれば、
・自分が出たほうがよいMTGを新人管理職と相談して決める。
・詳細を報告してもらったほうが良さそうなものを一緒に決めて進めていく。

実践としては
・成功とは何かを定義して、そのための数値の収集方法を提示してもらう。一緒に作る。
・システムから情報を収集する。
・プロジェクトの状況に合わせて収集すべき情報を修正していく
・基準を設ける。修正後に単体テストをどの程度加えるべきか。など。

情報は常にオープンにするほうが良い。

継続的なフィードバックが当たり前になるように継続し続ける。
フィードバックの内容自体は、
・1年全体に目を向ける。
・具体例を上げる
・長所も上げる
・改善点は簡潔に記述する
・決して驚かせてはいけない。定期的なフィードバックを行いながらいきなり悪い評価に驚くようなことはしてはいけない。

ローパフォーマーがいる場合は、改善計画を立てる。
何がダメで、どうなったら良いのか?いつまでそれを行うべきなのか?それを明確にして短い期間でのフィードっバックを行う。その際に、人事などにも入ってもらうのが良い。

チームの管理

ITスキルの維持には気を使おう。
人間関係の問題は早めに手を打とう。様子を見ても大抵は改善はしない。
過労には気を使う。ある程度期間が過ぎたら継続性を重視する
息抜きも大事なので飲み会や雑談は行うようにしよう。

チームが意思決定をできるように支援するには?
・データ重視にする
・顧客とは誰で何を求めているのかを明確にする
・将来のことも考えておく。
・意思決定の振り返りを行う。
・選択肢を提示して、意見や情報などのフィードバックを求める

問題行動のあるメンバーには早めに対処する。
何が問題かを明確にして、あまりに無礼であれば全体の前で批判することの重要になる。
その場合は、上司に相談するか人事に相談する必要があるだろう。

複数チームの管理

時間管理と優先順位付けはきちんとしなければいけない。
重要でない緊急の仕事に惑わされてはいけない。
頻繁な仕事は基本的に難しくても簡単でも移譲したほうが良い。
なぜならボトルネックになるから、難しい仕事はフォローしながらも任せることが重要。
頻繁でない複雑な仕事の代表は、勤務評価や人材募集計画だ。それは移譲していった方がよい。

なにか許可を求めてきた場合に、何回も同じことを言っていたら、ポリシーを決めるときが来たと思うべき。

チームの健全性は数値でみる。deploy頻度、インシデントの発生頻度、コードの生成量など。

チームのアイデンティティに、メンバーの得意なものを求めない。求めるとイングループが生まれる。

良いチームは
・リーダーがいなくなっても立ち直れる
・目標を駆動条件にする
・直属の部下ではなく、自分と同じレイヤーの人がチームであると認識する

複数管理者の管理

・スキップレベルミーティング
現状のプロジェクトの状態を現場から知ることと、うまく言っていない上司がいるのかを見極めることにもなる。
・責任を課する
どんな責任があるのか、何を明確に伝える必要があるのかを明確にする。上司が喜ぶことだけを言う人は実際にいるので、その人から情報が吸い上げられるようにしよう。

問題のある管理者がいた場合、その人の苦手な部分を手助けしてくれるような人をサポートでつけるのもありだ。例えば、プロジェクトマネージャーとか。


率直に言って、経営幹部の章と文化の構築については概念的な話が多いように思う。
だが、キャリアラダーをどのように作るのかなどは参考になるし、自分が管理職になってキャリアラダーに明確さがなくてみんなが困っているかもしれないと感じたら、参考にして作成するのが良い気がしている。

確証のチェック項目があるので、それをチェックするだけでも価値はありそう。

  • マネジメントの基本
    • できる上司のどのような行動や業績を素晴らしいとおもったか
    • 1on1が現状確認になっているなら他の手段があるか
    • 私生活の一大事を上司に話せるか
    • 上司からフィードバックがあるか。フィードバックを与えられているか
    • 目標設定で手助けをしてくれたか。手助けを出来たか。
  • メンタリング
    • インターンのメンターを希望しますか
    • 新人研修のアプローチはどのようなものですか
    • 新人のメンターを受けたいと上司に提案したいですか
    • そばらしいメンターがいたとしたら、どんなところが素晴らしかったですか
    • 成果が上がらなかったケースがあったら、それを今なら同会ゼインしますか
  • テックリード
    • テックリードがいるならば、Job descriptionは明確にありますか
    • プログラム以外の仕事もしなければ行けないし、コードは熟知していなければなりませんが、そのような人ですか
    • テックリードの期待値を上司とすりあわせているか
    • 最高のテックリードを見たことがあるなら、どんな行動でしたか
    • 不満があるテクリードがいるとしたら、どんな行動に不満でしたか
  • 人の管理
    • 定期的な1on1を計画していますか
    • 前回のキャリアアップについての内容をもう一度持ち出すことができる状態にしていますか
    • フィードバックを与えていますか
    • 最後にみんなの前で誰かを褒めたのはいつですか
    • 問題行動のあるメンバーにフィードバックをしたのは、問題行動からどのくらい時間が立ってからですか
    • 問題行動のフィードバックは、個人的にでしたか
    • 無駄な勤務評価が合ったとしたら、それをどうすれば改善できましたか
    • 一番有益だったフィードバックはなんですか
    • 昇進の手続きは公開されていますか
  • チームの管理
    • チーム管理者の責務とは
    • チーム管理のために他の人に譲った作業はなにか
    • チームがデプロイやサポートで日々直面している課題はなにか
    • 作業完了の報告頻度は
    • 最後にコードの変更を行ったのはいつか
    • 問題行動を起こすメンバーがいた場合の対処方法はみえているか
    • 仕事以外の話をメンバーで最後にしたのはいつか
    • 意思決定のルールはあるか
    • 管理者が下す意思決定に基準はあるか、それはどんなものか
    • プロジェクトの振り返りをして目標との差分をかくにんしたのはいつか
    • チームが担当しているプロジェクトをチームが持っているべき理由はあるか
    • プロジェクトで削ったことがあるならば、何で判断基準はなにか
  • 複数チームの管理
    • 最後にスケジュールの見直しをしたのはいつか
    • 過去3週間のスケジュールと今後3週間のスケジュールで、何を成し遂げて何を成し遂げたいか
    • 就業後にまでコードをかいているならばその理由は
    • 最後に移譲した仕事はなにか、複雑か単純か、いまはその作業は問題なくじっしされているか
    • 有望な管理者がいるなら、その人の昇進のためのコーチングはなにをしているか
    • プロジェクトのルーティーンはスムーズか、最後に大きい問題が発生したのはいつか、その時のチームの対処方法はなにか
    • プロジェクトの範囲を削る命令をしたのはいつで、なにか。スコープか品質か
    • 週末にメールしたか、それは返信が必要なものだったか
  • 複数管理者の管理
    • 自分に届く情報を受動的ではなく積極的に取るためにどのような手段をとっているか、それにどの程度時間をさいているか
    • 各管理者に期待していることはなにか、どんな責任をおっているか、その管理者の評価結果をどう評価しているか、彼らに必須の成功の条件とはなにか
    • 上の期待値と会社のJob descriptionに差分はあるか
    • 各管理者において研鑽が必要な項目はどこか、底に対するフィードバックの時間をとっているか
    • 自分がよく知らない分野の進捗や成功具合を聞いている頻度はどれくらいか
    • 自分がよく知らない分野で外せないポイントや成功の条件について担当管理者からレクチャーしてもらったか
    • スムーズなチームがあるならば、そのチームの他との違いは何か、どんな連絡方法をとっているのか
    • 管理者候補の面接では、哲学を聞いているか、メンバーと面談させているか、身元照会は行っているか
    • この四半期の目標はなにか、技術的な目標とどうすり合わせているか
  • 経営幹部
    • コーチングは社外のプロになる可能性が高い。自腹でもやる価値はある。
    • 社外に経営者仲間はいるか、ネットワークを持っているか
    • 尊敬する技術幹部がいるなら、どんなところか
    • 優先順位を変えた場合に、どうやって進めたか、その時の反応はどうだったか、いまならどうすすめるか
    • 会社が目指す方向を把握しているか、その時の技術的な戦略はなにか
    • 会社の近い将来の目標を達成するために各チームが当てるべき焦点はどこか、開発速度、人材採用、技術革新
    • 首脳陣は、自分の優先順位をどの程度理解しているか
    • チームに、自分がどの首脳陣と仲がよくて、どの首脳陣と仲が悪いか、わかるか聞いてみる。どう見えているか
    • 自分がロールモデルとなっているか
    • 業務で定期的に顔を合わせない部下に話しかけたのはいつか
    • シニアエンジニアに守って欲しい基本原則はなにか
  • 文化の構築
    • 会社や部署のポリシーはなにか、文書はあるか、最後の更新はいつか
    • 企業理念は、各チームでどのように体現されているか
    • キャリアラダーは定義されているか
    • キャリアラダーは、現在の反映か、将来の理想か
    • 重大なリスクはなにか、メンバーに不必要なプロセスを押し付けることなくリスクを避けられるか

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド   Camille Fournier https://www.amazon.co.jp/dp/4873118484/ref=cm_sw_r_tw_dp_U_x_YxsqDb7BTVJ09

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architectureについての解説で、いわゆる円形のあの概念などについても説明がある。

示唆に富む内容である。

まだ解説されていない文言が途中で出てきたりして、わかりにくい面もあるので、一度読み終わったらもう一度見返してみるのが良いと思う。


で、内容をざっくりまとめていく


リリースごとの人ごとのコード量は継続して計測したい。

優れたアーキテクチャとは、労働の最小化と生産性の最大化を実現する。

ソフトウェアの2つの価値、振る舞いと構造(アーキテクチャ)はどちらを優先すべきか?
どっちもなんだけど、往々にして振る舞いが優先される。

意図的に構造を優先する必要がある。
1.緊急かつ重要、2.緊急でないが重要、3.緊急だが重要でない、4.緊急でも重要でもない
3を最優先にする間違いを犯す
これをきちんと説明する必要がある
みんなが知っているわけではない。

アーキテクチャの関心事は、コンポーネントの分離、データ管理、機能、である。


プログラムの発展について

・構造化プログラミング
すべてのアルゴリズムが順接、反復、分岐の三つの組み合わせで記述できることに関連しており、gotoの批判などがある。

・オブジェクト指向とは、カプセル化、継承、ポリモーフィズムである。
ポリモーフィズムのパワーとは、デバイス非依存にできることだ。
そのI/Fが言語レベルで切れるところ。
それによって、ビジネスロジックからUIとIOを切り出して、独立なdeployまで可能にする。
プラグインアーキテクチャを可能にしている。

・関数型プログラミングは、値を可能な限り不変なものにして、可変なコンポーネントを意図的に作ってそこに集める。
また、ストレージと計算リソースが無限にあるならば全てを不変にできる。
初期値に対する変更の命令の全てを記録して計算を毎回全て行えばよいのだ。
codeのversion管理みたいに。


SOLIDの原則。

変更に強い、理解しやすい、コンポーネントの基盤として多くのソフトウェアで利用可のなソフトウェアを作るのを目的としている。


S
SRP Single Responsibility Principle 単一責任原則
モジュールを変更する理由が1つだけになるようにする。
組織が複数の役割を持たないようにするのと同じ。

O
OCP Open-Closed Principle
既存の変更よりも、新規追加による拡張を可能にしておくべき

L
LPS Liskov Substitution Principle リスコフの置換原則
ここのパーツを交換可能なように作らなければいけない

I
ISP Interface Segregation Principle インターフェイス分離の原則
使っていないものへの依存を回避すべきというもの

D
DIP Dependency Inversion Principle 依存関係逆転の法則
詳細側(UI,DB,NW)などが上位(アプリケーション)に依存すべきというもの。
上位は、詳細を知らない。ライブラリー開発をしていると割と一般的かも。

以下でそれぞれについて見ていく


・SRP Single Responsibility Principle 単一責任原則
CFOからの依頼で変更れた従業員情報がCOOの情報に影響を及ぼす感じ。
UML的なアクターが違えば、似ていてもコードは分離しておくべきということ。
集めたっくなったら、Facadeを利用してクラスを分割した後に集めれば良い。

・OCP Open-Closed Principle
拡張に対してOpenで変更にはClose
保護したいコンポーネント、影響を受けさせたくないコンポーネント
大抵の場合は、それはinteractor(usecase)になるが、それを他のモジュールが参照するようにすることで
UIやIOの変更が行われたとしてもビジネスには影響を与えたくない。

・LPS Liskov Substitution Principle リスコフの置換原則
派生クラスは、基本クラスの求めるものを全て満たさなければ行けない。
B extends A
なクラスがあったら、Aが満たすべきUnit testはBも満たすべきということ。

・ISP Interface Segregation Principle インターフェイス分離の原則
あるクラスに依存したとしても、使っていない公開APIが見えている状態が良くないので、Interfaceを必要な文だけ見られるようにして
それを見るようにしたほうが影響範囲が少なくなる。

・DIP Dependency Inversion Principle 依存関係逆転の法則
処理の流れとソースコード上の依存関係が逆になっているのをDIPとよぶ。
interactorからIOを呼び出すが、interactorで定義したi/fの実装がIOにあるような感じ
ビジネスのいちばん大事なところなどを安定化させて、変化しやすいところから切り出す効果がある。


コンポーネントについての説明。
SOLIDがレンガの組み方なら、コンポーネントは部屋の組み方。

コンポーネントとはDeployの単位。
単独でDeployできるシステム内の最小単位をさす

コンポーネントの凝集性とは、どのクラスをどのコンポーネントに入れるのか?の判断基準である。
原則は以下の3点
REP 再利用リリース等価の原則
CCP 閉鎖性共通の法則
CRP 全再利用の原則

・REP 再利用リリース等価の原則
まとめてリリース可能でなければならない。ライブラリがそれに当たる。
ライブラリならそれが当然であるが、コンポーネントもそうであるべき。
まとめようとすればするほど、同時にリリース可能だが、余計なクラスがコンポーネントに含まれることになる

・CCP 閉鎖性共通の法則
単一責務の原則をコンポーネント単位に言い直したもの。
同じタイミングで変更されやすいクラスは一つにまとめておけということ。
違うタイミングであるならば分けるべきということ。

・CRP 全再利用の原則
あるクラスに依存したときに、他の度のクラスにも依存しないということはまずない。
複数のクラスがセットで使われる事が多い。それらをまとめておくべき。
特定のコンポーネントに依存しているのであれば、そのコンポーネントに存在する全てのクラスに依存すべきである。
可能な限りそうすべき。

それぞれに反対の関係があるが、ちょっとすぐに理解するのは難しい。

REPだけを満たそうとすると、分けにくくなることによってCCP違反になり、依存しなくて良いものに依存してCRP違反になる
CCPだけを考えると、変更タイミングは違っても同時に使うもののリリースタイミングがずれてREP違反になるし、変更タイミングが近いというだけではCRP違反になる
CRPだけを考えると、コンポーネントがただ分割されるので、REP違反でCCP違反

非循環依存の原則(ADP)
循環参照は避けるべき、当たり前だが。
仮に作ってしまった場合は、DIPを利用して分割するか、循環のどこかに一つクラスを作って、そこで循環を断ち切る。

安定依存の原則(SDP)
安定しているモジュールに依存する方向で依存するようにする。
他から参照されているコンポーネントを参照するようにして、安定したコンポーネントは外部への参照を避けるようにすればよい。

安定度抽象度等価の原則(SAP)
安定したモジュールは抽象的であるべき。
いろいろなところから、参照されているなら、abstractにするかinterfaceにするかが良い。 

アーキテクチャとは
開発、運用、保守、デプロイ。
このサイクルをサポートするのがアーキテクチャ

開発
人数が増えてきたら、開発のためにアーキテクチャが必要でチームごとにコンポーネントを分けるべき

デプロイ
単一のアクションでデプロイしたい。デプロイの単位が分けれていれば可能なはず。

運用
サーバーを足すとかの運用がどうすればよいかが開発者がわかるようにすることが良いアーキテクチャ

保守
システムをコンポーネントに分割で切れいれば機能追加が可能なはず。
詳細の決定をできるだけI/Fの向こう側に押し込んで、決定を可能な限り遅らせる。

独立性
どうやって分割するのか?ということだ。
最初からマイクロサービスは明らかにやりすぎであるけど、将来的にそれができなくなったら困るわけで。
最初からマイクロサービスにも将来的にはできるようにソースコード単位で分割しておき
段々とデプロイー>サービスと分割の粒度を変えていくのが良い。
そのときに重要になってくるのが
ユースケースで分けるかレイヤーで分けるかである。

境界線
どこに境界線を置くのか?ということ。
具体的なDBとかUIとか外側の要素に境界を引いて、できるかだ気にははすことだ。
また、そのためにはコンポーネントをきちんと考えて分けておくことがそのために必要になる。

分割の戦略は
モノリス、デプロイ、スレッド、ローカルプロセス、サービス
などがある。

ビジネスルール
・Entityは、ビジネスデータとデータを操作するルールを記述した関数で構成される。
ビジネスそのもの。DBにもUIにも依存しない。特定企業のアプリにも依存しない。
・ユースケースは、アプリケーションそのもの。データのinput/outputなどを定義する。
ユースケースは、リクエストobjectとレスポンスobjectを必要とするかことがあるが、そのときにEntityを含めていはいけない。
Entityは最上位のclassで、リクエスト/レスポンスはより具体的なレイヤーだからだ。

アーキテクチャはやりたいことを記述しているか?
コードを見たら銀行のシステムとわかるか?
具体的なフレームワークが全面に出ていないことが大事。
ユースケースを見ればシステムが把握できるようにしておくのが良い

クリーンアーキテクチャーとは
・フレームワーク非依存
・テスト可能
・UI非依存
・データベース非依存
・外部エージェント非依存
レイヤーを作り依存を明確にすればよい。全ての実装のお手本になる気がする。

アーキテクチャーはテストしやすい部分としにくい部分で分離することが大事。

小さいプログラムでも分けることを想定する必要はある。現実に分けなかったとしても分けることを考えて常に監視し続けなければ行けない。

mainはクリーンアーキテクチャの最も外側に位置する。
Activityは外側なのである。

サービスで分けるということ。
サービスで分けたときに、ビジネスの中心が変わるときなどは各サービスの全てに影響がある。
例えば、通貨単位が増えたり法律の種類が増えるなどだ。
そうしたときには。全てに影響があるが、各Service内でEntityをそれぞれ作って対応すればdeployをずらすなの対応は可能。

テストAPIを作るのであればセキュリティissueにならないように決してdeployされないところに分けておくべきである。

データベース、Web、フレームワーク
これらは詳細だ。一番外にいるものだ。


Clean Architecture 達人に学ぶソフトウェアの構造と設計 Robert C.Martin
https://www.amazon.co.jp/dp/4048930656/ref=cm_sw_r_tw_dp_U_x_QOgqDbGETB94

2019年7月30日火曜日

SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法

Google Venturesが出資先の支援の際に行っているデザインスプリントのHowTo本。
面白いので一読の価値はあるとは思う。内容もよくまとまっているし読みやすい。

デザインスプリント自体が、体験すると面白いので何にでも使いたくもなるが、実際には以下の条件を満たす場合にのみ利用するほうが良さそう。
・リスクが高いとき。
・十分な時間がないとき。
・完全に行き詰まったとき。
時間がないときが条件になっているが、どんだけ時間がないかというと一ヶ月時間があるならやらないという選択も十分にあるといった感じだとおもう。
なれている人ならいざしらず、なれていない人が実践するにはかなりの準備が必要でかつ、準備しても成功するか未知数な面が大きい。
特に、デモ作成のときの実現性の妥当性については、議論が盛り上がると到底実現できないことが提案されそうであるので、進行役の人が実現可能性について常に気をつけなければいけないと思う。
それを怠ると、ただの楽しいアイディアソンになる可能性が高い。

SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法   ジェイク・ナップ https://www.amazon.co.jp/dp/447806699X/ref=cm_sw_r_tw_dp_U_x_J5YpDbR2M404G

ITエンジニアのための金融知識

銀行、証券、保険などの業務知識と、それぞれのシステムの概要を網羅的に説明してくれている。
そもそも単語がわからない人にとってはとても良い。
新卒で金融系に行ったら最初に読む本かな。
今どきのことは書かれていないけれども、それだからこそ比較的普遍的な知識が得られる気もする。
金融業務をしたことがある人向けではないけれど、良い本だと思います。

ITエンジニアのための金融知識   土屋 清美 https://www.amazon.co.jp/dp/B00IE3BNKG/ref=cm_sw_r_tw_dp_U_x_7VYpDb93CB67H

Clean Code アジャイルソフトウェア達人の技

コードにつていての原則などを説明している本。
すごい量が多いので、じっくり一回だけ読むというよりかは何回か読んだほうが良いと思う。
設計の技法などについて読むことが多いと思うけど、その設計を支えるべきcleanなcodeを作成する具体的な技法が習得するのも重要だと思う。
名前、関数、コメント、書式化、オプジェクトとデータ構造、エラー処理、境界、単体テスト、クラス
などがある。システムからは、やや設計的な内容になっていく。

それぞれの要点をまとめてみることにするが、最後のにおいのところだけをチェックリストのように使ってもよいのではないかと思えてくる。

・名前・意味のある名前
マジックナンバーを避けるなどして意味のある名前をつける
発音可能な名前をつける
検索可能な名前をつける
クラス名には名詞や名詞句を使う。InfoやManagerなどは避ける
メソッド名には動詞や動詞句をつけよう

・関数
関数は小さく、一つのことを行おう
関数の引数は、だいたい2つまでにする。3つまでは許すが4つはやめるべき
引数booleanはやめるべき、2つの目的が一つの関数にまとまっていることを示すから
引数が多くなる場合は、引数objectを作るのがよい
副作用は作ってはいけない。例えば、getなのに何かをinitializeしたり
コマンド、参照分離原則、参照しながら変更するをしてはいけない。変更するor参照する
try-catchの中身は関数にしたほうがよい
DRY(Don't Repeat Yourself)の原則、コピーすんなってこと

・コメント
意図や背景を説明するコメント
HTMLコメントはやめる。Javadocの出力は美しいかもしれないがコードとしては読みにくい

・書式化
Coding conventionのこと。基本的にはツールでformatを整えたりチェックしたりする方が懸命である

・オブジェクトとデータ構造
オブジェクトは操作を提供してデータを隠し、データ構造はデータのみを提供する
どちらが優れているということもない。データ構造の種類が増えていく場合は、オブジェクトのほうが良いが、処理の種類が増えていく場合はデータ構造の方が良い
一番ダメなのは、データ構造を公開しているが処理も持っているクラス

・エラー処理
アーリーリターンよりは例外
nullは返さないし、入れない

・境界
3rd partyのライブラリがよくわからなかったら、テストを書いてみるとよい。学習テストという。

・単体テスト
失敗するテストの前に、製品コードを書かない
単体テストは一つづつ書く。コンパイルして失敗したら次
失敗している単体テストが通るまで次に行かない
データ構築、データ操作、期待結果検証の3構造にすべてのテストをする。
1つのテストで1つの概念をテストしよう
テストの5原則FIRST
Fast - 素早い実行
Independent - テスト動詞が独立している
Repeatable - 何度でも再現可能
Self-Validating - 即時に結果がわかる
Timely - 書きたいときにすぐかける

・クラス
SRP(Single Responsibility Principle)単一責務の原則
変更の理由は常にひとつ
凝集性を高めるには、関数内で操作するメンバー変数が多いこと。


以降はわりとデザインの話が多くなる。
Clean Architectureと重なる面も多い。

・システム
決定は、手遅れになるギリギリまで遅延させることが最善。なぜなら、その時が一番情報があるはずだから

・創発
優れた設計などには原則がある。4原則。それを守ることで設計が単純化されて洗練される
全テストを実効する
重複がない
プログラマの意図が表現されている
クラスとメソッドを最小化する
プログラマの意図が表現されているというのがわかりにくかったが、要すると小さくすることで意図が曖昧にならないようにすることだ。

・同時並行性
マルチスレッドプログラミングで本がもう一つ必要だと思うが、原則としては
データスコープを限定する
データのコピーを利用する
スレッド間でデータの共有をしない
シングルスレッドでも動くようにする

具体例については、電子書籍だととても読みにくいものになっている。
ただ、匂いについてはチェックリストにしてもよいかも

C1 不適切な情報
C2 陳腐化したコメント
C3 冗長なコメント
C4 記述不足なコメント
C5 コメントアウトされたコード
E1 ビルド手順が1行でない
E2 テスト手順が1行でない
F1 引数は1〜2まで、せいぜい3つ
F2 out引数はだめ
F3 フラグ引数はだめ
F4 呼び出されていない関数は消す
G1 Java, HTML, Englishなどの複数言語はだめ
G2 当然の振る舞いは実装すべし
G3 境界値について正確な振る舞いを定義して、テストを書こう
G4 常に安全に倒す。ユーザーは悪意があるとみなす。
G5 DRY
G6 抽象レベルを揃える。abstract classで、utilityなど具体的なものを書かない。それは定数なども含む
G7 base classが具象クラスのことを知っていてはならない
G8 情報過多を避ける。スコープを小さくする
G9 デットコードは消す
G10 垂直分離、local変数は使う直前、private functionは使うすぐ下におく
G11 一貫性、あるクラスのインスタンスにつけた名前はどこでも同じものを使う
G12 雑然を避ける、実装のないコンストラクタなど
G13 人為的な結合を避ける。雑に一般的なものを具体的なクラスに含めたりしないこと。それがほかから使われたときに結合を生む。
G14 機能の羨望、クラスを引数として、そのクラス内のデータを操作しているならば、そのクラス内に関数を移動させたほうがよい。
G15 boolean引数など、振る舞いを選択させる引数はだめ
G16 コードの意図が正しく伝わる内容にする
G17 適当に変数を置くのではなく、適切な場所を選んで配置する。
G18 まよったら非staticにする
G19 変数自体を説明的にする
G20 関数名は何をするのハッキリと分かるようにする
G21 関数内部で何が行われているのか自明にする
G22 依存を物理的なものにする。物理的に持つべき場所に変数や定数などを定義する
G23 switchは一つまでにする。それ以上が必要ならばストラテジーを使えば良い
G24 コーディングコンベンションに従おう
G25 マジックナンバーは定数にする
G26 コードに曖昧な点をなくす。
G27 規約での制限よりも構造により制限する
G28 条件を関数化する(isXXXとか)
G29 否定条件を避ける
G30 関数で行うことは一つだけ
G31 呼び出し順が重要なときには、戻り値を次の関数の引数とするように順次処理が進むのを強制する
G32 いいかげんに内部にinnerクラスを作るなど、適当にならない
G33 境界条件はカプセル化する。ひとつに纏める
G34 抽象レベルを揃える。タグとサイズなど
G35 設定可能な値(キャパシティなど)は、できるだけ上位レイヤーに置く
G36 a.getB().getC().doSomethingのような構造は避ける
J1 import package.*を使って冗長なimportを避けよう
J2 interfaceに定数を定義して継承するのはやめる。static importで十分
J3 定数よりenum
N1 実装が予想できる関数名をつける
N2 interfaceでは具体的な名詞は避けたほうが無難
N3 できるだけ業界標準の名前を利用する
N4 関数名は長くなっても、内部で何をやっているか明確にする
N5 長いスコープで利用される変数は長めにする
N6 変数目m_とかのprefixはもう辞める
N7 createOrReturnXXXのように副作用があるならば、関数名で説明する
T1 テストは網羅的に行おう
T2 カバレッジツールを使おう
T3 些細なものでもテストを書こう
T4 @Ignoreはまずいサイン
T5 テストでは境界条件を忘れずに
T6 バグを見つけたらテストを足そう
T7 テストの失敗からバグが明らかになる
T8 テストで実行されていないところにバグがあるかも
T9 テストは高速化を追い求めるべき


Clean Code アジャイルソフトウェア達人の技 Robert C.Martin https://www.amazon.co.jp/dp/4048930591/ref=cm_sw_r_tw_dp_U_x_jJYpDbCM0YV0S

2019年7月26日金曜日

エンジニアが学ぶ金融システムの「知識」と「技術」

銀行や証券会社など金融に関係する分野について、かなりざっくりとした説明がおこなれている本。
全く業界について知らない場合は、導入としては良いかもしれないが、後半のシステムの話とかは、IT業界にいる人なら知っていることなので、なくても良いかもしれないので、立ち読みで十分かも。。。


エンジニアが学ぶ金融システムの「知識」と「技術」https://www.amazon.co.jp/dp/B07KS7RN3Z/ref=cm_sw_r_tw_dp_U_x_otEoDb7Z1KHE4

2019年7月23日火曜日

珈琲の世界史

珈琲の発見と現代に至るまでを世界史を交えながら解説してくれる本。

カフェインを含んでいるのもあるが、儀式で使われていた部分もあるようです。
ヨーロッパでは、カフェが政治活動の拠点になったりとか、ブラジルでは一大産業になる様子などが描かれている。
モカというと一般的なありふれた珈琲のイメージであったが、実際には高級品の代名詞となっていたらしい。
また、ブラジル産は大量生産で作られた豆で、スペシャリティコーヒーは、産地が限定された特別な豆のことを言うらしい。
うんちくが散りばめらており、楽しい本となっている。

珈琲の世界史 (講談社現代新書)   旦部 幸博 https://www.amazon.co.jp/dp/4062884453/ref=cm_sw_r_tw_dp_U_x_ArFnDb3RVD3EQ

アジャイルサムライ

エンジニア出身のプロジェクトマネージャーやリーダー向けのアジャイルの紹介本

合意しながら期待をマネジメントしながら、企画やデザイナーも含めてチームで開発をするということを書いている。
小さい規模感でアジャイル開発をしたことある人なら馴染みのある内容になっていると思う。

インプションデッキの作成については参考にすべきところが多いと思う。
インプションデッキを作成したことがないなら作ったほうが良いかも。自分も含めて。


  • 我々はなぜここにいるのか?何を実現するためにいるのか?
  • エレベーターピッチのテンプレ
    • 「潜在的なニーズを満たしたり抱えている課題を解決したり」したい
    • 「対象顧客」向けの
    • 「プロダクト名」というプロダクトは
    • 「プロダクトカテゴリー」である。
    • これは、「重要な利点、対価に見合う説得力のある理由」が出来、
    • 「代替手段の最右翼」とは違って
    • 「差別化の決定的な特徴」が備わっている
  • パッケージをデザインする
    • 機能の利点をアピールしよう。
    • 顧客への訴求要素が何かを明らかにすることが目的
  • やらないことリストを作る
    • 決められないなら後で決めるに入れておく
  • ご近所さんを探す
    • セキュリティ担当
    • 法律
    • インフラ
    • PR・マーケ

  • 解決案(アーキテクチャ)を描く
    • 描いて見てリスクを可視化しよう
  • 致命的でわかっているリスクを洗い出す
  • ざっくりのスケジュール
  • 諦めるものを決める
    • スケジュール
    • スコープ
    • 品質
    • 予算
    • をそれぞれ優先順位付けする。同じ値はありえない
  • 何がどのくらいいつようか。ざっくりでも良いので出してみる
    • どのくらいの期間
    • 何人
    • いくら
    • 運用ではどのくらい??
ユーザーストーリーについては、Sprintと似ているなーという感じ。この本に書いてある内容としては、テストが可能な内容でユーザーの価値が書いてあるユースケースのことだ。

見積もりはざっくりだ。
大中小で分けて、代表的なものを一つづつ見積もって、相対的に決めても良い。
ポイントを利用してverocityを計測してみよう

計画MTGは受け入れテストができるのか?などをチェック。これから始められるのかを確認する。
実行は作るだけ
ショーケースは、実際にデモして見せることだ。
次のイテレーションを計画する。ベロシティを見て入れられる量を決めたりだ。
最後は振り返り

現場の見える化は大事だ。
自分たちにも大事だけど、偉い人のためでもある。
バーンダウンチャートを作ったり、カンバンを用意したりだ。


最後は、プログラムについてであるが、エンジニアにはこれが最も大事かも。
これを外すといろいろ積む。
ユニットテスト
リファクタリング
テスト駆動開発
CI

良い内容の本なので一読の価値があると思う。


アジャイルサムライ−達人開発者への道−   Jonathan Rasmusson https://www.amazon.co.jp/dp/4274068560/ref=cm_sw_r_tw_dp_U_x_ScEnDb6B9CZNV