ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくるやつの矛盾

**仕様書無しさん** · 2018/04/15(日) 13:13:44.63

機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん

**仕様書無しさん** · 2018/04/25(水) 23:23:52.25

ほう
https://github.com/gitlabhq/gitlabhq/blob/master/app/helpers/submodule_helper.rb

**仕様書無しさん** · 2018/04/25(水) 23:25:40.51

>>645
それを見つけるまで、何ファイル探したかな？
ものすごくレアだってのがわかるだろう。

長いそれであっても50行は超えていない

**仕様書無しさん** · 2018/04/25(水) 23:25:41.82

コードの優劣は、そのコードが生み出す経済的価値によって決まる
ただ綺麗なコードより汚くても利益を生むコードの方が価値がある
大して価値のないコードを一生懸命リファクタリングしてる奴には、そんなゴミ捨てて意味のあるコードを書けと言いたいね

**仕様書無しさん** · 2018/04/25(水) 23:26:50.34

はい、言い訳きたーｗ

**仕様書無しさん** · 2018/04/25(水) 23:30:48.77

英検1級レベルに満たない奴はローマ字でコードを書け

**仕様書無しさん** · 2018/04/25(水) 23:31:01.06

くり返し言うが、俺が言いたいのは、技術力高い所は
本当にこれぐらいのレベルなんだよ、
ありえない話はしていない。その証拠

**仕様書無しさん** · 2018/04/25(水) 23:31:51.26

>>646
そんなに探してない
ＤＢとかＨＴＭＬに値入れてるとことか長くなりがちなとこ探したけどなかったんで
helperっていう割とやばめの文字列が目に入ったんで開いたらあった

やっぱり扱うものによる

一番下のやつ５０行超えてるぞアウトだアウトだ
https://github.com/gitlabhq/gitlabhq/blob/master/app/helpers/application_settings_helper.rb

**仕様書無しさん** · 2018/04/25(水) 23:32:00.49

>>650
他人のふんどし

**仕様書無しさん** · 2018/04/25(水) 23:32:43.50

>>651
そもそもrubyがカス

**仕様書無しさん** · 2018/04/25(水) 23:33:46.00

>>651
今までに何ファイル探した？
少ないのがわかるだろう？

**仕様書無しさん** · 2018/04/25(水) 23:35:10.56

>>651
よくそんなの見つけてくるねｗ
ただの配列定義だった

**仕様書無しさん** · 2018/04/25(水) 23:35:35.10

>>640
でもよ
それって設計書書くの大変じゃない？
200行のメソッドって10個～20個になんだろ？
クラス図だって10倍か20倍にデカくなんだぞ
トレードオフの問題ちゃうんか？
たくさん仕事してるようで大半がメソッド名決めてるだけみたいな

**仕様書無しさん** · 2018/04/25(水) 23:36:38.18

>>652
いや、自分も同じレベルだけど、自分のコードは出せないだろう？
オープンソースで参考にできるもの。

あの関数の短さで大規模なエンタープライズ向けの開発ツールが作れる。
そういう事実がそこにある。

**仕様書無しさん** · 2018/04/25(水) 23:36:38.93

>>656
コードが設計書

**仕様書無しさん** · 2018/04/25(水) 23:37:57.03

>>656
> それって設計書書くの大変じゃない？

設計書書くの大変なんだよ？

ようするに設計書はこのぐらいのものを作って
一人前ってことなんだよ。

普段どれだけ適当な仕事しているかってのを
わかってほしい。それだけのレベルの差がある

**仕様書無しさん** · 2018/04/25(水) 23:38:04.24

>>657
1関数100行でも作れるよ

**仕様書無しさん** · 2018/04/25(水) 23:39:09.20

メソッドの仕様まで設計書に起こす奴って脳死しすぎやろw

**仕様書無しさん** · 2018/04/25(水) 23:39:47.86

設計書書くの大変かどうかは知らんが
事実としてあのコードは存在する。

あのコードを作るにはどうすればいいかを考えたほうが良い

**仕様書無しさん** · 2018/04/25(水) 23:40:24.20

>>662
そうだな

リファクタする時間をプログラマにくれればいいんじゃないかな？

**仕様書無しさん** · 2018/04/25(水) 23:41:06.73

>>660
作れるかどうかという理論上の話ではなく
実際に作られたシステムが、あれだけ関数の長さが短いという事実

**仕様書無しさん** · 2018/04/25(水) 23:41:39.80

>>663
その分、設計してる人の時間をとるんだろ？

**仕様書無しさん** · 2018/04/25(水) 23:42:57.70

>>665
役に立たない設計書を書いてるような
やつに時間はいらない

**仕様書無しさん** · 2018/04/25(水) 23:43:22.49

>>665
コードの奇麗さが価値なら
客からリファクタ用の時間をたっぷりふんだくれるはず

**仕様書無しさん** · 2018/04/25(水) 23:47:04.45

>>667
別にいらんよ。コードが綺麗なら
同じ時間でより多くのものが作れる。

言い換えると技術力が高ければ、
同じ時間でより多くのものが作れる
という当たり前の話だ

**仕様書無しさん** · 2018/04/25(水) 23:48:23.93

>>667ってなんか発想がおかしくね？
客から作業代をどうやってむしり取ろうかって発想になってる。

**仕様書無しさん** · 2018/04/25(水) 23:49:15.19

>>664
Jenkinsは至るところで使われてるけど50行以上のメソッドなんていくらでもある事実

**仕様書無しさん** · 2018/04/25(水) 23:54:21.44

>>670
これ？なかなか見つからなくて苦労している
https://github.com/jenkinsci/jenkins/tree/master/core/src/main/java/jenkins/model

**仕様書無しさん** · 2018/04/25(水) 23:55:28.95

まあJavaだしね。

**仕様書無しさん** · 2018/04/25(水) 23:57:50.39

Rubyは結構変な構文で圧縮してる

**仕様書無しさん** · 2018/04/26(木) 00:03:21.92

>>659
原点回帰が必要だよお前
人間が見てわかりやすい範囲を明らかに逸脱してるだろ
概算で役に立たない
2000行規模のコードでメソッド200個近く作るんだろ
どうやって表現すんの？お前
なんもドキュメント作らない前提じゃないと成り立たない

つっかえねーｗ

**仕様書無しさん** · 2018/04/26(木) 00:05:16.32

われながら途中で投げ出してわかるからと適当に書いた設計書がやばい
自分はわかるがテスターが
どうしよ

**仕様書無しさん** · 2018/04/26(木) 00:11:00.24

>>668
当たり前とはつまり自分の思い込みで根拠がないことを指す

このコードだって最初からきれいに書いてちゃっちゃと作ったのか
時間をかけてレビューして整頓したのかどうかなんてわかんないじゃん

**仕様書無しさん** · 2018/04/26(木) 00:17:32.88

>>674
> 2000行規模のコードでメソッド200個近く作るんだろ
> どうやって表現すんの？お前

でもさ、コードでは実際にそう表現されてるよ？
そこの矛盾に、君が気づかないといけない

**仕様書無しさん** · 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行にかかるコードレビューの時間です。

**仕様書無しさん** · 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ファイル程度

俺は妥当なところだねと思うが、
そう思わない人がいる。

そこにレベルの差を感じる

**仕様書無しさん** · 2018/04/26(木) 00:34:49.47

トレードオフって言葉を覚えた方がいいよ
この機能を実現するために必要な処理は何？
って聞かれても何も答えられないっしょ？
さらにドキュメントを書かせる現場で君は役に立たない
たった2000行程度で200個もメソッド作るようなカスはどこ行っても
使えねーからオープンソースでも
組んでろよ

**仕様書無しさん** · 2018/04/26(木) 00:44:22.87

> この機能を実現するために必要な処理は何？
> って聞かれても何も答えられないっしょ？

「この機能」って？
この機能だけで見積もりできるの？設計できるの？

**仕様書無しさん** · 2018/04/26(木) 00:45:19.30

>>678
で、なにが言いたいの？
スレの流れは関数の長さとそのレビューにかかる時間だったけど、その引用のレビュー時間は
関数の長さとどう関係があんの？
まさか、2000行のコードっていうのを、2000行のひとつの関係って解釈した？

**仕様書無しさん** · 2018/04/26(木) 00:46:39.82

>>680
2000行なら100メソッドだろ？
何勝手に水増ししてんだｗ

普通に作れば100個のメソッドなんて普通にできる
1関数10～20行にしないとテスト不可能
テスト可能にするとだいたいコレぐらいになる。

そこから逆算すれば100個のメソッドは
普通に作ればできる

トレードオフの話をするのであれば、
トレードオフした結果が100個だ

って、やっぱりマジ1関数10～20なんてありえない
50行超えるのがザラなの？　レベルに大きな差があるよ。
自覚だけはしておこう

**仕様書無しさん** · 2018/04/26(木) 00:49:24.26

トレードオフって何と何のトレードオフなんだろう？

最初から短い関数で書けばいいと思うけど、
関数を長くすることで、何のメリットがあるの？

**仕様書無しさん** · 2018/04/26(木) 00:49:29.64

>>678
そもそもテクニカルレビューってなに？
どういう目的でどういうレビューをしてるかによってかかる時間はいくらでも変わると思うけど、
テクニカルレビューがなんなのかわからないから10～20時間が長いのか短いのか評価できないんだけど

**仕様書無しさん** · 2018/04/26(木) 00:51:12.51

ふつうだのレベルだの漠然としたことしか言わんやっちゃ

**仕様書無しさん** · 2018/04/26(木) 00:51:43.19

例えばプロだと間違えずにキーを打つことが高速にできる。

だけど素人だと間違えずにキーを打たなければいけないという
条件をつけると途端にタイプするのが遅くなる。

それと一緒でプロだと普通に作っても関数は10～20行にできるが
そうでない素人だと頑張らないと達成できない

そう、素人

**仕様書無しさん** · 2018/04/26(木) 00:52:05.80

>>685
リンク先読めば？

**仕様書無しさん** · 2018/04/26(木) 00:57:05.65

>>688
わかんないままドヤ顔で引用しちゃったんだな

**仕様書無しさん** · 2018/04/26(木) 01:00:43.49

技術的難易度が低いただのCRUDアプリみたいなものしか作れない人は、いかに綺麗にコードを書くかとか
そういう話題でしか技術っぽい話ができないから、ここぞとばかりに語るよな

**仕様書無しさん** · 2018/04/26(木) 01:00:54.12

>>683
それって20行換算じゃん
最大行で見積もるなんて心苦しいから10行にしてやったんじゃん

2000行でメソッドが200個できて
20000行で2000個だ
100000行で10000個じゃん

この間やったプロジェクトのコードがそんなもんだったけど
メソッド10000個とか明らかに
茶碗が小さすぎる
おちょこに飯もってるみたいにアンバランスだろ

**仕様書無しさん** · 2018/04/26(木) 01:04:35.27

>>689
> わかんないままドヤ顔で引用しちゃったんだな
いや、普通にリンク貼ってるじゃん？

**仕様書無しさん** · 2018/04/26(木) 01:06:27.50

>>691
> この間やったプロジェクトのコードがそんなもんだったけど

お？　ちょうどいいやん。
何ファイルで何クラスで何行ぐらい？

**仕様書無しさん** · 2018/04/26(木) 01:10:21.07

>>693
いいや、コードは100000行でメソッド数は2000ってとこだね
10000とかドキュメント工数単純に5倍になんじゃねーか？

**仕様書無しさん** · 2018/04/26(木) 01:14:29.41

そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか？
設計書に書いた処理とソースの処理を一致させないと説明が面倒だろ

**仕様書無しさん** · 2018/04/26(木) 01:15:20.39

>>691
> 100000行で10000個じゃん
数を大きくして、多く見せたいようだけど無駄ｗ

10万行だろ？ 1ファイル（=1クラス相当）が200行ぐらいなので
500個もファイルがある。メソッド1万個は1ファイル（クラス）20個のメソッド
これは普通の規模だ

そもそもお前、ちゃんとモジュール化できてないだろ？
役割ごとにちゃんとファイル（クラス）分けろ

**仕様書無しさん** · 2018/04/26(木) 01:17:14.11

>>695
> そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか？

実際にコードはそれぐらいになるんだから、
それに相当するメソッドは誰が作り出してるかってことだよ。

設計書にこの程度の数のメソッドが書いてないなら、
その設計書通りに作ると破綻するということを意味する

きちんとレビューしてテストするためには、
実際にそれだけの小ささのメソッドでなければいけないのだからね

**仕様書無しさん** · 2018/04/26(木) 01:25:34.92

実際にコードを書いてる人は、これぐらいの数の関数は作ってるんだよね。

それにたいして、こんなに大量の関数なんて設計できない。
予め想定することなんてできない

っていうのなら、そういうことだよ。
お前らがやってる設計とやらの仕事は、
現場には通用しない仕事だということ

Sヨとか言われてバカにされてるじゃん。
それが事実だってことだよ。

**仕様書無しさん** · 2018/04/26(木) 01:39:49.55

さてリファクタリングの話に戻すぞ？

これが実際の優れた開発の現場だから、最初に全部設計して
最初に考えた関数だけで作るなんて不可能なわけさ
関数の数が多すぎる！って叫んでるアイツ見りゃわかるだろ？

でも実際のコードはそれだけの数の関数がある
この差をどうやって埋めるよ？

最初は設計に書いたとおりの形から始める
実装が進んで次第にコードが膨れ上がっていく
テストできなくなってしまうから、再設計が必要
といっても大きなものじゃない。こまめにやる。

これが開発の中に自然に含まれているリファクタリングだ。
リファクタリングは開発に含まれるもので
別の作業として分離してやるもんじゃない。

**仕様書無しさん** · 2018/04/26(木) 02:27:16.80

糞コードいつか破綻するのはわかってるのに
そのまま売りまっくて最終的には極悪に肥大したクソコードのリファクタリングしろという
まずその事実を知っていて売り続けた開発部長やら上層の誰かに責任取らせろやハゲが

**仕様書無しさん** · 2018/04/26(木) 03:03:40.58

>>699
リファクタリングは「改修」に含まれるものっていう主張はやめたんだねw
視野が狭かったことに気づいてくれて嬉しいよ

**仕様書無しさん** · 2018/04/26(木) 03:26:26.13

ん？やめてないよ。開発の中に改修は含まれている
改修をしない開発会社なんてないんだから

**仕様書無しさん** · 2018/04/26(木) 03:26:52.94

はいはいw

**仕様書無しさん** · 2018/04/26(木) 05:13:46.24

>>695
ソースレベルの設計書なんて書くわけないやろ

**仕様書無しさん** · 2018/04/26(木) 09:34:52.67

ソースレベルの設計書とか言ってる奴はまだマ歴1ヶ月なんだから優しくしてやれ

**仕様書無しさん** · 2018/04/26(木) 09:51:20.89

つまり

1. テスト可能なメソッドは十分短いものである
2. 設計でそれらを全て洗い出すのは無理

ってことなんだよね

これは重要な大前提では？

**仕様書無しさん** · 2018/04/26(木) 09:52:44.36

>>705
世の中には、設計で洗い出した関数しか作らない
作れないプロジェクトがあるらしい

そういうプロジェクトが破綻するのは目に見えてる

**仕様書無しさん** · 2018/04/26(木) 10:30:15.01

ソースレベルの設計書ってなに？詳細設計よりもっと細かいやつ？
アセンブラ時代のフローチャートはほぼソースとイコールだったけど

**仕様書無しさん** · 2018/04/26(木) 12:27:07.55

>>707
それくらいで破綻しないよ、昔の人の多くはそれでやってたんだから
破綻するなんてのは、誰にでもできるがゆえに参入障壁が低く競争過多な世界で納期に追われてる奴の発想笑

**仕様書無しさん** · 2018/04/26(木) 12:31:16.98

破綻はしないが非効率的すぎるわな

**仕様書無しさん** · 2018/04/26(木) 12:57:21.34

設計で関数を洗い出すのはいいんじゃねーの？
ソースは完全にプログラマに任せるスタイルなのか、ある程度は監視するスタイルなのかの差だと思うよ
個人の技量に任せたら関数の切り出しするやつとしないやつで差がですぎてソースが混乱する

**仕様書無しさん** · 2018/04/26(木) 15:10:37.16

そこまで細かく詰めるならその場でコードまで書いてコンパイルと簡単なユニットテスト通しちゃえよ
少なくともインターフェースとスタブは書けるだろ

**仕様書無しさん** · 2018/04/26(木) 17:56:23.04

>>712
それをやることになんの意味が？

**仕様書無しさん** · 2018/04/26(木) 18:26:57.92

>>713
無駄な工数を省いた上に戻りも減らせる

**KAC** · 2018/04/26(木) 20:18:39.67

>>712
コードを書かなきゃ必要な関数を洗い出すこともできないのは最近の風潮だよな

大規模なチームで設計するときにも、
各自が関数洗い出したのを持ちよって全体最適化とかしてないだろ？

普及している手法にはメリットやデメリットがあるのは当たり前
色々な開発手法知らないと最善策見つけられんだろ

**仕様書無しさん** · 2018/04/26(木) 21:06:08.65

昔に比べりゃ関数作るのはアホみたいに簡単になった
CollectionやらThreadやらStringやら
大体コアになるもんはありものが揃ってるし

**仕様書無しさん** · 2018/04/26(木) 21:57:25.51

設計書ってパンチカード時代の名残だぞ
そんなものを未だに盲信してるなんて滑稽だ

**仕様書無しさん** · 2018/04/26(木) 22:34:16.48

デシジョンテーブルは書くやろ？

**仕様書無しさん** · 2018/04/26(木) 22:43:24.25

>>718
そうやってすぐコード以外のなにかに逃げようとすんなよSEさんよ

**仕様書無しさん** · 2018/04/26(木) 22:52:07.11

そらDBからデータを取り出してブラウザに返すだけのアプリに設計書なんていらんわな

**仕様書無しさん** · 2018/04/26(木) 22:59:08.51

二人以上で作業するなら電卓アプリでも設計書いるわ

**仕様書無しさん** · 2018/04/26(木) 23:20:45.92

>>720
メモリからデータを取り出して画面に表示するだけのアプリばかりでは？

**仕様書無しさん** · 2018/04/26(木) 23:44:04.93

DBからデータを取り出してブラウザに返す仕事なんて、専門教育を受けてない文系でもこなしてるという事実

**仕様書無しさん** · 2018/04/26(木) 23:45:51.71

リファクタリングの話が盛り上がるのは、文系でも参加できるから

**仕様書無しさん** · 2018/04/26(木) 23:52:49.47

文系が参加って、技術的な話での参加じゃないじゃんｗ

**仕様書無しさん** · 2018/04/26(木) 23:57:54.18

>>723
宇宙ロケットのネジだって高卒が締めてるにちがいない
そんな理屈で仕事の難しさがわかるものか

**仕様書無しさん** · 2018/04/27(金) 06:18:08.07

設計書なんてコードから生成するもんだろが

**仕様書無しさん** · 2018/04/27(金) 07:15:01.31

>>727
そのコードを最初に、どうやって書く訳？

**仕様書無しさん** · 2018/04/27(金) 07:24:26.55

エディタ開いてタイプしろよ
そんなことも言われなきゃわからん？

**仕様書無しさん** · 2018/04/27(金) 12:13:18.45

>>729
お子ちゃま？

**仕様書無しさん** · 2018/04/27(金) 21:44:36.77

>>728
それ辿るとBIOSまで行くぞいいのか

**仕様書無しさん** · 2018/04/27(金) 21:54:27.71

すでに存在するものまで遡らなくていい

**仕様書無しさん** · 2018/04/27(金) 21:57:24.49

リファクタできない無能には9連休なんてないんだろうなww

**仕様書無しさん** · 2018/04/27(金) 22:13:06.31

明日からリファクタリングのために9連勤です
この工数がなければ休めたのに

**仕様書無しさん** · 2018/04/27(金) 22:20:26.31

ほらな。なんどもリファクタリング単体の作業は間違ってる。
ふつうの開発（改修含む）に含まれているものだ。
と言ってるのに、やっぱり理解できていない
完全に間違いが身にしみてるんだろうな

**仕様書無しさん** · 2018/04/27(金) 22:50:04.81

すでに運用中のシステムの保守開発に途中参画して、リファクタリング単体の仕事をやることもありますね。
視野が狭い方には思いもよらないでしょうけど。

**仕様書無しさん** · 2018/04/28(土) 00:55:26.89

>>731
howだけじゃなく、why for why考えれるかが分岐点。

**仕様書無しさん** · 2018/04/28(土) 01:04:45.94

なんで？

**KAC** · 2018/04/28(土) 01:49:53.92

>>735
お前さん、純粋なリファクタリングやったこと無いのな。
どおりで作業量とかリスクとか全く理解していない訳だ。

**仕様書無しさん** · 2018/04/28(土) 02:04:59.74

純粋なリファクタリング（笑）

どこ出典ですかねそれ
お前の最強の純粋なリファクタリングみしてみろよｗ

**KAC** · 2018/04/28(土) 02:37:47.95

>>740
お前は「リファクタリングを改修と併せてやる」事しか知らないんだろ？
「リファクタリングのみ」の評価知らないのに正しく評価できないだろ。

**仕様書無しさん** · 2018/04/28(土) 02:41:55.96

だからどんなもんか試しにみしてみろって言われてんじゃん

**仕様書無しさん** · 2018/04/28(土) 04:13:15.29

>>731
宇宙誕生まで調べるだろフツー

**仕様書無しさん** · 2018/04/28(土) 07:14:45.24

改修準備
調査分析
自動テスト作成
負債返済
利便性向上

少なくともこの5種のリファクタリングを日常的に行う
改修前のリファクタリングしか知らないならまだまだだね