アカウント名:
パスワード:
http://d.hatena.ne.jp/irof/20120808/p1 [hatena.ne.jp]こういう感じの日本語でコーディングしてるような仕様書って、なんの役にもたたないと思うけど膨大な工数をかけて作製してる現場あるよね。こういうのが何の役にもたたないってのが理解出来ない人がけっこう、っていうかかなりいるからせめてこういうツールで自動化する流れになってほしいわ。
ありがとう。自分の職場に不満があったんだけど、贅沢な悩みだったということを確認できた。
リンク先の話って「ifとかswitchとか英語わからんのだったら日本語でおk」「お、かしこい♡」というレベルの話ですよね。。。つらい、つらいよ。。なんだか泣けてくる。。。
>「ifとかswitchとか英語わからんのだったら日本語でおk」
昔、NHKで日本語C言語というのが紹介されていた。予約語が日本語というもので例えばif () {} else {}を条件 () 成立 {} 不成立 {}
と書きましょうというもの。開発マネジャー曰く「日本語なのでパッと見判りやすい」PG曰く「開発効率上がりました(チッ」
#Fだった気がするんだがググッても出てこない
アレを使えば仕様書要らないね(棒
富士通だったら YPS かなぁ。今は YPS/COBOL だけなのかな? YPS/C はさすがに死んだか。
#define 条件 if
「if」と2タイプで済むのに、「jouken[変換]」と7タイプも必要となって、効率低下だ。どうせコンパイルエラーが起きると、エラーメッセージは全部英語なんだろwwww
ぴゅうた?
日本語入力の手間を考えてないマネージャーって、タイピングおっそいんだろうな。PGもちゃんと声を上げろよ、「効率上げるわけないだろボケ」って英和辞書贈れ。
同意するけどおそらく見果てぬ夢に近いものがあるんじゃないかなー。でも追加記述なしに自動的に仕様書なり設計書なりとバイナリが生成されるプログラミング言語ならまだ...。# プログラミング言語の型とかによる縛りはキツ目の方がドキュメントの自動生成はやりやすそうだ。その方がコード自体も安全だし。
確かにほぼ役に立たない。
「ソースコードから自動生成できる設計書」ということは、その設計書はソースコードの持つ情報量を実質超えないわけで、余計なドキュメントが増えるだけだわな。
言語が読めない人のために自動翻訳した日本語訳をつけておく、程度の存在価値しかないドキュメントだけど、逆に言えばその程度の僅かな存在価値はあるので、こういったツールがゆくゆくはソースコードのビューワーみたいな形になると良いのだろう。
志村~、設計書設計書。
この形式の詳細設計書を作る現場に入った事がありますが、そこではステップテスト仕様書を兼ねていました。Excel方眼なのでチェックも簡単です(棒。その意味で「(3)処理を続行する」はいりませんよね。該当するステップがありませんから。
逆に自動出力すると必ずテストに成功しますw
まぁ受託出向で得体の知れない20代が集まっていたということもあって、事前レビュー繰り返して技術的なところを揃える意味もあったのでしょう。実際ここまでやっても、できない人はできませんでした。
ちなみにこの手のツールとかサービスですが、もともとの仕様や設計との差異をあぶりだしてしまうと言う意味で有用だと思います……
仕様書を書く人やレビューする人の脳内コンパイラ、脳内デバッガが優秀ならいいけどね。仕様書ってあまり細かく書きすぎると、レビューアが見付けられないバグが大量に埋め込まれる可能性があるから。コード中やテスト中に仕様書バグが発覚すると、仕様書とソースとテスト項目全部直す必要がでて、メンテが追い付かずに仕様書がすぐにゴミになりかねない。レビューア次第だけど、仕様書はもっとおおざっぱで良いと思う。特にレビューアがプログラミングを知らない人の場合は。
コードから仕様書を起こすのが困難というのは誰でも知ってるのに、こういう、コーディングに限りなく近い仕様書は仕様書として役にたたないということが理解できない人がいるのがよく分からない。
「仕様がここまでできてるなら、もう直接コーディングしたほうがいいですよ」とか言っても「手抜きするな。いきなりコーディングなんか素人のすることだ」みたいな反応になるんだよな。
はっはっは。IFとかDOとかをインデントできない言語を使ったことがないみたいですね。そういう言語で、深くネストしたIF文の意味を理解する時には、このレベルの仕様書がないと手がつけられませんよ。
そして仕様書とコードが一致してないというw# プリプロセッサを作って編集用ソースからビルド用ソースを生成したらどうだろう。
逆にソースをフォーマッタにかけてから読むという手もあるね。
どのみち書かなければならないのだから両方を相手にしたくなきゃ読むフォーマットと各フォーマットは一致してなきゃならない。となるとプリプロセッサ一択になるのよ。
処理系が出力するメッセージによってはデプロセッサみたいなのも必要になるだろうけど。# 昔マルチバイト文字をそのまま突っ込めるようにプリ/デ・プロセッサ書いたのはいい思い出w
#2371500の話はビルト用のソースが書き辛いって話だからプリプロセッサの方が良いだろうねえ。いずれにしろ、#2371500程度の目的で同じロジックを別言語(ビルト用に処理言語、設計書用に日本語)でわざわざ書く必要はないように思える。
これって「入力値を受取るのってこの言語では何て関数だったっけ?」みたいなことを調べるためにいちいち立ち止まることなく大まかな処理の流れだけ一気に考えて書き留めておきたいときに「無題. - メモ帳」に書き殴る奴じゃないの?
H系ではとっても大事ですね…。
膨大な時間を掛けて書かせるが、コードを書ける人が少ないので逆に難解になる。下から上へのリンク情報に欠け、いざ問題が起きたときに下からトレースできない。上下の文書に同じ記述ができ、どこかで細かく修正したときに、すぐに不整合が起こる。下層で多くの重複ができる。実コーディングする人も仕様や設計を知らない人が多く、単純な間違いを多数作り込む。「上」から怒られるのが怖くて、ほとんどの人が自分のことだけで頭が一杯になる。随所で独自フレームワークやツールを強制させ、効率をどんどん悪化させる。さらにそこへ「仕様変更」が絡み、コーディング/テスト期間で炎上する。
どうもこう、頭でっかちな人がスムーズに行くことだけ考えてる感じなんだよなー(うまく行かないのは全て各「担当」が悪い)。Excelだけで1万ファイルも作って、その膨大な仕様書の整合性を取るためだけに全員土日出勤なんて、他でどれだけあるのかな…。
理由というのはロジックを書けないプログラマがたくさんいる職場だから?
それも一つだろうね。元コメが役に立たないとは限らないが確実に宝の持ち腐れ。例えばExcel方眼紙は(情報を認識できないアレでも)それっぽい書類を作れる(と皆が思っちゃうくらい皆もアレ)だから絶滅しない。
# OJTって「今、目の前にあるソレに対するHowTo」しか教えないから間違いを拡大再生産するのよな。# それだけでなく間違っていることほど取り扱いに注意を要するから拡大再生産されやすいというか。
その職場に行かないと分からんだろ。顧客がそのレベルの設計書(?)を要求していて、契約に含まれてるとかそのドキュメントからなんかを自動生成してるとか。
もっと効率的に見える方法はあるが、そちらに移るコストのほうが上回ってしまいそうで動けんってのは良くあるね。上の人に「鶴の一声」を出してもらう根回しするのがベストかも。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
http://d.hatena.ne.jp/irof/20120808/p1 [hatena.ne.jp]
こういう感じの日本語でコーディングしてるような仕様書って、なんの役にもたたないと思うけど膨大な工数をかけて作製してる現場あるよね。
こういうのが何の役にもたたないってのが理解出来ない人がけっこう、っていうかかなりいるからせめてこういうツールで自動化する流れになってほしいわ。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:2)
ただ、こういう形で完全統一出来ていなくて、部分的に言語依存な書き方しているのが殆どだから役に立たないって所だね。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
ありがとう。
自分の職場に不満があったんだけど、贅沢な悩みだったということを確認できた。
リンク先の話って「ifとかswitchとか英語わからんのだったら日本語でおk」「お、かしこい♡」
というレベルの話ですよね。。。
つらい、つらいよ。。なんだか泣けてくる。。。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
>「ifとかswitchとか英語わからんのだったら日本語でおk」
昔、NHKで日本語C言語というのが紹介されていた。
予約語が日本語というもので例えば
if () {} else {}
を
条件 () 成立 {} 不成立 {}
と書きましょうというもの。
開発マネジャー曰く「日本語なのでパッと見判りやすい」
PG曰く「開発効率上がりました(チッ」
#Fだった気がするんだがググッても出てこない
アレを使えば仕様書要らないね(棒
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
富士通だったら YPS かなぁ。
今は YPS/COBOL だけなのかな? YPS/C はさすがに死んだか。
Re: (スコア:0)
#define 条件 if
「if」と2タイプで済むのに、「jouken[変換]」と7タイプも必要となって、効率低下だ。
どうせコンパイルエラーが起きると、エラーメッセージは全部英語なんだろwwww
Re: (スコア:0)
ぴゅうた?
Re: (スコア:0)
日本語入力の手間を考えてないマネージャーって、タイピングおっそいんだろうな。
PGもちゃんと声を上げろよ、「効率上げるわけないだろボケ」って英和辞書贈れ。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
同意するけどおそらく見果てぬ夢に近いものがあるんじゃないかなー。
でも追加記述なしに自動的に仕様書なり設計書なりとバイナリが生成されるプログラミング言語ならまだ...。
# プログラミング言語の型とかによる縛りはキツ目の方がドキュメントの自動生成はやりやすそうだ。その方がコード自体も安全だし。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
確かにほぼ役に立たない。
「ソースコードから自動生成できる設計書」ということは、
その設計書はソースコードの持つ情報量を実質超えないわけで、
余計なドキュメントが増えるだけだわな。
言語が読めない人のために自動翻訳した日本語訳をつけておく、
程度の存在価値しかないドキュメントだけど、
逆に言えばその程度の僅かな存在価値はあるので、
こういったツールがゆくゆくはソースコードのビューワーみたいな形になると良いのだろう。
Re: (スコア:0)
志村~、設計書設計書。
この形式の詳細設計書を作る現場に入った事がありますが、そこではステップテスト仕様書を兼ねていました。
Excel方眼なのでチェックも簡単です(棒。
その意味で「(3)処理を続行する」はいりませんよね。該当するステップがありませんから。
逆に自動出力すると必ずテストに成功しますw
まぁ受託出向で得体の知れない20代が集まっていたということもあって、事前レビュー繰り返して技術的なところを揃える意味もあったのでしょう。
実際ここまでやっても、できない人はできませんでした。
ちなみにこの手のツールとかサービスですが、もともとの仕様や設計との差異をあぶりだしてしまうと言う意味で有用だと思います……
Re: (スコア:0)
仕様書を書く人やレビューする人の脳内コンパイラ、脳内デバッガが優秀ならいいけどね。
仕様書ってあまり細かく書きすぎると、レビューアが見付けられないバグが大量に埋め込まれる可能性があるから。
コード中やテスト中に仕様書バグが発覚すると、仕様書とソースとテスト項目全部直す必要がでて、メンテが追い付かずに仕様書がすぐにゴミになりかねない。
レビューア次第だけど、仕様書はもっとおおざっぱで良いと思う。
特にレビューアがプログラミングを知らない人の場合は。
Re: (スコア:0)
コードから仕様書を起こすのが困難というのは誰でも知ってるのに、こういう、コーディングに限りなく近い仕様書は仕様書として役にたたないということが理解できない人がいるのがよく分からない。
「仕様がここまでできてるなら、もう直接コーディングしたほうがいいですよ」とか言っても「手抜きするな。いきなりコーディングなんか素人のすることだ」みたいな反応になるんだよな。
Re: (スコア:0)
はっはっは。
IFとかDOとかをインデントできない言語を使ったことがないみたいですね。
そういう言語で、深くネストしたIF文の意味を理解する時には、このレベルの仕様書がないと手がつけられませんよ。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
そして仕様書とコードが一致してないというw
# プリプロセッサを作って編集用ソースからビルド用ソースを生成したらどうだろう。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
逆にソースをフォーマッタにかけてから読むという手もあるね。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
どのみち書かなければならないのだから両方を相手にしたくなきゃ読むフォーマットと各フォーマットは一致してなきゃならない。
となるとプリプロセッサ一択になるのよ。
処理系が出力するメッセージによってはデプロセッサみたいなのも必要になるだろうけど。
# 昔マルチバイト文字をそのまま突っ込めるようにプリ/デ・プロセッサ書いたのはいい思い出w
Re: (スコア:0)
#2371500の話はビルト用のソースが書き辛いって話だからプリプロセッサの方が良いだろうねえ。
いずれにしろ、#2371500程度の目的で同じロジックを別言語(ビルト用に処理言語、設計書用に日本語)でわざわざ書く必要はないように思える。
Re: (スコア:0)
これって「入力値を受取るのってこの言語では何て関数だったっけ?」みたいなことを調べるためにいちいち立ち止まることなく大まかな処理の流れだけ一気に考えて書き留めておきたいときに「無題. - メモ帳」に書き殴る奴じゃないの?
Re: (スコア:0)
H系ではとっても大事ですね…。
膨大な時間を掛けて書かせるが、コードを書ける人が少ないので逆に難解になる。
下から上へのリンク情報に欠け、いざ問題が起きたときに下からトレースできない。
上下の文書に同じ記述ができ、どこかで細かく修正したときに、すぐに不整合が起こる。
下層で多くの重複ができる。
実コーディングする人も仕様や設計を知らない人が多く、単純な間違いを多数作り込む。
「上」から怒られるのが怖くて、ほとんどの人が自分のことだけで頭が一杯になる。
随所で独自フレームワークやツールを強制させ、効率をどんどん悪化させる。
さらにそこへ「仕様変更」が絡み、コーディング/テスト期間で炎上する。
どうもこう、頭でっかちな人がスムーズに行くことだけ考えてる感じなんだよなー(うまく行かないのは全て各「担当」が悪い)。
Excelだけで1万ファイルも作って、その膨大な仕様書の整合性を取るためだけに全員土日出勤なんて、他でどれだけあるのかな…。
Re: (スコア:0)
理由というのはロジックを書けないプログラマがたくさんいる職場だから?
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
それも一つだろうね。元コメが役に立たないとは限らないが確実に宝の持ち腐れ。
例えばExcel方眼紙は(情報を認識できないアレでも)それっぽい書類を作れる(と皆が思っちゃうくらい皆もアレ)だから絶滅しない。
# OJTって「今、目の前にあるソレに対するHowTo」しか教えないから間違いを拡大再生産するのよな。
# それだけでなく間違っていることほど取り扱いに注意を要するから拡大再生産されやすいというか。
Re: (スコア:0)
その職場に行かないと分からんだろ。
顧客がそのレベルの設計書(?)を要求していて、契約に含まれてるとか
そのドキュメントからなんかを自動生成してるとか。
もっと効率的に見える方法はあるが、そちらに移るコストのほうが上回ってしまいそうで動けん
ってのは良くあるね。上の人に「鶴の一声」を出してもらう根回しするのがベストかも。