ほとんどプログラムの知識がない私が自作のシストレプログラムを書き始めてかれこれ1年近くたちました、空いた時間で少しずつ書き足してきたプログラムですが、何もかもが手探りでフローチャート等はたまにしか書かず設計図の大部分は頭の中というようなものが多い状態です、、
最近それらの総ファイル数がかなり増えだんだん収集がつかなくなってきましたので、ここでプログラミングの基礎について始めて調べてみることにしました。
何も知識が無くプログラミングを始めて困っている事
主にこの2つの事です 、これらをうまくやるために異常に気力と時間を消耗するという事がわかってきました。
以下検索結果上位に表示されたページでわかりやすく簡潔に書かれた物をピックアップしました。
プログラミングの基本
初学者向け「プログラミングの心得」 (翔ソフトウェア (Sho’s) Fujiwo の日記)
良いコードとは、心得5ヶ条 [ThinkIT]
プログラミングスキルを上げるには
きれいなソースコードを書くために必要な、たったひとつの単純な事
プログラマーの開発速度は「はまる」時間の長さで決まる
プログラミング心得 – シミュレーション & ゲーム 開発
きれいなプログラムを書くには ~プログラミング基礎 -/成長ブログ@ライブレボリューション
バグの修正(デバッグ)の方法
デバッグ -フリープログラマへの道-
デバッグ – いいプログラムを書こう
今日は楽しいバグ修正の日:小野和俊のブログ
バージョン管理・その他
プロのプログラマーは専用のソフトウエアでバージョン管理をしているらしい。
バージョン管理システム – Wikipedia
[ThinkIT] 第2回:Subversionによるバージョン管理(前編) (1/3)
Eclipse 3.4でのバーション管理方法(Subversion編) ~Eclipse 3.4入門~
第9回 簡易バージョン管理システム – かんたん10分プログラミング:ITpro
Emacs
プログラミング基礎文法最速マスターまとめ – ネットサービス研究室
以上、時間が無くざっくりとではありますがこんな所でしょうか、これらのテーマは追求するとかなり奥が深そうです。w
プログラミングの基礎についてはだいたい似たような物が心得として書かれてるようです、これは1年プログラムを書いているうちに自然と身についている物もありましたが、意識してなかった物もあり勉強になりました。
バグの修正方法について書かれた記事は結構少なく専門的な物が多く初心者には難しすぎる内容の物が多いようでしたが、その中でもわかりやすくまとめられた上記の3つを読みますと、とにかく場数を踏んで経験を積むしかないのかなと思いました。
バージョン管理について書かれた記事もこれは!と思う物が見つからず残念です、、プロは専用ソフトを使って管理しているようですね、時間がありましたら手を出してみようかと思います。
-余談-
ちなみに自分のシストレ開発は新しいアイデアを思いついたら週末にまとめてコーディングそれ以外は、1日1個程度に絞って機能を修正していくというようなやり方で進めています。現状の問題点をリストアップし、それぞれがどのくらいの時間でできるかを予想しその予想時間に応じて空いている時間に割り当てて修正を行っています。平日なら15分とか30分でできそうな簡単な物を直し数時間かかりそうな物は週末へ回すと言ったような要領です。現在一個の手法の完成間際にして2週間かけても解決できないバグが発生しどうにもこうにも前に進まなくたったためこの記事を書くに至りました、、w
この記事はシストレを作らない人には全く参考にならない記事かもしれません、
シストレってどうなの?と思われている方のために自分の考えているシストレの2つの利点を最後に書いておきます、興味のある方は是非挑戦してみて下さい。
シストレの利点2つ
1.
極めて短い時間の間にかなり高度な計算をさらりと行うことが出来る。
使用するソフトと環境にもよるかと思いますが、だいたい理論値では0.25秒遅れても0.5秒と1秒以内の間に計り知れない数の計算を行うことが出来ます、とはいいましてもExcelseatのF9キーを押して答えが表示されるスピードの事ですが、気が付いたら自作しているExcelのシートが80行×Rの列までびっしり埋まっている状態です、それらの結果を統合して0.5秒の間にエントリーするかしないか、する場合はどの注文パターンにするかを判断することができます。これを自分の頭と手でやることは100%不可能ですのでこの辺はシストレで追求していく所かと考えています。
2.
その1舜のタイミングを同じクオリティーで何時間でも何日でも待ち続けることが出来る。
これも人間には出来ない技です。
-2010/10/31 追記-
本日何とかバグを消すことに成功しました、やはり基本は大事ですね。 問題は作成したコードの中にあるのではなくWindowsのシステムが絡んだ物でした、いくらコードを修正しても解決しないわけですw、しかしながら上記のリンクのプログラミングの心得などで書かれている事はヒントになりました、コードの命令をすべて最小単位にわけ1つづつ実行することによってエラーの原因が突き止められました。結果は特定のネットワーク下で実行するとエラーを起こすという意外な結果でしたが、最小単位で実行すればその分一回あたりの検証時間も早くなりますので効果的でした。
ポイントはプログラミングの心得の中に、これって当たり前じゃないかと思うような事があえて念を押して書かれている箇所ではないかと思います、読んでいる時は何でこんな事を書いてあるのだろうなと思いましたが、修正しているうちに当たり前すぎてその部分を1度も検証していない事に気が付きましたw やはりその道のプロが念を押しているところは大事ですね。
-関連記事 -
→ HPのWorkstation xw4200 2台目を購入 / システムトレードでPCは何台あると良いのか?
→ IBM IntelliStation M Pro (6225-2J7) を購入
→ HPのWorkstation xw4200を購入