いきなりコードを書くな。設計してから書け。

1 ：仕様書無しさん：2015/11/27(金) 20:07:51.16 .net

っていうけどさ、そんなレベルの人が設計を書いても設計が
正しいかどうかなんて判定できないと思うんだが？

だって実装した時に書き直しが必要ない完璧な設計を作らないと
いけないわけでしょ？それって実際に実装できる力がないと無理でしょ？

初心者が設計したとしても、ダメな設計しかできず、
どっちみ書き直しが必要になると思うんだ。

745 ：仕様書無しさん：2016/01/25(月) 08:47:06.99 .net

hage

746 ：仕様書無しさん：2016/01/25(月) 17:57:33.53 .net

下流上流というか、エンジニアとプログラマで給料に差がある求人見ると何だかなぁって思うよ
建築の設計者と大工の関係のつもりなんだろうけど
あれ二級建築士の場合なら大工のほうが給料いいからな

747 ：仕様書無しさん：2016/01/25(月) 17:57:35.72 .net

おまえらはどちらのスキルもないよなw

748 ：仕様書無しさん：2016/01/25(月) 18:08:49.60 .net

No Skill, More Money

749 ：仕様書無しさん：2016/01/25(月) 19:19:19.95 .net

>>746
二級建築士レベルはエンジニアに含まないって事だろ
どっちかっつうと、求められてるのは建築士じゃなくて現場監督じゃね？

750 ：仕様書無しさん：2016/01/25(月) 20:17:23.73 .net

土建の現場監督は仕事を熟知してるから
あらゆる取り纏めと細かい指示と責任者としての責務を全うしてる

IT業界の現場監督はほぼ何の役にも立ってないうえに
指示も適当かつアバウト、そして責任は一切取らない

751 ：仕様書無しさん：2016/01/25(月) 20:23:02.50 .net

>>744
下流工程を高い水準でこなせる人間は、上流行程も問題なくこなせるよ
下流行程の経験もスキルも低い人間は、上流行程なんてできないけど
精々、客と的外れな話をして間違った伝言をする伝書鳩が良いところ

752 ：仕様書無しさん：2016/01/25(月) 23:01:58.43 .net

設計なのに関数インターフェイスから中のコードまで書かれてて
非常にコードが書き辛い。

何が辛いって、必要なパラメータが無かったり
処理順番が間違ってたり、デタラメだったり
いっそ無い方がやり易い。

753 ：仕様書無しさん：2016/01/25(月) 23:05:51.55 .net

>>752
実際に動かす所までやらないと、間違いなんてわかりませんからねぇ。
動かしていてもバグが有るというのに、
動かさないでバグがわかるわけがない。
当たり前でしょう。

754 ：仕様書無しさん：2016/01/25(月) 23:10:46.35 .net

ならば余計な手数だから設計にコードなんか載せるなやw

755 ：仕様書無しさん：2016/01/25(月) 23:16:30.09 .net

そういうまっとうな反論がまったく通じないのがSIerの恐ろしいところなんだよ。

756 ：仕様書無しさん：2016/01/25(月) 23:41:22.75 .net

それ設計ちゃう

757 ：仕様書無しさん：2016/01/25(月) 23:41:49.86 .net

設計書に書いてコード設計するのって
目の前に電卓があるのに、紙に書いて手計算してるようなもんだな

758 ：仕様書無しさん：2016/01/25(月) 23:47:04.97 .net

必要なのは、実際に動くサンプル実装。
紙やエクセルに書いても意味は無い。

759 ：仕様書無しさん：2016/01/25(月) 23:51:51.82 .net

あからさまなページ数稼ぎだな
設計書からコード取っ払ったらテンプレートしか残りませんでしたとさ

760 ：仕様書無しさん：2016/01/26(火) 00:02:30.63 .net

二度手間設計乙であります

761 ：仕様書無しさん：2016/01/26(火) 01:55:02.61 .net

>>758
動くコードはzipでくれたらええねん

762 ：仕様書無しさん：2016/01/26(火) 04:31:59.49 .net

詳細設計はコードを含めた実装そのもののことです。

763 ：仕様書無しさん：2016/01/26(火) 05:00:40.98 .net

>>762
それはプログラム設計

764 ：仕様書無しさん：2016/01/26(火) 06:55:17.27 .net

いや詳細設計だろ

765 ：仕様書無しさん：2016/01/26(火) 07:22:19.53 .net

文化の違い

766 ：仕様書無しさん：2016/01/26(火) 09:15:04.34 .net

基本設計
↓
詳細設計
↓
プログラム設計

767 ：仕様書無しさん：2016/01/26(火) 09:19:52.40 .net

まともなもの作って動かしたことあるんかね

768 ：仕様書無しさん：2016/01/26(火) 09:42:37.87 .net

見てくださいこれがSIerです。

769 ：仕様書無しさん：2016/01/26(火) 10:54:02.34 .net

設計が難しいのはわかるんだけどね
それなら周りに頼って設計レビューとかして貰ったら良いのに

770 ：仕様書無しさん：2016/01/26(火) 10:56:51.64 .net

設計という言葉で　あーだこーだ　いってるんだから
レビューとかいっても言葉で　あーだこーだ　いいあうだけで
ちゃんちゃん

771 ：仕様書無しさん：2016/01/26(火) 10:57:52.99 .net

設計はレビューじゃなくて承認しか行われてないからな。

こんなのにします、いいですね？

772 ：仕様書無しさん：2016/01/26(火) 11:00:16.89 .net

どんと節なとこにはいたくないな

773 ：仕様書無しさん：2016/01/26(火) 11:00:45.19 .net

漫画家だって設計書のネームは編集者にボロクソ言われて書き直されるらしいぞ
やっぱりそれやらなきゃだめよだめだめ

774 ：仕様書無しさん：2016/01/26(火) 11:02:51.84 .net

やることが確立されてるとこと比較しても

775 ：仕様書無しさん：2016/01/26(火) 11:06:07.12 .net

せやろか

776 ：仕様書無しさん：2016/01/26(火) 11:07:54.42 .net

ペン入れ　はじまったら、おおきな修正はできなくなるからとかでは　漫画は

777 ：仕様書無しさん：2016/01/26(火) 11:14:40.70 .net

出来るけどそれやると原稿が汚くなったりストーリーに矛盾が生じたりページが足らなくなったりする
だからネームの段階で出来るだけ修正する

778 ：仕様書無しさん：2016/01/26(火) 11:16:38.15 .net

どんぐりさんはみんなおんなじことができる前提で分業して
いきなり全部くっつけて動かそうとしてるから　DEATH魔

要求仕様の難易度にかかわらず

779 ：仕様書無しさん：2016/01/26(火) 12:27:35.69 .net

コンパイルに一日かかってた時代は机上でやってたんでないの？

780 ：仕様書無しさん：2016/01/26(火) 12:32:12.01 .net

>>776
プログラムも同じやんけ。
コーディング始めてから大っきな変更は難しいやろ？
ちっさい変更はなんぼでも出来るけどな。
大事なんは大っきな骨格やで。

781 ：仕様書無しさん：2016/01/26(火) 12:38:05.61 .net

根幹の設計見誤ったらそりゃ悲惨やで

782 ：仕様書無しさん：2016/01/26(火) 12:59:42.16 .net

元々の設計が悪くて修正が大変なことになってるのに、
その修正をやれてる俺は凄いやつって勘違いしてるのもいるよな

783 ：仕様書無しさん：2016/01/26(火) 13:16:09.76 .net

トップダウン、ボトムアップ混ぜるんではないの？設計時

784 ：仕様書無しさん：2016/01/26(火) 14:11:16.02 .net

>>780
最初に骨格を作るのはいいが、その後に中身を作ると
その骨格で問題が出てくることがあるんだよ。

つまり大きな変更をしなくてはいけない状況になることがある。

だから最初に実際に動く中身のサンプルを作って、
その骨格で問題がないことを確かめないといけない。


これをやらないから、この骨格で大丈夫かなぁ？
大丈夫であるという根拠はないけど、これでいいや。決定！
なんてことをするから、後で大きな変更もできない。
でも変更しないと骨格に収まらない。って状況になるんだよ。

骨格 → 中身 → 全体のテスト じゃなくて、
骨格 → 骨格のテスト → 中身 → 中身のテスト ってわけないといけない。

785 ：仕様書無しさん：2016/01/26(火) 14:11:41.43 .net

不幸かなプログラムは作ってみないとシステム的な不具合は客観視し辛いんだよな。
経験者が何言っても無駄で権限で強行するんだから始末が悪い。

漫画に例えるなら、編集者が持って来たポンチ絵にいきなりペン入れしちゃう感じだな。

786 ：仕様書無しさん：2016/01/26(火) 14:26:34.77 .net

おまいらって、そんなに依存度ガッチガチのコード組んでるのけ？

787 ：仕様書無しさん：2016/01/26(火) 14:53:35.45 .net

骨格ってインタフェースで作るんじゃ？

788 ：仕様書無しさん：2016/01/26(火) 19:06:09.08 .net

>>766
＞基本設計
＞↓
＞詳細設計
↓
プログラミング

もうこれでいいと思う、そのかわり、外部IF等の取り決めは詳細設計（実現・実装方式の検討）
に含めちゃう感じで。
その代わり、単体テストがやりにくいという意見は出てくると思う。俺的には単体レベルは
もはやコード書いた奴が作りながらやっとけという感じだけども。

789 ：仕様書無しさん：2016/01/26(火) 19:13:09.16 .net

>>784
全てを想定した設計なんてありえない。
自分で要件を決めれるなら話は別だけど。

できる限りのありえそうなことを想定して設計した結果、偶然的に対応できない要件はなく、上手く行ってるってだけ。

790 ：仕様書無しさん：2016/01/26(火) 19:25:15.67 .net

>>788
プログラム設計は現実的には存在しないんだが、詳細設計に追し込む馬鹿が多く困る。

詳細設計書がただのコードの日本語説明になっているひどいのもある。

こういう現場は基本設計が自体がないので、なんでこれを作らなきゃいけないのかすらどこにも書かれていない。

791 ：仕様書無しさん：2016/01/26(火) 19:56:15.37 .net

動かしてみないと判らない、ってどういう状況なの？普通はだいたい判るでしょ

792 ：仕様書無しさん：2016/01/26(火) 20:04:31.57 .net

汎用性も無く制限も無い、ってか？
気合の込もったゴミ作ってんたろなぁ

793 ：仕様書無しさん：2016/01/26(火) 20:24:02.25 .net

>>773
漫画の設計ってプロットとかだろ、あれは基本設計レベルだよ

794 ：仕様書無しさん：2016/01/26(火) 20:28:12.65 .net

正規表現は動かしてみないと想定外の動作することあるな

795 ：仕様書無しさん：2016/01/26(火) 20:35:27.15 .net

>>790
俺のプロジェクトがまさにそんなもんだね
お陰でソースを修正するたびに詳細設計書もセットで修正しなければいけなくなるという二度手間

796 ：仕様書無しさん：2016/01/26(火) 20:40:46.94 .net

詳細設計書なんて誰が見てんの？

797 ：仕様書無しさん：2016/01/26(火) 20:41:04.54 .net

動かしてみないとわからない。
ダングリングポインタの状態によって挙動が変化する仕様のアプリなのさ

798 ：仕様書無しさん：2016/01/26(火) 21:02:16.28 .net

世の中には考えながら書き下せる代物じゃないフレームワークがあってだな
大手ほどそういうのがおおい

そういうとき詳細設計の出番だ

799 ：仕様書無しさん：2016/01/26(火) 21:09:33.41 .net

上にゴミがのさばってると二度手間仕事作るからな害悪でしかない

800 ：仕様書無しさん：2016/01/26(火) 21:44:44.56 .net

下のゴミはいいのか

801 ：仕様書無しさん：2016/01/26(火) 21:49:14.08 .net

下のゴミは放置で終わりだが、上のゴミは自分達で後始末しなきゃならんし。

802 ：仕様書無しさん：2016/01/26(火) 22:03:45.83 .net

要求定義(要求仕様書の作成)
↓
基本設計(製品の概要を決める)
↓
機能設計(製品の機能を決める)
↓
構造設計(ソフトウェアの構造やインタフェースなどを決める)
↓
詳細設計(プログラムの関数の処理を決める)
↓
コーディング(プログラミング)
↓
単体試験(関数内の処理のテスト)
↓
結合試験(各関数間、各レイヤ間、各システム間のテスト)
↓
総合試験(機能仕様通りの動作を行っているかのテスト)
↓
フィールド試験(客先での試運用テスト)
↓
出荷

803 ：仕様書無しさん：2016/01/26(火) 22:21:36.46 .net

ソフトウェアでもそうだが糞みたいな間接層なんてのはいらんのだよ

804 ：仕様書無しさん：2016/01/26(火) 22:27:06.37 .net

>>800
無能な上司に無能な部下がつくと、いつまでも無能のまま変わらない

無能な上司に優秀な部下がつくと、優秀すぎて勝手に動くから
本末転倒ともいえる行動制限を付けて能力を殺しにかかる

優秀な上司に無能な部下がつくと、確実に成長する

優秀な上司に優秀な部下がつくと、各人の能力をうまく引き出して
のびのびと仕事ができるようになる

805 ：仕様書無しさん：2016/01/26(火) 22:45:48.56 .net

上流下流と上司部下の関係は微妙に違うぞ

806 ：仕様書無しさん：2016/01/26(火) 22:56:12.84 .net

その通り。上流を部下がやって、下流を上司がやってもいいわけだ。

だがそれを許さないのが日本。
上流・下流という名前が悪かったよな。
上下関係とウォーターフォールモデルが意識される。

807 ：仕様書無しさん：2016/01/26(火) 23:26:08.97 .net

会社に長年いると、あの人はきちんと設計書や仕様書を書く人、
あの人は書かずにいきなりコーディングを始めて品証部の監査時に設計書や仕様書をでっちあげる人ってのがわかってくる

808 ：仕様書無しさん：2016/01/26(火) 23:33:11.74 .net

きちんと設計書や仕様書を書くという人が、一切設計書や仕様書を
修正すること無く、コーディングを終えられるなら説得力あるけど、
実際は、クソ設計書、クソ仕様書と呼ばれるのがオチ

なぜなら、コーディングしていてもバグが有るように
設計書や仕様書にもバグはあるものだから。
ただしコーディングは動くものができるからすぐに確認して修正できるが、
設計書や仕様書は、コーディングまで終わらないと中々バグが見つからない。
所詮、頭の中の想定でしか無いからだ。

結局のところ設計書や仕様書は概要レベルで十分。
その後実装に入って、動くものを見て確認修正を行うのが一番効率がいい。

動くものもないのに、客にこれでいいですね？って見せて
お互い違うものを想像しているのに、それで同意をとって
ハンコをもらうなんて詐欺でしか無い。

809 ：仕様書無しさん：2016/01/26(火) 23:40:22.60 .net

モデルベース開発やってるところは
UMLの詳細設計とソースコードは連動してる

自動車とかの制御系だと
MATLABのSimulinkのブロック線図やStateFlowの状態遷移図と
ソースコードが連動してる

810 ：仕様書無しさん：2016/01/26(火) 23:43:04.11 .net

自動車メーカーの人が言ってたけど
エンジン制御のプログラムとかも
半分以上はMATLABで自動生成してやってるから
ソースはあまり書かないらしいな

811 ：仕様書無しさん：2016/01/26(火) 23:43:58.03 .net

> UMLの詳細設計とソースコードは連動してる
クラス定義（中身なし）だけだろ？

同じものを、テキストで楽々書くか、
マウス使ってポチポチ書くかの違い。

PlantUMLというテキストからUMLを生成する
ツール便利だよねｗ

812 ：仕様書無しさん：2016/01/26(火) 23:49:55.08 .net

図があったほうが一目で構成がわかっていいな
世の中の大半のソースコードはモジュール構造図やクラス図みたいな図化したら
とんでもないスパゲッティな構造になってあらわれる場合が多いだろうけど

813 ：仕様書無しさん：2016/01/27(水) 00:08:02.69 .net

>>812
> 図があったほうが一目で構成がわかっていいな
否定はしないがそれはコードから自動生成した方がいい。

マウスでポチポチ書くか、テキストで書くかの違い。

814 ：仕様書無しさん：2016/01/27(水) 00:12:53.46 .net

>>807
どこをどう見てわかるようになるの？
というより、それがわかると何か変わる？

時間をかけて手順通りに作業して、保守性が悪くバグのあるシステムを作る人と
書類手順を飛ばして短時間でものを作ってバグもなく保守性も高いものを作る人

品質の良し悪しと、書類などの作業手順に、それといった因果関係はないよ
つまりクソ真面目に手順を踏んでも品質向上には繋がらないってこと

815 ：仕様書無しさん：2016/01/27(水) 00:23:06.69 .net

UMLってたまに使ってる会社あるけど、見ても直感性に劣る
フローやERみたいに一目で追えるものとは違う、ずばり読みづらい

816 ：仕様書無しさん：2016/01/27(水) 00:32:33.20 .net

それお前が慣れてないだけだわ

817 ：仕様書無しさん：2016/01/27(水) 01:08:25.09 .net

UMLがいるようなシステムがそもそも少ない。

818 ：仕様書無しさん：2016/01/27(水) 01:23:16.21 .net

UMLの図の一つに状態遷移図というのがある。

システムのほぼ全てのものは何かしらの状態を持つものであるが、
その全てに状態遷移図を書くわけじゃない。
書いているところなんて無いはずだ。

つまり、明らかにわかるような所は
書く必要はないということだよ。

819 ：仕様書無しさん：2016/01/27(水) 01:26:28.36 .net

>>818
それはそうなんだが、UMLが読みづらい事の理由にはなってない

820 ：仕様書無しさん：2016/01/27(水) 01:33:14.89 .net

UMLが読みづらいというのは、何に対してか？という話だ。

同じ用途のものでUMLよりも読みやすいものが
あるというのなら、それを使えばいいだろう。
ただし自分だけじゃなくて他人も読みやすくなくてはならないがね。

もしUMLよりも読みやすいものがないならば、
それはこれ以上簡単にすることが出来ないということ。

本質的に難しいものというものは何にでもある。
だから難しいことが出来るのが技術者と呼ばれるわけで。
後は君が頑張るしか無いんだよ。

821 ：仕様書無しさん：2016/01/27(水) 01:50:26.62 .net

>>820
あぁ、お前804と808が同じ人物だと思って発言してる？
そしたら言ってる内容分かったわ

822 ：仕様書無しさん：2016/01/27(水) 01:54:46.30 .net

>>821
> あぁ、お前804と808が同じ人物だと思って発言してる？
知らん。適当にレスしてる。

823 ：仕様書無しさん：2016/01/27(水) 03:30:06.11 .net

>>822
じゃあ話になるわけないわ
めんどくせーから黙ってろ

824 ：仕様書無しさん：2016/01/27(水) 06:54:02.17 .net

>>820
読むのは開発者だけではなく客も読むし
客も含めて誰にでも受け入れられるとは限らないってことを憶えないとね
使うのは義務でもなんでもなく、選択肢の一つに過ぎないし
UML以上に解りやすい図なんて当たり前にあるしね

客がユースケースの書かれたページを開くとまず嫌さが顔に出る

UMLを使ってるところは結局のところユースケース、シーケンス、クラス位しか使ってないけど
クラス図が分かりにくい、所々親子を逆に書いてくる会社もある
それでも違和感なく読んでしまうこともあるけど
クラス図からソースを起こすとか、邪魔な拘束具にしかならん

825 ：仕様書無しさん：2016/01/27(水) 07:11:57.41 .net

真の技術力は、使い手、読み手のことをどれだけ客観的に考えて
それを形にできる力を持ってるかってことだから
受け入れられないものを使ってたって技術力とはいえない

826 ：仕様書無しさん：2016/01/27(水) 07:15:20.90 .net

UMLは読むもんじゃない、とくにクラス図

あれは自分でいっぺんざっくり書いて
ソースの全容を把握するためのもんだ

827 ：仕様書無しさん：2016/01/27(水) 07:16:51.87 .net

真の技術力は、ユーザのことをどれだけ客観的に考えて 、望むものを提供する力を持ってるかってことだから、手段は関係ない。

828 ：仕様書無しさん：2016/01/27(水) 07:25:47.63 .net

>>827
>>825と何か違うこと言ってる？

829 ：仕様書無しさん：2016/01/27(水) 07:29:35.26 .net

>>826
メモでよくね？

830 ：仕様書無しさん：2016/01/27(水) 09:26:03.96 .net

>>824
> 読むのは開発者だけではなく客も読むし
だからなんだよ？

客がプログラム一切わかりませんって言ったらどうするんだ？

831 ：仕様書無しさん：2016/01/27(水) 12:24:03.21 .net

>>817
メッセージやりとりするシステムでは状態遷移図とシーケンス図無いと無理。
他は書かなくてもなんとかなる場合が多いが。
状態遷移図は状態遷移表で代用することもあるけど。

832 ：仕様書無しさん：2016/01/27(水) 12:37:09.98 .net

>>808
ボケーっと見てるから、設計書が役に立たないんだよ。もしくはアタマが悪いか。
普通は、設計段階でシミュレーションして考慮漏れが無いかどうかチェックして
設計をブラッシュアップしていく。もちろん、設計段階で潰しておくべき不具合
が後工程で見つかることもあるけど、設計をしないのよりよほどマシ。

「実際に動かしてみないと設計のミスが見つかりません」って
「私は初心者レベルのプログラマです」って言っているようなもの。
みんな影で笑ってるから、あまり人前で言わないほうがいいよ。

833 ：仕様書無しさん：2016/01/27(水) 12:41:58.68 .net

スクリプト言語で数千行程度のプログラムだったら、いきなりコードを書き始める方が手っ取り早い

834 ：仕様書無しさん：2016/01/27(水) 12:53:05.37 .net

>>833
その通り。

火星探査機を作ってるわけじゃないんdな。
膨大な時間が無駄になるようなものじゃない。

さっさと作って動かして検証したほうが早い。
シミュレーションやる時間があればできることだ。

835 ：仕様書無しさん：2016/01/27(水) 16:18:23.78 .net

天文学的組み合わせを潰してからですか
結局

836 ：仕様書無しさん：2016/01/27(水) 17:53:29.92 .net

全部やってたら天文学的組み合わせになるものを、
どれだけコンパクトにできるかってのが実力差ってやつだよねー

837 ：仕様書無しさん：2016/01/27(水) 20:48:28.50 .net

>>832
いきなり作っても設計ミスは起きないし
設計と開発は同時進行だからね

838 ：仕様書無しさん：2016/01/27(水) 21:07:16.33 .net

会社で物買うにも稟議書が必要な様に、プログラム組むにも設計して承認取らないとダメなんだよな。
まあ、おまいらは稟議書要らない消耗品買うみたいなもんしか作って無いからいらないとか言えるんだけどな。w

839 ：仕様書無しさん：2016/01/27(水) 21:15:34.07 .net

DEATH魔でホクホクの上司さんがいっぱい？

840 ：仕様書無しさん：2016/01/27(水) 21:34:15.25 .net

>>838
「開発に必要だから作る」ではなくて
「稟議書が必要だから作る」になってるぞ

841 ：仕様書無しさん：2016/01/27(水) 21:36:51.37 .net

サラリーマンは
気楽な稼業と きたもんだ
二日酔いでも 寝ぼけていても
タイムレコーダー ガチャンと押せば
どうにか格好が つくものさ
チョッコラ チョイと
パアにはなりゃしねェ アッソレ

842 ：仕様書無しさん：2016/01/27(水) 22:36:04.69 .net

>>838
たとえがホント下手くそだな
設計書が必要な奴って、バカだから必要なんだなとつくづく思う

843 ：仕様書無しさん：2016/01/27(水) 22:37:43.60 .net

そんで、周りもみんな自分レベルの阿呆だから設計書が必要だと思い込んでる

844 ：仕様書無しさん：2016/01/27(水) 22:37:45.83 .net

ケースバイケースじゃないの？

845 ：仕様書無しさん：2016/01/27(水) 22:40:47.36 .net

だいたい設計と設計書は同時進行なのか？
清書しながら設計してたら真のアホだな