コード設計 (1)

コード設計についてまとめようと思います。

今後、後輩を見ることになるし、何よりも、他人のコードを多く見ていくことにもなる。

さらに見られるようになる。

良いコードとは何かを考えてみようと思う。

現在、当該内容について、読んでいる本。

・達人プログラマー(発行：株式会社ピアソン・エデュケーション)

個人的な意見として、組み込みの分野の人は、特に我が強い人種だと思います。

自分のやっていることについて、間違いと言わない人が多いと思います。

この本については、良いプログラマーになる上での内容を記載しています。

読み終えたら、どんなことが書いてあったか、

この本から、僕はどのようにコードを書かないといけないかをまとめようと思います。

# 今月から、来月のエントリーで書こうと思います。

さて話が逸れましたが、現在、自分がコード設計をするうえでどのようにしているかを記述しようと思います。

# ひょっとしたらこの本を読むことで変わるかもしれませんね。

コードの設計と一重に言っても、いっぱいありますね。

・ドキュメントからコードに起こす上で初めにすること

・実際のコーディング

・全体的に心がけること。

製造(メイク、コーディング)という工程の中で考えると沢山あります。

今回は、コードを書く前に行うことを書こうと思います。

全体像の把握

以下のことを洗い出します。

・自分が何を作るか

・それにはどのような機能が必要か

人によっては、

・このシステムにはどのような機能が必要か

から考える人もいると思います。

これは、必要な分だけの機能だけ、設計・作成することが出来れば、問題ないと思いますが、

使わないものまで、残るパターンが多いです。

そうすると、使用しない機能(関数)が残り、

「本当にこの関数は必要なのだろうか？」

ということになってしまいます。

後々、コードを見る人にとってやさしくありません。

やはり、コードは、他人に優しくなければいけないと思います。

話はそれましたが、

要は、システムの機能をボトムアップで設計するか、トップダウンで設計するか

というところに集約されます。

組み込みの場合、

ある程度、どのようなものを作るか、システムの全体像が決まっていることが多いと思います。

ですから、トップダウンの設計で問題ないのかなと私は思っています。

あくまでも私が携わっているHWに近いプログラムでのお話ですが。

SWになると、トップダウンとボトムアップを組み合わせないといけないかもしれません。

利点としては、不要なコードが減るといったところですかね。

コードというのは、後々誰かに見られ、保守・管理されていくものだと思っています。

# 使い捨てのコードというものは、聞いたことありません。

保守・管理の人達にとって困るものは、コードにおける不具合だと思っています。

いつまでも、そのコードを作った人が、保守･管理をするということはありません。

不具合が出たとき、誰かが対応します。

そのときに、「本当にこのコード必要？」という疑問を持つでしょう。

そのようなことはコメントでカバーも出来ますが、必要でないものは、オブジェクトサイズを

考えないといけない場面もあると思いますし、よろしくないと思います。

結論から言うと、「全体を考えて作成」することがよいコード作りの入り口になると思っています。

バイトオーダー

# 凄く間が空いてしまいましたが、これからは、週1ペースで更新をするようにします。

いかんせ、私は、まだ駆け出しの組み込みエンジニアであるゆえ、間違いもあると思います。

誤りを見つけられた場合は、ご指導のほどよろしくお願いいたします。

----------------------------------------------------------------------------------------

組み込みの仕事をすると、よく聞きます。

「リトルエンディアン」とか、「ビックエンディアン」とか。

これについて初めのエントリーとして書いてみます。

・バイトオーダーとは

「2bytesや4bytesといった多バイトで表現する数値をメモリに格納する際のバイトごとの並び。」のことです。

(参考：ASCIIデジタル用語辞典)

最上位バイトが下位にあるのがビッグエンディアン。

最下位バイトが上位であるのがリトルエンディアン。

言語で言うと、Javaは、ビッグエンディアンで、C言語はリトルエンディアン多バイトを表しますね。

# 社会人1年目のPJでネットワークシステムで、サーバJava、クライアントC言語といったシステムで、

# 通信ではまったこともあったりして、この辺りはなんとなく覚えていたりする。

では、そもそも、何故バイト、オーダーって存在するのでしょうね。

・何故、二つのエンディアンが存在するのか？

# これについては完全に調べ切れていません

　インテル系のCPU (IBM) = リトルエンディアン

　モトローラ系のCPU(SUN / Apple) = ビッグエンディアン

おそらくは、インテルやモトローラが作ったものが、リトルエンディアン、ビッグエンディアンを採用したからと

思われます。

# 調べていくと皆、そういう風な回答になりますね。

では、何で、各メーカーは、そのエンディアンを採用したのでしょう。

何かもっと深い理由がありそうですね。

用途の問題なのでしょうかね。

I/Oについては、リトルが多いし、画像系の規格であれば、ビッグが多いし。

各用途によって、早くなるのかな。

TCPとかはビッグを利用するから、AppleやSUNのPCの方が早そうだけどなぁ。

・長所、短所

ここまで考察してみましたけど、結果的に、長所・短所がわらからないのと、選定する場合には何を基準にして

選定するのでしょうか、不明ですね。

そもそも、何故二つの規格というところに戻ってしまいます。

・エンディアンが違った場合、変わった場合に注意すること

現在、両エンディアンに対応するようなプログラムを作成しているので、本内容を題材にしました。

どのようなところに注意すべきか。

　・多バイト長アクセス　→　32bitでデータを扱う場合は、32bit変数、16bit変数の考慮が必要です。

特にレジスタアクセスの場合は、32bit幅でアクセスしたほうが無難かも

しれませんね。

・DMAなどのメモリ転送 → メモリとプログラムで扱うエンディアンが違った場合、正しく転送されません。

・ネットワークを利用した通信 → DMAと同じですが、対向のエンディアンが同じであればよいですが、

　　　　　　　　　　　　　　　　　　　　　　違った場合は、変換の必要がありますね。

ここからは不明。

宿題な方向で。

・変数のマスクについては、ひっくり返すべき？

・両エンディアンの必要性

次回は・・・正しいコードの記述について考えてみようかと思います。

チェックリスト

ここ2週間、リーダーが休暇中ということから、私がリーダーの代わりをし、そのサポートとして課長が付くという形で作業をしています。

ぎこちない部分が多々ありますが、なんとかプロジェクトは回っています。

課長と作業しているせいか、色々と指摘を受けます。

今日はいくつかあるうちの中で、これは誰でも実践すべきだと思ったことを書きます。

・チェックリストの作成

作業工程でレビュを行い、指摘受けることがあります。

それについて、指摘を直して、その工程完了・・・・ってなる人って多いのではないでしょうか？

# 少ないよ、ということを言われると、話が進みませんので、多いということで進めます。

私は、それで完了という人間です。

本日、レビュを行い、課長が些細なミスを指摘しました。

そこで、私にケアレスミスが多いと踏んだ課長が私に提案したこと

それがチェックリストの作成でした。

何かというと、「今まで指摘された事項をまとめなさい。」ということでした。

まとめた結果、毎回レビュ前に「それに書かれている内容を確認しなさい」ということです。

チェックリストを作ることによって、今までの自分の財産となり、今後、後輩を指導するようになったとき、

それを見せるようにすることによって、作るものの品質があがるというプラスの効果が期待されます。

今からでも遅くないので、それを実践しようと思います。