設計技法の講座として、オブジェクト指向設計と構造化設計を実施しています。
オブジェクト指向設計では、何割かのエンジニアは理解できずに、現場展開につながりませんでした。
アーキテクチャ中心開発の勘所として、(1)静動分離、(2)アーキテクチャテンプレート、(3)WhatとHowの補助線、という3点を載せています。
エンジニアからアーキテクトになるために不足している３つのスキルが見えてきました。
１．ビジネスを見据える力
２．本質を捉える力
３．相手に伝える力
です。
IT用語辞典によると、「プログラムの振る舞いを変えることなくソースコードを変更すること。（…一部省略…）各種問題を解決し、将来の仕様変更に柔軟に対応できるようソースコードの手直しを行うこと。」と記載されています。
様々な企業の方とお話ししていると、「今まさにリファクタリングやってます」「リファクタリングのやり方が分からない」「検証済みのソースコードなので、リファクタリングをする事への理解が得られない」などの話が飛び交います。言葉の意味や、皆さんとの会話で判明したことがあります。それは…
「リファクタリング」という言葉を使っていても、それぞれ考えていることが違う。
機能追加、バグ修正をする際、テスト範囲や修正箇所を特定する作業が一般的に必要となります。この作業をするためにgrepを活用して、関数の呼出し関係、関数と変数の参照更新関係を調べます。grep作業と頭の中の整理だけで作業を進めると、必ず混乱してしまいます。
そのため、多くのソフトウェア技術者の方は、grep作業の結果を『関数ツリー』の形式でメモ書きしていると思います。『関数ツリー』は「どの関数がどの関数を呼んでいるか」「どの関数がどの変数を参照更新しているか」が明確になり、テスト範囲や修正箇所の特定に役立ちます。また、『関数ツリー』を自動生成してくれるツールがいくつかあるため、ツールを活用しているソフトウェア技術者の方も多くいらっしゃると思います。多くのソフトウエア開発現場では、ドキュメントを作りなさいと言われていると思いますが、この『関数ツリー』をドキュメントに貼りつけると、設計書として形になります。このように多くのソフトウェア開発現場は、『関数ツリー』を活用して開発効率を高める活動を行っています。このような良い活動は、さらに良い成果をもたらすスパイラルとなります。
しかし・・・
多くのソフトウェア技術者の方は、機能追加・バグ修正をする時、関数名や変数名を起点にソースコードのgrep検索（全対象ファイルの中から文字列）をして、影響範囲の調査などを行います。
「ある関数を呼び出している関数はどれか？」
「ある変数を参照更新している関数はどれか？」
影響範囲を調査すること非常に重要です。
最近は、アーキテクトの戦略的な育成に関わることが多くなってきました。
アーキテクトは、ソフトウェアを複数のビューで構造的に表現できることが求めれます。
日々のプログラミングでも、手続きの一筆書きではなく、モジュールの構造化設計、に取り組んできたエンジニアが、アーキテクトへと成長する姿をよく見かけます。
ソフトウェアは時間が経つと劣化していく、というソフトウェア疲労の症状を列挙してみました。ソースコードレベルで改修を繰り返していくと、徐々に設計構造が崩れ、設計意図が分からなくなってしまいます。その様なソースコードを引き継ぎ、担当することになったら大変です。引き継いだコードを、一生懸命にコードレベルで修正すると、さらに状況が悪化する、という悪循環になってしまいます。頑張れば頑張るほど、仕事がきつくなってしまいます。
ソフトウェア疲労の最後の現象は、全体構造の調和の欠如です。ソースコードに近い関数やクラスではなく、関数やクラスの集合体であるコンポーネントの構造に着目します。
ソフトウェアの設計は、静的構造と動的構造の二つの視点で図面化することが大切です。今回は、動的構造の典型的な課題と設計原則を紹介します。
前回に引き続き、設計技法の適用ミス、です。今回は、構造に焦点を当ててみます。
よく見かけるのは、Ｃ言語でのスパゲティプログラムとＣ++言語での中央集権プログラムです。
そもそも設計していない現象の典型例として、一筆書きとクローンがあります。
一筆書きとは、処理な流れをそのままひとつのモジュールにしたものです。例えば、ひとつの関数で「入力処理して、演算処理して、出力処理をする」といったものです。C言語は手続き型言語なので、このモジュールでもコンパイルして、動作するものができます。しかし、次の様な問題が発生します。
前回までの7回で、全体を俯瞰して、かつ、際どいところを押さえるアーキテクチャの構築と、それを使ってリーダーシップを発揮するアーキテクトの役割について書いてきました。しかし、実際のソースコードが、ぐちゃぐちゃになっていては、いくらアーキテクトが頑張っても、開発の現場は楽になりません。
何を作るのか、と、どのように作るのか、をつなぐものがアーキテクチャとなります。すなわち、アーキテクチャとは、ものづくりの経営と製品のテクノロジの架け橋といえます。そして、それを実現するための重要な役割を担う人がアーキテクトです。
既存のソースコードの構造と目指すべきアーキテクチャ設計の構造が分かれば、両者のギャップも明確になります。ギャップを狭める、そして、ギャップが広がらないよう技術的なマネジメントが大切です。
アーキテクチャ設計はしたいけど、今のソースコードがある、という方も多いと思います。動いているソースコードを捨てて、新たにアーキテクチャ設計する、という機会はなかなかありません。そして、新しくアーキテクチャ設計しても、それできちんと動くかどうかは、動かしてみないと分からないというリスクも抱えてしまいます。今のソースコードは、動いている限りはソフトウェア資産といえます。
アーキテクチャ設計は、複数の視点（ビュー）で製品像を明確にして、製品開発を牽引するものです。私たちは、組込みソフトウェアアーキテクチャとして、（1）目論見、（2）設計方針、（3）静的構造、（4）動的構造、（5）実装構造の5つの視点を定義しています。
アーキテクチャ設計は、箱と線でつながった構造で表現します。しかし、そのような無機質な「箱＋線」だけではなく、そこに心として意図を含めることで、理解しやすく、安定して、劣化しにくいアーキテクチャとなります。すなわち、アーキテクチャ設計は「箱＋線＋心」といえます。
多くの組込みソフトウェアは、ソフトウェアが増大傾向にあり、ソースコードに近い設計図だけでは、全体を俯瞰できなくなりつつあります。全体を俯瞰し設計意図を明確にすることをアーキテクチャ設計と呼んでいます。すなわち、ソースコードに直結するコンポーネント設計と、それより上位の設計意図を伝達するためのアーキテクチャ設計とを連携させることで、大規模ソフトウェアを上手に開発することにつながります。
世の中には、すでに実装済みの多くの設計技法があります。それらの技法は、品質の高いソースコードを、生産性を高めて開発していくことを解決します。その一方で、価値ある製品作り、ゴールは何なのか、というものづくりのビジネス視点の話題には、あまり触れられておりません。
アーキテクトへの道
ビースラッシュ株式会社
Copyright © BACKSLASH DESIGN CO.,LTD. Allrights reserved.
