失敗して覚える

プログラムを組むときも仕事を進める上でもそうですが、失敗やできないことがあって初めて、色々と気がついたり・調べたりして自分の知識や経験として蓄えられることがあります。

例えば、モデル部分が何度も破綻したりして、だんだんと進化していきます。
それ以外にも仕様を検討する際に、間違った部分などがあり指摘を受けた時などです。

これは人に教えてもらって、身につくものではありません。失敗して自分で考えて初めて失敗を生かすことができます。

最初から上手くいくはずがないのです。自分で考えて考えてそれでもわからないときもあります。まずは悩むことです。
そして悩んだもの以外については考えないで一点に集中すべきです。

原因を掘り下げて、自分の知識や経験を見につける癖を最初からつけておかなければならないと最近特に感じます。

プログラマとアハ！体験

ひらめき脳 (新潮新書) 茂木 健一郎 新潮社 このアイテムの詳細を見る

最近、「ひらめき脳」という本を読み始めました。その中で、アハ！体験ということが書かれておりました。

アハ！体験とは、一生懸命考え続けていると、ある瞬間にパッと「わかった」というような体験だそうです。

脳科学的には、ドーパミンが分泌されているので、脳が活性化されるようです。

これと同じような体験を芸術家や発明家になる人はこういった体験が忘れ名入れないからそのような職業についている人が多いそうです。

私も、プログラミングで色々と考えていたり、悩んでいるときに、その場では判らず、帰りの車の中でふとした瞬間にひらめくことがあります。

これは一種のアハ！体験ではないかと思います。ちなみにこのひらめきというのはリラックスした状態で起こるようです。
私にとってのリラックスは車の中ということになります。

プログラマも芸術家と同じで、どのように綺麗にソースコードを書くかは同じになります。芸術と一緒で点数をつけることができません。

私もプログラムを書いて、脳を活性化し続けなければならないと読んでいて感じました。

これはないな

今日、カタログギフトの注文をハガキで書くのは面倒だったので、ネットから注文をしました。

郵便番号を入力したらリアルタイムで住所が表示されるようになっており、おそくらAjaxではないかと思います。

カタログギフト系の注文サイトとしては、使い勝手の面などでは優れていると思います。

バグだと思いますが、住所欄に詳細な番地などを入力する際に、文字数の制限があり、すべての住所を入力することができませんでした。

ここまで出来がいいのに、こんなオチがあるんだなと思いました。すべて全角で入力しなくてはならないので、住所という非常に重要な情報が入力できないのは、システムとして致命的なバグです。

ハングアップなどと優先度は同じになります。

非常に残念であるし、非常に初歩的なミスだと感じます。

パソコン甲子園のプログラミング部門

最近、パソコン甲子園のプログラミング部門というものがあるのを知りました。

プログラミング部門の予選を通過したものが本選の問題を解くことができるというもので、内容を見たところ非常にいい問題がありました。

新人のプログラミング研修で用いてもいいような問題がありました。

基本的に扱える言語は、C言語かJavaになっています。
実際に私もJavaで2009年の予選問題を行ってみました。

内容的には、main関数内でベタで書いてもできるし、クラスを作成してからもできるし、ある程度たった人の技術を確認するためにもいいなと思いました。また、そんなに私はJavaは詳しくないので、言語仕様やあるクラスの使用方法を学ぶのにも役に立ちました。

この試みは非常にいいと思いますので、是非続けていただきたいなと思います。

クラス図は手書きがいいな

最近、あるプロジェクトで、モデル部分のアーキテクチャを考えて、最初に、概念図程度のクラス図を作成して、自分が考えているもので実現可能かどうかを検証するためにコーディングをしています。

やはり、どうしても上手くいかなくなってしまった部分があり（破綻したと叫びました）、現在は再度構成を考え直して、再検討をしている状態です。

大体、現在考え直した方式であれば、できそうだなというめどがたってきました。

最初に概念図程度のクラス図を作成するのに、手書きで書いて検証していたので、手書き部分にどこかがダメなのかを書くことで思考を整理することができました。

これが、ツールを利用して清書していたら、思考をまとめるのにもっと時間がかかっていたと思います。

やはり、誰かに見せるなどしなければ、クラス図は手書きで作成したほうが早いなと思います。

Listを教えるために必要なこと

最近、C#のListやArraryListを初心者に教える機会があり、非常に難しいと思いました。

単純にデータをListに追加するなら、Addを使えばいいと教えれば済みます。

しかし、それでは全く意味がないので、スタックとヒープの違いと、Listと配列の違いを説明しました。

どうしてもListを説明するには、スタックとヒープの違いやあわせてListでは必要ありませんが、Static領域を説明しなくてはなりません。

中々初心者に教えるのは非常に難しいことですが、教わる側からすると、このことを意識するかしないかが数年後には非常に大きな力の差になってきます。

それ以外にもたまたま書いたコードでミスがあり、それをデバッグしてもらい、スタックとヒープで、=が違いことも理解できたようだったので、ものにできつつあるのかなと思います。

テストコードとテストエンジニア

以前から、テストエンジニアがテストコードを書けるようになったほうがいいとこのブログ上で書いてきました。

実際に、私がテストエンジニアが書いたテストケースを元に、テストコードにすべて登録した場合と、テストエンジニアがテスト実施を2R行った倍の時間を比較したところ、約3時間程度短縮することが実証されました。

ただし、これには注意しなくてはならないことがあります。それは、テストコードが正しく記述されているかを必ず検証する手間があること・テストケースの全体像を把握しておかないと、重複するようなケースが発生することがあります。

上記の改善案としては、かならず、テストコードが正しいかを検証すること・全体像をまずは把握してから実装することが必要になります。

本来のテスト駆動開発とは違う意味合いで使用していますが、非常に簡単にできるので広めていこうと思います。

それ以外にもこれを実施するためにはViewの処理が正しく行われているというのが前提なので、最初にViewの確認をしておかなければなりません。

メリットとしては、テストコードを登録しておくので、テスト時間が短縮される・開発者がデグレを引き起こしたときにすぐにわかることがあります。

アーキテクチャ：Layer

アーキテクチャのパターンにLayer(レイヤ)があります。

これの典型的な例が、OSIの参照モデルがあります。
それ以外に何があるかなと考えると、入力・処理・出力のようにレイヤを分けることあるなと思います。

例えば、SNSで考えたときに、会員登録画面・会員登録処理・会員データというレイヤで分けることができます。

これは、MVCモデルでも実装できるので、アーキテクチャの基本は、MVCモデルだということが改めてわかりました。

ビジネス価値を生むために技術を磨く

いくら高いプログラミング能力があっても、それをビジネスとして生かす（顧客にとっての価値）ことができなければ、意味がありません。

非常に高いプログラミング能力を持っていて、非常に開発効率がよかったり、利用しやすかったりしてもするアーキテクチャを作成できたとしても、顧客にとって価値を生み出さなければ、まったく意味がありません。

上記のような場合には、大体は顧客価値を生んでいるとは思いますが。

極論をいうと、顧客価値を生んでいれば、コードが汚くもそのソフトウェアを利用する人にとってはどうでもいいことです。

そういったことを技術者が言ってしまうと、それはそれで問題です。

なぜなら、ソフトウェアというのは保守があります。そのためには読みやすいコードを書いたり、再利用しやすいようにしておかなければなりません。そのために、技術を磨くわけです。

つまり言いたいこととしては、プログラミング能力だけ高くてもダメですし、ビジネスのところだけ高くもダメです。ともに能力を向上させなくてはなりません。

ビジネスの価値を生むために、技術を磨いていく必要があります。

メールソフト作成中

C#で現在、メールソフトを作成しています。メールの送信に関しては、namespaceのSystem.Net.MailにMailMessageとSmtpClientを利用すれば簡単にメールを送信することができます。

今度は、受信を行うように考えましたが、TCPClientやStreamreaderなど色々とコーディングをしなくてはなりません。送信の時と比較すると、コード量が約10倍になります。

なぜ、送信は簡単に実現できるのに、受信ができないのかとちょっと考えると、送信に関しては様々なアプリケーションであります。ただ、受信に関しては特にメールソフトがあれば、問題ないので、簡単にする必要がないのではと思います。それ以外にも商品戦略上のこともありそうですが。

メールソフトを作成していると、メールサーバーやSMTPやPOPといったプロトコルも理解することができるので、勉強になります。