プログラマの雑談部屋 ★41
■ このスレッドは過去ログ倉庫に格納されています
>>590
いやいや、コードだと、今コード書いているクラスについでにこの機能も書いちゃえ的な思い付くままがあるから、たちが悪い。 >>588
例えば
ドメインレイヤに侵食してきたデータアクセス処理をリファクタリングで隔離しデータアクセスレイヤに閉じ込めるといった作業でもリファクタリングが活躍します
これはアーキテクチャのないシステムにアーキテクチャを導入するという基本設計の大きな変更にすらリファクタリングで対応可能ということです >>593
最初はそれでかまいません
まずは動作するコードをテストで保護してリファクタリングで責務を分割してみましょう
これは設計書ではとても難しい作業になりますがコードなら実に容易です 機能追加してって言われた仕様書みても、元のコード見ても全然理解出来ないし頭に入ってこない
新人だから自分ができないのはわかるけどここまで要求に応えられないと仕事嫌になってきて転職とか考え始めた
あと素人目で見てもひどいコードなのにこれでゴーサイン出てるあたり、コードの品質とか全く見ない会社なんだなって いや、設計は最初に役割の洗い出しと分割からやるから。 >>595
おめーみたいな新人に教えるノリで中堅に最初はそれでも構いませんとかリアルでも言ってたら、ボコボコに殴られるぞw >>597
それもコーディングで行います
役割の洗い出しと分割とはつまりインターフェースやクラスの列挙のことです >>598
モダンなエコシステムを学んでいるグループに設計書信者を装って参加したことがあります
逆にボコボコに叩かれまてしまいました
スキルアップの意識が高く勉強熱心な人たちはどうやらわかっているようですね 個人で作るなら全部リファクタリングで改善してけばいいよ。
何社も参加してる大規模プロジェクトで手直しなんか指示してたら、担当外されるわ。 最初は動くだけのコードを書くだけでいいんです
テストで保護してリファクタリングすれば動く綺麗なコードになるからです
もちろん最初から動く綺麗なコードを書いても構いませんがそれは難しいですよね
それと同じかもっと難しいのが最初から動く保証があり綺麗な設計書を書くことです
設計書は次の工程に渡るまで正当性が確認できません
完全な設計書を書くことはプロ野球のノーヒットノーランやゴルフのホールインワンを達成するようなものです 小規模な開発しかしたことないからこそこうやって理想を語れるんだ そのノーヒットノーランが出来ないと、大規模プロジェクトは動かせないって言ってるし、
小規模でもそんなやり直しなんか従業員にやらせてる暇も金も無いんだよ。 >>601
そうですね
そしてそれこそがそのような大規模プロジェクトがことごとく失敗する原因なのです 自分はまだ設計書ある現場しか行ったことないけど設計書なしでやってる現場ってどういうのだ？ >>604
大規模な開発でノーヒットノーランはありえません
めった打ちにされた挙句に金でサクラを動員して乱闘騒ぎでゲームをうやむやにするのが関の山でしょう ウォーターフォールとExcel方眼紙崇拝とか日本終わってる
効率悪すぎて海外の競合に出し抜かれる訳だ 小規模ならともかく大規模でできるかよバーカ！
↑
なら小さく分割しろよｗｗｗ
やっぱり基本ができてない人が設計書をありがたがるんだなぁ 作るものをまず青写真にして共通認識持たせる。
それが設計書。
隣の席同士の2、3人で作る共通認識も毎日会話してるだろうが、
他所の会社の担当者に毎日押し掛けて会話するか？ >>609
ウォーターフォールは、
金・人・時間を管理する側のえらい人が楽できるから
日本じゃ廃れないよ。 >>554
クックパッドってそんな高度な設計必要じゃなくね >>611
毎日会話してたって共通認識なんてもてないわな。
設計書があるくらいでそこが解決できてるなら
デスマーチにはならんわな。 >>614
そりゃあ、アニメの話してても意味無いぞ？ >>611
ブループリントレベルの粒度で
共通認識合わせる事出来んのかね？
細かい設定を確認する為の設計書も必要だろ。 設計書が必要なのは
俺にとって確定事項だから
議論しようと思わないな 雑談スレなのにつまらない話していがみ合って馬鹿じゃね 細かい設定は、詳細設計書を担当者レベルで作って、担当者間で相互認識して貰う。 みんなで議論して設計して決まったことを紙に書く
みんなで議論して設計して決まったことをエクセルに書く
みんなで議論して設計して決まったことをコードに書く
設計書とは設計を形に残すためのものでしかない
コードという形に残すのだから紙やエクセルは必要ない
ここに気がつけるかどうかだね 設計書まだ見たこと無い
マニュアルというかユーザーに渡す説明書みたいなの渡されてこれ作ってみたいな指示しか来ない
やっぱそういうの作るのってめっちゃでかいシステム作るところくらいなんだなって思ってたけどうちの会社もしかしてまずい？ 普通、納品物に設計書ってあるから
必要なくてもなんか作るだろ。 ウォーターフォールからアジャイルへの移行は難しいね
なかなか進まない 設計書って名前つけただけのゴミならいくらでも見たことあるけど
これが本物の設計書かと思わせるような品には出会ったことがないね と本物の設計書じゃないと難癖をつけて
何も産み出さない批評家気取りは何処でも湧くねえ 要求仕様書から機能一覧出して
機能一覧から設計書作って
設計書を元にコードとテスト作って
テストやって納品
楽じゃん プログラミングより設計書書く方が楽しいとかいう奴いないの？ 結局、設計書が役に立たないのは網羅性が薄いから
要求仕様書のすべての要求が入った機能一覧が必要でここで漏れがあったら終わり
機能一覧のすべての項目の記述のある設計書でなければならないし
設計書のすべての項目が実装されていなければならず
設計書のすべての項目のテストがなければならない >>631
違うな
機械的にできるはず
楽しいのは企画書書いてるフェイズぐらい
あとはできて当たり前できなきゃ減点しかされない DB設計って政治層の意向が強すぎて
きれいに正規化とか絶対にできないから
大嫌い 詳細設計書くくらいならコードを初めから書いた方が建設的 >>634
Viewやトリガーなど色々駆使して綺麗なDBに見せかける変換層を考えるの楽しい 業務系だとビューすら作る権限ないのでリポジトリに実装を隠蔽する対処法が正解 【作業期限】損害だから断れ【客先指示】
☆不利益で迷惑だから料金増やすか生産減らせ☆
人手不足が深刻な5つの業界。それぞれの現状と今後の見通し
1.情報サービス
2.家電・情報機器小売
3.放送
4.運輸・倉庫
5.建設
https://help-you.me/blog/lack-of-manpower
SI業界は、7Kと呼ばれるほど労働環境が良くない業界なので、他の業界と人員獲得競争に負ける可能性が大いにありますし、また同じIT業界内でも、webサービス企業や事業会社のITサービス部門ともエンジニアの争奪戦を繰り広げなくてはなりません。
Webサービス企業や事業会社は自社サービスということもあり、劣悪な労働環境は少なく、採用の競合としては、Webサービス企業や事業会社は強敵となるでしょう。 お盆休みが明日で終わりだ・・・もう胃が痛い。
お盆休みを取ったせいで９月まで土曜日と祭日の休みが
なくなったしな。 基本情報持ってないんだけど、試験日が比較的頻繁で基本情報よりおすすめの資格はありますか？ >>625
そりゃな
顧客も受ける側も積極的に参加しないと成り立たないやり方だからな
丸投げしてあとよろしくが主流な日本じゃうまくいくわけがない アジャイルなんて幻想だよ
って昔から言われてるじゃん。
ただの理想論で実現しない。
共産主義みたいなものだよ。 丸投げじゃないと案件幾つも掛け持ち出来ないからさ。 今時アジャイルって単語出てる時点で大きく遅れまくってるんだよな
しかも認識も曖昧な奴が多い
そういうバカが上にいるとマジで炎上しかしない アジャイル開発てあれだろ
ソシャゲみたいにとりあえずリリースしてちょこちょこ不具合を修正していく感じでしょ 日本企業にはアジャイルではなくアジャイルカーゴ・カルトが限度
つまり猿真似止まりである オブジェクト指向とテスト自動化を理解していれば自然とアジャイルになるんだけど
国内ではオブジェクト指向を理解してる人は極少数派だから仕事で使うのは難しいね アジャイルの成功例を猿真似どころか
真似しようともしていない件 サマータイムが社会問題になっているのにあいかわらず
設計の重要性がわかって無いアホPG
変更しやすく作れよ 今ふと思って検証したんだが、ミンミンゼミは８拍子で鳴いてるんだな。 オブジェクト思考を熱く語るやつにかぎって、現場で役に立たない件について staticおじさんとか、動的型付け苦手おじさんとか、もうねぇ。 >>660
動的型付けは苦手、動的型付けそのものが苦手なのではなく、typo を防止できないことが
typo を防げる動的型付け（option explicit があるもの）は存在しませんか？ 俺もアシスト無しで生産性上がるってのが不思議
関数名とインアウト全部覚えてるん？ どうせ上から降りてきたサンプルプログラムをコピペして、
担当のところの画面なり帳票なりバッチ処理なりに
書き直すだけだから、
なんとか思考とかプログラマには無関係な話だな。 すげー偏見だけど、動的型付け好きな人って
行き当たりばったりでロジック考えてそう 動的型付け苦手おじさんとか言われる時代になったのか 自分は尋常じゃないくらい頭が悪いのですが、超猛烈に努力を積み重ねていけば、
グレゴリー・ペレルマンさんやマキシム・コンツェビッチさんみたいな超絶の天才になれるのでしょうか？ 夏休みだからリーダブルコード読んでるんだけど、これ実践できてるプログラマってどれくらいの割合でいるもんなの？
おまいらどう？ >>669
普通に書いてたらだいたい書いてあるとおりにならないか？
もちろんたまに違うなってとこはあるにしても >>672
まだ半分ちょっとしか読んでないけど、俺が初心者だっていうのもあるかもしれない
本の前半(変数やコメントの使い方)はまあ分かる
9章の中間変数の削除とか、10章の無関係の下位問題の抽出とかのあたりを適切に出来てる人がそんなに多くいるとは思えないんだよね >>675
基本中の基本だけどできない人もいるんだね 全知全能の存在が無限の無限乗の無限乗の無限乗の無限乗の無限乗・・・・・（これが無限回続く）
以上居て、ガチで戦ったらどうなるのでしょうか？ 「変数は書き込みを1度だけに抑え、使用箇所の直前で定義すべきである。」
後半はまあそうなるように書けば良いとして
前半は関数型プログラミングするとか？ 変数宣言は、関数の先頭にまとめて書けよ。
そうしないと納品できないじゃん。
規約だよ。 >>680
ネタじゃなくマジの話？
そんなとこまで検収でチェックすんの？ >>679
switchやifが式じゃない言語でconstは厳しい
かといって三項演算子を大量に使うとカオスになる
配列操作も
配列をミュータブルにして要素を追加したり、
状態を持たせるboolの変数は作っちゃだめ JavaもC#やScalaに対抗してか
関数型言語っぽい機能を追加するという話があった >>678
初期化のみ代入禁止をガチガチに守ると手続き型ではforループで合計も求められないよ
その辺はパラダイムに合わせて出来るだけ守るでいいんじゃないか
畳み込みとかモナド使えってことを言ってるわけじゃなさそうだし >>682
する。
大手は独自ツールがあって
ソースコードをそれにかけて
指摘項目がゼロにならないと受け取らない。
外部ライブラリとか使ってると地獄。
そのひっかかった項目は修正できない理由を
レポートにまとめないといけない。 >>678
・悪い例(書き換えまくり)
decimal result = 0;
result = basePrice;
if (waribiki_hantei()) {
result = result * 0.9;
}
result = result * (1 + taxRate);
print result;
・良い例(書き換えなし)
decimal discountPrice = waribiki_hantei() ? basePrice * 0.9 : basePrice ;
decimal priceIncludingTax = discountPrice * (1 + taxRate);
print priceIncludingTax;
・さらに良い例(変数ではなく問い合わせを使う)
decimal getDiscountPrice() {
if (waribiki_hantei()) return basePrice * 0.9;
else return basePrice;
}
decimal getPriceIncludingTax() {
return getDiscountPrice() * (1 + taxRate);
}
print getPriceIncludingTax(); >>685
sequence.Sum(x => x.SomeValue); >>682
するところはする
した場合としない場合で業績にどういう影響があるかは解明されていない >>686
自分らで使えって強制してきたくせに動作が気に入らないから
使わないで組み直せタダでとか言うから
訴えてやったわ
結局示談になっていくらかもらって向こうの担当者のクビが飛んだだけだった
それまでこっちが悪くない証拠や議事録抽出するの大変だったわ >>686
根本的な設計が狂ってることからは頑なに目をそらすのに
重箱のすみを突くときだけやたらと神経質になるよな大企業のプロパーさん
完全に無能な働き者ってやつだよ
つっても膨大な設計書を書いちゃったせいで根本的な設計なんて変えようがないから、重箱のすみを突くしか出来ることないんだけどなｗ ■ このスレッドは過去ログ倉庫に格納されています
