アカウント名:
パスワード:
情報共有しない技術者だとそうなる気がします。うちの会社にもいますが自分がやってることを共有しないで、その人がいないとダメっていう仕事があったりします。その人が「この会社は俺がいないと・・・」って言ったときはあきれたものでした。しかもプログラム上のコメントも書かないし、コードも読みにくい。
そんな企業だったとしたらいざその技術者不在で別の人間が入ろうとしても難しいのかもしれませんね。
//私はいつ自分がいなくなってもいいように、//できれば自分の仕事が減らせるように//いろんな情報を共有しておいています。//新人は私が共有している情報から仕事をしているようです。
この前ペイントソフトのようなものをJavaScriptで作った。(ちょっとボカしてるよ)面白い画像処理もやるので、高速化とか結構大切だし不特定多数のユーザさんが使うものだから、なんか編集したら選択範囲のant marchの枠線がプルンと震えるとか画面のエフェクトとかもつけて楽しく作業できなきゃやだし。
って事で、業務用Webサービスのような上から下に流れる事務的な処理じゃなくてどちらかと言えば小さくて多くの部品が協業するゲーム的なコーディングとなった。コードの分かりやすさよりは、若干、実行速度に重みを置いた感じ。
ここで悩みが。こういう場合の他人が読むためのドキュメントって、読んだことが無いんよね。とりあえずUMLで表せるものはちょこちょことUML書いた。他は、どういうドキュメントを残せばいいのか知らない。ゲーム会社さんはどういうドキュメントを残してんだろ?
コード1行ずつ日本語に翻訳したドキュメントを残してもねえ・・と思うし。(某大企業さんの金勘定のサーブレットは、そういうドキュメントを残してるようだけど。 「これこれこういった場合の手数料は?」と質問したら、ドキュメントを読んでくれ、と答えが返ってくるという・・)
プログラムを作る前に考える「こういう風に作ろう、こういう機能を抽象化してこう登録して、コールバックはこう扱って、エラーはこう処理して」というのをドキュメント化するのがいいかと。コード詳細よりも概念の説明が欲しい。
もう一つは「このプログラムを理解するにはまずここを読め、動きを理解したら具体例としてここを読んで理解を深めろ」ってのが欲しいな。
コードは詳細設計として、基本設計書を作りましょ。概要、目的、環境、要件、挙動を記述して、コードが同じになるかどうかはともかく、基本設計書を見て作れば成果物の挙動は同じものが作れるっていうのを目指して記述する。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
情報共有しない技術者だと (スコア:1)
情報共有しない技術者だとそうなる気がします。
うちの会社にもいますが自分がやってることを共有しないで、その人がいないとダメっていう仕事があったりします。
その人が「この会社は俺がいないと・・・」って言ったときはあきれたものでした。
しかもプログラム上のコメントも書かないし、コードも読みにくい。
そんな企業だったとしたらいざその技術者不在で別の人間が入ろうとしても難しいのかもしれませんね。
//私はいつ自分がいなくなってもいいように、
//できれば自分の仕事が減らせるように
//いろんな情報を共有しておいています。
//新人は私が共有している情報から仕事をしているようです。
Re:情報共有しない技術者だと (スコア:2, 興味深い)
この前ペイントソフトのようなものをJavaScriptで作った。(ちょっとボカしてるよ)
面白い画像処理もやるので、高速化とか結構大切だし
不特定多数のユーザさんが使うものだから、なんか編集したら選択範囲のant marchの枠線がプルンと震えるとか
画面のエフェクトとかもつけて楽しく作業できなきゃやだし。
って事で、業務用Webサービスのような上から下に流れる事務的な処理じゃなくて
どちらかと言えば小さくて多くの部品が協業するゲーム的なコーディングとなった。
コードの分かりやすさよりは、若干、実行速度に重みを置いた感じ。
ここで悩みが。
こういう場合の他人が読むためのドキュメントって、読んだことが無いんよね。
とりあえずUMLで表せるものはちょこちょことUML書いた。
他は、どういうドキュメントを残せばいいのか知らない。
ゲーム会社さんはどういうドキュメントを残してんだろ?
コード1行ずつ日本語に翻訳したドキュメントを残してもねえ・・と思うし。
(某大企業さんの金勘定のサーブレットは、そういうドキュメントを残してるようだけど。
「これこれこういった場合の手数料は?」と質問したら、ドキュメントを読んでくれ、と答えが返ってくるという・・)
Re: (スコア:0)
プログラムを作る前に考える「こういう風に作ろう、こういう機能を抽象化してこう登録して、コールバックはこう扱って、エラーはこう処理して」というのをドキュメント化するのがいいかと。コード詳細よりも概念の説明が欲しい。
もう一つは「このプログラムを理解するにはまずここを読め、動きを理解したら具体例としてここを読んで理解を深めろ」ってのが欲しいな。
Re: (スコア:0)
コードは詳細設計として、基本設計書を作りましょ。
概要、目的、環境、要件、挙動を記述して、コードが同じになるかどうかはともかく、基本設計書を見て作れば成果物の挙動は同じものが作れるっていうのを目指して記述する。