What one likes, one will do well 〜好きこそ物の上手なれ〜

寄り道しながらも、最後は昔から好きな物理とプログラミングに戻ってくる。そんな男の思いをつづるブログです。

アジャイルソフトウェア開発の奥義を読みました。

はじめに

アジャイル開発に興味があり調べていると、「アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技」と言うのがオススメされていて読んでみました。コードがたくさん書いてあり、具体的で体系的にまとまれていて、とても読み応えがあり、楽しかったです。かなり分厚い本なので、最後は息切れしてしまいましたが。。。読んで心に残ったことをまとめます。

アジャイル開発

最初はアジャイル開発のアジャイルアライアンス宣言や原則、エクストリームプログラミングのプラクティスがまとめられています。顧客が受け入れテストを書くと言うのが目からうろこでした。

実際にリファクタリングをする例やプログラミングエピソードで実際にペアプログラミングテストファーストを実践している例がコードと共に書かれていて、具体的にイメージできました。かなり勉強になりました。

アジャイル設計

設計における原則が書かれていました。難しい内容も多かったのです。後の章で実際のコードと共に原則を使っており、とても大切なことがわかります。自分の理解を整理する上でも内容をまとめます。

  • 単一責任の原則は、クラスは一つの責務を持つこと
  • オープンクローズドの原則は、修正せずに(クローズド)拡張できること(オープン)。具体的には、ポリモーフィズムを利用して、サブクラスを追加する事で機能追加できる設計
  • リスコフの置換原則は、スーパークラスをサブクラスに置き換えても正常に動く状態。これを満たしていないとオープンクローズドの原則が満たされない可能性が高い。またサブクラスがスーパークラスのメソッドで使わないものがあれば違反している
  • 依存関係逆転の原則は、上位がインターフェースを提供し、それに下位が合わせる状態。上位が下位を使うと下位に依存する。下位が上位に依存するのが正当。そうすれば同じインターフェースを持つ下位を自由に使える。実現において重要なのは抽象化
  • インターフェース分離の原則は、関連がうすいインターフェースを分離すること。関連のないインターフェースの変更の影響がそれを使うクライアントにいかない事が大切
  • 原則はたくさんあるが必ず守る必要はない。しかし一度問題が発覚したら、次は起こらないように原則を適用して改善することが大切

給与システムのケーススタディ

抽象化することでオープンクローズドの原則に則って実装されのが具体的にわかりました。クラス作りすぎるのは煩雑だと思っていたけど、変更に強いし、理解すればわかりやすいです。コードがたくさんでボリュームがありますが、コードを読むことで理解が深まりました。このケーススタディで使われていたデザインパターンが最初にまとめられていたので、自分の理解を整理するためにまとめます。

デザインパターン

  • Commandは、クラスにコマンドを実装
  • Template methodパターンは、処理のテンプレートを実装して、それを継承し、詳細な処理を実装する
  • Strategyは、必要な処理をインターフェースに移譲し、処理を実装する。実際の処理を実装しているクラスと処理しているクラスが分離される
  • Facadeは、汎用インターフェースをシンプルに使いやすくする。ラッパーと似てると思うけど、違うかわからなかった。汎用インターフェースに使用方針や制約を課す
  • Mediatorは、Facadeと同じく方針や制約を課すのだけど、リスナーなどを使用して、意識することなく課される
  • Singletonは、自身のインスタンスをstaticで持ち、コンストラクタはprivateにし、インスタンスの生成は決まったstaticなメソッドで行い、staticな自身のインスタンスを返す事で、インスタンスが一つしか発生しないようにする
  • Monostateは、変数をstaticにし、別のインスタンスからでも同じstaticな変数を返すため、全て同じインスタンスのように振る舞う
  • Null Objectは、何もしないオブジェクト。クラスにstaticなNull Objectを保持し、インスタンスが生成できない条件のときに返す。Nullのときのメソッドの処理を調整し、存在チェックをシンプルにできる。(例:DBに存在しないときは、Null Objectを返すなど)

給与システムのパッケージング

給与システムのケーススタディのクラスをパッケージングしていました。最初にパッケージ設計の原則があり、その後使うデザインパターンの説明、最後に実際のコードでパッケージングしていました。難しかったです。。。

パッケージ設計の原則

  • 再利用リリース等価の原則は、再利用されるパッケージとリリースの単位が等価であること。再利用されるパッケージがリリースの単位より小さくなることはない。
  • 全再利用の原則は、パッケージ内のクラスは一緒に再利用されるべきで、関係ないものは含まないということ。パッケージには強い関連性があるもののみを含む
  • 閉鎖性共通の原則は、単一責任の原則のパッケージ版。変更に対して閉じているべきで、変更はパッケージ内全てに影響を及ぼすが、他のパッケージには影響しない。同じ理由で変更される可能性のあるクラスをまとめることでもある
  • 非循環依存関係の原則は、依存関係を循環させないこと。循環すると結局全てのパッケージと依存関係が生まれ一つの変更で全てビルドリリースが必要になる。解決するには依存関係逆転の原則を使う。AがBを使っているとする。Aが使うインターフェースを作る。Bはインターフェースを利用したクラスを提供する。Bがインターフェースに依存するので、依存関係が逆転する。またAとB両方が依存する新しいパッケージを外出して作るのも循環を防ぐ。パッケージ構造は変化し成長するもの。トップダウンでは設計できない
  • 安定依存の原則は、安定していて変更したくないパッケージに依存するようにして、変更したいものは依存されないようにすること。依存関係は安定するものに流れるようにする
  • 安定度抽象度等価の原則は、パッケージの安定度と抽象度は同程度でなければならないこと。安定するということは、抽象化されているということ

デザインパターン

  • Factoryは、インスタンス化することを請け負う。具体的なインスタンス化は、依存になる。依存をさけるためFactoryを作成し、インターフェースのみにつながる。しかし複雑なため乱用は勧めない

パッケージ設計で注意すべき点

  • パッケージは似た機能をまとめるだけではダメ。依存される「責任がある」パッケージと依存しない「独立した」パッケージがある。「責任がある」パッケージは、抽象化され再利用可能なもの。「独立した」パッケージは、変更が頻繁な詳細な処理を持つ。しかし保守性や再利用背性と依存関係の複雑性はトレードオフでパッケージの利用によって検討する必要がある。
  • パッケージ内で処理を完結させる
  • メトリック。凝縮度、内側に向かう結合度、外側に向かう結合度、抽象度、不安定度、主系列からの距離。定量的に測る

気象観測所のケーススタディとETSのケーススタディ

これ以降は内容が難しくなってきて、一応読んだもののケーススタディはほとんど理解できませんでした。何とかまとめたデザインパターンだけ記載しておきます。

  • compositeは、同じ処理を繰り返し行うときに使う。既存の処理は変えずに、リストに入れ、繰り返し処理すればよい
  • observerは、何かを監視するときに使う。observerを登録して、subjectに変化がありnotifyされたら、登録されているobserverのupdateを読んで更新する。更新にはpull型とpush型がある
  • abstract serverは、インターフェースをいれて、具体的なクラスが直接依存しないようにする。インターフェースを定義するときにクライアント側の名前にするのがコツ
  • adapterは、ソースコードを持っていない対象にabstract serverパターンを適用する時に使う
  • bridgeは、中間にコントロール層を作って管理する。複雑になるためおすすめはしない
  • proxyは、ビジネスロジックとDBの処理を分離すること

まとめ

アジャイル開発の原則からプラクティス、プラクティスの具体例に、デザインパターンケーススタディのコードと盛りだくさんでした。まえがきで「コードをじっくり読んでほしい」とあるが、まさにその通りで、コードを読むことで学ぶことがたくさんありました。(最後は読み切れませんでしたが。。。)

付録にある「皮肉な運命」や「ソースコードは設計である」はとても興味深い内容でした。

全てを読み切れなかったし、読んだ部分も全てを理解できている訳ではないので、何度か読みなおしたい本です。本を見ればわかるように分厚く、かなりのボリュームです。その分内容もかなり深いと思います。オススメの一冊です。

 

 

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

 

 

ケントベックのテスト駆動開発入門を読みました。

はじめに

ケントベックのテスト駆動開発入門を読んだ。3,4年前に読んで今回が2回目。最初に読んだ時も衝撃を受けたが、2回目読むとさらに理解が深まり、ケントベックのすごさが分かった。

今回読んで心に残ったことを記載していく。

テスト駆動開発の基本

テスト駆動開発の基本は、

だと感じた。

テストを素早くパスさせるために、定数を返すなどのコードを書くのだが、それが抵抗感があった。しかしテストコードとコードに同じ定数があるため、重複を取り除くためにリファクタリングを実施する。すると求めているコードになっていく。

前回は理解できていなかったが、今回少し理解できた気がした。

テスト駆動開発のパターン

アサートファーストが「おっ!?」と思った。テストを作成するときにどこから書けばいいのか迷う。まずクラス考えて、メソッドを考えて、引数を考えて、戻り値を考えて、アサートするというように上から順に考えていた。でもアサートファーストということで、アサートから考えるのがよいようだ。オブジェクトから何を得るか。結果から考えることで、テストを書きやすいと感じた。

レッドバーに関するパターン

「パソコンには安価な机。プログラマには良質な椅子。」と言うのはおもしろかった。やはり開発する環境と言うのは大切だと思う。

テストに関するパターン

「1人でプログラミングをしているときは最後のテストを失敗のままにして終える。」と言ういのは、やってみようかと思った。失敗のテストにより前の状態を思いだそうと考えるきっかけができる。

前にたまたまテストが失敗の状態でしばらくコードができないことがあった。失敗のテストのおかげで、前の状態を思い出したことがあったので、1人のプログラミングの時はやってみようと思う。

グリーンバーに関するパターン

仮実装などの話。上記の「テスト駆動開発の基本」でも書いたが、やっと少し理解できた。

xUnitに関するパターン

例外のテストの部分は参考になった。エラーが起きた時は何もせずに、エラーが発生しなかったときはテストを失敗させる。例外のテストは難しいと感じていたので、やってみたい。

デザインパターン

デザインパターンは難しく、まだ全ては理解できない。でも他の書籍を読んだり、実際にコードを書くことで、理解できるパターンが増えてきた。一番重要なのはコードを書くことだと思う。

リファクタリング

マーチンファウラーの「リファクタリング」を読んでいたせいか分かりやすかった。こちらの方がコンパクトにまとまっていて、分かりやすかった。すでにリファクタリングを読んでいたおかげだと思う。

TDDの習得

「途中でどのようにTDDに切り替えるのか」と言うのが興味があった。全部ではなく変更のスコープを決めて切り替える。確かにその通りだと思う。少しずつTDDに切り替えていきたい。

 おわりに

テスト駆動開発入門を2回目読んで本当によかった。さらに理解が深まり、プログラミングへの熱意も高まった。もっとコードを書きたい、テストを書きたいと思った。

実はxUnitの例はまだ読んでいない。それは、エクセルのマクロ用のxUnitを書こうと思っているから。

仕事ではエクセルのマクロなどで少しコードを書くことぐらいしかない。マクロでコードを書くときもテストを書くのだが、自分オリジナルで書いている状態だ。マクロのxUnitも使いたいと思っているが、モジュールなどをたくさん読みこまないといけないようだから躊躇している。

一方でもっとテストをシンプルに綺麗に書きたいと思っているので、勉強もかねて自分でマクロ用のxUnitを実装してテストを書こうと思っている。コンセプトとしては、「読みこむモジュールは1ファイルだけ」だ。完成したら公開したいと思う。

 

テスト駆動開発入門

テスト駆動開発入門

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2003/09
  • メディア: 単行本
  • 購入: 45人 クリック: 1,058回
  • この商品を含むブログ (162件) を見る
 

 

2016年10月のつぶやき

 

Qiitaに記事を投稿しました。クラウド統合開発環境Cloud9でTensorFlowを使う~ソフトマックス回帰~

Qiitaに記事を投稿しました。

TensorFlowで手書きの数字を認識するものです。チュートリアルを実装してみただけですが、今後実際に使って理解を深めたいと思います。

 

qiita.com

育休を2年間とってみて~おやじの会~

学校との関わり

育休中に小学校のPTAをやったり、行事には必ず参加するなどしていました。必然的に先生と話す機会が増え、私の顔を覚えてもらえるようになりました。そうして学校との関わりが強くなっていきました。

おやじの会の提案

そんな中、校長先生からおやじの会をやってみませんかと提案がありました。とは言っても仲間がいない事には始められません。提案があってから1年ぐらいは何もできずにいました。

仲間が見つかる

おやじの会について気になってはいたものの何もできずにいましたが、ひょんなことでおやじの会に興味を持っている人がいる事がわかりました。すぐに連絡してみると何かやりたいという気持ちがあって、トントン拍子でおやじの会を立ち上げる事になりました。

おやじの会の準備

立ち上げるにあたっては何度か打合せして目的や趣旨を決め、校長先生に承認をもらいました。その上で募集のチラシを作り学校経由で配布してもらいました。

おやじの会第一回会合

そして第一回会合を開きました。募集チラシを出したものの集まったのは、自分達で直接声をかけた人達だけでした。チラシを見て行こうと思う人はなかなかいないようです。気にはなっている人は多いようですが、声をかけて後押しされて一歩踏み出せる方が多いような気がします。

おやじの会の活動

まだ出来たばかりで実績がないため活動実績が必要です。学校行事や地域行事の手伝いなどできる事から始めました。まずは認知される事が必要だと思います。今後はおやじの会独自のイベントなどが出来ればと思っています。

育休を2年間とってみて~外の空気に触れて~

育休中は大忙し

育休中に色々やろうと考えていました。ブログ、料理、プログラムの勉強、アプリ開発、など。でもほとんど何もできずに終わりました。それは育児をしていると自分の事に集中できないから。子どもと常に一緒にいるわけですから常に相手をしないといけません。相手にせず自分のやりたい事に集中していると必ず「パパ〜!」と呼ばれます。
やはり子どもは自分の事を見てほしいのです。

自分の時間を作るには

そんな中自分の時間を作るには、子どもが寝た後か、奥さんに子どもを任せて外出するかです。

子どもが寝た後は、数時間ほど自分の時間になりますが、そこは奥さんとの時間でもあります。子育てについて話したり、今日あった出来事を話したり、晩酌をしたりと大切な時間です。

と言う訳で自分の時間を作るには外出が一番です。会社に行くと言うのは自分の時間を作ることにもなると感じました。

外の世界に触れて

そんな中、CodeIQでプログラムの問題を解いていたら、忘年会の案内がきました。育児ばかりで外の世界に触れてみたいと思っていたので、奥さんに相談すると、快く行かせてくれました。

CodeIQの忘年会では色んな方の話を聞きました。新しい技術や働き方、自分の知識のなさを痛感し、とても刺激を受けました。その中でも一番心に刺さったのはソニックガーデンさんのリモートワークという働き方。在宅勤務と考えればよいのですが、社員全員がリモートワークしてるとのこと。そのため東京の会社なのに全国各地に社員がいる。

納品のない受託開発をやっていて、お客様のシステムを開発したりするようでさが、さらに驚いたのはお客様との打合せもリモートとのこと。全てリモートだから全国どこにいても全国のお客様の仕事をできる。

職場に出勤して仕事、お客様との打合せは対面が当たり前だった自分にとっては大きな衝撃とともに魅力を感じました。

刺激を受けて

久しぶりに外の世界に触れてとても刺激を受けました。仕事をしていた時は職場と家の往復だったので、外には行っていたのですが、狭い世界にいたと思います。

刺激を受けてもっと新しい技術を学びたい、よりよい働き方をしたい、技術を磨きたいと思いました。そして学ぶ事に対するモチベーションが上がり、新しいことを勉強しインプットしました。それを本当に自分のものにするために今はアウトプットする事に目を向けています。

ブログやQiita、Githubなどでアウトプットしていこうと思います。まだまだ出来ていることは少ないですが、できる事からアウトプットしていく。それが成長に繋がると思います。

さいごに

定期的に外の世界に触れる事は大切だと思いました。外の世界に触れる事で今の自分の位置や外の状況、何が出来ていて何が出来ていないのかがわかります。知らない事もたくさん学べます。自分と外の世界のギャップを知る事で、学びや何かをやるモチベーションにもなります。

モチベーションを保つためにも、外の世界から置いていかれないためにも、自らが新しい事をやるためにも、定期的に外の世界に触れて行こうと思いました。

 

育休を2年間とってみて~職場復帰~

職場復帰が近づいて

育休が終わりに近づいて職場復帰の日が近づいてきました。久しぶりの職場復帰となると不安になると思います。

私の場合は四半期に1回職場に顔を出して、近況報告していました。顔を出したときは知っている人に声をかけていました。そうすると「久しぶり〜。元気?」と喜んで相手してくれるので、職場復帰に対する不安感はありませんでした。みなさん理解ある人たちばかりでありがたかったです。

復帰後の仕事は?

気になるのは復帰後の仕事だと思います。私の場合は会社に顔を出していたとき、復帰後の仕事について希望を聞かれたり、会社の状況など説明されたので、本当に理解があり、助けられたなという気持ちです。

しかし何の仕事をするかというところは簡単ではありませんでした。希望はあってもその仕事に人が必要か、育児で時間的制約が出てこないか、育休をとった人をマネージャーが受け入れるかなど、希望を聞いてもらっても、そのまま通るとは限りません。

私の場合は、ちょうど復帰のタイミングで希望する仕事をしている部署で人を募集していたためうまく希望が通りました。こればかりは運やタイミングになってしまいます。私は運がよかったです。

職場復帰後

復帰した職場は上司が女性で育児にも理解がある環境でした。子どもの送り迎えなどで時間的制約があっても理解があり、子どもの行事などの休暇も取りやすい環境でした。

この辺は職場や上司の理解がないと難しいので、本当にありがたい話です。逆に自分が上司になったりしても理解ある上司でありたいと思いました。

また時間的制約があるなかで仕事をするため仕事の効率が上がった気がします。終わりの時間が決まっていると早くアウトプットを出すために集中して考えて形にします。早くにレビューを受けて、フィードバックをもらうことで、早くに完成形に持っていけます。終わりが決まっていることで、ダラダラ残業が減り、ムダな時間を減らせると思います。

さいごに

育休を2年間もとりましたが、とても充実した日々を過ごす事ができました。家族との絆が深いものになったと思います。

それには会社や職場の理解が必要不可欠だと感じ、感謝の気持ちしかありません。

仕事に復帰しましたが、育休中に築いた家族の絆を大切にしつつも、仕事を効率よく結果を出して、職場の仲間に対して育児に対する理解を示していきたいと思います。

ワークライフバランスという言葉がありますが、まさにそれを実践していきたいと思います。育休中は育児に専念しましたが、これからは仕事と育児を両立していきたいと思います。