プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
[的]今日の三角巾(2006-02-16)
→ [MEMO] Sun の日本語スタイルガイド sunの日本語Language Lead であるさいとうれいこ氏らによる、日本語表現についてのガイドライン。 「技術文章を書く」という場面で従うべきことが、きれいにまとまっている。いくつか抜き出してみよう—— 英数字には半角文字を使います。例外は「〜 『 』 「 」 。 、・」です。 まわりくどい言い回しや誤解を生みやすい用語は簡潔な表現になるよう工夫してください。(例)「制御を行います」⇒「制御します」 文語調は口語調に言い換えて、なるべく使わないでください。(例)「〜にて」⇒「〜で」 送り仮名は本則と、通則 7 の慣用に従います。(例)「(正)引っ越し」「(正)行なう」 カタカナ語の表記方法 …… 3文字以内のカタカナ語には語尾に長音記号を付け、4 文字以上には長音記号を付けません。合成語は各要素で考えます。(例)「(正)ユーザーインタ
『ドキュメント内のリテラルにも注意』
というように、決まった値を持つようなもの（名義尺度や順序尺度 ）である。 プログラミングでこうした値を扱う場合は、数値やコード値をそのまま（リテラル ）では記述せず、定数を定義して、それを使う。あるいは、「列挙型 」を扱える言語であれば、そちらを使う。 ソースコードが読みやすくなるのはもちろん、数字と「意味」の対応が変わった時に、定義だけを変えれば対応できるからだ。例えば、途中に新しいステータスが挿入されて後ろの数字がずれたとしても、既存のソースコードには影響しない（もちろん、挿入したステータスを使う必要がある箇所は別だし、新しいステータスの追加により「意味」が微妙に変わったりすると、修正が必要にはなるが）。 これはプログラマにとっては基本的なテクニックであり、初心者の書いたコードでもそうなっていることがほとんどだろう。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
