プログラマの雑談部屋 ★26
■ このスレッドは過去ログ倉庫に格納されています
>>322
ないですよ。
Kindleは各国の著作権やら法規制やら新しいデバイスに合わせて
常に変化していますからAPIなんて提供できないですよ！ >>323
どうしていやなの？
おれはカナダとタイで仕事したけど、外国人って平気でウソつくよ。
つか、ウソつくのも仕事のうちと思ってるから始末におえない。
正直なほうがいいなんてのは日本だけ。 >>324
そうなんだ
ブック一覧とかコレクション操作とかその程度で十分なんだけど……
ヘッドレスブラウザで頑張るしかないのかな むしろデータ引っこ抜かれるからAPIなんか触らせてやらないんだと思うぞ。 >>320
これ職場に貼り付けておきたいわ
昼食も飲みも付き合わないやつが多すぎる プログラムの授業をエロ画像クローラーの開発にすれば捗る男子高校生なら 今どきクローラーなんぞ設定ファイル書く程度の難易度やろw インターネットがこれだけ発展できたのは
エロのおかげ お？BBAの上司に叱られてちんこバッキバキスレか？ 色々な意見があるが
たった一つだけ言える真実がある
プログラマは家庭を諦めろ 詳細設計書とか言うソースの日本語訳ゴミドキュメントだけど
あった方が工数水増し出来て儲かるとかそういう実務と全く関係ない理由だったりするんだろうな
その設計書書く時間でコーディングしてたら開発要員集める必要なんて全くないよねっていう 詳細設計書ってどんなの作ってんの？
せいぜいデータの入力元と出力先、タイミングが書かれてる程度で
「ソースの日本語訳」ってどういう状態なのか想像つかん
かなり大雑把なフローチャートぐらいはついてくる時があるけどな >>343
こんなんだよ
こんなんが最初から用意されてることもあればコーディングした後ソースを元にこんな設計書を書くこともある
１．顧客データの件数分以下の処理を繰り返す
＜顧客区分がA区分の場合＞
①顧客情報登録変数の名前フィールドに顧客の名前を格納する
②顧客情報登録変数に住所フィールドに顧客の住所を格納する
＜顧客区分がB区分の場合＞
①DB検索処理を呼び出す 引数：顧客ID
２．DB更新
①DB更新処理を呼び出す
＜DBExceptionが発生した場合＞
ⅰログ出力する
ⅱ再度例外を投げる
３．ログ出力
４．TRUEを返却する ついでに関数名しか書かれてない見ても全く意味の分からないフローチャートがついてたりもする
あまりにも意味がないから無視してると存在を忘れて途中からソースとの不整合が起きたりして
もういつどこから忘れてるのかもわからないけど、どうせ誰も見ねえだろと放置
当然誰にも指摘されない
底辺の派遣常駐だがこんな世界
常駐先はNとかFとか 簡単か難しいかわかるから、
コーディングは若手とか他に割り振ったりできるじゃん。
この例えレベルのテストで工数取られるの正直めんどうだし、作文でテスト免除なら引き取ってもらえるだけ嬉しい。 なるほどね、そういう利点があるのか
穴掘って埋めてるような虚無感があったけど完全な無意味ってわけじゃないなら少しは気が楽になるな 関数の設計ならコメントかかせりゃいい
その関数を使う人向けのな
実装向けには多少の注意点だけになる
なんでも箇条書きにする奴は大抵ダメな奴 >>346
foreach (i in 顧客データ) {
if (顧客区分 == "A区分") {
顧客情報登録.名前 = 顧客の名前
顧客情報登録 = this.住所 = 顧客の住所
}
if (顧客区分 == "B区分") {
DB検索処理(顧客ID)
}
}
DB更新処理()
catch(DBException ex) {
ログ出力();
throw ex;
}
ログ出力();
return TRUE;
ループ変数使ってない
いきなり未定義の変数が登場
異なる型の変数に代入
DB検索処理の結果を捨ててる
DB更新処理のパラメータは？
tryばいけどいいの？
なにをログ出力したいの？
言語そのものが曖昧な日本語で書くからあやふや
IDEのサポートがないから矛盾だらけ
やけに手続き的だけどこれはCOBOLの設計書？
コーディングと同程度かそれ以上のタイピング量(工数倍増)
めちゃくちゃだ
酷すぎる 例えばの話に神経質になる・・・
エンジニアの悪い癖ですねぇ でもコードから逆に起こしてる仕様書ならこんなもんか
どうせいらないからやっつけるに限る >>352
これは例えばだけど実際の詳細すぎる設計書もこんなもんだよ
長いこと働いてるがこの手の形式で正確な詳細設計書なんて見たことない 設計書として書くべきことがおかしいから>>351みたいなのがでてくる >>347
仕様書がメチャクチャで非正規がどうすんだこれと言うと
こんな事も出来ないの
で、即チェンジ
で、メチャクチャなのをメチャクチャな方向で直せるアイディアマンが評価される
javaで6重ループ理解して8重ループの処理作る脳が柔軟な人みたいな 最底辺で非正規低賃金でソース書く人が
超能力で仕様を見抜かないといけない日本のIT業界。
くさってるよな システムエラーが出ても報告してこない製造者がいるんだけどどうしたらいい？
問題があれば報告したり相談するのも仕事のうちだと思うんだけど、本人は設計書通りだから問題だと思わないらしい
気が触れてるとしか思えないんだけど何か対策ってないかな？ システムエラー吐いてもOKなところいくらでもあるしな >>360
そいつアスペか反日のキチガイだろうから、
別の人に交代させたら？ 今の現場凄い嫌だわ
設計がこのくらいコーダーで考えろやみたいな感じで仕事を丸投げする上に、出来上がってきた物に文句ばっかり言ってる
完全に上下関係が出来てて、コーダーを労働力としか見てない
一緒にやるって意識がまったくなくて奴隷かよって思う
気分悪いわ コーダーがアルゴリズム考えるのかw
そりゃあ効率悪いなw >>360
仕様通りに動いてれば問題ないという認識こそグローバルスタンダード >>365
for(false){
そのくらい自分で考えろ
なんでこんな仕様にしたんだ
}
は業界のデファクトスタンダード >>366
コーダは要件定義からに決まってるだろバカか そんなん自分で考えろ
なんでこんな仕様にしたんだ
使えない派遣だチェンジ
これで成り立ってるのがIT土方業界 >>365
一切忖度するな
「こうですかね？（全く違う）」
ってメール出しまくれ >>371
堂々と聞け
ccにできるだけ偉い人付けて
メール出せ >>365
コーダーなんて奴隷だし、使い物にならなかったら切り捨てて別の入れるだけ。
奴隷かよって思う、じゃなくて奴隷だよ。何言ってんの。 >>373
コーダーのクセに何わけわからん事言ってんの？
てかなんでそんな仕様にするんだよw >>360
社内の人間なら教育
社外の人間なら作業マニュアル作って
それでも役立たずなら交換 >>375
だから聞けよ
メールで
その際にccに偉い奴付けてくだんねーことほざけないようにしろ >>378
それそれ
そーゆーくだんねー返しは許さない
回答もらえるまで自社で作業あるからねｗ（ないけど） 詳細設計書は作らなくてもいいよね（社長部長先輩同期）
って意見に必要ですって答えたら
君は詳細設計書ないとプログラム作れないの？
って言われたことあるんだけど
プロジェクトの要員に追加されたり自分が作ってないプログラムの修正やらされる事になった場合って普通はどうしたらいいの？
webサイトとかwindowsプログラムをvisualstudio使って.netで開発がメインの会社です 作業をするうえで分からないことをリーダーか分かる人に質問すればいいんじゃない 基本設計の副次資料として詳細設計があるんだから、省略しても問題ないはず。
ただ、QAとして詳細設計が欲しいとか非エンジニア用の資料として必須なら日本語で作らなきゃいけない。
・基本設計にI/Oがない
・可読性の悪いソース
・コメント、docなし
・ステップ数を圧縮する要件がある
などエンジニアに不利な話があるときだけエンジニア向けの詳細設計があればいいんじゃね。
普段から子供でもわかるような簡単で整理されたスコープの読みやすいコーディングが出来るかが技量だと思うね。 C#でいちいちコード書くやつって、ネイティブコードを直に書けない池沼だよね ここの人たちは賢すぎたりワンラインナーで書くから詳細が必要なんだよ。 大丈夫って言ったから確認しませんでした
みたいな話でしょ？
問題が起きた時に収集がつかなくなるリスクをどう捉えるか
あと作りっぱなしの売り切りなら問題ないけど、仕様変更とかあったら分析コストが実費になるリスクもあるな 正確でエレガントな詳細設計: 必要
日本で一般的な私大文系の書いた詳細設計: 足を引っ張るだけのゴミ そうやって学歴とかでマウント取り始める奴がいるから話が進まないんだよなぁ プログラマはドロップアウトしたゴミが30歳まで食いつなぐための仕事
30超えたら大体精神病んで生活保護
もしくは自殺 いまの30代は高卒も大卒も就職氷河期だったからろくな経歴積めてない。
経歴がまともな30代は貴重だから適当にちやほやして使い倒したほうがいい。 仕様がなくても忖度してコードを書くことを要求されるのが
日本のプログラマ 要求仕様書からの機能一覧の抽出ですべての勝負は決まっている 機能一覧漏れてるのにオブジェクト指向だのインターフェースだのウンコクラスだの拡張性だの汎用性だの意味ねぇんだよ
お前はすでに
死んでいるんだ
友達なーんーだー >>396
わかってねえなぁ
仕様がスカスカで間違いだらけだから変更に強いオブジェクト指向を使うんだよ
完璧な仕様書なんて存在しないって当たり前の現実を素直に受け容れろ >>397
いやいや
要件定義からやってるなら
お前が頑張れよ 偉そうな元請けのやつらにこっちの手取りを教えてやると
「え！？それだけしか貰ってないの・・・」みたいな反応して対応が優しくなるからオススメ >>400
仕様変更に強い代わりに
バグを直すのが難しくなる。 >>400
変更に強いんじゃないよ。ラッピングが得意なだけだよ。 >>396
オブジェクトができてるなら機能の追加とかすぐだろ >>401
だよなぁ
俺もCの時代から変更に弱いコードってのがわからないからいまいちピンとこないんだよな
何がいいんだろオブジェクト指向って >>360
システムエラーが出るという設計なら問題ないだろう
未定義なら例外シナリオの設計漏れだろう >>407
例えば機能追加
ドメイン内のオブジェクトが揃ってればその組み合わせで大抵実現できるだろ
まあ比較対象によるけどな
手続き型のみでもデータ構造をしっかり設計してればそんなに変わらない
けどそれってオブジェクト指向プログラミングでないだけでオブジェクト指向設計だよね >>402
バグ治すのも簡単になるよ
特定が楽になる
修正もしやすい
テストも楽ちん >>409
はぁ？
必要な機能（もちろん処理も）は変わらないはずなのにどっから湧いてくんのそれ？ そもそも大体のバグは見つけるのは難しいけど直すのは簡単だからな
オブジェクト指向関係あるんかそれ？ >>414
良いオブジェクト指向のプログラムは一つのクラスが一つの関心ごとに、
逆に一つの関心ごとが一つのクラスに紐付いてるんだよ
だからバグの症状から即座に問題の候補はあれとこれだな、それらと紐付いてるクラスはあれとこれだな
といった具合に障害点の候補がすぐに見つかる オブジェクト指向はユニットテストと相性が良い
障害データログからユニットテストを失敗させるテストケースを簡単に追加できる
テストケースを追加できれば自動的に問題点が浮かび上がり、そのテストケースを通すと自然とバグが解消される
場合によってはデバッグで障害を特定する必要すらなくなってしまう >>416-417
何言ってるのかさっぱりわからない
こんなくだらないこと
今までやってきたのか？ オブジェクト指向なんて採用したら教育コストが跳ね上がるよ！！
VBで関数使うだけで「わかりにくい！！」って怒られるし！
「全部１つに収まってるほうがわかりやすいよね」っていう業界だよ！！！ >>420
データベース系はハゲてるイメージ
ネットワーク系は長髪
プログラマは生えてるけど洗ってなくて汚い ■ このスレッドは過去ログ倉庫に格納されています
