機能追加や変更した時に、全部テストしてるでしょ?
いつもやってることじゃん
リファクタリングすると全部テストしろと言ってくるやつの矛盾
■ このスレッドは過去ログ倉庫に格納されています
2018/04/15(日) 13:13:44.63
626仕様書無しさん
2018/04/25(水) 08:41:32.66 組織と自分の履歴サーバを別けている
日本のリファクタリングあるある
日本のリファクタリングあるある
627仕様書無しさん
2018/04/25(水) 17:33:16.56 人気グループ「TOKIO」の山口達也メンバーが、自宅マンションの部屋で女子高校生に無理やりキスをするなどの行為をしたとして、警視庁は強制わいせつの疑いで書類送検しました。
全文は以下
https://www3.nhk.or.jp/news/html/20180425/k10011417181000.html
全文は以下
https://www3.nhk.or.jp/news/html/20180425/k10011417181000.html
630仕様書無しさん
2018/04/25(水) 18:43:41.61 レビューしないのかな?
631仕様書無しさん
2018/04/25(水) 20:35:48.01 ぬおーん
632仕様書無しさん
2018/04/25(水) 22:46:40.90 コード読めないからレビューできないんじゃね?w
633仕様書無しさん
2018/04/25(水) 22:49:39.16 ここで一部の人に衝撃的な事実を言っておきますね。
レビューができるコードっていうのは1関数あたりだいたい10〜20行程度までです。
50行なんて超えたらぜったいにレビューできません。
人の能力の問題じゃなくて、レビューできないコードです。
解析が必要になったら、それはレビューとは言えません。
だから1関数当たり10〜20行になっていなければいけません。
これを超えるものがざらにあるようなプロジェクトは失格です
レビューができるコードっていうのは1関数あたりだいたい10〜20行程度までです。
50行なんて超えたらぜったいにレビューできません。
人の能力の問題じゃなくて、レビューできないコードです。
解析が必要になったら、それはレビューとは言えません。
だから1関数当たり10〜20行になっていなければいけません。
これを超えるものがざらにあるようなプロジェクトは失格です
634仕様書無しさん
2018/04/25(水) 22:54:58.77 10行って引数の多いメソッドの前準備してるだけで終わるレベル
俺は200行程度まで許容範囲
俺は200行程度まで許容範囲
636仕様書無しさん
2018/04/25(水) 23:02:01.36 レビューは通過儀礼だから
コードなんて誰も見てない
見てるのは担当者の活舌
コードなんて誰も見てない
見てるのは担当者の活舌
637仕様書無しさん
2018/04/25(水) 23:02:22.78 Web業務なら少々長くても大丈夫
帳票とかDBとかでっかい構造体にいっこずつ値入れてるだけだから
長くても込み入ってないことおおい
組み込みとかどうだろう
帳票とかDBとかでっかい構造体にいっこずつ値入れてるだけだから
長くても込み入ってないことおおい
組み込みとかどうだろう
638仕様書無しさん
2018/04/25(水) 23:03:22.71639仕様書無しさん
2018/04/25(水) 23:03:29.06 関数の行数よりネストの深さとスコープの方が大事
640仕様書無しさん
2018/04/25(水) 23:07:40.35 >>636
> コードなんて誰も見てない
だろ?
長いコードは読まない。
レビューできないから
>>637
ウェブ系でもありえないな。
ほんとね、一人前のプログラマか、ゴミかどうかは
1関数10〜20が普通って聞いて信じられるかどうかでわかるよ
比較的大規模なウェブアプリの例。みてみろ。コレがレビュー可能なコードってもんだ
https://github.com/gitlabhq/gitlabhq/tree/master/app
50行とか超えてるコードばかり見てる人、↑これみれば、
50行なんて長いコードはレビューできないのが当たり前ってわかるよ。
> コードなんて誰も見てない
だろ?
長いコードは読まない。
レビューできないから
>>637
ウェブ系でもありえないな。
ほんとね、一人前のプログラマか、ゴミかどうかは
1関数10〜20が普通って聞いて信じられるかどうかでわかるよ
比較的大規模なウェブアプリの例。みてみろ。コレがレビュー可能なコードってもんだ
https://github.com/gitlabhq/gitlabhq/tree/master/app
50行とか超えてるコードばかり見てる人、↑これみれば、
50行なんて長いコードはレビューできないのが当たり前ってわかるよ。
641仕様書無しさん
2018/04/25(水) 23:10:26.57 小さなクラスやメソッドにするのはいいことだけど、適切な命名ができるのが大前提
英語が苦手な奴はデタラメな名前をつけるから余計わかりづらくなる
形だけ小さくして満足してるバカが多い
英語が苦手な奴はデタラメな名前をつけるから余計わかりづらくなる
形だけ小さくして満足してるバカが多い
643仕様書無しさん
2018/04/25(水) 23:16:39.06 どうせ携帯のちっこい画面用だろ
644仕様書無しさん
2018/04/25(水) 23:17:41.01 リファクタリングするとバグがーとか言ってるのは
おそらく50行とか平気で超えてるような所だろう
レベルに大きな差があるから話が通じない。
1関数たったのこれだけしかないから、
この関数が動くかどうかテストするのは簡単なんだ
おそらく50行とか平気で超えてるような所だろう
レベルに大きな差があるから話が通じない。
1関数たったのこれだけしかないから、
この関数が動くかどうかテストするのは簡単なんだ
645仕様書無しさん
2018/04/25(水) 23:23:52.25646仕様書無しさん
2018/04/25(水) 23:25:40.51647仕様書無しさん
2018/04/25(水) 23:25:41.82 コードの優劣は、そのコードが生み出す経済的価値によって決まる
ただ綺麗なコードより汚くても利益を生むコードの方が価値がある
大して価値のないコードを一生懸命リファクタリングしてる奴には、そんなゴミ捨てて意味のあるコードを書けと言いたいね
ただ綺麗なコードより汚くても利益を生むコードの方が価値がある
大して価値のないコードを一生懸命リファクタリングしてる奴には、そんなゴミ捨てて意味のあるコードを書けと言いたいね
648仕様書無しさん
2018/04/25(水) 23:26:50.34 はい、言い訳きたーw
649仕様書無しさん
2018/04/25(水) 23:30:48.77 英検1級レベルに満たない奴はローマ字でコードを書け
650仕様書無しさん
2018/04/25(水) 23:31:01.06 くり返し言うが、俺が言いたいのは、技術力高い所は
本当にこれぐらいのレベルなんだよ、
ありえない話はしていない。その証拠
本当にこれぐらいのレベルなんだよ、
ありえない話はしていない。その証拠
651仕様書無しさん
2018/04/25(水) 23:31:51.26 >>646
そんなに探してない
DBとかHTMLに値入れてるとことか長くなりがちなとこ探したけどなかったんで
helperっていう割とやばめの文字列が目に入ったんで開いたらあった
やっぱり扱うものによる
一番下のやつ50行超えてるぞアウトだアウトだ
https://github.com/gitlabhq/gitlabhq/blob/master/app/helpers/application_settings_helper.rb
そんなに探してない
DBとかHTMLに値入れてるとことか長くなりがちなとこ探したけどなかったんで
helperっていう割とやばめの文字列が目に入ったんで開いたらあった
やっぱり扱うものによる
一番下のやつ50行超えてるぞアウトだアウトだ
https://github.com/gitlabhq/gitlabhq/blob/master/app/helpers/application_settings_helper.rb
656仕様書無しさん
2018/04/25(水) 23:35:35.10 >>640
でもよ
それって設計書書くの大変じゃない?
200行のメソッドって10個〜20個になんだろ?
クラス図だって10倍か20倍にデカくなんだぞ
トレードオフの問題ちゃうんか?
たくさん仕事してるようで大半がメソッド名決めてるだけみたいな
でもよ
それって設計書書くの大変じゃない?
200行のメソッドって10個〜20個になんだろ?
クラス図だって10倍か20倍にデカくなんだぞ
トレードオフの問題ちゃうんか?
たくさん仕事してるようで大半がメソッド名決めてるだけみたいな
657仕様書無しさん
2018/04/25(水) 23:36:38.18 >>652
いや、自分も同じレベルだけど、自分のコードは出せないだろう?
オープンソースで参考にできるもの。
あの関数の短さで大規模なエンタープライズ向けの開発ツールが作れる。
そういう事実がそこにある。
いや、自分も同じレベルだけど、自分のコードは出せないだろう?
オープンソースで参考にできるもの。
あの関数の短さで大規模なエンタープライズ向けの開発ツールが作れる。
そういう事実がそこにある。
659仕様書無しさん
2018/04/25(水) 23:37:57.03 >>656
> それって設計書書くの大変じゃない?
設計書書くの大変なんだよ?
ようするに設計書はこのぐらいのものを作って
一人前ってことなんだよ。
普段どれだけ適当な仕事しているかってのを
わかってほしい。それだけのレベルの差がある
> それって設計書書くの大変じゃない?
設計書書くの大変なんだよ?
ようするに設計書はこのぐらいのものを作って
一人前ってことなんだよ。
普段どれだけ適当な仕事しているかってのを
わかってほしい。それだけのレベルの差がある
661仕様書無しさん
2018/04/25(水) 23:39:09.20 メソッドの仕様まで設計書に起こす奴って脳死しすぎやろw
662仕様書無しさん
2018/04/25(水) 23:39:47.86 設計書書くの大変かどうかは知らんが
事実としてあのコードは存在する。
あのコードを作るにはどうすればいいかを考えたほうが良い
事実としてあのコードは存在する。
あのコードを作るにはどうすればいいかを考えたほうが良い
668仕様書無しさん
2018/04/25(水) 23:47:04.45671仕様書無しさん
2018/04/25(水) 23:54:21.44 >>670
これ? なかなか見つからなくて苦労している
https://github.com/jenkinsci/jenkins/tree/master/core/src/main/java/jenkins/model
これ? なかなか見つからなくて苦労している
https://github.com/jenkinsci/jenkins/tree/master/core/src/main/java/jenkins/model
672仕様書無しさん
2018/04/25(水) 23:55:28.95 まあJavaだしね。
673仕様書無しさん
2018/04/25(水) 23:57:50.39 Rubyは結構変な構文で圧縮してる
674仕様書無しさん
2018/04/26(木) 00:03:21.92 >>659
原点回帰が必要だよお前
人間が見てわかりやすい範囲を明らかに逸脱してるだろ
概算で役に立たない
2000行規模のコードでメソッド200個近く作るんだろ
どうやって表現すんの?お前
なんもドキュメント作らない前提じゃないと成り立たない
つっかえねーw
原点回帰が必要だよお前
人間が見てわかりやすい範囲を明らかに逸脱してるだろ
概算で役に立たない
2000行規模のコードでメソッド200個近く作るんだろ
どうやって表現すんの?お前
なんもドキュメント作らない前提じゃないと成り立たない
つっかえねーw
675仕様書無しさん
2018/04/26(木) 00:05:16.32 われながら途中で投げ出してわかるからと適当に書いた設計書がやばい
自分はわかるがテスターが
どうしよ
自分はわかるがテスターが
どうしよ
676仕様書無しさん
2018/04/26(木) 00:11:00.24677仕様書無しさん
2018/04/26(木) 00:17:32.88678仕様書無しさん
2018/04/26(木) 00:20:48.44 面白いのを見つけてきた
【読者参加型企画】2,000行のJavaソースコードを読むのに何分かかりますか?
https://codezine.jp/article/detail/4388
コードレビュー速度 (1時間あたり)
IEEE: IEEE Standard for Software Reviews and Audits(1028-2008) によると
100〜200行(Technical reviews)らしい。
つまり2000行だと10〜20時間、1日〜3日、コードレビューにかかる
いいですか?
2000行にかかるコードレビューの時間です。
【読者参加型企画】2,000行のJavaソースコードを読むのに何分かかりますか?
https://codezine.jp/article/detail/4388
コードレビュー速度 (1時間あたり)
IEEE: IEEE Standard for Software Reviews and Audits(1028-2008) によると
100〜200行(Technical reviews)らしい。
つまり2000行だと10〜20時間、1日〜3日、コードレビューにかかる
いいですか?
2000行にかかるコードレビューの時間です。
679仕様書無しさん
2018/04/26(木) 00:32:42.36 https://gigazine.net/news/20150918-google-2billion-code/
> 2015年1月時点で、総ファイル数は10億、ソースファイルの数は900万、
> コードは20億行あり、3500万回のコミットがあって、内容は86TBあるとのこと。
> そして、営業日1日に対してのコミット回数は4万5000回。
1ファイルの平均は20億÷900万=222行でした。
2000行規模なら10ファイル程度
俺は妥当なところだねと思うが、
そう思わない人がいる。
そこにレベルの差を感じる
> 2015年1月時点で、総ファイル数は10億、ソースファイルの数は900万、
> コードは20億行あり、3500万回のコミットがあって、内容は86TBあるとのこと。
> そして、営業日1日に対してのコミット回数は4万5000回。
1ファイルの平均は20億÷900万=222行でした。
2000行規模なら10ファイル程度
俺は妥当なところだねと思うが、
そう思わない人がいる。
そこにレベルの差を感じる
680仕様書無しさん
2018/04/26(木) 00:34:49.47 トレードオフって言葉を覚えた方がいいよ
この機能を実現するために必要な処理は何?
って聞かれても何も答えられないっしょ?
さらにドキュメントを書かせる現場で君は役に立たない
たった2000行程度で200個もメソッド作るようなカスはどこ行っても
使えねーからオープンソースでも
組んでろよ
この機能を実現するために必要な処理は何?
って聞かれても何も答えられないっしょ?
さらにドキュメントを書かせる現場で君は役に立たない
たった2000行程度で200個もメソッド作るようなカスはどこ行っても
使えねーからオープンソースでも
組んでろよ
681仕様書無しさん
2018/04/26(木) 00:44:22.87 > この機能を実現するために必要な処理は何?
> って聞かれても何も答えられないっしょ?
「この機能」って?
この機能だけで見積もりできるの?設計できるの?
> って聞かれても何も答えられないっしょ?
「この機能」って?
この機能だけで見積もりできるの?設計できるの?
682仕様書無しさん
2018/04/26(木) 00:45:19.30 >>678
で、なにが言いたいの?
スレの流れは関数の長さとそのレビューにかかる時間だったけど、その引用のレビュー時間は
関数の長さとどう関係があんの?
まさか、2000行のコードっていうのを、2000行のひとつの関係って解釈した?
で、なにが言いたいの?
スレの流れは関数の長さとそのレビューにかかる時間だったけど、その引用のレビュー時間は
関数の長さとどう関係があんの?
まさか、2000行のコードっていうのを、2000行のひとつの関係って解釈した?
683仕様書無しさん
2018/04/26(木) 00:46:39.82 >>680
2000行なら100メソッドだろ?
何勝手に水増ししてんだw
普通に作れば100個のメソッドなんて普通にできる
1関数10〜20行にしないとテスト不可能
テスト可能にするとだいたいコレぐらいになる。
そこから逆算すれば100個のメソッドは
普通に作ればできる
トレードオフの話をするのであれば、
トレードオフした結果が100個だ
って、やっぱりマジ1関数10〜20なんてありえない
50行超えるのがザラなの? レベルに大きな差があるよ。
自覚だけはしておこう
2000行なら100メソッドだろ?
何勝手に水増ししてんだw
普通に作れば100個のメソッドなんて普通にできる
1関数10〜20行にしないとテスト不可能
テスト可能にするとだいたいコレぐらいになる。
そこから逆算すれば100個のメソッドは
普通に作ればできる
トレードオフの話をするのであれば、
トレードオフした結果が100個だ
って、やっぱりマジ1関数10〜20なんてありえない
50行超えるのがザラなの? レベルに大きな差があるよ。
自覚だけはしておこう
684仕様書無しさん
2018/04/26(木) 00:49:24.26 トレードオフって何と何のトレードオフなんだろう?
最初から短い関数で書けばいいと思うけど、
関数を長くすることで、何のメリットがあるの?
最初から短い関数で書けばいいと思うけど、
関数を長くすることで、何のメリットがあるの?
685仕様書無しさん
2018/04/26(木) 00:49:29.64 >>678
そもそもテクニカルレビューってなに?
どういう目的でどういうレビューをしてるかによってかかる時間はいくらでも変わると思うけど、
テクニカルレビューがなんなのかわからないから10〜20時間が長いのか短いのか評価できないんだけど
そもそもテクニカルレビューってなに?
どういう目的でどういうレビューをしてるかによってかかる時間はいくらでも変わると思うけど、
テクニカルレビューがなんなのかわからないから10〜20時間が長いのか短いのか評価できないんだけど
686仕様書無しさん
2018/04/26(木) 00:51:12.51 ふつうだのレベルだの漠然としたことしか言わんやっちゃ
687仕様書無しさん
2018/04/26(木) 00:51:43.19 例えばプロだと間違えずにキーを打つことが高速にできる。
だけど素人だと間違えずにキーを打たなければいけないという
条件をつけると途端にタイプするのが遅くなる。
それと一緒でプロだと普通に作っても関数は10〜20行にできるが
そうでない素人だと頑張らないと達成できない
そう、素人
だけど素人だと間違えずにキーを打たなければいけないという
条件をつけると途端にタイプするのが遅くなる。
それと一緒でプロだと普通に作っても関数は10〜20行にできるが
そうでない素人だと頑張らないと達成できない
そう、素人
690仕様書無しさん
2018/04/26(木) 01:00:43.49 技術的難易度が低いただのCRUDアプリみたいなものしか作れない人は、いかに綺麗にコードを書くかとか
そういう話題でしか技術っぽい話ができないから、ここぞとばかりに語るよな
そういう話題でしか技術っぽい話ができないから、ここぞとばかりに語るよな
691仕様書無しさん
2018/04/26(木) 01:00:54.12 >>683
それって20行換算じゃん
最大行で見積もるなんて心苦しいから10行にしてやったんじゃん
2000行でメソッドが200個できて
20000行で2000個だ
100000行で10000個じゃん
この間やったプロジェクトのコードがそんなもんだったけど
メソッド10000個とか明らかに
茶碗が小さすぎる
おちょこに飯もってるみたいにアンバランスだろ
それって20行換算じゃん
最大行で見積もるなんて心苦しいから10行にしてやったんじゃん
2000行でメソッドが200個できて
20000行で2000個だ
100000行で10000個じゃん
この間やったプロジェクトのコードがそんなもんだったけど
メソッド10000個とか明らかに
茶碗が小さすぎる
おちょこに飯もってるみたいにアンバランスだろ
693仕様書無しさん
2018/04/26(木) 01:06:27.50694仕様書無しさん
2018/04/26(木) 01:10:21.07695仕様書無しさん
2018/04/26(木) 01:14:29.41 そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか?
設計書に書いた処理とソースの処理を一致させないと説明が面倒だろ
設計書に書いた処理とソースの処理を一致させないと説明が面倒だろ
696仕様書無しさん
2018/04/26(木) 01:15:20.39 >>691
> 100000行で10000個じゃん
数を大きくして、多く見せたいようだけど無駄w
10万行だろ? 1ファイル(=1クラス相当)が200行ぐらいなので
500個もファイルがある。メソッド1万個は1ファイル(クラス)20個のメソッド
これは普通の規模だ
そもそもお前、ちゃんとモジュール化できてないだろ?
役割ごとにちゃんとファイル(クラス)分けろ
> 100000行で10000個じゃん
数を大きくして、多く見せたいようだけど無駄w
10万行だろ? 1ファイル(=1クラス相当)が200行ぐらいなので
500個もファイルがある。メソッド1万個は1ファイル(クラス)20個のメソッド
これは普通の規模だ
そもそもお前、ちゃんとモジュール化できてないだろ?
役割ごとにちゃんとファイル(クラス)分けろ
697仕様書無しさん
2018/04/26(木) 01:17:14.11 >>695
> そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか?
実際にコードはそれぐらいになるんだから、
それに相当するメソッドは誰が作り出してるかってことだよ。
設計書にこの程度の数のメソッドが書いてないなら、
その設計書通りに作ると破綻するということを意味する
きちんとレビューしてテストするためには、
実際にそれだけの小ささのメソッドでなければいけないのだからね
> そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか?
実際にコードはそれぐらいになるんだから、
それに相当するメソッドは誰が作り出してるかってことだよ。
設計書にこの程度の数のメソッドが書いてないなら、
その設計書通りに作ると破綻するということを意味する
きちんとレビューしてテストするためには、
実際にそれだけの小ささのメソッドでなければいけないのだからね
698仕様書無しさん
2018/04/26(木) 01:25:34.92 実際にコードを書いてる人は、これぐらいの数の関数は作ってるんだよね。
それにたいして、こんなに大量の関数なんて設計できない。
予め想定することなんてできない
っていうのなら、そういうことだよ。
お前らがやってる設計とやらの仕事は、
現場には通用しない仕事だということ
Sヨとか言われてバカにされてるじゃん。
それが事実だってことだよ。
それにたいして、こんなに大量の関数なんて設計できない。
予め想定することなんてできない
っていうのなら、そういうことだよ。
お前らがやってる設計とやらの仕事は、
現場には通用しない仕事だということ
Sヨとか言われてバカにされてるじゃん。
それが事実だってことだよ。
699仕様書無しさん
2018/04/26(木) 01:39:49.55 さてリファクタリングの話に戻すぞ?
これが実際の優れた開発の現場だから、最初に全部設計して
最初に考えた関数だけで作るなんて不可能なわけさ
関数の数が多すぎる!って叫んでるアイツ見りゃわかるだろ?
でも実際のコードはそれだけの数の関数がある
この差をどうやって埋めるよ?
最初は設計に書いたとおりの形から始める
実装が進んで次第にコードが膨れ上がっていく
テストできなくなってしまうから、再設計が必要
といっても大きなものじゃない。こまめにやる。
これが開発の中に自然に含まれているリファクタリングだ。
リファクタリングは開発に含まれるもので
別の作業として分離してやるもんじゃない。
これが実際の優れた開発の現場だから、最初に全部設計して
最初に考えた関数だけで作るなんて不可能なわけさ
関数の数が多すぎる!って叫んでるアイツ見りゃわかるだろ?
でも実際のコードはそれだけの数の関数がある
この差をどうやって埋めるよ?
最初は設計に書いたとおりの形から始める
実装が進んで次第にコードが膨れ上がっていく
テストできなくなってしまうから、再設計が必要
といっても大きなものじゃない。こまめにやる。
これが開発の中に自然に含まれているリファクタリングだ。
リファクタリングは開発に含まれるもので
別の作業として分離してやるもんじゃない。
700仕様書無しさん
2018/04/26(木) 02:27:16.80 糞コードいつか破綻するのはわかってるのに
そのまま売りまっくて最終的には極悪に肥大したクソコードのリファクタリングしろという
まずその事実を知っていて売り続けた開発部長やら上層の誰かに責任取らせろやハゲが
そのまま売りまっくて最終的には極悪に肥大したクソコードのリファクタリングしろという
まずその事実を知っていて売り続けた開発部長やら上層の誰かに責任取らせろやハゲが
702仕様書無しさん
2018/04/26(木) 03:26:26.13 ん?やめてないよ。開発の中に改修は含まれている
改修をしない開発会社なんてないんだから
改修をしない開発会社なんてないんだから
703仕様書無しさん
2018/04/26(木) 03:26:52.94 はいはいw
705仕様書無しさん
2018/04/26(木) 09:34:52.67 ソースレベルの設計書とか言ってる奴はまだマ歴1ヶ月なんだから優しくしてやれ
706仕様書無しさん
2018/04/26(木) 09:51:20.89 つまり
1. テスト可能なメソッドは十分短いものである
2. 設計でそれらを全て洗い出すのは無理
ってことなんだよね
これは重要な大前提では?
1. テスト可能なメソッドは十分短いものである
2. 設計でそれらを全て洗い出すのは無理
ってことなんだよね
これは重要な大前提では?
707仕様書無しさん
2018/04/26(木) 09:52:44.36708仕様書無しさん
2018/04/26(木) 10:30:15.01 ソースレベルの設計書ってなに?詳細設計よりもっと細かいやつ?
アセンブラ時代のフローチャートはほぼソースとイコールだったけど
アセンブラ時代のフローチャートはほぼソースとイコールだったけど
709仕様書無しさん
2018/04/26(木) 12:27:07.55710仕様書無しさん
2018/04/26(木) 12:31:16.98 破綻はしないが非効率的すぎるわな
711仕様書無しさん
2018/04/26(木) 12:57:21.34 設計で関数を洗い出すのはいいんじゃねーの?
ソースは完全にプログラマに任せるスタイルなのか、ある程度は監視するスタイルなのかの差だと思うよ
個人の技量に任せたら関数の切り出しするやつとしないやつで差がですぎてソースが混乱する
ソースは完全にプログラマに任せるスタイルなのか、ある程度は監視するスタイルなのかの差だと思うよ
個人の技量に任せたら関数の切り出しするやつとしないやつで差がですぎてソースが混乱する
712仕様書無しさん
2018/04/26(木) 15:10:37.16 そこまで細かく詰めるならその場でコードまで書いてコンパイルと簡単なユニットテスト通しちゃえよ
少なくともインターフェースとスタブは書けるだろ
少なくともインターフェースとスタブは書けるだろ
715KAC
2018/04/26(木) 20:18:39.67 >>712
コードを書かなきゃ必要な関数を洗い出すこともできないのは最近の風潮だよな
大規模なチームで設計するときにも、
各自が関数洗い出したのを持ちよって全体最適化とかしてないだろ?
普及している手法にはメリットやデメリットがあるのは当たり前
色々な開発手法知らないと最善策見つけられんだろ
コードを書かなきゃ必要な関数を洗い出すこともできないのは最近の風潮だよな
大規模なチームで設計するときにも、
各自が関数洗い出したのを持ちよって全体最適化とかしてないだろ?
普及している手法にはメリットやデメリットがあるのは当たり前
色々な開発手法知らないと最善策見つけられんだろ
716仕様書無しさん
2018/04/26(木) 21:06:08.65 昔に比べりゃ関数作るのはアホみたいに簡単になった
CollectionやらThreadやらStringやら
大体コアになるもんはありものが揃ってるし
CollectionやらThreadやらStringやら
大体コアになるもんはありものが揃ってるし
717仕様書無しさん
2018/04/26(木) 21:57:25.51 設計書ってパンチカード時代の名残だぞ
そんなものを未だに盲信してるなんて滑稽だ
そんなものを未だに盲信してるなんて滑稽だ
718仕様書無しさん
2018/04/26(木) 22:34:16.48 デシジョンテーブルは書くやろ?
720仕様書無しさん
2018/04/26(木) 22:52:07.11 そらDBからデータを取り出してブラウザに返すだけのアプリに設計書なんていらんわな
721仕様書無しさん
2018/04/26(木) 22:59:08.51 二人以上で作業するなら電卓アプリでも設計書いるわ
723仕様書無しさん
2018/04/26(木) 23:44:04.93 DBからデータを取り出してブラウザに返す仕事なんて、専門教育を受けてない文系でもこなしてるという事実
724仕様書無しさん
2018/04/26(木) 23:45:51.71 リファクタリングの話が盛り上がるのは、文系でも参加できるから
725仕様書無しさん
2018/04/26(木) 23:52:49.47 文系が参加って、技術的な話での参加じゃないじゃんw
■ このスレッドは過去ログ倉庫に格納されています
