日々の暑さに滅入りつつ、
駅から微妙に上り坂徒歩15分の職場に憎しみを覚えつつ、
毎朝死にかけながら職場へ向かう葉月の月影です。
こんばんは。
美容院へ行くかどうかとかいいながら、
結局セルフカットセットで済ませてしまった自分の心の弱さも、
この暑さと湿気で磨きがかかった感じです。
ええと。
とりあえず、今の仕事の契約は今月で切れます。
ということは、次の仕事を探さないといけないわけですが。
そろそろ同じ仕事にも飽和してくる頃でもあるので、
正直、ちょうど良い頃に契約切れだなぁ…、
なんて思ってたりするのですけどね。
仕事自体は、いろいろ面白い技術に触れることが出来て、
かなり自分の知識の糧にはなった感じ。
職場の人間関係もそれほど悪くもなく、
PLさんはワンマンぽいけど、仕事でなければ普通に話せる人（多分）なので、
少なくとも社員だった頃よりは良い仕事ができたと思ってます。
良い仕事、というか、実りある仕事、というべきか。
やり方は結構そのPLの人のやり方にはめこまれている感じだけど、
そういうやり方もあるんだなぁ、という勉強にはなるわけですな。
とりあえず、
契約を終えるにあたって感想を。
仕事内容は、結構面白いと思えた部類。
Web上でDirectXを使って動画や音声を再生するという
いわゆるマルチメディアオーサリングシステム（？）の開発なので、
グラフィック系の処理や音声の処理など、
今まで扱ったことのない技術や知識ばかりで新鮮だったし、
この知識は今後もいろいろ役に立ちそうです。
あと、DBもSocket（通信）もないシステム開発は自分史上初かも。
職場の状態や雰囲気は、多分標準的？
環境は、ほぼM社時代と変わらない感じ。
某S社系プロバイダの開発部門なので、
基本S社の潮流を汲んでいる会社なのでしょう。
ただ、拘束時間が朝10時から夜8時というのが、ちと長いと思う。
まぁ、その分月額も出ているのでしょうけど。
やっぱりフリーになったんだから、
もうちょっと自由度は欲しいかなぁ、みたいな。
人間関係は、それなりに良好。
PLの彼が、ちょっと我の強いところがあって付き合いにくいが、
他の同僚はほぼ同年代で話しやすく、基本的に気さく。
特筆すべきは、ゲーム系の人（？）が多いな、と。
CGとかやる仕事だと、それ系の人が集まるのかな。
その他、気になったこと、気づいたこと。
私は、確かプログラマとして雇われたと思ったのだけど、
ドキュメント整理なんかの雑用も結構やったな。
あと、最近は納期も近いこともあって、テスタっぽいことも。
今日なんかテストシナリオつくってたし。
あと、この職場（というかPLの彼の？）文化では、
古いソースコードをコメントアウトするという習慣がないらしい。
私のコーディング文化では、
コードを修正するときは、古いコードはコメントアウトして、
その日付と修正理由なんかをコメントで書き残すのだけど、
彼らは、もうバッサリ削除してしまう。Deleteですよ。
その形跡（コメント）すら残さない。漢！
バージョン管理はSVN（CVS）に一任ってやつなのか。
世の中の文化はどうなんでしょう、コレ。
総評として、まぁまぁかなーと。
理想してたのとはちょっと違うけど、社員時代よりは大分良いってとこですか。
さて。
次の仕事ですが、今の委託会社の営業さんから、
既に次の仕事の依頼がきてたりします。
しかも、明日面接だって。はや。
IR情報システムとだけ聞いてるけど、詳しいことはまだよくわからん。
まぁ、とりあえず、
その職場が駅から近いことを祈ることにしますヨ。。。
コメント
どうもです。
古典的な開発現場だとコードに修正履歴を残すと思いますが、CVS やらのバージョン管理を使っているのであれば、簡単に変更履歴が見れるわけですから、明らかな単純ミスなども全て残していくと、逆に二重管理になって首を絞めることになりませんか？
修正履歴をコード自体に残すと、コードの見通しが、変更する度に悪くなり、処理の意図が解りにくくなるデメリットがあります。
メリットの修正履歴が解るというのは、CVS 等で実現できるので、個人的に修正履歴等は余程、今後コードを触る人への警告文を含める以外は不要と考えます。
もちろん、慣れもあると思うのですが、もし、寄せ集めのメンバーで保守をしなければならない状況を考えると、修正履歴だらけのコードに手を加えるのは、工数が高くなるハズです。
常にシンプルな方が結果、生産性が良くなりますよ。
でわでわ
ナルホド。
私の文化はVSSとかCVSとか以前の時代の古いやり方なのでしょうね。
開発時はコードばっさり書き換えた方がいいと思いますが、結合試験後か本番リリース以降は、
修正履歴をコードに残していて欲しいなと自分は思っています。
開発～結合試験の間は、工数削減を優先したいし、その後、保守ドキュメントとして、
詳細設計書をプログラム説明書として整備することが多いので、それまでに起きた
仕様変更等は、反映できるけど、いったん保守に入ってしまうと、開発時のような
管理の徹底がなくなってしまいがちになるので、運用開始後に発生したことというのが、
なかなかドキュメントに残らないことが多いです。
それに、システムが長生きして５年１０年経つと開発に関わった人は、そこで保守を
していないから、プログラムがこうなっていることの背景がなかなか捉えられなくなるし、
保守してる会社が変わってしまうとCVS等の環境は納品物件ではないから、
それまでの変更履歴は引き取った側からはまったくわからなくなってしまう。
なんでこうなってるかは、結局ユーザ側もよくわかってないので、知っても知らなくても
一緒という意見もあるけど、リプレイスになったとき等にドキュメントもメンテされてない
最悪な状態の時、ソースに残っているとやっぱり助かる。
（リプレイスや保守会社を変えるときは、もう最悪の状態ということが多かったりしますから）
長くなりました。すみません。
私自身、結構古い資産に出会うことが多々あって、そういうソースコードって大抵コメントが残っていなかったりしました。コードにコメントを書くという習慣がなかった時代なのかなと勝手に理解してましたが。
そういうのに閉口してた背景もあって、少なくとも自分のコードは、どういう理由でその修正を入れたのか、というコメントを（忘れない意味でも）必ず書くようにしてるんですよね。
これは、納品前後関係なく、です（笑）
むしろ開発中のコードだからこそ、やっぱり前の仕様に戻して、とか、こういう仕様になるかもしれないけど今は実装しないで、とか結構あって、そういうときに、直した（直すべき）箇所が一発で分かるようなコメントがあると、サクッと書き換えられたりするので、これが私の常套手段というか、コーディング手法になってました。
SVNやCVSなら、リビジョン戻したりブランチしたりすれば良い話なんでしょうけどね。なかなかそういうのが有効活用できないのも現実でして。流行に従って使いこなしたいとは思ってるんですけどね…。
あと、ソース=ドキュメントというケースも、確かに少なく無いですね（メンテされてないドキュメントは、飾り以下デス）。