ちょいちょい話題になっているようだったので読んだ。一見、エディタや 統合開発環境の本に見えるけど、そうじゃなくてプログラミング言語の歴 史が書かれた本。 前半はなじみ深いCやLispが例に出ることが多く、サクサク読めた。やっぱ、 CとLispはテッパンですね。 今なんとなく使っているif文や名前空間、継承などは、歴史によって磨か れ当たり前に使われていると再認識。 各章はコンパクトにまとめられているのでサクサク読めた。内容もそんな に濃くないので、GWにさっと読むのは良いかも知れない。
[2011-04-22-1] に受託開発から自サービス開発に移って、１年ちょっと過 ぎました。今さらながら気づいたことがあったので、ちょっとメモ。 受託開発は契約が無事決まるとやるべき作業や予算が決まる。どのくらい 開発リソースを使えるかが分かるので、その範囲内で新規実装やメンテナ ンスなどをする。基本的には他の案件は発生しないが、この案件は○○に 含まれるよねなどと、契約の範囲内で対応を要望されることはよくある。 プロジェクト開始時の要件定義が重要。どちらかと言うとウォーターフォー ル型開発と相性が良い。 自サービス開発はやるべき作業が決まっても、どこからも予算(お金)は降 りてこない。昨日決まったことが今日覆ったり、なくなったり、全然違う 急ぎの作業を要望されることは日常茶飯事。サービスをリリースしないと 売り上げが分からないので、極力小規模で開発することが重要。受託開発 と同様、中長期的なスケジュールは立てる必要はあるが、状況は刻々と変 わるため、よりこまめな更新が必要。アジャイル開発と相性が良いという か、それしか選択肢がない。 ※ 受託開発の時はそこそこの規模の会社(300人くらい)で、自サービス開 発は零細企業(開発者数人)なので、その辺の違いもあります。
去年の [2011-04-22-1] に組み込み系＆受託のお仕事から、Web 系＆自サー ビス提供のお仕事に転職し改めて思ったので書き留めておきます。特定の 個人を批判する記事ではないのであしからず..。 何かサービスを作るときに、中身がぐちゃぐちゃでも動くプログラムに価 値があることには全く同意します。私は０を１にするのは得意ではないの で、むしろ尊敬します。しかしそこで終わってしまってはそのサービスの 将来は暗いでしょう。 メンテナンス性の高いコードに！ サービスが安定稼働し始めたら、メンテナンス性の良いコードに変更して いく必要がありますし、新しく追加する機能も同じです。 ※ もっとも、緊急時は最小限の工数でできる変更を採用すべきですが、 あとで絶対に適切な修正に改めなければいけません。 その新しく追加する機能なんですが、私は実装して開発環境で意図通りに 動いた時がスタートラインだと思っています。 ちゃんと動いた時がスタートライン そこからバグや重複、むだなコード、むだなコメントを減らし、いかにメ ンテナンス性の良いコードにするか、集中して作り込みます。もちろんテ ストも書きます。 私はここがプログラマの腕の見せ所だと思ってますし、細かいこだわりを 入れられたり、より良いやり方で作り込めると、何度も何度もコードを読 み直してニヤニヤしてしまいます。 プログラムは仕様通りに動いて当たり前なので、プログラマとしてはメン テナス性の良さだとか、パフォーマンスだとかの付加価値を付けることが 重要です。しょうもないバグは論外です。 もうひとつ大事なのが、コミットにストーリー性を持たせることです。 コミットにストーリー性を持たせる 私は最低でもインストール前に５回は変更を見直して、「本当にこの変更 で良いのかな」「このコミットは２つに分けた方が良いな」とか「これと これは同じコミットだろう」とかやってます。Git だとこれが容易なので、 とっても便利です。最終的には２０回くらい見直していると思います。 ※ 平時はこのくらいやる習慣を付けることが重要です。ろくに確認しない ことを習慣化してはいけません。 インストール後は(当たり前ですが)、インストールした環境で正常に動作 するかをチェックします。 まあ、Jenkins で CI(継続的インテグレーション) やっているので、単体 レベルでの動作はあまり気にしなくて良いのは助かります。 まとめ 仕様通りに動くようにプログラムを作るのは、プログラマとして当然です。 コードに付加価値を付けることが、自分への付加価値に繋がると信じてい ます。 おまけ 組み込み系でも Web 系でも「品質の良いコードを書く」ことについては同 じでした。前職では数百人規模のプロジェクトに所属しており、自分要因 でシステムが止まる恐ろしさは十分すぎるほど分かっているので、その点 は良い経験でした。 Web 系だと新しいツールを使いやすかったり、テスト環境も構築しやすかっ たり、他社のプログラマーとの交流もしやすいので、プログラマーの幸福 度は高いかも？