コーディングは大丈夫だろうか？

最近、C言語やC++言語を勉強していて、様々なソースコードを読んだり、書いたりしています。

今日は、帰宅途中に、本屋にちょっと寄ってみたら、「危険なプログラムの処方箋」という本があったので、購入しました。

自宅に帰ってきて、少し読んでみました。その中に、綺麗なソースコードには主観が入るので、気をつけたほうがいいとありました。
このことは、自分のスキルが足りないだけかも知れない場合があるので、気をつけましょうということです。
これは、人それぞれのクセみたいなものがあるので、気をつけなくてはならないと思いました。

↑の部分と反するかも知れませんが、割とベテランのエンジニアが実装した部分でも「なんだこれ」という処理があります。
そもそもどのようなコードが良いコードで、これは悪いコードだということを認識しないままに進むからであると思います。

私も知らず知らず悪いコードを作成しているときがあるので、少しでも良いコードに触れていかないとならないと思いました。

ソフトウェア開発で気をつけなくてはならないこと

今日、ある動画ソフトを使用して、ファイル形式の変換や動画の編集を行いました。

そのときに、ファイルを変換するボタンがあり、そこのボタンのEnabledがTrueにならず、色々と操作してもFalseのままでした。
変換ボタンがある画面はシンプルなインターフェースで構成されているので、Enabledが変更されるような箇所はどこにもありませんでした。

結局は、設定のところで、あるソフトウェアを設定しておかないと、変換ボタンのEnabledがTrueにならないということがわかりました。そこまでの所要時間約1時間かかりました。

フリーソフトなので、特に文句も何もありませんが、これは中々気がつかないと思いました。

今回のことで、私たちソフトウェア開発にかかわるものとしては、気をつけなくてはならないと思いました。

シンプルなインターフェースを提供していても、どうしてもエンドユーザーにとってはわかりにくい場合があります。

ユーザーの心理状態によって、ソフトウェアの善し悪しがきまることもあるのではないかと感じました。

テストしにくいとは？

ソフトウェアテストにおいて、テストしにくいポイントがあると思います。

例えば、画面や帳票などのViewの部分やデータベースに格納されたデータの確認などはどうしても目視での確認になります。

上記のように、テストしにくいポイントというのは、画面の表示はそこだけに集中させるように設計し、それ意外のテストが必要となるロジックが含まれないようにする必要があります。

一つのやり方ではありますが、このようにテストしにくいポイントは、クラスやメソッドに分割することである程度解消されるのではないかと思います。

クラスやメソッドに分割することで、TDDでユニットテストを行うことで、テストしにくいポイントも効率的になり、ミスも少なくなると思います。

顧客ニーズを探るのは難しい

ソフトウェア開発だけに限ったことではありませんが、顧客ニーズというのを探るのは非常に難しいと思います。

顧客ニーズにも、顕在ニーズ・潜在ニーズとあり、特に潜在ニーズは難しいと思います。

ソフトウェア開発では特に、様々な要求保持者がいて、その人たちの顧客ニーズを合っていない過剰な機能や無駄な機能ができてしまい、使われない機能やシステムが出来上がっているのだと思います。

では、そのような顧客ニーズを探るためにはどのようにしたらいいかというと、私には正直わかりません。
巷では、マーケティング（市場調査）等をして、ニーズを探ろうとしています。
それも必要だし重要であると思いますが、何かもう少し早く探るための手段はないかと考えてみたところ、その要求保持者やそのニーズがどれくらい影響するかを実際に販売している人やサポートしている人に聞くことが一番であると思います。
ただ、一番いいのは、その要求をあげた人に聞けるのが一番だとは思います。

このブログも、沖縄旅行のことを書いたときには、アクセス数はかなりありましたが、通常の時には、あまりアクセスがありません。
顧客ニーズとあっていないことがこのようなことからも顧客のニーズがどこにあるのを探るのは難しいと思います。

C++のクラスとDelphiのクラス

C++のクラスは、Delphiのクラスと違って、動的にメモリを確保しなくても使用できることがわかりました。

どういうことかというと、

C++のクラスを使用する場合に、変数宣言すれば、クラスの中のメソッドにアクセスできるということです。

Delphiの場合には、変数宣言をして、動的にメモリを確保(MyClass :=　TMyClass.Create)としてあげなければなりません。

これはおそらく言語の仕様上、このようになっていると思います。
私としてはどちらがいいかというと、C++の仕様の方がいいのではないかと思います。
このように、言語一つとっても設計思想（ちょっと言い過ぎかも）を理解することで、その言語の作成者の意図などが明確になったりするので、やはり他の言語を学ぶことは重要であると思います。

プロ野球開幕

今日、パリーグで開幕戦がありました。
結果は、
ソフトバンク-オリックス：オリックスの勝ち（８対５）
日本ハム-ロッテ：引き分け（４対４）
西武-楽天：西武の勝ち（５対２）

でした。

ようやく、開幕を迎えて、これから10月の日本シリーズに向けて各チーム競い合っていきます。

オリックスのファンなので、なんとしてもオリックスにAクラスに入って欲しいと思います。
今日の開幕戦は勝てて良かったです。

仕様の矛盾点を見つけるためには？

ソフトウェア開発をしていると、どうしても仕様の矛盾点や不整合が生じることが多々あります。
そういった仕様の矛盾点を見つけるのは、非常に難しいと思います。

私なりに色々と考えてみて、仕様の矛盾点を見つけるコツは「気づき」であると思います。そういったことはどうしても属人化してしまいます。

その気づきを磨くために、バグりそうなパターンやソフトウェアがどのように動作しているかを調べたり・勉強したりしなくてはいけないと思います。

ただその中でもバグりそうなパターンというものはある程度、ノウハウとして蓄積されているので、そこをいかに共有していくかが、極力属人化させないための一つの手段であると考えます。

その他にも、前提として対象のソフトウェアを熟知することは言うまでもありません。

レビューは必要か？

最近、ソフトウェアテストに関する本を読み返していて、レビューに関することがソフトウェアテストの書籍に載っていることがあります。

レビューの種類も様々ありますが、本当に必要なのかと考えてみました。

新人やスキルがあまりない人にコードレビューは必要だと思いますが、ある程度スキルがある人に対してコードレビューやインスペクションをすることは必要なのかと問われると必要ないのではないかと思います。

そもそも、大量のソースコードやドキュメントを渡されて、要件自体を理解している人が行えば、効果はあるのかも知れませんが、やはり実際に作成している人が一番理解しているので、レビューをする意味がないのではないかと思います。

これを自動化できれば、効果はあると思いますが、手動で行っている以上、レビューする側・される側にとっても負担が大きいこと・無駄な投資をしていることになるのではないかと私は考えます。

他の言語から気がつくこと

最近、他の言語を勉強していて気がつくことがあります。

例えば、C言語には論理型がないや共用体があることなどDelphiを使用しているだけではわからないことなどです。ポインタの操作や使用するメリットなどです。

その他にも色々と気がつくことが多々あります。

そのようなことは1種類の言語しか知らない人にはわからないと思います。

ある程度1種類の言語を習得したら他の言語を学ぶことは重要であるなと改めて感じました。

トミカ博に行ってきました

今日、静岡で行われているトミカ博に行ってきました。

場所に行くと、クラウンの消防の車を貰うことができます。

中に入ると、思っていたよりも前回よりも人は少ない感じがしました。
前回は、ツインメッセの外で並びましたが、今日はまったく並ばないで、入場することができました。給料日前だからでしょうか？

まず、最初に緊急車両コーナーがあり、その周辺で、色々なイベントが行われています。

実写のパトカーと消防車があるので、それを見るのもいいかもしれません。

今回は、前回と違い、子供のために行ったので、視点が前と違って子供が喜びそうなところを中心に回りました。

色々な食べ物もあるので、行ってみるといいと思います。