・今の会社には、長々といるべきではない

給与もそうですが、僕が頑張っても、上長の期待は得られなさそうだ。

とりあえず、景気はあと１年から２年で上向いてくるだろう。

そのときを狙い、転職をします。

そのときの準備として、色々勉強して行こうと思います。

そのフィードバックをこのblogに綴ります。

「入力」「処理」「出力」の3つが基本となっているのですね。

ハードウェアも何かを与えたら(入力)、計算して(処理)、何かを出す(出力)。

これを念頭にしてプログラムを見ると、プログラムが本当に綺麗なのかなと、思ったりします。

# まだ実践していませんが。

その機能は、何かを与えられることによって、これを計算して、何かを出すということを考える。

# その前に関数の分割がうまく出来ないとだめだろうけど。

コードを書く上での意識をすると、その関数の目的の明確化、更には機能についての明確化も出来そうですね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・実際のコーディング

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

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

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

全体像の把握

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

・自分が何を作るか

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

人によっては、

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

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

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

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

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

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

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

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

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

話はそれましたが、

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

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

組み込みの場合、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・バイトオーダーとは

「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と同じですが、対向のエンディアンが同じであればよいですが、

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

ここからは不明。

宿題な方向で。

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

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

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

・チェックリストの作成

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

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

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

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

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

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

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

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

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

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

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

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

<朝>

・15分前くらいには出社。本日の作業内容の確認

・・・といった具合でしょうか。

よくネットとか、やって、作業時間を迎える人がいるけど、やはり、作業は、定時から始まるもので、

その終了時間の前に、どの程度の成果が出せて、そして、それを元にどの程度、残業すればよいのかとかを

考えるのかな。

目標の設定という意味でもあるから、これを外すと、何をどこまでするのか、わからなくなるのかな。

<昼>

作業。

睡魔が天敵だけど、どのようにすればよいのかしら。

コーヒーをガブ飲みすればよいのかしら。

集中力がなくなってきたときの気分転換方法とかも謎だけど。

これは、後日考えるとするかしら。

<夕>

・作業内容の成果確認

基本的に残業はしない。

明日出来るようであれば明日片付ける。

日数が迫っているもであれば、早めに終わらすのも手。

ただ、僕は、残業について反対であるのと、会社にとって必要悪と思っていないので、

貰わないようにするものだと思っています。

何かを履き違えて、残業しようとする人も多いですが、この姿勢は、基本的に、変わらずにやって行きたいと思います。

・・・ということで、1日の作業についてまとめると。

朝

・本日の目標設定

昼

・その目標の実践

夕

・目標に対するアウトプットの確認

→完了してれば、作業終了

→完了していなければ、その目標内容について、あとどれくらい行えば、完了するかを見積もる。

　状況によって残業。

それが出来たらよいのかな。

考察した結果、以下の通り。

１．転職を目標として、仕事をしていた。

２．実は自分が出来る人間だと思い込んでいた。

３．まだ、実は、答えが出せるものではない。

１について。

転職したことで目標が達成されてしまいました。

次の目標を探していない状態なのではと思われます。

私は、そういう状態なのです。

今の会社で、技術者として成長したいなと思っています。

でも、ソフトウェア開発者というのは決して、技術者というカテゴリに入らないんですよね。

# このことについては、後日書くとして。

・・・ということに気づいた瞬間、マネージメント系のエンジニアにならないと、この会社では

生きていけないのだろうなと思っています。

仕事のモチベーションを上げるために、今一度、今年の目標と数年の目標を決めないと

いけないのであろうなと思います。

２．について。

やはり、仕事の基本ができていなかったために、大目玉を仕事で食らいました。

だから、これもいえるのかなと。

例えば、報連相ができないとか。

リーダーが仕事をするもので、その手伝いをするのだから、基本、仕事はリーダーの

意思決定で決まるということ。

まぁ、リーダーがそういう認識で仕事をしていなかったら微妙ですが。

３．について

やっぱり、３年やそこらでうまく、言えるものでもないだろう。

・・・もともと第２新卒のようで入ったわけだし。

とりあえず、今は、今年の目標と、近い未来の目標を立てないといけないのだと思います。

・・・・目標が無いが故に、今迷っているのかもしれません。

あとは、どういう風になればよいのだろうというのが見えないんだろうね。

ｘｘｘに詳しくなるとか、組み込みの分野では、ハードウェアの知識が多く求められて、

ドライバを作るようであれば、そのハードがどのように動くとかまで、理解しなければいけないわけで、

難しいところ。

今は、少なくとも、設計、プログラムやら、コーディング、テストといった工程の精度を上げることが

求められるのかな。

でもそれだけでは、ダメだと思うので。

少しずつ、ハードの知識もここでまとめながら、ひとつのシステムについて、提案できるように

なれるくらいまでなれればよいのかな。

とりあえずは、今年は、実装系の内容をちゃんとできるようにを目標にします。

最低限のことを出来るように。

システムで3年、組み込みで3年、仕事をしている私ですが、今だに、組み込みでの仕事に慣れません。

そして、今まで行ってきた作業での知識というものをまとめずにいたということもあり、

今でも未熟なエンジニアとして扱われている状況を打開したいがために、このblogを開設しました。

更新間隔は不明ですが、拙い文章になるかもしれませんが、よろしくお願いいたします。