ソースコードを日本語訳したレベルの詳細設計書ってどう？ [無断転載禁止]©2ch.net

**仕様書無しさん** · 2016/09/26(月) 22:56:23.89

これって普通なん？

**仕様書無しさん** · 2017/10/29(日) 12:13:22.80

なんだ、ただの「上司に意見しちゃう俺」アピールじゃん

**仕様書無しさん** · 2017/10/29(日) 18:53:08.50

>>616
おまえの意見は正しい
問題はこのあたり

・プログラム言語固有の識別子や型宣言、演算子
・複雑な末端アルゴリズム
・ローカル変数

このへんをクリアすれば本当に読めるはず

**KAC** · 2017/10/29(日) 20:26:44.28

>>616
それはお前が詳細設計書というものを全く理解できていないだけ。

**仕様書無しさん** · 2017/10/29(日) 20:33:14.49

>>619
詳細設計書はゴミ
こんなゴミをありがたがる連中はプログラミングを理解してない

**仕様書無しさん** · 2017/10/29(日) 20:48:28.20

詳細設計なら
変数の型を端折れるし
XXを取得するってかいたらローカル変数とGetXXで二回XXを書かないでもすむし
定数の名前とか逆に具体値とかその場で決める必要ないし
先に詳細設計書いたほうが楽じゃないの？

**仕様書無しさん** · 2017/10/29(日) 20:53:34.47

>>621
曖昧になってあっという間に破綻する
まさにゴミ

**仕様書無しさん** · 2017/10/29(日) 21:12:47.66

名前と動詞を統一しとけばそんなに破綻しないよ
経験上だけど

破綻はおもに必要な情報の不足から起こる
設計書はXXを作成するとかって結果から書いていって順々に中と必要な情報詰めていくかんじ
コード上だと最初から必要な情報洗い出されたうえで引数決めて書く必要があるから
下位でこれたりねーってなったら、上位メソッドまで全部変えなきゃいけなくなる

破綻を見つける能力はコードに劣るけど破綻を回復する能力は詳細設計のほうが全然上だ

**仕様書無しさん** · 2017/10/29(日) 21:14:12.39

おまえら簡単に破綻しすぎw

**仕様書無しさん** · 2017/10/29(日) 21:33:50.23

俺が破綻するのか

**仕様書無しさん** · 2017/10/29(日) 21:37:02.89

何が面倒って名詞に英語の名前つけるのが一番面倒
アルゴリズム考えながら全体見通して無理のない統一された英名考えるとか
俺には無理だ
外人はこんな苦労しなんだろうな

**仕様書無しさん** · 2017/10/29(日) 21:51:33.31

>>623
ほらな
やっぱりわかってない
OOPはボトムアップだよ
必要なものがなければその場で作ればいいだけ
疎結合だから他への影響も心配ない
トップダウンで機能分割していく手続き型じゃこうはいかない
一個破綻したら全部持っていかれる
そして世の中の殆どの設計書は手続き型の方法論を踏襲して書かれるものだ
だから簡単に破綻する
ゴミなんだよ

**仕様書無しさん** · 2017/10/29(日) 21:55:06.47

必要な情報が欠けてても開発を進められるのがオブジェクト指向の最大の利点
いわゆる決定の遅延って奴だな
これがあるからアジャイルが成立する

全部決めてから着手なんて頭の悪いやり方はオブジェクト指向ではやらない
そういうのはCOBOLとかでやればいい

設計書も同じこと
そういうのはCOBOLでやってくれ

**仕様書無しさん** · 2017/10/29(日) 21:55:39.82

>>627
OOPがインターフェースの情報不足をどう解決してくれるのかさっぱり見当がつかない
そもそもボトムアップでコード作れるのは先にトップダウンで設計書き下してるからこそじゃないの？

**仕様書無しさん** · 2017/10/29(日) 22:04:31.71

>>629
インターフェースが変わるなら修正すればいい
なんのためにリファクタリングツールが発展したと思ってるんだ
一度書いたら直さないなんて腐った発想が全てを台無しにする
そんなのは一筆書き戻りなしの制約をつけて巨大迷路をクリアするようなものだ

>>629
OOPでも全体を俯瞰するときにはトップダウンで考える
例えばそれはコンテキストの境界を考える場合だ
しかし手続き型のアホどものようにコード全てをトップダウンで解析するようなバカな真似はしない

**仕様書無しさん** · 2017/10/29(日) 22:13:59.08

インターフェースのリファクタって
一番自動でできないとこじゃんかー！

嫌だやっぱ先に詳細設計かく

**仕様書無しさん** · 2017/10/29(日) 22:18:01.99

>>631
アホか
お前の使ってる開発環境は静的解析もできない欠陥品かよ

**仕様書無しさん** · 2017/10/29(日) 22:24:13.57

インターフェースは実装と切り離されてるからむしろリファクタリングは非常にやりやすい
これからレガシーシステムのリファクタリングやりますってなったらまず真っ先にインターフェースで実装の結合を分離して手を出せる状態を作り出す
リファクタリングとインターフェースはサイモンとガーファンクルのデュエットのように相性バツグンなんだよ
やったことない奴には一生わからんかもしれんがそういう奴らは一生スパゲティCOBOLでも啜ってればいい

**仕様書無しさん** · 2017/10/29(日) 22:25:53.80

インターフェースの中身を挿げ替えるのはそりゃ簡単ですよ

**仕様書無しさん** · 2017/10/29(日) 22:30:09.23

>>634
インターフェースは責務が明確で余裕があるからコントラクトを変えるのも簡単
コントラクトを変えなくてもアダプティブに変更できる場合も多い
インターフェースを使わないと中身の変更も大変だし
コントラクトと中身が結合してしまうからコントラクトを変えることも難しくなる

**仕様書無しさん** · 2017/10/29(日) 22:46:58.15

コントラクトってなに

OOPに幻想もちすぎじゃないの
責務の範囲を区切ったって結局実装するメソッドは手続きの中で考えないと
責務を全うするためにいらんメソッドまでいっぱい実装する羽目になって余計工数かかるし

インターフェース自体を変えなきゃいけないってなったら影響範囲半端ないし
作り終わったあとのリファクタはやりやすいかもしれんが、
作りながら破綻がみつかりしだい改修とか作る片手間にやれるこっちゃない

OOPだと余計詳細設計重要なイメージしかないんですが

**仕様書無しさん** · 2017/10/29(日) 22:55:29.29

>>636
要するに君が下手くそなんだよ
実装が手続き汚染されるのは手続き脳から離れられないから(頭が硬い)
責務を全うするのにいらんメソッドなんかない
インターフェースがあるから影響範囲を最小化できる
ダメージが軽微なうちから修正しながら進めるから修正コストが最小化される
OOPに必要なドキュメントは詳細設計書ではなくストーリー

**仕様書無しさん** · 2017/10/29(日) 22:57:41.13

要らないメソッドってむしろ手続き型の方が多いだろ
トップダウンで分析するから細部まで手が回らず似たようなメソッドを何度も何度も作る

あっそうか手続き型の連中はメソッド書くんじゃなくてコピペするのか
そりゃメソッドが増えないわけだよ

**仕様書無しさん** · 2017/10/29(日) 23:05:23.45

全てを結合するまで破綻していたことに気が付かない
それがトップダウン手続き型の開発手法だ
ノコギリで素材を直感に頼り切り分けてそのまま雑にくっつけて家具を作るようなものだ

しっかりしたもの作るならそうじゃない
ヤスリがけなどで加工して寸法チェック強度チェックなど部品単体としての欠陥がないか確かめながら無理のないように組み上げるだろ
それがOOPによるコーディング設計術の心得な

**仕様書無しさん** · 2017/10/29(日) 23:05:28.05

なんか掛け声は威勢いいけど
言ってることに具体性なさすぎて何言ってんかわからん

**仕様書無しさん** · 2017/10/29(日) 23:07:24.37

>>640
抽象的な思考力がないのはOOPやる上で致命傷

**仕様書無しさん** · 2017/10/29(日) 23:08:36.00

酒でもくらいながら書いてんじゃないよな

**仕様書無しさん** · 2017/10/29(日) 23:31:58.27

どうせOOP言いたいだけだろ。

**仕様書無しさん** · 2017/10/29(日) 23:33:11.29

負け惜しみの捨て台詞頂いたんでここらで終了ですかね

**仕様書無しさん** · 2017/10/30(月) 08:28:43.81

>>644
おまえは二度と来るな。
ここは手続き型言語で（誤った意味での）ウォーターフォールをやるとこ限定なんだよ。

**仕様書無しさん** · 2017/10/30(月) 18:41:37.51

スレタイ通りの詳細設計は不要かな。
障害対応時の報告資料や変更点説明資料としては有りだけど。

**仕様書無しさん** · 2017/10/30(月) 21:55:28.13

雑に書いた基本設計の体裁を綺麗に整えて文章も畏まったふうにして詳細設計書とする

**仕様書無しさん** · 2017/10/31(火) 07:45:41.76

かりこまりぃ～

**仕様書無しさん** · 2017/11/02(木) 01:39:07.49

OOPは凝りだすとオーバーエンジニアリングになるきらいがあるからなぁ

**仕様書無しさん** · 2017/11/03(金) 01:29:31.10

>>623
「コード書く前に完璧なシーケンス図書いて見せるまでコード書くな」
という詳細設計って話じゃないならいいんだけどね

元請けの要求を満たすために、「本当にそうなのか」をチェックするためにコード書いて
書類書くってこともあるので、午前3時に

APIリファレンス眺めてこれでいいのかっつってテキトーな図書いても絶対そうならないんで……という奴

**仕様書無しさん** · 2017/11/03(金) 10:39:25.81

きっちりレビューした詳細設計書が降りてくるのならいいのだが、
作ったもの動かしてもらって「XXの場合の処理がおかしい」などという指摘が飛んでくるとレビュアー百回死ねと思う。

**仕様書無しさん** · 2017/11/03(金) 11:26:54.71

>>651
それは製作中に問い合わせて言質とっとかないと。

**仕様書無しさん** · 2017/11/04(土) 01:07:17.67

最初から完璧な指摘ができるレビュアーなどいない
瑕疵が発覚したあとに責任を誰になすりつけるかの問題

**仕様書無しさん** · 2017/11/06(月) 16:29:08.92

コーダー含めて関係者全員をレビューに集めて合議で決めればレビュー漏れはみんなの責任となる。
レビュー漏れで一番ひどい目に合うのはコーダーなんだけどな

**仕様書無しさん** · 2017/11/16(木) 19:45:16.19

日本語ソースコードみたいな詳細設計書はコストを増やす原因
基本設計書ともソースコードとも合ってないドキュメントは悪臭放つゴミ
効率化だのなんだののたまうならまずメンテナンスのコストを下げる努力をしろ老いぼれ脳みそ

**仕様書無しさん** · 2017/11/16(木) 21:08:57.41

>>655
お前みたいな下請けはコストのことなんて気にしなくてよろしい
ゴミを作るのにかけたコストはどうせ元請けが支払ってくれるんだから

**仕様書無しさん** · 2017/11/18(土) 13:42:35.15

>>618
よめねーよ
素人は2重ループから理解できないわ

**仕様書無しさん** · 2017/11/18(土) 19:13:30.65

>>657
2重ループ書いちゃうような素人がいきがんなよ

**仕様書無しさん** · 2017/11/19(日) 16:51:00.88

>>658
書く書かないの話はしてないってことを理解できないなら素人以下だな
日本語読めないレベル

**仕様書無しさん** · 2017/11/19(日) 19:00:46.00

>>659
読解力のない素人だなあ
あのね？キミが何を言いたいかなんて問題にしてないの？わかる？
ボクがそれなりの根拠にもとづいてキミは2重ループを書いちゃうような素人だと判断したって事よ？
日本語ってムズカシイよね素人クンw

**仕様書無しさん** · 2017/11/19(日) 19:15:44.41

わかったけど関係ないし邪魔だから帰れｗ

**仕様書無しさん** · 2017/11/19(日) 19:20:54.90

>>660
つまり「煽りたいだけ」ってことか
中身のないやつは俺にレス付けんなくず

**仕様書無しさん** · 2017/11/19(日) 20:49:32.68

設計書どうでもいいからさっさと手を動かしてコード書けよ。

**仕様書無しさん** · 2017/11/19(日) 21:36:09.13

>>662
素人認定されたから中身のない煽りって事にしたいんだろうけど
世の中そんなにキミの都合に合わせて動くわけじゃないからねえ
というかキミ只の素人というより頭の悪い素人だよね？w

**仕様書無しさん** · 2017/11/19(日) 21:40:35.24

ないようがないよう

**仕様書無しさん** · 2017/11/19(日) 21:43:38.69

こういうガイジは無視して

**仕様書無しさん** · 2017/12/29(金) 18:24:36.23

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

43A84H5OM5