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

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

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

**仕様書無しさん** · 2018/04/24(火) 11:20:18.41

常に機能追加や改修しているようなソフトウェアであればリファクタリングは有効
一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ

つまり、アマゾンドットコムみたいに常に機能追加や改修が行われる投資対象であればリファクタリングで機動力を確保するのは理にかなってる
逆に家電に代表されるような組み込み系、もしくは制御系のような、機能追加や改修の頻度が低いものであればリファクタリングする意味は相対的に小さい

お金をつぎ込めばつぎ込むほどリターンがあるのであれば、CIの中にリファクタリングを入れてしまえばいいだろう
リファクタリングの結果がすぐに出やすく、デメリットであるリファクタリング起因の不具合についても
改修が多ければ多いほど、リファクタリング起因の不具合減産と相殺されるからだ

リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ
これらの分野は製造工数とテスト工数の比でいうとテスト工数の割合が大きい
つまり、リファクタリングによって過大なテスト工数が必要となってしまい、リファクタリングのメリットが吹き飛んでしまう
しかしながら動いている箇所はいじらない方針もいつまでも続くわけじゃない
いつかのタイミングで全面リプレースするか、リファクタリング（もはや資料もなく知っている人もいない）を行うことになる

**仕様書無しさん** · 2018/04/24(火) 12:15:51.10

リファクタリングによって設計が改善されたと思ってるのはやった本人だけとかありがち

**仕様書無しさん** · 2018/04/24(火) 13:06:03.44

>>583
うちもそうだよ？
課レベルのシステム、部レベルのシステム、社レベルのシステム
があって、それぞれの長が変わったらシステムの仕様変更が最初の長の仕事になってる。
システムの見直しと再設計って、その部署の現在運用を把握するのに最適という理由で。

**仕様書無しさん** · 2018/04/24(火) 13:34:56.47

それはそのシステムで業務効率化はされてるんか...?
もはやマニュアルってレベルだろそれ
エンジニアしか理解できない仕事のマニュアル。

**仕様書無しさん** · 2018/04/24(火) 13:49:15.67

まず業務があってシステムを作るべきか　※日本風
システムのあわせて業務を再構築するべきか　※欧米風

どっちがいいんだろうね

**仕様書無しさん** · 2018/04/24(火) 14:48:59.76

>>590
欧米は、システムに最初から経営方針や業務設計を盛り込んでるだけだよ？
日本と欧米に差はない。
あるのは、システム開発を速攻で内製で仕上げているか否か。

**仕様書無しさん** · 2018/04/24(火) 15:14:51.24

>>591
国内で内製やった7&iホールディングスが大コケしたけど

**仕様書無しさん** · 2018/04/24(火) 18:11:05.66

>>592
セブンミール時代からたまに使ってるけど、たしかに使いづらくなった。
けど、冷静に考えると。今のレベルのシステムを一応作れたなら。元々のシステムも実装できる。

運用方針を新システム化した際に「顧客のニーズ」を取り入れるために店長に聞いたら。
「店長のニーズ」を取り入れちゃったんだろうｗｗｗ

ただ、「店長のニーズ」も旧システムで現実に起こってる問題の結果で、
さらに、現在、店舗自体が人手不足に陥ってるから配達要員、商品供給ライン等で
旧システムであっても実際には様々な遅延等々があったんだろう。

おそらく、システムの使いづらさの原因は、まさかのアナログな「現場の配達に要する人手不足」だと思うわｗ

**KAC** · 2018/04/24(火) 18:20:09.23

>>590
本来なら日本風がいいんだけど、
パッケージ売りの欧米風の方が格段に安いから。

**仕様書無しさん** · 2018/04/24(火) 18:32:53.31

リリース前のコードまで
ガチガチに変更管理してる
現場ってあんの？

**仕様書無しさん** · 2018/04/24(火) 19:13:54.37

>>595
は？折角テスト終わったのに変更すんな
殺すぞ

**仕様書無しさん** · 2018/04/24(火) 19:16:58.60

>>596
は？
ボタン押すだけだろ

**KAC** · 2018/04/24(火) 19:17:09.86

>>595
リリース前も後も管理するのは当たり前

**KAC** · 2018/04/24(火) 19:19:03.12

>>597
お前さんが試験したこと無いのはよく分かった

**仕様書無しさん** · 2018/04/24(火) 19:22:18.29

ボタン押すだけとか前時代的すぎるwww
今はもうpushするだけの時代だぞ爺さん

**仕様書無しさん** · 2018/04/24(火) 20:26:27.79

>>600
変更中で清書する前のコードならpushしねえよ

**仕様書無しさん** · 2018/04/24(火) 20:45:57.41

>>586
> 常に機能追加や改修しているようなソフトウェアであればリファクタリングは有効
> 一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ

やっぱりまだ勘違いしてる。

リファクタリングが、一度作った後に行うものだと、まだ勘違いしている。

一度目であっても、作ってる最中に、こまめにリファクタリングしていくもの
という考えがどうしても理解できないらしい

それとも詳細設計というものがあって、そこに最初から
すべてのクラス、関数、引数がプライベートのものまで
全部網羅されてるとでもいうのか？

**仕様書無しさん** · 2018/04/24(火) 20:48:25.79

>>601
> 変更中で清書する前のコードならpushしねえよ

書きかけではなく本当に清書？
清書前でも理解しにくいだけで動くが、
理解しやすくために清書するってこと？

ならそれはリファクタリングに相当するね
もちろんちゃんとした手順でやらないといけないが

**仕様書無しさん** · 2018/04/24(火) 20:49:37.09

>>596
> は？折角テスト終わったのに変更すんな

それなら、テストする前にリファクタリングすればいいんだよ

**仕様書無しさん** · 2018/04/24(火) 20:52:29.27

>>587
> リファクタリングによって設計が改善されたと思ってるのはやった本人だけとかありがち

そういうレベルの人たちしかいないなら、
コードメトリクスを測定するツールで客観的に
判断したほうがよいだろう。

**仕様書無しさん** · 2018/04/24(火) 21:01:28.79

>>602
ちゃんとした手順がなにを指してるか知らんが、ファウラーのリファクタ本だとしたら
リリース前のコードに対してあんなまどろっこしいことせんよ

**仕様書無しさん** · 2018/04/24(火) 21:10:16.77

>>605
ツールで測定できるレベル（抽象度的な意味で）じゃ設計の善し悪しは測れないんで

**仕様書無しさん** · 2018/04/24(火) 21:15:31.28

>>586
> リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ

そういう分野で、循環的複雑度100オーバーの関数1000個のソフトウェアを
修正させたらどんなにテストしていたとしても修正のたびにバグ入れると思うよ。
どうやってこの問題を解決する？

何十回、何百回もテストするかい？それこそ過大なテスト工数だよね。
テストを一回やったらバグが全て見つかり一回の修正で全部直る。
修正後の再テストはバグが見つかった所だけでOK。とか思ってないか？

参考循環的複雑度は
　50以上でテスト不可能バグ混入確率70%
　75以上でいかなる変更も誤修正を生むバグ混入確率98%
と言われている。10以下にするのが普通

とここまで書いて思ったが、どんなコードが良いコードなのかわからない人は
実際にダメなコードの複雑度がどれくらいなのか具体的な数値を示さないと
わからないだろうな。どこかにサンプルないだろうか

**仕様書無しさん** · 2018/04/24(火) 21:16:39.31

>>607
> ツールで測定できるレベル（抽象度的な意味で）じゃ設計の善し悪しは測れないんで

だから自分たちで、判断できないレベルの人ばっかりなところだって、
ツールは測定するため物で、ちゃんと測定できますってｗ

完璧なものはわからないかもしれないけど、少なくともツールで
大きくだめだって言われた所は、マジでだめ

**仕様書無しさん** · 2018/04/24(火) 21:17:39.58

>>606
> リリース前のコードに対してあんなまどろっこしいことせんよ

しないから、エンバグするんでしょ？

**仕様書無しさん** · 2018/04/24(火) 21:21:24.00

>>609
そういうことじゃないです
ツールには文脈がわからないと言っています
コーディングじゃなくて設計の話です

**仕様書無しさん** · 2018/04/24(火) 21:24:58.14

>>610
開発中の話だからエンバグしたっていいんだよ、どうせすぐに検知できるし
開発中のテストと品質のためのテストは目的が違うので

**仕様書無しさん** · 2018/04/24(火) 21:26:26.40

リファクタリングとかやっちゃうお前らだと、給料っていくらぐらい？

**仕様書無しさん** · 2018/04/24(火) 21:34:10.80

>>602
そうだよ
トップクラスの企業になると詳細設計で全てが完全に定義されててコーディングは規則に従い変換して写すだけ
なのでリファクタリングの出る幕はない

**仕様書無しさん** · 2018/04/24(火) 21:54:55.03

>>614
証拠見せて

**仕様書無しさん** · 2018/04/24(火) 21:57:22.40

トップクラスの企業ってGoogleとかじゃないの？

**仕様書無しさん** · 2018/04/24(火) 22:10:14.59

自分の書いたコードが汚すぎて死ぬ

**仕様書無しさん** · 2018/04/24(火) 22:21:22.68

>>615
転職

**仕様書無しさん** · 2018/04/24(火) 22:23:41.34

>>618
今より落ちるのはちょっとｗ

**仕様書無しさん** · 2018/04/24(火) 22:40:05.38

>>614
（奴隷度）トップクラス

**仕様書無しさん** · 2018/04/25(水) 00:01:43.85

トップクラスの企業って言葉で連想するのはメーカー子会社の協力企業あたりだな
GoogleやAmazonを表現するのにトップクラスの企業って言葉じゃ足りない

**仕様書無しさん** · 2018/04/25(水) 00:12:23.85

株式会社トップクラス

**仕様書無しさん** · 2018/04/25(水) 00:27:05.94

FAMGAは企業を超えたよくわからないシステム

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

>>602
リリース前のアルファ版未満モック以上版なら、デグレ上等でノリと勢いでガンガン変わってくだろ。
わざわざリファクタリング手順など踏まんで、テスターとペアになって開発した方が良い

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

>>613
手取り35

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

組織と自分の履歴サーバを別けている
日本のリファクタリングあるある

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

人気グループ「ＴＯＫＩＯ」の山口達也メンバーが、自宅マンションの部屋で女子高校生に無理やりキスをするなどの行為をしたとして、警視庁は強制わいせつの疑いで書類送検しました。

全文は以下
https://www3.nhk.or.jp/news/html/20180425/k10011417181000.html

**KAC** · 2018/04/25(水) 18:02:35.15

>>626
分けるメリットがなんかあるの？

**仕様書無しさん** · 2018/04/25(水) 18:20:49.80

>>628
メリットなんてないよ

PUSHに上司の承認が要る部署とか以外は

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

レビューしないのかな？

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

ぬおーん

**仕様書無しさん** · 2018/04/25(水) 22:46:40.90

コード読めないからレビューできないんじゃね？ｗ

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

ここで一部の人に衝撃的な事実を言っておきますね。

レビューができるコードっていうのは1関数あたりだいたい10～20行程度までです。
50行なんて超えたらぜったいにレビューできません。

人の能力の問題じゃなくて、レビューできないコードです。
解析が必要になったら、それはレビューとは言えません。

だから1関数当たり10～20行になっていなければいけません。
これを超えるものがざらにあるようなプロジェクトは失格です

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

10行って引数の多いメソッドの前準備してるだけで終わるレベル
俺は200行程度まで許容範囲

**KAC** · 2018/04/25(水) 22:57:37.78

>>633
レビューできない根拠が
理由にすらなってない訳だが…

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

レビューは通過儀礼だから
コードなんて誰も見てない
見てるのは担当者の活舌

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

Ｗｅｂ業務なら少々長くても大丈夫
帳票とかＤＢとかでっかい構造体にいっこずつ値入れてるだけだから
長くても込み入ってないことおおい

組み込みとかどうだろう

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

>>634
許容とかそういうレベルじゃない。
どんだけヘボならそんな長いコードができるんだ？レベルだよ。
これは本当の話

>>635
マジレビューできないってｗ

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

関数の行数よりネストの深さとスコープの方が大事

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

>>636
> コードなんて誰も見てない
だろ？
長いコードは読まない。
レビューできないから

>>637
ウェブ系でもありえないな。

ほんとね、一人前のプログラマか、ゴミかどうかは
1関数10～20が普通って聞いて信じられるかどうかでわかるよ

比較的大規模なウェブアプリの例。みてみろ。コレがレビュー可能なコードってもんだ
https://github.com/gitlabhq/gitlabhq/tree/master/app

50行とか超えてるコードばかり見てる人、↑これみれば、
50行なんて長いコードはレビューできないのが当たり前ってわかるよ。

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

小さなクラスやメソッドにするのはいいことだけど、適切な命名ができるのが大前提
英語が苦手な奴はデタラメな名前をつけるから余計わかりづらくなる
形だけ小さくして満足してるバカが多い

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

>>641
それは当然だけど、50行とか平気で超えてるようなコードを書く人たちに
現実ってものを突きつけたいと思ってね。

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

どうせ携帯のちっこい画面用だろ

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

リファクタリングするとバグがーとか言ってるのは
おそらく50行とか平気で超えてるような所だろう

レベルに大きな差があるから話が通じない。

1関数たったのこれだけしかないから、
この関数が動くかどうかテストするのは簡単なんだ

**仕様書無しさん** · 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

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