テクニカルエンジニア(データベース)平成17年度問題
会社終わりに午前問題と午後Ⅰ問題を一問ずつ解き。
休日に午後Ⅱ問題を解くということで、
なんとか平成17年度問題を解いてみた。
午前は6割程度。
午後Ⅰ問題は8割程度。
午後Ⅱは・・・orz
午後Ⅱ問題がなかなか厳しい（；´д｀）
とにかく4年分の問題を解けるだけ解いておきたいと思う。
クロスサイトスクリプティング
結構有名なクラッキングの手段。
基本中の基本などで、決して自慢げに語らないようにした方がいいと思います・・・
先週の土曜日に、大学の知人と飲んだ話を書きたいが時間がない・・・・orz
コーディング力
しまじゅんコメントサンクス
ということで、コメントをくれたしまじゅんへの返事も兼ねて今日の日記。
>ＰＧっていうとそんなに技術がなくても「そこそこ」動くものも出来てしまう
これは非常に同意できる。
そして「そこそこ」というのがポイントで、
いくつかのテスト(同値分割とか)を通ることができるプログラムというのは簡単に作れてしまう。
しかし、こういう「そこそこ」動くものというものは、
ちょっと複雑なテストデータ(限界値分析とか)を入れると計算が狂ったり表示がおかしくなったりする。
ひどいときは落ちてしまう時がある。
そして中身をみると「あぁ・・・やっぱり・・・」ということが多い。
私はコーディングする時、常に質を意識している。
量やスピードは後からついてくるものだと思っている。
品質を落とすことで、作業が手戻りしたり他人に迷惑をかけるのは私は避けたい。
そして、テスト段階で発見されるバグを直すのは、
コーディング段階で発見したバグを直すよりも数倍の労力がかかるという話もある。
人は完璧じゃないのでバグを出さないというのはありえないと思う。
しかし、重要なのは極力バグが出ないように考えながらコーディングをする、最低限のテストをする。
そして、バグが出た時に対処できるようにコーディングする。
これこそが大事だと私は思うわけです。
新人教育への要望
今日仕事中、先輩と話をしていると新人教育の話が出てきた。
自分の新人教育も担当してくれた先輩で、
何がためになったのか？何がおもしろかったのか？という内容だった。
「メーラーを作ったのが面白かった」とか
「チームに分かれて作ったのが面白かった」などを言ったのだが、
それよりも私はこれだけはやって欲しいということを提案しました。
それはコーディング規約です。(色使ってみました・・・)
頼むからコーディング規約だけは教えてください・・・orz
コーディング規約はプロジェクトによって多少違うこともありますが、
私が教えて欲しいことは基本的なことです。
・ヘッダをつける。
・マジックナンバーは極力さける。
・メソッド名、変数名はわかりやすいようにする。
これは、この一年私が同期のソースを修正していて痛感したことです。
マジックナンバーだらけのソースには本当に苦労させられました。
a = hoge[1];
b = hoge[2];
c = hoge[3];
d = hoge[4];
for(Int32 i = 0; i < 5; i++)
何をさしてるかわかりません・・・（；´д｀）
5って何を表してるの？
みたいなのです。
あと変数名も連番とかはやめて欲しいです。
a1 a2 a3 a4
とか・・・・orz
せめてそれが何を表しているのかぐらい表現してください。
趣味で作る分には全然かまわないと思うのですが、
仕事で作るソースは、他人が修正する場合もあるからです。
保守の事まで考えて作るのがプロだと思うのです。
私はまだ一年に満たない身ですが、
プロとして保守の事まで考えてプログラミングを行なっています。
心がけをするだけでも全然違うと思います。
ジム3回目
ジム3回目行ってきました。
エアバイクを20分したあと、
筋トレを3セットやってきました。
すごく上半身が疲れたのだが、
こんなに上半身が疲れたのは何年ぶりだろうか？
いかに自分が運動不足だったのかがわかったorz
とりあえず目標は週1で通うこと、がんばろう(´･∀･`)