連載コラム

 
  • ホーム>
  • 連載コラム アーキテクトへの道

アーキテクトへの道

  • アセンプラ的プログラムの課題と解法 【設計図フォーラム2017】

    開発現場で2種類の課題をよく見かけます。ひとつはアセンブラ的プログラム、もうひとつは在庫化プログラムです。

    ▶より詳しく

  • リバース&リファクタリングで資産価値向上

    ソフトウェア疲労を起こしていませんか?

    ▶より詳しく

  • アーキテクトの実力をつける新規セミナー

    エンジニアからアーキテクトになるために不足している3つのスキルが見えてきました。
    1.ビジネスを見据える力
    2.本質を捉える力
    3.相手に伝える力
    です。

    ▶より詳しく

  • リファクタリングへの理解

    IT用語辞典によると、「プログラムの振る舞いを変えることなくソースコードを変更すること。(…一部省略…)各種問題を解決し、将来の仕様変更に柔軟に対応できるようソースコードの手直しを行うこと。」と記載されています。

    様々な企業の方とお話ししていると、「今まさにリファクタリングやってます」「リファクタリングのやり方が分からない」「検証済みのソースコードなので、リファクタリングをする事への理解が得られない」などの話が飛び交います。言葉の意味や、皆さんとの会話で判明したことがあります。それは…

    「リファクタリング」という言葉を使っていても、それぞれ考えていることが違う。

    ▶より詳しく

  • 関数ツリーの限界

     機能追加、バグ修正をする際、テスト範囲や修正箇所を特定する作業が一般的に必要となります。この作業をするためにgrepを活用して、関数の呼出し関係、関数と変数の参照更新関係を調べます。grep作業と頭の中の整理だけで作業を進めると、必ず混乱してしまいます。

     そのため、多くのソフトウェア技術者の方は、grep作業の結果を『関数ツリー』の形式でメモ書きしていると思います。『関数ツリー』は「どの関数がどの関数を呼んでいるか」「どの関数がどの変数を参照更新しているか」が明確になり、テスト範囲や修正箇所の特定に役立ちます。また、『関数ツリー』を自動生成してくれるツールがいくつかあるため、ツールを活用しているソフトウェア技術者の方も多くいらっしゃると思います。多くのソフトウエア開発現場では、ドキュメントを作りなさいと言われていると思いますが、この『関数ツリー』をドキュメントに貼りつけると、設計書として形になります。このように多くのソフトウェア開発現場は、『関数ツリー』を活用して開発効率を高める活動を行っています。このような良い活動は、さらに良い成果をもたらすスパイラルとなります。

    しかし・・・

    ▶より詳しく

  • grepだけでは成長できない

     多くのソフトウェア技術者の方は、機能追加・バグ修正をする時、関数名や変数名を起点にソースコードのgrep検索(全対象ファイルの中から文字列)をして、影響範囲の調査などを行います。

      「ある関数を呼び出している関数はどれか?」

      「ある変数を参照更新している関数はどれか?」

    影響範囲を調査すること非常に重要です。

    ▶より詳しく

  • 第15回 構造化設計の定規を作りました

    最近は、アーキテクトの戦略的な育成に関わることが多くなってきました。
    アーキテクトは、ソフトウェアを複数のビューで構造的に表現できることが求めれます。
    日々のプログラミングでも、手続きの一筆書きではなく、モジュールの構造化設計、に取り組んできたエンジニアが、アーキテクトへと成長する姿をよく見かけます。

    ▶より詳しく

  • 第14回 コード中心から設計中心へ(2012年5月9日)

    ソフトウェアは時間が経つと劣化していく、というソフトウェア疲労の症状を列挙してみました。ソースコードレベルで改修を繰り返していくと、徐々に設計構造が崩れ、設計意図が分からなくなってしまいます。その様なソースコードを引き継ぎ、担当することになったら大変です。引き継いだコードを、一生懸命にコードレベルで修正すると、さらに状況が悪化する、という悪循環になってしまいます。頑張れば頑張るほど、仕事がきつくなってしまいます。

    ▶より詳しく

  • 第13回 老舗温泉旅館と一枚岩<全体の設計思想の欠如>(2012年4月17日)

    ソフトウェア疲労の最後の現象は、全体構造の調和の欠如です。ソースコードに近い関数やクラスではなく、関数やクラスの集合体であるコンポーネントの構造に着目します。

    ▶より詳しく

  • 第12回 寄り道、裏取引<アドホックな制御構造>(2012年3月27日)

    ソフトウェアの設計は、静的構造と動的構造の二つの視点で図面化することが大切です。今回は、動的構造の典型的な課題と設計原則を紹介します。

    ▶より詳しく

  • 第11回 スパゲティと中央集権<構造の曖昧さ>(2012年3月13日)

    前回に引き続き、設計技法の適用ミス、です。今回は、構造に焦点を当ててみます。

    よく見かけるのは、C言語でのスパゲティプログラムとC++言語での中央集権プログラムです。

    ▶より詳しく

  • 第10回 神様データ<設計技法の適用>(2012年2月27日)

    前回は「そもそも設計していない」という症状を書いてみましたが、今回は、設計技法の適用がうまくいっていない例を紹介します。

    ▶より詳しく

  • 第9回 一筆書きとクローン<そもそも設計していない>(2012年2月20日)

    そもそも設計していない現象の典型例として、一筆書きとクローンがあります。

    一筆書きとは、処理な流れをそのままひとつのモジュールにしたものです。例えば、ひとつの関数で「入力処理して、演算処理して、出力処理をする」といったものです。C言語は手続き型言語なので、このモジュールでもコンパイルして、動作するものができます。しかし、次の様な問題が発生します。

    ▶より詳しく

  • 第8回 ソフトウェア疲労とは(2012年2月13日)

    前回までの7回で、全体を俯瞰して、かつ、際どいところを押さえるアーキテクチャの構築と、それを使ってリーダーシップを発揮するアーキテクトの役割について書いてきました。しかし、実際のソースコードが、ぐちゃぐちゃになっていては、いくらアーキテクトが頑張っても、開発の現場は楽になりません。

    ▶より詳しく

  • 第7回 アーキテクチャ設計で経営とテクノロジをつなぐ(2012年2月6日)

    何を作るのか、と、どのように作るのか、をつなぐものがアーキテクチャとなります。すなわち、アーキテクチャとは、ものづくりの経営と製品のテクノロジの架け橋といえます。そして、それを実現するための重要な役割を担う人がアーキテクトです。

    ▶より詳しく

  • 第6回 アーキテクチャ設計と既存ソースコードのギャップを見える化する(2012年1月23日)

    既存のソースコードの構造と目指すべきアーキテクチャ設計の構造が分かれば、両者のギャップも明確になります。ギャップを狭める、そして、ギャップが広がらないよう技術的なマネジメントが大切です。

    ▶より詳しく

  • 第5回 ソースコードから設計意図を発掘する(2012年1月10日)

    アーキテクチャ設計はしたいけど、今のソースコードがある、という方も多いと思います。動いているソースコードを捨てて、新たにアーキテクチャ設計する、という機会はなかなかありません。そして、新しくアーキテクチャ設計しても、それできちんと動くかどうかは、動かしてみないと分からないというリスクも抱えてしまいます。今のソースコードは、動いている限りはソフトウェア資産といえます。

    ▶より詳しく

  • 第4回 複数の視点でアーキテクチャを定義する(2011年12月26日)

    アーキテクチャ設計は、複数の視点(ビュー)で製品像を明確にして、製品開発を牽引するものです。私たちは、組込みソフトウェアアーキテクチャとして、(1)目論見、(2)設計方針、(3)静的構造、(4)動的構造、(5)実装構造の5つの視点を定義しています。

    ▶より詳しく

  • 第3回 アーキテクチャ設計は箱+線+心(2011年12月19日)

    アーキテクチャ設計は、箱と線でつながった構造で表現します。しかし、そのような無機質な「箱+線」だけではなく、そこに心として意図を含めることで、理解しやすく、安定して、劣化しにくいアーキテクチャとなります。すなわち、アーキテクチャ設計は「箱+線+心」といえます。

    ▶より詳しく

  • 第2回 コンポーネント設計とアーキテクチャ設計(2011年12月12日)

    多くの組込みソフトウェアは、ソフトウェアが増大傾向にあり、ソースコードに近い設計図だけでは、全体を俯瞰できなくなりつつあります。全体を俯瞰し設計意図を明確にすることをアーキテクチャ設計と呼んでいます。すなわち、ソースコードに直結するコンポーネント設計と、それより上位の設計意図を伝達するためのアーキテクチャ設計とを連携させることで、大規模ソフトウェアを上手に開発することにつながります。

    ▶より詳しく

  • 第1回 アーキテクチャ設計とは(2011年12月5日)

    世の中には、すでに実装済みの多くの設計技法があります。それらの技法は、品質の高いソースコードを、生産性を高めて開発していくことを解決します。その一方で、価値ある製品作り、ゴールは何なのか、というものづくりのビジネス視点の話題には、あまり触れられておりません。

    ▶より詳しく

連載コラム アーキテクトへの道
コラム一覧
  • アーキテクトへの道
  • オープンセミナースケジュール
 
ページの先頭へ