« 2017年9月 | トップページ

2017年10月

2017/10/14

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係

@t_wadaさんのBlogを読んでいたら、「プラグイン機構はソフトウェアの構造がコミュニティの構造に及ぼす事例に相当する」という重要な指摘があった。
考えたことをラフなメモ書き。

【参考】
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

akipiiさんのツイート: "「ソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方である」 https://t.co/07wYG0M7yf"

akipiiさんのツイート: "Redmineもプラグイン機構を持ちカスマイズしやすい特徴もここに理由があるのかな?「組織構造がソフトウェアの構造に影響を及ぼす(Conwayの法則)と同じように、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうる」 https://t.co/07wYG0M7yf"

【1】上記の記事では、「良い OSS 開発と良いソフトウェア設計の間には緊張関係があると思いますか?」という質問が発端になっている。
意図としては、OSSが良い設計であるには、ユーザからの多数の要望を五月雨式の取り入れると、アーキテクチャとしてもUIとしても一貫性がなくなり、複雑化するだけなので、取り入れないべき。
一方、OSSが活発に活動を維持するには、熱心なユーザがフィードバックやパッチをどんどん送り、ソフトウェアをバージョンアップしながらどんどん機能改善していくミッションがあるべき。

(引用開始)
しかし、それは結果的にソフトウェアの構造をゆがめることにつながらないだろうか。活発さを志向するあまり、機能やコードベースの肥大化を招いてしまい、統一感のある小さく単機能なソフトウェアの姿を保てなくならないだろうか。
もし活発さを志向する OSS 開発にそのようなバイアスがかかるのであれば、そこには構造的な問題、不幸な構図があるように見えてしまう。
(引用終了)

つまり、OSSコミュニティの活発さとより良いソフトウェア設計の間には、トレードオフがある。
では、どうやってその折り合いを採るべきなのか?

一つの解決策としては、OSSにプラグイン機構を設けて、「ソフトウェアを汚さずに、ソフトウェアを拡張する機構」というI/Fを用意しておくことだ。

(引用開始)
プラグイン機構による開発者コミュニティへの質的な転換

その意味で、モリスさんの講演にあったようにソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方であると再認識した。
組織構造がソフトウェアの構造に影響を及ぼすというのは最近よく聞く話だが(コンウェイの法則)、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうるというのは重要な気づきであったと思う。

OSS プロダクトがメジャーになればなるほど、コントリビューションを取り入れつつ、全体の整合性は壊さないような舵取りが大事になってくるのだろう。
大きめの OSS プロダクトや言語設計者のバランス感覚や調整能力が際立つのもわかる。
(引用終了)

つまり、プラグイン機構とは、ユーザコミュニティが単に、ソフトウェアを使用するだけの受動的立場から脱却して、自ら必要な機能はプラグインで実装するように、誘導するためのソフトウェア設計機構なのだ。

よって、プラグイン機構は、「ソフトウェアは組織構造に従う」というConwayの法則の逆パターンのコミュニティ版と言えるのではないか。
つまり、「より良いソフトウェア設計はOSSコミュニティという組織を活発化させる」。

【2】上記の記事を読んで、改めてRedmineについて思いを巡らせた。

【2-1】RedmineはRailsを開発基盤としているので、ソースも読みやすいし、プラグイン機構でユーザが機能拡張することも容易だ。
実際、Railsのプラグインの作成手順は、ネット上にいくらでも転がっている。

日本では、自分たちの組織に合った開発プロセスや業務プロセスに、Redmineを従わせて、Redmineを自由に使いたい、という要望が多い。
日本人はパッケージ製品をそのまま導入するのは嫌で、自分達なりにカスタマイズしたがる、という特徴が、Redmineにも出てくるわけだ。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

Redmineが日本人好みのツールであるという仮説 part2~日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

その時、Redmine本体を修正するのではなく、プラグイン機構を使えば、Redmine本体の影響を最低限に抑えて、カスタマイズすることが可能だ。
そうすれば、Redmine本体のVerUPに追随しながら、カスタマイズした機能の保守コストを下げることができる。

【2-2】では、なぜ、「プラグイン機構=ソフトウェア本体を汚さずにソフトウェアを拡張する機構」がRedmineにあえて必要なのか?

以前、Redmine勉強会では、JPLのRedmineの開発スタイルは非常に保守的である、という話があった。
実際、大幅な機能追加はやらないし、FunctionalTestが通らないパッチは受け取らない。
テストカバレッジは基本は100%になるまでリリースしない。

第8回東京Redmine勉強会の感想 #redmineT: プログラマの思索

JPLの美的感覚、設計思想が、熱心なユーザの機能改善要望を全て実現するのではなく、Redmineの発展に必要な機能、さらに、Redmineの品質低下を起こさないような機能だけに絞り込んでいるのだろう。

すると、確かにRedmine本体はVerUpしても安定しているだろうが、ユーザにとっては、標準機能だけでは機能不足と感じる場面も多くなる。

そんな時に、Redmineのプラグイン機構を用いて、Redmine本体に手を加えずに、自分たちの組織やプロセスに見合った機能を追加するわけだ。

換言すれば、プラグイン機構という柔軟なソフトウェア設計が、OSSアプリの標準機能では物足りないと感じるユーザに、自分達でカスタマイズできる余地を残しておき、それを利用させるような雰囲気を奨励している、とも言えるだろう。
それによって、Redmineは標準単体で安定した品質を保ちながら、ユーザはプラグインを入れて、自分達の環境に合ったプロセスを実現できる。
つまり、Redmineの柔軟なプラグイン機構が、ユーザにプラグイン開発を促進させ、多様なプロセスを実現することを促進させているわけだ。

【2-3】だから、Redmineのように、自由に機能拡張できるI/Fを持つOSSソフトウェアは、日本人向きなのだろう。

実際、Redmineはプラグイン機構以外にもREST APIやメールによるチケット登録、rakeコマンドなどの数多くのI/Fがあり、それらを適材適所に当てはめれば、機能をカスタマイズしやすい特徴がある。
以前、この辺りの事情は分析していた。

Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索

但し、この特徴はRedmineに限らず、SAPなどの著名なERPにおいても、パッチ当てをプラグインのような機構で実現しているので、そんなに特別なわけではない。

【2-4】一方、Redmineは「プラグイン機構=ソフトウェア本体を汚さずにソフトウェアを拡張する機構」の特徴を持つことで、Redmineコミュニティ自身が活発になりやすいこともあるだろう。

日本のRedmineコミュニティではプラグイン開発者が多い、という特徴を以前、@agilekawabataさんが指摘していた。

Redmineが日本人好みのツールであるという仮説part3~日本のRedmineコミュニティにはプラグイン開発者が多い: プログラマの思索

この意味は、日本企業はRedmineを自分たちの組織にあわせてカスマイズしたがるので、プラグイン開発者を必要としていることだ。
そして、そういうプラグイン開発者が日本のRedmineコミュニティには結構多い。

OSSの日本人Redmineプラグイン開発者として、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@onozatyさんたちがすぐに思い浮かぶ。
また、日本企業でも、アジャイルウェアなど、Redmineプラグインを専門に開発するSI企業も結構いる。

そういうプラグイン開発者や開発ベンダーは、RedmineというOSSコミュニティの活動にとても貴重な人達だ。
なぜなら、彼らはRedmine本体に取り込まれなかった機能を無償・有償でプラグインを公開してくれており、ユーザも恩恵を受けられるからだ。

また、彼らはRedmineの機能改善や利用事例に関するニーズも多数保持しているだろう。
そこで得られた知見も多いに違いない。
そして、実際、そういう知見をRedmineコミュニティで発表して、ユーザと共有してくれている。

そんな事を考えると、プラグイン機構というソフトウェア設計は、OSSソフトウェア本体を汚さずにOSSコミュニティを活発化させていくために必要な特性と言えるのだろうと思う。

つまり、柔軟なソフトウェア設計は逆に、OSSコミュニティという組織構造に良い影響を与えているわけだ。

【3】「Redmineは組織構造に従う」「柔軟なソフトウェア設計はOSSコミュニティを活発化させる」という二つの経験則は、正直面白い。

似たような経験則として、逆コンウェイ戦略「望ましいアーキテクチャに合わせて、アジャイルな開発チームを作る」という話もあった。

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

これ以外にも、Redmineインスタンスとプロセスの密接な関係もある。
「唯一のRedmineインスタンスで、組織内の多種多様な状況に合わせた標準プロセスを実現する」という観点と、「それぞれの開発チームの組織文化や開発プロセスに合わせて、あえて、Redmineインスタンスを複数個立てて運用する」という観点の二つのやり方がある。

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

どちらが正しい、というのではなく、それぞれの前提条件、組織の状況に応じて、コンテキストは変わる。

今の僕の興味は、Redmineのような柔軟なOSSソフトウェア、それを運用する組織構造やプロセスとの間に、どんな関係があり、どのようなコンテキストが発生しているのか、を経験則として抽出して、その本質を探ってみたい、と思っている。

| | コメント (0)

2017/10/12

astahを起動せずにJavaScriptで情報を取得する方法

tokudiroさんが、astahを起動せずにJavaScriptで情報を取得する方法を公開されていたのでメモ。

astah APIをjjsを使って楽に呼び出す - Qiita

やり方は、java8 のjavascript 実行エンジンjjsを使って、下記のようなコマンドを実行すればよい。
詳細は上記参照。

jjs.exe -cp astah-api.jar;astah-community.jar openProject.js hoge.js closeProject.js -- fuga.asta

使いたい状況としては、astahファイルからクラス情報などを一括出力したい時、hoge.jsにJSスクリプトで取得プログラムを書いておき、JJSエンジンで実行すればよい。
これは便利だ。

astahにはスクリプトエディタがあり、そこにJavascript、Ruby、Groovyなどを書けば即実行できるが、バッチ出力したい状況も多い。
プログラムは使い慣れたテキストエディタや開発環境の方が書きやすいから。
また、astahのスクリプトエディタではなく、プログラムを別ファイルで保存できるので、バージョン管理もやりやすい。

たぶん、JavaScriptだけでなく、Ruby、Groovyでも、上記と同じようなやり方で実行できるだろうと推測する。

利用シーンは、たとえば、本番稼働中の既存ソース群をastahへリバースして、クラス図などで設計図を書き起こした後、astahAPIでソフトウェアメトリクスを計算するJavaScriptをプログラム化しておき、上記のJJSエンジンでメトリクスを一括出力する、とか。

astahのモデルからソフトウェアメトリクスを出力して、既存のソフトウェア工学の理論を実証実験したい時に有効活用できるような気がする。

| | コメント (0)

astahのシーケンス図をPlantUMLへ変換する方法

astahのシーケンス図をPlantUMLへ変換する方法が公開されていたのでメモ。
これは興味をくすぐる。

【参考】
astah*で描いた図をPlantUMLやmermaid用に変換 | astah in 5 min

Avens666/Astah_Jude_UML_export_to_Markdown-mermaid-Plantuml-: Use Astah JS plugin, export astah diagrams data (such as flowchart, class chart ) to mermaid text fomat and Plantuml format

PlantUML インストール方法 - unhurried

UML図を描画するための単純なテキスト記述を使用したオープンソースのツール。

テキストでUMLを書く - Qiita

【1】手順はこんな感じ。

astahのシーケンス図を開く

astahのスクリプトエディタ起動

Jude_sequence_to_plantuml.jsを貼り付ける

スクリプトエディタからRunで実行

実行結果に、PlantUMLのソース(シーケンス図)が出力される

たとえば、PlantUML Web Serverに、PlantUMLのソースを貼り付けると、シーケンス図が表示される。
これは便利だ。

Jude_sequence_to_plantuml.jsを読むと、astahのシーケンス図の要素をAPIで取得して、PlantUMLの記法にセットしているだけでシンプル。
このやり方を真似れば、PlantUMLのクラス図、ユースケース図、アクティビティ図、コンポーネント図などにも適用できるだろう。

【2】PlantUMLを使いたい場面は、UMLの各種ダイアグラムで基本設計や詳細設計の成果物を作りたい時。

以前は、RationalRose、EnterpriseArchitect、Astahなどの設計ツールか、ExcelやVisioなどのOfficeソフトでお絵描きするのが普通だったが、こういうお絵かきツールはちょっとした仕様変更にすごく弱い。

メソッドが1個増えただけで、レイアウトが大きく変わり、お絵かきの修正にかなりの時間が取られたりする。
お絵かきがしたいのではなく、クラス設計に注力したいのに、実際は、線1本のレイアウトに時間を取られる時の方が多くないだろうか?

また、お絵かきソフトは、バージョン管理が弱いので、修正履歴がない場合が多い。
すると、ちょっとした変更で間違えたので元に戻したい、という作業ができなくなる。

そんな場面では、PlantUMLのように、UMLの各種ダイアグラムもテキストで書いた方が楽。
テキストであれば、Gitでバージョン管理できるので、Undo・Redoがいつでもできるので、試行錯誤しながら、設計することもできる。
バージョン管理の環境がない作業は、UndoやRedoができないので、今何をやっているのか、常にログを残して覚えておく、というプレッシャーが残り、本来の創造的な作業がやりにくいように思う。

但し、ラフなスケッチでお絵描きしたい時もある。
だから、astahで書いてPlantUMLに出力し、その後はPlantUMLのソースを修正していく方が楽かもしれない。

【3】上記のやり方を発展させると、以下のような機能へ発展できないか、と思う。

・astahから、PlantUMLの各種ダイアグラム(クラス図、ユースケース図、シーケンス図等)のソースを出力する
・PlantUMLのソースから、astahへリバースしてダイアグラムを復元する

つまり、astahとPlantUMLで相互にエクスポート・インポートできるようになれば、色んな可能性が出てくると思う。
たとえば、astahでラフなスケッチをしてからPlantUMLに出力して、ソース管理する。
本番稼働中の既存ソースをastahへリバースしてクラス図を作り、PlantUMLへ出力してバージョン管理しておく、とか。

あるいは、PlantUMLからastahへインポートして、さらにastahからJavaやC#のスケルトンクラスを出力する、とか。

プラグイン化できたら面白そう。

【追記】
RedmineにPlantUMLを表示するプラグインは、既に公開されている。
海外の開発者のコメントを見ると、好評らしい。

plantuml - Plugins - Redmine

dkd/plantuml: PlantUML Plugin for Redmine

RedmineでPlantUMLを使う事例: プログラマの思索

Redmine で技術仕様書を書こう | Aiming 開発者ブログ

| | コメント (0)

« 2017年9月 | トップページ