コードの行数を減らすと生産性があがりバグも減る [転載禁止]©2ch.net

0001仕様書無しさん2015/09/12(土) 10:34:48.38
この事実を発見してから我が社では既存のコードを修正し、
行数(正確にはステップ数)を極限までに減らす修正をすることで
バグを大幅に減らして生産性も大きく上げる事に成功した。

0002仕様書無しさん2015/09/12(土) 11:41:44.60
>>1
可読性まで犠牲にして逆にバグが発見でき無いコードにならんようにな。

0003仕様書無しさん2015/09/12(土) 14:50:35.49
縦スパゲッティか横スパゲッティの違いじゃないの?

0004仕様書無しさん2015/09/12(土) 14:56:15.81
できるだけ改行しなければいいのか。

そんなソースコードとは関わりたくないが。

0005仕様書無しさん2015/09/12(土) 15:09:44.46
全部1行で書けば良いんだな。

0006仕様書無しさん2015/09/12(土) 16:24:51.96
アホやw

行数よりも
コードの見やすさとコメント量の方が大事

誰が見てもわかりやすいコーディング

メンテで差がつく

0007仕様書無しさん2015/09/12(土) 16:30:30.70
でもコードの行数がすくなければ
メンテする量も減るんですよ。

0008仕様書無しさん2015/09/12(土) 17:00:07.26
>>7
そりゃ、処理、機能がないんだからそうなるなw

0009仕様書無しさん2015/09/12(土) 18:01:10.45
コメントも多すぎると、そのコメントのメンテナンスも
必要になるから、コメントも少ないほうがいい。

0010仕様書無しさん2015/09/12(土) 18:06:43.59
>>9
おまえが文章書くのが苦手なのは分かった。

0011仕様書無しさん2015/09/12(土) 18:10:05.58
>>10
どこかまずい所があったら直しますんで、
具体的に指摘してみてください。

0012仕様書無しさん2015/09/12(土) 18:11:48.38
コメント三回は多すぎるわなぁ

0013仕様書無しさん2015/09/12(土) 18:20:39.62
>>12
え?そんだけ?

0014仕様書無しさん2015/09/12(土) 18:54:26.57
こんなん当たり前の話とちがうん?

昔のエライ人が言ってだろう?

「シンプル・イズ・ベスト」

簡単なモノは壊れにくい。複雑なモノほど壊れやすい。
これはプログラムコードにも当てはまるんよ。

俺はもう設計屋だから、コード書かせるときに必ず若いもんにこれ言うわ。

0015仕様書無しさん2015/09/12(土) 19:50:30.60
>>14
その当たり前のことが出来ないんだよね。
ソフトウェアの難しいのは、
バージョンアップしていく所。

大きい物と小さい物は作り方が違うんだけど、
小さく作って大きくしていく時に、
既存の部分を大きい作り方に直さないといけないんだけど、
「既存の部分に手を付けるな」とかいう馬鹿な奴が
指揮をとると、どんどん複雑になって手がつけられなくなる。

既存の部分を修正すれば、1.1の量で済むことが、
手を付けれないからコピーして、2になる。

0016仕様書無しさん2015/09/12(土) 21:44:56.56
本当に手を付けられないコードは、ある。

コードに手を入れればコード増加は少ないだろうが、リグレッションテストの工数が増えるだろ?

どっちの工数が少ないか秤にかけ、コードに手を入れない事は、フツウにあるだろ?


どっちがいいかは、プログラマには関係ないことだ。

0017仕様書無しさん2015/09/12(土) 22:05:13.11
> リグレッションテストの工数が増えるだろ?

そうならないように自動化すればいい。

結局オレが言ってることと一緒で、
手を入れるから増えるのではなく、
手遅れになってるから増えるんだよ。

0018仕様書無しさん2015/09/12(土) 23:42:51.35
>>16
> どっちがいいかは、プログラマには関係ないことだ。
いや、プログラマが判断することだろ。

0019仕様書無しさん2015/09/13(日) 00:11:27.61
>>1
生産性の定義すら提示してないから、もともと議論する気はなさそうだな。

0020仕様書無しさん2015/09/13(日) 00:22:41.16
生産性の定義なんか必要あるのか?

0021仕様書無しさん2015/09/13(日) 01:01:54.35
自動化なんかしたら工数減るだろ!

0022仕様書無しさん2015/09/13(日) 04:20:58.66
シンプルなソースと行数は相関関係がないと思うんだが
一行に纏めて読みづらいif文よか5行でも読みやすい方が
保守工数は減るんでね

0023仕様書無しさん2015/09/13(日) 10:14:22.51
>>19
単位時間当たりの生産量だろ?プログラマなら、単位時間当たりの
コーディング量+テスト量って事になる。

0024仕様書無しさん2015/09/13(日) 18:00:38.85
>>22
共通関数用意してるのに使えないから誰も使わなくて至る所で同じような処理が行われてるとか、
しかもそれが微妙に違うから各モジュールでデータをやり取りするときに変換かけないといけないとか
そういうのは?

0025仕様書無しさん2015/09/13(日) 18:20:29.09
つまりなんだ、このスレはソースコードの負の遺産の話でしょ
ゴミや糞は片付けよう!

0026仕様書無しさん2015/09/13(日) 18:20:46.50
少ない行で書けるシンプルなコードを書けということで行数を減らすのが目的ではないよな

0027仕様書無しさん2015/09/13(日) 19:26:52.62
結果的に行数が減るだろ?

0028仕様書無しさん2015/09/13(日) 21:06:13.85
行数が問題なんじゃねえよ

instructionが少なくなるように書けっつってっだろ?

0029仕様書無しさん2015/09/13(日) 23:10:18.70
>>28

>>1
> 行数(正確にはステップ数)を
を読んでますか?

0030仕様書無しさん2015/09/14(月) 01:53:05.12
ワンライナーってやつか

0031仕様書無しさん2015/09/14(月) 07:09:08.63
>>29
はあ?
instructionだよアホ

頭ん中で簡単なアセンブリしながら書けっての

0032仕様書無しさん2015/09/15(火) 02:02:28.77
if文に関数コール埋め込んだりすると行数は減るがデバッガで追いにくくなるんだが

0033仕様書無しさん2015/09/15(火) 08:42:35.42
三項演算子とかも二重三重にまとめ書きして行数減らすのが推奨?
解読困難になるけど

0034仕様書無しさん2015/09/15(火) 12:33:59.71
>>32
最近はデバッガで追うようなことはしなくなってるよ。
まずはテストコードが書けるようなシンプルな関数を作る。
テストコードがあればデバッガはほとんど必要ない。

0035仕様書無しさん2015/09/15(火) 20:55:41.82
コーディングスタイルで行数を減らすって話じゃないだろ
その機能を実現するのに最適なロジックを選択したら行数も減るってことの裏返しを言ったんだよな?>>1

0036仕様書無しさん2015/09/15(火) 22:26:56.30
>>34
いいこと言うなあ
その通りだよな

0037仕様書無しさん2015/09/16(水) 00:26:51.04
>>20
お前だけ、経営者が決めた生産性でやってれば良いんじゃね?

0038仕様書無しさん2015/09/16(水) 01:38:23.18
>>34
テストが通らないときはどうするの?

0039仕様書無しさん2015/09/16(水) 04:29:24.38
>>38
ソースコードを眺めて(セルフレビュー)して
間違いを見つける。

これができない=コードが複雑 ということ

0040仕様書無しさん2015/09/16(水) 06:56:26.57
>>39
のんびりとした開発してるんだね

0041仕様書無しさん2015/09/16(水) 07:34:06.22
ただの裏方データ処理ならいくらでもシンプルにできるだろうけど
GUIが入ると人間の曖昧性を処理しなきゃいけないから
コードをシンプルにすればするほどゴミUIに近付いていく

0042仕様書無しさん2015/09/16(水) 08:08:20.95
>>40
デスマ乙。

0043仕様書無しさん2015/09/16(水) 10:38:38.57
>>40
コード読むとのんびり?
あんた、他人がコードレビューしてないの?
読むのに時間がかかるコードだから?
終わってるねw

0044仕様書無しさん2015/09/16(水) 10:56:39.34
眺めるならテストコードとパターンだろ。
テスト結果が合えば終わり。
合わなきゃテストパターンから原因箇所は特定できる。
お前のセルフレビューが正しいって保証はどこにあんだよ。

0045仕様書無しさん2015/09/16(水) 13:12:44.83
>>43
レビューはデバッグの時間じゃないぜ

0046仕様書無しさん2015/09/16(水) 13:39:49.39
>>45
そうだよ?

レビューとデバッグは両方やるし、その両方でコードを読む。
だからコードはスムーズに読めるに、なっていなければならない。
コードは解析するものじゃない。

デバッグで解析は楽ですーっていっても、
レビューでコードを読むわけで、コードを読む=のんびり。であるなら
まずその問題を解決しなければならないよね?

で、その問題が解決できれば、コードを読んでバグの修正もできる。

0047仕様書無しさん2015/09/16(水) 15:00:27.70
>>46
問題にしているのは、コードを読む時間ではない。
バグの修正にデバッガを使わないことで無駄になる時間を問題にしている。
あるバグを修正するのに、デバッガを使えば1分で原因が特定できたのに
使わなかったために原因の特定に10分かかった場合は、9分間給料泥棒
やってたことになる。
30分コード見ても原因が特定できずに、結局デバッガ使うことになったら
30分まるまる給料泥棒だ。

0048仕様書無しさん2015/09/16(水) 15:13:17.77
>>47
そもそも、デバッガを使っても
時間は短くならない。

0049仕様書無しさん2015/09/16(水) 15:17:56.63
>>48
そりゃ酷いコードだ

0050仕様書無しさん2015/09/16(水) 15:31:48.72
>>49
逆w

酷いコードだと
中で何やってるかわからないから
デバッガ使って動かしてみないとわからない。

ちなみに基本的にコードレビューというのは
実行しないで行う。

0051仕様書無しさん2015/09/17(木) 07:28:06.59
主な使い捨て実態派遣作業
・データ > ロジック
・簡単ロジック
・大量データ
・フレームワーク
・Web
・DB
・SE適性不要
・IT資格不要
・大卒資格不要
・文科系対象
・体育系対象
・業務系処理
・商業系業種

0052仕様書無しさん2015/09/18(金) 21:01:01.79
同じコードを2度書くな
大切なことだからもう一度書いとくよ
同じコードを2度書くな

コードの行数は減ることが多い
単体レベルのテストは減る
同等のコードなので生産性は上がらない
コードが分散しないのでバグは減る

同じコードを2度書くな(大切なのでry
違和感があるときはリファクタリングのタイミング

0053仕様書無しさん2015/09/19(土) 10:38:44.77
>>52
二度以上書かないとならない数行のコードなんて普通にあるから。
おまいの書いた内容程度の行数なら何回でも同じコードを書いてもいいよw

0054仕様書無しさん2015/09/19(土) 11:09:54.23
類似性のある複数のコードは、相違点だけを引数とかで吸収するようにして纏めてしまえ、てことなんでしょ

纏め方も、サイズ重視か速度重視かで関数なのかマクロなのか変わるだろうけど

0055仕様書無しさん2015/09/19(土) 11:27:10.06
そんな意味の無い関数作るなw
マクロは引き継ぎ者が迷惑する。

0056仕様書無しさん2015/09/19(土) 11:58:18.51
>>52
大切なことだから何度も同じコードを書いてるってこと?

0057仕様書無しさん2015/09/19(土) 15:20:39.29
つべこべ言わずにDRYになれよ

0058仕様書無しさん2015/09/19(土) 15:37:44.61
>>54
似てるからまとめました
は後でメンテするときに非常に迷惑。

0059仕様書無しさん2015/09/19(土) 15:38:44.41
むしろ、似てないけど同じ意味だからまとめましたを推奨すべき

0060仕様書無しさん2015/09/19(土) 15:40:47.41
いや、まとめちゃいかんな。
同じインタフェースにしましたにすべきだな。

0061仕様書無しさん2015/09/19(土) 17:04:29.25
うむ、コピペ推奨だな

0062仕様書無しさん2015/09/19(土) 18:44:30.51
コピペはそれはそれで間違えるんだよな
コピペのあと一箇所変更しないといけない、みたいな時に変更忘れたり間違えてたり

0063仕様書無しさん2015/09/19(土) 19:17:06.65
論理的凝集・・・
全然ダメじゃん

0064仕様書無しさん2015/09/19(土) 20:56:12.34
DRYの法則とか人から聞かないとそういう考え方が
存在するっていうのすら分からんからなあ。

0065仕様書無しさん2015/09/19(土) 23:32:16.30
大体、ロギングとかで困るな。
プロキシ作ってやるのがええけど、めんどいよな。

0066仕様書無しさん2015/10/23(金) 09:27:10.14
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

0067仕様書無しさん2015/10/26(月) 06:17:13.37
アプリケーションの生産性と、
アプリケーションを構成するソースコードの情報エントロピー
の相関から情報理論を組み立てている人がいるよ。
その人は今、その情報理論に基づいて、
ttps://cooplights.info
でライセンスやアーキテクチャを作っているみたいだけど、スレ主は注目する価値があると思うよ。

0068仕様書無しさん2015/10/26(月) 06:23:57.53
>>67
その人にサイトの可読性が悪いって伝えておいて

目がチカチカする

0069仕様書無しさん2015/11/22(日) 08:40:51.32
【 オンラインTCGエディター 】 >>1

デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。

例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト(エディター)。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーローなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック:ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ!って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。

設計思想は 《 RPGツクール 》 が良いかな?  他に、優れたエディター有ったら挙げてみて。

個人や企業などのベンダーが提示する開発費(見積もり)で折り合えば、発注する。

エディター群から基本コンセプトを絞り込む(もちろんオリジナルで優れた新ネタが有れば導入する)。

遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述3つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。

各社TCGを再現するテストプレイ ⇒ 更に改良や修正。

機能制限した下位版を5万円以上で発売 + デュエリ−グ用に改造した上位版でサーバー稼動=営業開始。

下位版の改造および商用利用には、別途で当社との契約が必要。

さ〜て、製作ベンダー見つけよっと!ww(クス
http://wc2014.2ch.net/test/read.cgi/entrance2/1447639727/-18

0070仕様書無しさん2015/11/22(日) 11:00:29.43
転職の際に必ず思い出してください。
下記の条件が全て当てはまる会社にご注意下さい。

・IT系 in 東京
・転職会議で2.5点
・転職会議の「その他>2ch情報」の欄で過去の労基2chスレが表示される

0071仕様書無しさん2016/02/11(木) 16:03:13.23
age

0072仕様書無しさん2016/02/16(火) 23:19:25.13
職種にもよるが業務系であればコードの整理よりも扱ってるデータの整理が最優先。
データを整理・管理・保守しやすい形にすればコードは自ずとスマートになる。

コードは結果だお。

0073仕様書無しさん2016/02/18(木) 19:35:31.47
それをデータ中心設計といってだな。

0074仕様書無しさん2016/03/13(日) 08:09:30.96
残業SEは大迷惑!

時間外労働違反となる
契約に作業期限はない
契約の延長がなくなる
健康障害をもたらす
対人障害をもたらす
能力評価が低下する
生産評価が低下する
時間報酬が低下する
学習時間が減少する
副業時間が減少する
訴訟が増加する
失業が増加する
貧困が増加する
独身が増加する
早死が増加する

0075仕様書無しさん2016/04/22(金) 04:24:44.03
同じような処理はメソッドにまとめろってことだろ
それはそのとおりだ

新着レスの表示
レスを投稿する