プログラマの雑談部屋 ★9 [無断転載禁止]©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2017/07/07(金) 01:23:34.00
プログラマは
こちらで雑談してください。

ユーザ、ＳＥが馬鹿過ぎる、
上司が陰険だからもう辞めたい、
もう少しまともな仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。

※前スレ
プログラマの雑談部屋 ★8
http://medaka.2ch.net/test/read.cgi/prog/1498187067/
2017/07/20(木) 21:16:24.43
>>752
それはお前がどれくらいから考えないとコーディングできないかによるんじゃないか?
テストとか例外処理とか考えなくてもできるがそれなりに時間かかる

あと時間の問題だけじゃなく
分担することで設計で手を抜けなくなる
わかってる人が複数になる
ミスに気付きやすくなる
2017/07/20(木) 21:39:42.14
>>761
それ設計効率変わるほど大活躍するの?ｗ
設計図を書いてからモノを作ること自体に慣れてないんちゃう?
どうよ?
そういう経験もあった上でプログラミングに関しては組んだ方が速いって言ってるの?
2017/07/20(木) 21:54:23.68
>>762
あ？wbsつくったのおまえらだろが
自分でできますって言ったことができないとかさ
子供じゃないんだから
イイトコみせてよ
2017/07/20(木) 21:57:09.39
>>764
手短に絵を描いて
ポイントだけ日本語で注釈を入れる
後の細かい部分はコードの方がはるかに早い
設計書なんて細かく書けば書くほどDRY原則違反になるだけ
だから俺はコードの方が表現力が優れている部分はコードで書く
それ以外の部分では設計書(というかほぼ設計図)を残す
2017/07/20(木) 22:03:58.57
コードそのまま生成できるならメタプログラミングじゃん
2017/07/20(木) 22:04:24.44
>>766
あんまりやったことないだけで言うほど書くこと多く無いよね？
ただの食わず嫌いだろお前
2017/07/20(木) 22:22:27.93
>>768
細かく書いて失敗した経験なら昔から何度も味わってるよ
少しずつ省く部分を模索していって今に至る
概要の図と詳細のコードがベスト

思考停止してとりあえず設計書ってスタイルに疑問を持たない人は最悪だ
疑って考えて模索する人になって欲しい
つまり理系脳になってくれ
2017/07/20(木) 22:30:37.14
>>769
思考停止っていうかむしろ必要な資料なんだから
速く書く工夫でもしたらどうなの?

そんなにコード書くほうが速いって言うならdoxygenでも使ったらいいじゃん

でも俺だったらお前より速く仕上げる自信あるけどね
2017/07/20(木) 22:37:08.61
必要な資料は作りたくないです
プログラムだけ組みたいです
なんてアマチュアじゃん

一生懸命資料を書かない理由なんて探してんじゃねーよクズが
2017/07/20(木) 22:38:28.98
>>770
生成できるものは当然する
むしろ手で書いてはいけない

自信を持つことはいいこと
きっと優秀なんだろう
無駄なドキュメントに割く労力がなくなればもっと上を目指せる
まずは取り組んでみよう
それからだよ
2017/07/20(木) 22:40:25.46
手を使って考えて書かないといい設計書はできないよ
2017/07/20(木) 22:40:30.62
>>771
強い思い込みに囚われている
必要な資料が実は必要ではないかもしれない
そう考えられるようになれば一歩前進
2017/07/20(木) 22:41:25.50
>>771
下手くそな煽りだなwwwwwwwww
2017/07/20(木) 22:41:31.57
>>772
いやいや勝手に無駄って決めてんじゃねーよｗ
記述粒度もお客様と調節済みだよアホが

お前んとこみたいな
雑な業者に入られないようにしっかり書いてるんだよｗ
2017/07/20(木) 22:42:14.93
まー雇われの底辺じゃあ保守とか考えなくていいもんな
ふざけんなよ底辺
2017/07/20(木) 22:42:15.70
>>773
その通り
手を動かして絵を描こう
コードを書こう
頭の中だけで考えても限界がある
2017/07/20(木) 22:43:14.62
>>778
だからお前はdoxygenで書けばいいじゃん
2017/07/20(木) 22:43:17.48
左手の上下運動頑張るか…
2017/07/20(木) 22:47:51.91
>>776
何を持って無駄と定義するかは大きな問題だね
穴を掘って元どおり埋める作業をすれば金をやろうと雇い主が言った
雇い主との契約を満たすのは有意義な仕事だ無駄じゃないんだと自分をなんとか納得させるあなた
確かに金をもらえるけどそれはあきらかに無駄な作業だよねと考える私
物事は様々な見方があるということは今日の教訓として覚えておいて欲しい
2017/07/20(木) 22:48:22.11
>>777
ドキュメントとコードを二重管理しなければならない保守担当者の苦労も考えてください
2017/07/20(木) 22:49:11.02
>>779
そうだね
2017/07/20(木) 22:49:36.31
>>781
穴ばっか掘ってると頭おかしくなるんだな
2017/07/20(木) 22:51:04.02
>>782
じゃあexeだけでよくね?
c#なら逆アセすればいいよね?
2017/07/20(木) 22:55:10.60
>>784
人はそういった場面でおかしくなると意味のない作業に対する信仰心のような気持ちが生まれる
穴を掘って埋める作業にもなにか崇高なる意味があるのだと思うようになる
そうしないと精神が壊れてしまうからだ
そこまで追い詰められる前に冷静にこの作業には意味がないのではないかと疑問を持てるかどうかがデッドラインになる
2017/07/20(木) 22:56:52.55
>>782
それ二重管理っていわなくね？
違うものだぞ？
触る工程も違うんだし
なにいってん？
2017/07/20(木) 22:57:17.26
>>785
exeは編集するには向かない
コードは編集するのに向いている
これは重要なポイント
2017/07/20(木) 23:01:07.90
>>745
あるある
うちは遺族と山分けっぽいから良心的なのかな
過労死になったら労災もらえるように記録だけはつけとく
2017/07/20(木) 23:02:27.67
>>787
いいえ二重管理です
2017/07/20(木) 23:10:49.81
内部の変数名まで決めてくれなくていいけど
データがなかった場合どうするかとかは書いてほしい
2017/07/20(木) 23:12:09.02
つーか、大きめのアプリをドキュメント書かずに作るのって不可能だろ
2017/07/20(木) 23:14:35.33
>>790
うわあ
こういう感じなんだ
2017/07/20(木) 23:26:58.78
保守管理はgitの修正履歴で追うのが一番
ジャップは世界標準に合わせられなくて段々とガラパコスになっていくから注意しないと
2017/07/20(木) 23:30:50.15
凝り性なとこあるよね
ひたすら進捗の辻褄を合わせる係の人が10人くらいいる
2017/07/20(木) 23:33:08.90
コメントっていうアイデア自体がナンセンス
テキストしか表現媒体がなかった時代の遺物といえよう

リンクでも貼ってドキュメントに飛ぶようにしとくべきではないか
2017/07/20(木) 23:33:20.26
考えながらコーディングしたほうが速いっていうのはだいたい嘘で
今まで同じようなことをやってるから、思い出しながらコーディングしてるだけ
もちろん、その時の設計を思い出すから考えながらやってるわけじゃない

よく「まず手を動かせ」って初期に教育するけど
趣味のマイコンと混同してるよね
2017/07/20(木) 23:36:06.32
>>792
ドキュメント書いてようがコケるときはコケる
あと「ドキュメントなしで大きめのアプリを書くことは不可能ではない」を示せばいいなら「Apache」でググればいいと思う
設計書は存在しただろうか

>>769スタイルが一番妥当な気がする(自治体・大企業が相手ではない場合）
2017/07/20(木) 23:42:17.35
Apacheは技術的な根拠となるRFCがたくさんあるから
ドキュメントなしっていうのはつらいんじゃねーの
2017/07/20(木) 23:42:21.69
>>797
設計っつっても何をもって設計と呼ぶか、次第だと思う

日本語で念入りに「もしxxxがなんちゃらだったらどうこうする」か書くとか
コード書く前から念入りにシーケンス図書くとかを設計というなら
たぶんそれ机上（あるいは脳内）で実装してるのと一緒かも

依存してるライブラリのバージョン上がった時でも机上が通用するならいいんだけど
多分何かしら違うので100%の通用はしないし
2017/07/20(木) 23:44:13.61
設計図といって皆が同じような図と思い浮かぶほど
まだ枯れてないよね
設計技術や記法も
2017/07/20(木) 23:45:18.86
>>799
RFCをベタ書きしてApacheになるわけでもない気がする
どっちかってと、設計の根拠として「RFC4254を参照せよ」とか書く感じじゃね？
2017/07/20(木) 23:47:29.77
神の如きSEが書いた設計書ならともかく
大抵はあっても無くても一緒か
却って害をなすゴミだし
2017/07/20(木) 23:48:56.54
まあ俺はドキュメント無しでできることなんてたかが知れてると思ってるから
お前ら雑魚は一生自分の知ってる環境だけで頑張ってればいいよ
実際それで足りるときもあるしね
2017/07/20(木) 23:50:21.95
新規ならともかく改修や他システム連動するときに
ドキュメントがないと困る
2017/07/20(木) 23:51:33.65
>>765
何も情報出さないで、とりあえずでいいから線引いてみてって言ったんだろ?
それ以前に前工程のが終わってないのにブロックされてる次工程が始まるわけないだろ
さっさと直してこい
2017/07/20(木) 23:55:18.56
>>732
もっとエクストリームな奴あるぞ

お客さんは基幹系を作り直し中
で、作り直し中の基幹系DBを流用してフロントのアプリ書いてください、というもの
流用したらコスト浮きますよね、とのこと
ボクは反対致しましたが営業の上司に怒られました

ER図の変更と、仕様変更と、要件変更がドカっと来たり来なかったり
大体毎日何かしら書き換えかなぁ
2017/07/20(木) 23:55:30.14
全体のバランスや結合度を調整するときもソースコードでするの?
依存関係や循環参照ってコードで見える?
2017/07/20(木) 23:57:28.46
>>808
ごめん、逆に聞くが、できんのか？
2017/07/20(木) 23:58:10.87
>>808
今どきはIDEが指摘してくれる
2017/07/21(金) 00:01:00.37
政治的っていうかさ
社内の偉い人向けの報告資料づくりとかそのための辻褄合わせ、嘘とかさ

意味ある？ジャップ？
2017/07/21(金) 00:01:45.95
今後は中国企業が成長して日本のITはますます衰退する
2017/07/21(金) 00:06:23.46
>>809
>>810
そういう局所的なものでなくて全体的な流れ
小規模とか作って終わりならどうでもいいけど
長期的にメンテとかするんだと必要
2017/07/21(金) 00:06:39.98
誰も動くもの作ってないのに
何故今月中に完了すると思うのか
2017/07/21(金) 00:15:26.70
>>813
何を言いたいのかよくわからない
クラス図的な意味だろうか？　それともDFD？

例えばドキュメントとソースに相違があるならソースからリバースするしかない場合はある

単なるポンチ絵レベルで循環参照とか言ってるなら、多分あんまり意味ないんじゃねえかなぁ
例えばUMLモドキのクラス図モドキ風の絵で「顧客」クラスが「会計」クラスに「決算情報を問い合わせる」
……みたいなやつ

もうすこし詳細なクラス図であっても、あんまりあてにならない場合がよくある

いやそっちが厳密にプロジェクトやっててそんなことないって話なのかも知らんけど
こっちは「あなたはそう仰るけど、こっちが放り込まれた案件ではそんなこたぁなかった」という経験の話も含むから
平行線になりえるのは注意
2017/07/21(金) 00:23:00.73
現実と理想に相違がある場合に「理想（ドキュメント）が正しいんです！」なんて言われても
現実（ソース）を洗ってみなきゃ話にならない状況はまれによくあるって感じ
2017/07/21(金) 00:29:28.57
プロジェクト新入りに説明できるような資料はほしいよな
てか今なくて困ってるんだが
2017/07/21(金) 00:30:42.25
普通にどういう構造しててどう作ったんだよ
作ったものは要求仕様を満たしているの?

ってことを説明する必要があるわけだが
2017/07/21(金) 00:31:37.55
>>813
具体的に
2017/07/21(金) 00:31:41.78
ソース見ろって言ってるわけ?
マジキチだろ
2017/07/21(金) 00:34:28.30
>>818
どのみち、客はあなたがおっしゃった要求仕様を満たしているかどうかなんて興味ないよ
客自身のビジネスで使えるかどうかに興味がある

……後半でなんじゃこりゃあラッシュになるのは避けたいねお互い
2017/07/21(金) 00:35:32.31
そもそも通信相手のアプリの方はどういう設定でどう動いてるわけ?
通信相手って複数いるみたいだけどそれって誰と誰でどういうやり取りしてんの?
ってとこまでやっぱソースみんの?

マジキチだろ
2017/07/21(金) 00:36:12.11
>>821
マジキチだろ
2017/07/21(金) 00:39:31.29
>>822
ごめん、どの業界の話してるんだ？

「おそらく相手は業務系の話だろう」と仮定してレスってたんだが
パケットのナカミみたいな話を設計と言ってるな必要だろうね、くらい
2017/07/21(金) 00:43:18.92
要件が固定的なら設計するのがベターだが
要件がゆるふわなら都度おっつけでないと時間がいくらあっても足りない（こっちの話で、設計重視派の人だろうと俺は仮定した）

このくらいだが、全部設計カッチリやるべき主義者なら頑張ってくれとしか言いようがないスな
2017/07/21(金) 00:55:32.94
昔ながらのCOBOL的なプログラミングスタイルでやってるとコードのもつ記述力を過小評価してしまう
彼らの世界観では日本語の説明より明確で簡素な記述がコードで実現できるとは全く想像もつかないんだろうな
2017/07/21(金) 01:01:24.32
「正しい仕様か？欲しけりゃくれてやる、探せ！このプロジェクトの全てをそこにおいてきた！」
男達は納期を目指し、数ギガのソ−スを追い続ける。世は正に大IT時代！
2017/07/21(金) 01:02:11.25
休みたい休みたい休みたい休みたい休みたい
あああああああああああああああああああああああああ
あああああああああああああああああああああああああ
あああああああああああああああああああああああああああ
2017/07/21(金) 01:04:45.42
>>827
ソースでそれだけあるとドキュメントはさらに酷いことになる
大航海どころか惑星探査するようなもんだ
2017/07/21(金) 01:05:26.98
永眠したい
2017/07/21(金) 01:22:10.75
スクリーンショットだらけの環境構築手順書.xlsに何日も悩まされたことがある
別の同程度の規模の案件では構成管理をプロビジョナーで行なっていた
設定ファイルを読んで構成を把握して自社ネットワークに合わせてインベントリを修正して実行して全部で二時間もかからなかった
ドキュメントとは一体なんだったんだろう
2017/07/21(金) 01:29:07.44
>>825
それって開発側が
あんたの欲しいアプリってこれじゃない？
って示せないからでしょ？
お前の提案がイマイチだからだよ

例えばやたら外観ばっかり気にしてる客とか相手だと
もうデザインと機能を完全にブチ切って
ウチの部署は機能だけ作りますわ
デザインはweb製作部があるんで別途発注してください
って提案するのだって能力なのよ
プログラマだからってプログラムしか組めない奴に価値は無いよ
2017/07/21(金) 01:30:06.78
>>831
でも無い方が良かったってエピソードじゃないみたいだからよくわからないよ
2017/07/21(金) 01:41:46.98
>>832
営業支援システムで「客の購買履歴から、次にどんな商品提案したら売れるかを予想する機能は必要ですか？（多変量解析）」と言って
「いらん」との客の返答があったので考慮せずそれっぽい図でも書いてたら
後日「やっぱいるから付けて」とか

そういうところまで織り込んだ設計を事前に提案せいってなら、提案が甘いのかもしれんが
相手がNOといった機能をあえて実装するわけにもいかんしな

という状況もある
相手だって全部わかってるわけじゃないんだから、要件は細かく切って都度おっつけのほうがマシだと思ってる
2017/07/21(金) 01:43:58.90
>>834
違うよ
現行業務フローが把握できてないから
客が迷っちゃうんだよ
それにいるかいらないかまで出てるなら見積り出してあるだろ
いつ追加されてもいいだろそんなもん
2017/07/21(金) 01:47:52.42
>>835
リコメンドエンジン付けるのに業務フローもクソもねぇYO

フローは何ら変わらない、ただどこぞのグループウェアのカレンダー見て「xxx株式会社訪問」とあらば
その会社では次何売ればいいか（統計的に）売りやすいかってのを分析したメールを営業にぶっこむだけだ
2017/07/21(金) 01:52:52.54
>>836
違うな
浅いよ
アプリをどういうフローで使用するかの洗い出しが浅いっつってんの

このアプリはこうやって使用する
→だからこの機能がいる、いらない

こういうストーリーが客に対して描けないから必要ないものを自分が把握してない経緯でねじ込まれたりするの

機能がねじ込まれたりするときに客がどう考えたのか全くわからずにただボケっとしてんだろお前
2017/07/21(金) 02:04:53.96
生き字引みたいにずっとその製造物に1人で携わるつもりとか、作ってはいさようならとかなら
資料なんてほとんど何もいらんだろうな。 だけど実際は、ちょっとこのプロジェクトやばいから
手伝ってとか連れてこられて、資料何もないけどソースから読み取れるから読み取って
頑張ってねとか言われたら、普通に死ねとか思うよな。
2017/07/21(金) 02:06:08.42
>>837
> アプリをどういうフローで使用するかの洗い出しが浅いっつってんの
> このアプリはこうやって使用する
> →だからこの機能がいる、いらない

説明はしたものの
「特定の企業向けに売れそうな商品をリコメンドをメールで送信」機能いるかってのを説明して、当初は不要
後日、いらないというのが社内の事情でいることになったから
追加の予算と納期延長請求ですわな
あとは「そこをなんとか」のあの面倒な話

っていうかなんであなたそんなに「自称俺なんでも知ってる君」なん？　要件変更一回も受けたことないの？
2017/07/21(金) 02:08:31.32
昔覚えた人給だの生産管理だののアプリを別企業でやりなおしてるんじゃないか……？
という疑惑

その場合だいたい同じ提案で済むやろしね、お気楽な仕事でしょう
2017/07/21(金) 02:31:59.57
>>815
ああ頭がフローチャートなんだな
2017/07/21(金) 03:50:29.59
要件変更されるのはそのプログラマが無能だからだという
主張は初めて見た。
843仕様書無しさん
垢版 |
2017/07/21(金) 06:12:44.39
>>842
違うよ無能なのはコーダーだってば
2017/07/21(金) 06:24:51.77
>>838
容易に情報を読み取れない下手くそなコード
概要を掴むためのドキュメントがない
そのプロジェクトの失敗原因

概要を把握しやすい図が多いドキュメント
整理されて読みやすいコード
この2つが前提にあってこそ(詳細な)ドキュメントなんて要らないよと言える

ドキュメントなんかいらんと言う時は必ずそう説明するんだが
ドキュメント推進派は決まってこれを曲解して(あるいは無視して)
ドキュメントは全くのゼロでコードは可読性のかけらもないスパゲティという前提で話を進めたがる

それはアンフェアな議論だ
2017/07/21(金) 06:31:09.59
>>844
結局ドキュメントがいるって話だろ。
ドキュメントが前提にあってドキュメントがいらねとか意味分からねえからw

基本設計書があれば詳細設計書は不要とかならまた言ってることは分からなくはないが。
2017/07/21(金) 06:40:07.71
>>845
ほらまさにこう言うタイプね
ドキュメント推進派って文書をありがたがる割りにレスを読まないよね
2017/07/21(金) 06:51:44.49
>>846
いやお前の言ってることさっぱりわからん
論点が吹っ飛んでるじゃん
お前はドキュメントいるんだよな？
2017/07/21(金) 06:55:01.57
>>839
金払わないって話はなんかちがくね?
849仕様書無しさん
垢版 |
2017/07/21(金) 08:05:00.50
【期日強要】実態派遣SEは捨てられる【指示強要】

人月１００万円以下で作ってはならない理由

・料金搾取の業界損害がある
・偽装請負多重派遣の業界損害がある
・将来リストラ問題の業界損害がある
・契約外期限遵守の業界損害がある
・客先指示遵守の業界損害がある
・知的財産譲渡の業界損害がある
・時間外労働違反の業界損害がある
・低予備工数見積の業界損害がある
・残業見積の業界損害がある
・無料追加の業界損害がある
・学習不足の業界損害がある
・裁判苦手の業界損害がある
・対人障害の業界損害がある
・健康障害の業界損害がある
・使い捨ての業界損害がある
・孤独死の業界損害がある
・低収入の業界損害がある
・低技術の業界損害がある
・結婚障害の業界損害がある
・鬱病早死多数の業界損害がある
・孤独死多数の業界損害がある
・技術裁判困難の業界損害がある

派遣社員は使い捨てという厳しい現実
https://xn--t8jud0j6au6x3bvde6876eixa.biz/tsukaisute/
2017/07/21(金) 11:09:19.97
>>845
理解力ゼロｗｗｗ
2017/07/21(金) 11:25:30.95
ドキュメント書くのって面倒臭くね？
俺作文は苦手
2017/07/21(金) 11:27:58.16
このスレ、PG言語どころか日本語出来ない奴しかおらんな
2017/07/21(金) 12:29:53.13
底辺の吹き溜まりだからな
2017/07/21(金) 12:30:53.41
日本語は曖昧でわかりにくい
コードの方が正確でわかりやすい
2017/07/21(金) 12:32:35.45
このスレというかこの業界だな
中国人韓国人の方が日本語が達者
ゆとり世代は特にひどい
2017/07/21(金) 12:46:39.24
英語>韓国語>日本語 の潤に論理性高い
2017/07/21(金) 13:41:02.58
God Fucking Damn It!!!
858仕様書無しさん
垢版 |
2017/07/21(金) 14:28:06.71
>>856
エアプ
韓国語と日本語は文法同じなんですが、そもそも論理性の根拠なんですか
2017/07/21(金) 14:50:21.01
「ウチの会社は仕様書作らないけど、いい？」

と面接の時に言ってくる会社は、プロジェクト中で
コロコロ仕様を変えたり言ってることが変わったりして、
「前は○○って言ってましたよね」と聞くと

「そんなことない！最初からそう言ってた！お前が勘違いしただけ！」

と強弁する連中が多い。仕様書がないからやりたい放題。
2017/07/21(金) 16:24:04.09
最近うちのプロジェクトに入ったメンバーがちょっと使えない感じの人で困ってる

テストが甘くて、○○が設計書通りに動作していないって指摘をしても、○○は△△をベースに作っています。○○は△△と同じように動作しているので問題ありません。とか意味不明な事を言ってくる。

いやいや、設計書きちんと読んでよ

あと、最近多いのは○○を△△と同じように組み込んだんですけど、動きません。何が悪いんですか？って原因調査を丸投げしてくる

仕方がないから毎回こっちで原因調査をして解決方法(大体移植する時に何かしらミスってて設計のミスとかじゃない)を伝えてるんだけど、そんなだから毎回詰まるとこっちに丸投げしてくるようになってて困ってる

どうしたらいいのか教えて
2017/07/21(金) 16:30:16.82
始めまして、プログラマーの皆さん

再来週、社員旅行に出かけるのですが、私だけガラケーでラインできなくて困ってます。
PC版のラインが来たらヤフーメールなどで、ガラケーにメールを送る事は可能でしょうか？

浪費家でガンダムのプラモデルを毎回、買ってしまいます。
貯金が無いので、何とか成りませんか？
できれば、そう言ったサービスなどを教えて下さい。
2017/07/21(金) 16:49:09.37
>>860
作業の精度がわからないんだな
俺も経験ある
他の資料がグダグダなのに
設計書だけキチンと守れってあまりにも精度が違い過ぎて何言ってるのかわからない
○○は△△をベースにってのは作業を指示した時に△△を参考にって説明しちゃったんじゃない?
となると△△の動作を優先させるのか設計書を優先させる現場なのかわからない
そもそもその設計書があるべき姿の最終形態って説明してないだろ
口頭の指示は○○は△△をベースにってしただけなんちゃう?

んで○○を△△のように組んだんだけどってのはまず設計書通りに組むって意思疎通ができてないよね
あくまで指示は○○は△△をベースにってのが彼の中で優先されちゃってそれが設計書のどの部分なのかマッチしてない
っていうか作業自体は設計書通りに組めばできるの?
おそらくできないから○○は△△をベースにって説明が入っちゃったんだろ?
2017/07/21(金) 16:56:17.25
んでそういう説明があったとした上で
動かないよっていうのは
設計書通りにやれば動くっていう頭が彼には認識が無いと思われるので
お前の言うとおりにやってみたけど動かないよ
他に何か足りないとこある?
って質問だと思う

指示が曖昧なのが伝わってくる

○○は△△をベースに組んでね
設計書通りに組んでね

の２つの指示が俺にはどのように消化して組んだらいいのかわからない
んで仮にそのどちらかの方法でできない場合はソースの一斉解析をする前にまず担当者にどのような作業をやってほしいのか確認に行くと思う

んでイマココ
だったんじゃん?
実際どうなの?
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況