書評☆3: Redmine超入門 増補改訂版 | 楽天でのRedmine導入秘話と便利機能紹介

概要

  • 書名: Redmine超入門 増補改訂版
  • 副題: ITの現場全員が使い助け合う 最強の無料プロマネツール
  • 著者: 飯田 治行 and 大澤 文孝 and 大和田 裕 and 小川 明彦 and 楠川 智久 and 阪井 誠 and 内藤 淳
  • 出版日: 2015-08-13
  • 読了日: 2020-02-22 Sat
  • 評価: ☆3
  • パーマリンク: https://book.senooken.jp/post/2020/03/03/

評価

Bug Tracking System (BTS) のRedmineの入門書となっている。

ソフトの紹介と導入企業の事例紹介として楽天社の話が掲載されていた。

その後は,インストール,使い方,プラグインや機能の紹介,業務での利用ケースの紹介などがあった。

「お役立ちプラグインBEST20」の紹介があり,Wikiの中でチケット一覧を表示する機能など,いくつか便利そうな機能を知れて参考になった。

その他,サーバー台帳や議事録の管理に使う事例が紹介されており,そんなふうにも使えるのかと参考になった。

結論

BTSのRedmineの紹介と使い方の紹介がされていた。

業務で使ったことがあるのだが,ユーザーとしてただ使うだけだった。ここに書かれているような,拡張機能や,台帳や議事録の管理にまで使うという発想はなかった。

Redmineを本格的に使う上では,軽く目を通しておくと参考になると思った。

書評☆3: 現場で役立つシステム設計の原則 | 失敗の原因はデータクラス/機能クラスによる手続き型設計

概要

  • 書名: 現場で役立つシステム設計の原則
  • 副題: 変更を楽で安全にするオブジェクト指向の実践技法
  • 著者: 増田 亨
  • 出版日: 2017-07-18
  • 読了日: 2020-01-31 Fri
  • 評価: ☆3
  • URL: https://book.senooken.jp/post/2020/02/04/

評価

書名どおり,現場で役立つシステム設計の方法について書いてあった。いろんなところで参照されており,評判が高かったので興味を持って読んだ。

内容としては,プログラミング言語Javaを例としたオブジェクト指向設計について論じたものであり,リファクタリングやドメイン駆動設計やDB,Web APIとの連携の設計についても書いてあった。

一番印象に残っているのが,「Chapter 3 業務ロジックをわかりやすく整理する」だ。変更しにくく,似たような処理が至るところに記述される状態ができる原因として,データクラスと機能クラスを使った手続き型設計を指摘していた。これはたしかにそのとおりだと思った。

内容全体として,オブジェクト指向に沿った設計を行い,業務の関心事項の単位でクラスを作ることでうまく設計できるという話だった。

いろいろ書いてあったが,結局はオブジェクト指向を意識してやれば大丈夫という内容だった。

結論

既存コードの失敗例を上げながら,なぜダメなのかどうすればいいのかをオブジェクト指向に従った形で解説されていた。

オブジェクト指向を理解して実践できていれば,当然と思うような内容がやや多かった。リファクタリングなどの話も交えていて,まあまあよかった。

ただ,巷での前評判が高かったので,それと比べるとやや過大評価に感じた。

あくまで著者が考える方法のひとつであり完璧とも思わない。それに,知っていても実際に自分の場面で適用できるかどうかはある程度経験が必要になる。

そういう意味で,普段の開発に問題を抱えている人が読むと参考になるだろうと感じた。

書評☆4: [改訂第3版]Jenkins実践入門 | ハイテクチームで必須の定番CIソフトを網羅的に解説した唯一の本

概要

  • 書名: [改訂第3版]Jenkins実践入門
  • 副題: ビルド・テスト・デプロイを自動化する技術
  • 著者: 佐藤 聖規 and 和田 貴久 and 新井 雄介 and 米沢 弘樹 and 山岸 啓 and 岩成 祐樹
  • 出版日: 2017-05-24
  • 読了日: 2019-12-18 Wed
  • 評価: ☆4
  • URL: https://book.senooken.jp/post/2019/12/18/

評価

一流ハイテクチームで当たり前のように使われているCIの代表的なソフトであるJenkinsについて解説している。

Jenkinsの使い方について1冊まるごと書かれている本は本書が唯一であり,Jenkinsについて学ぶ上では外すすことができない本だろう。

書籍の構成は以下のとおりとなっていた。

  1. JenkinsとCIの説明
  2. Jenkinsのインストール・設定
  3. ビルドの自動化
  4. 開発環境の準備
  5. ビルド以外のテスト,カバレッジ,インスペクションなどの自動化など

Java製のサンプルプロジェクトを題材に,Jenkinsによる自動化の第一歩として,ビルドの自動化から始まり,徐々にテストやカバレッジなどビルド以外にも自動化するとよい作業を追加で設定していくという手順をとっていた。

それぞれの段階で必要なツールの簡単な使い方から設定方法が書かれており参考になった。

また,応用的な使い方としてPipelineやJenkinsのプラグイン開発についても言及があり,Jenkinsについて全体を知る上で必要な情報が網羅されていた。

引用

p. 26: 1.3.2 Jenkinsの歴史

JenkinsはもともとHudsonという名前で開発されており,開発元のSun Microsystems社のOracleへの買収などをきっかけに2010年にJenkinsに改名となった。Jenkinsの歴史がまとめられておりわかりやすかった。

p. 66: Column GitからJenkinsビルドをトリガーする

Gitの「ポストコミットフックスクリプト」からJenkinsのビルドを開始する方法が書かれていた。この方法でコミット時にビルドさせると,masterへのマージ時にビルドエラーやコーディング規約などのチェックもできていいなと思った。

p. 299: Column Xvfb PluginによるXvfbでのSeleniumの実行

GUI環境がインストールされていなかったり,画面の接続されていないLinuxマシン上で画面を表示する方法が解説されていた。

Jenkinsとは関係ないが,丁度VNCでモニターの接続されていないLinuxマシンで画面解像度を変更する方法を探しており,Xvfbで実現可能なことがわかり参考になった。

p. 314: Column Infrastracture as CodeではじめるインフラCI

なお、 Chefと Jenkinsを組み合わせたインフラ自動構築については本書の姉妹本である WEB+DB PRESS plusシリーズの『Chef実践入門―コードによるインフラ構成の自動化』に詳しく 書かれているので、興味があれば、 ぜひご一読ください。

インフラ自動構築についてはあまり興味なかったが,必要になったらここで引用されている本を読もうと思った。

p. 384: Column Continuous Deliveryとは?

Continuous Deliveryについて書籍『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・ テスト ・ デプロイメントの自動化』に詳しい記述があります。 Jenkinsは Continuous Deliveryを実現する上で中核となるソフトウェアです。 ぜひ Jenkinsでワンクリックデプロイにチャレンジしてみてください。

CIのさらに一歩進んだやり方としてCDについて参考書籍が紹介されていた。

結論

ハイテクチーム・企業で当たり前のように使われているCIの代表的なソフトであるJenkinsについて網羅的に解説されている本だった。

Jenkinsについてきちんと解説されている本は少なく,日本語では本書が唯一の本だろう。IT技術者としてレベルを高めるために必要なCIの技術について本書で学べる。

Jenkins認定試験の参考書にもなりえる本で,Jenkinsを学ぶ上で必須の本だろう。

内容自体も基本的なことから応用的なところまで,実例を交えながら解説されていた。題材はJavaの開発プロジェクトであったが,ビルドツールなどを他に置き換えることで,C/C++やJavaScriptのプロジェクトにも応用できると思った。

書評☆3 Code Reading | 大量のOSSの実コードを引用した学術的要素高めのC言語ベースのコーディング技法解説

概要

  • 書名: Code Reading
  • 副題: オープンソースから学ぶソフトウェア開発技法
  • 著者: トップスタジオ and まつもと ゆきひろ and 平林 俊一 and 鵜飼 文敏
  • 出版日: 2004-06-10
  • 読了日: 2019-11-05 Tue
  • 評価: ☆3
  • URL: https://book.senooken.jp/post/2019/12/13/

評価

新しい仕事に取り掛かる際に,既存ソフトのソースコードを眺めて作りを理解する必要に迫られた。今までも似たような作業があり,コードリーディングの能力を高める必要があると思い,本書を読んだ。

内容としては,既存のOSS (Open Source Software) のソースコードを使って,実際にどのような手法が使われているかを解説したものだった。

既存OSSがC言語のものが多かったということで,C言語をベースとしたコーディング技法を解説していた。

流れとしては,目次通り以下の流れで解説されていた。

  1. 序論
  2. ループやifなどの制御構造
  3. Cのデータ型
  4. Cのデータ構造
  5. 制御フロー (上級編): 再帰,例外,並列,シグナル,マクロ
  6. プロジェクト
  7. コーディング規約
  8. ドキュメント
  9. アーキテクチャ
  10. コードリーディングのツール
  11. 総合的な例

個人的には,1-4章と10章が特に有益だった。Cのデータ型やデータ構造が実コードでどのように使われているのか解説されていた。

用途が不明だった,unionも多態の実現にstruct内で使われていることを知れた。また,コードリーディングでは,変数や関数 (シンボル) の定義元,関数の呼び出し元を探すことがよくある。ここの作業に時間がかかっていて,どうにかしたいなと日頃から感じていた。今まで知らなかったソフトを多数を知れてよかった。

ただ,その他の6-9章は内容がやや高度であったので,自分ではあまり理解できなかった。

本書の最大の特徴は,大量のOSSで実際に使われているコーディング技法を大量に引用しているところだろう。ここまで細かくコード片を引用し,その出所も行数まで掲載されているのには驚いた。かなり労力のかかっている本だと思った。

引用

p. 13: 1.2.2 ダイアグラム

デザインダイアグラムには、事実上の業界標準となっているUML (Unified Modeling Language) を採用しました。本書を準備する段階で、UMLダイアグラムを生成するオープンソースの宣言型言語 <[注5] (https://www.spinellis.gr/umlgraph/)> を開発すると都合が良いことがわかり、それに伴いGraphVizツールのコードベースにも少し改良を加えました。

UMLの生成言語としてはPlantUMLを知っていたが,この他にもUMLGraphというものを知れた。

p. 66: 3.1 ポインタ

Cプログラムのポインタには次の用法があります。

  • リンクデータ構造を作る
  • 動的に割り当てられたデータ構造を参照する
  • 参照呼び出しを実装する
  • 一連のデータ要素にアクセスする
  • 配列を引数として渡す
  • 関数を参照する
  • 別名で参照する
  • 文字列を表現する
  • システムメモリに直接アクセスする

C言語のポインタの用法がまとまっていた。

p. 69: 3.1.4 データ要素へのアクセス

表3.1 T型の要素を持つ配列をインデックスまたはポインタで操作する

  • 配列インデックスによるコード | ポインタによるコード
  • int i; | T *p;
  • i = 0 | p = aまたはp = &a[0]
  • a[i] | *p
  • a[i].f | p->f
  • i++ | p++
  • i += K | p += K
  • i == N | p == &a[N]またはp == a + N

Cのポインタと配列は混同しやすいので対応が整理されていてよかった。

p. 102: 4.1 ベクタ

配列の要素は、Cライブラリ関数のfwriteでファイルに保存されることがよくあります。

if (fwrite(buf, sizeof(char), n, fp) != n) {
    message("write() failed, don't know how", 0);
}

ファイルに保存された要素をメインメモリに読み込むときは、fread関数を使用します。

if (fread(buf, sizeof(char), n, fp) != n) {
    clean_up("read() failed, don't know why");
}

変数内のデータを簡易的に出力・入力する方法が書かれていた。内部表現をファイルに出力する都合,同一アーキテクチャのマシンでしか機能しないが,手っ取り早い方法として悪くない。

p. 389: 10.7 コードブラウザと美化ツール

次に、よく知られているオープンソースブラウザをいくつか取り上げ、簡単に紹介しておきます。

  • cscope <注21>。Unixベースで、テキストインターフェイスを持つソースコードブラウザ。Cの解析用に設計されているが、パーサの柔軟性が高く、C++やJavaでも有用である。cscopeは、Emacs、nvi、vimなどのエディタと統合できる
  • cbrowser <注22>。C/C++ソースコードの検索と閲覧のためのグラフィカルツールで、関数呼び出しの階層表示もできる。cscopeを土台とし、その上に組み立てられている
  • Source-Navigator <注23>。C、C++、Tcl、FORTRAN、COBOLを始め、その他いくつかの言語を扱えるブラウザ
  • LXRブラウザ <注24>。Webベースのブラウザで、大量のコードコレクションの相互参照ができる。

コードリーディングのためのツールをいろいろ紹介していた。ctagsやcscopeは知っていて,特にcscopeはたいへん便利で重宝していた。ここでさらに,cbrowserというツールやその他のコードブラウザの存在を知れてとても良かった。

cscopeは関数ツリーをたどることはできないのが惜しいなと思っていたのだが,cbrowserでは関数ツリーをたどることができるとのことで,これは是非試したいと思った。

結論

学術的な要素があり,やや難易度の高い部分があり,中級者向け以上の本となっている。また,C言語のコードをベースにしているので,最低限のC言語の知識を前提としていることに注意が必要だ。

学術的な要素があり,2004年とやや古い出版であるが,多数のOSSのベースとなっているC言語をベースに,データ型や制御構造など実際のコード片を引用しながらコードリーディングの技術を解説していて,よかった。

個人的には,コードリーディングのツールをいろいろ知れたのがとても良かった。このあたりのツールは作業効率に影響出るのだが,あまりネット上にも情報が出ていない。cscopeは知っていたが,cbrowserは知らなかった。

ただし,労力がかかっているのは分かるが,プレミアムブックスは値段が高すぎる。図書館でどうにか借りて済ませるのがよいだろう。

書評☆3 [改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 | USDMによる要求記述方法と計測の重要性

概要

「派生開発」を成功させるプロセス改善の技術と極意』で変更要求仕様書などの記述に使われていたUSDMについて書かれた本だ。

前著に興味を持ったので,こちらも読んだのだが,こちらはややいまいちだった。細かいことがけっこう書いてあり,読んでいて面倒くさくなった。

まず,具体的な書き方が始まる第6章に入るまで,書籍の半分近くの文量を占める1-5章が既存の問題の説明やなぜ要求が必要なのかといったことがひたすらひたすら何回も書かれている。この時点で既に読む気が失せていた。いくら何でもくどすぎる。

そして,第6章以降も同じような感じで,細かいことや似たようなことを繰り返し説明していた。言いたいことがいろいろあるのはわかるが,もっと要点を絞って簡潔にまとめてほしかった。

書き方の説明があったり,計測について説明があったのはよかったのだが,全体的に記述が冗長で,ひたすらくどいうという印象だけが残ってしまった。

結論

前著が悪くなかったので期待していたのだが,全体的に記述が冗長でくどいところだけが印象に残ってしまった。

くどい書籍から自分に必要なところを取り出すのはけっこうしんどい作業だ。

具体的な記述や計測に関する話は比較的よかったので,全体としては残念だった。

パーマリンク: https://book.senooken.jp/post/2019/08/27/

書評☆4 「派生開発」を成功させるプロセス改善の技術と極意 | 派生開発の極意は記録にあり!

概要

XDDPやUSDM,PFDなど,一部で採用されている開発手法が解説されている本だ。

ソフトウェアやシステム開発においては,新規開発と既存の資産をベースに機能修正・改良を行う派生開発の2種類が存在する。

開発手法では新規開発に焦点をあてたものが多く,派生開発を念頭に置いたものがなかった。そこで,著者が派生開発のための開発手法として,XDDP (eXtreme Dervied Development Process) を編み出した。

XDDPは以下の成果物から構成される。

  • 変更要求仕様書
  • トレーサビリティ・マトリックス
  • PFD

修正箇所に関する情報を,仕様書としてきっちりと文書に残すことで,修正の漏れや修正箇所・方法の誤りが分かるようにしている。

また,開発の工数,変更行数などをきっちりと計測することで,生産性を計測している。

冒頭で,既存の派生開発でよく生じる様々な問題が説明されており,共感した。そして,記録を残すというやり方はいいなと感じた。

ドキュメント作成の方法がまた独特なので,クセがあるが,一度試す価値はあるかなと感じた。

ただ,書籍が冗長な記述が多いので,もう少し要点を絞ってコンパクトにできないかなと思った。文量が多いので,けっこう読むのはたいへんだった。

結論

2018-12にある現場の面談で,USDMという文書形式で開発文書を残すという話を聞いて,USDMという単語が気になって調べ,この本に辿り着いた。

開発資料をきっちり文書に残してトレーサビリティを確保するという考え方はいいなと感じた。

実際にこの方法を取り込むには,それなりにやり方を整理して,学ぶ必要があり時間がかかるだろう。

普段の開発でも,自分の生産性を考えることはあまりなかった。開発修了時に,変更前後のコード差分と,かけた時間で自分の生産性 (1日あたりの変更行数) を計測して,今後に役立てたいと感じた。

パーマリンク: https://book.senooken.jp/post/2019/08/26/