今までみた絶望的なソースコード [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2015/04/17(金) 23:00:30.63

今井氏：ソースコード公開は、社長のティム（*2）の意向です。彼はバリバリのプログラマーで、初期の「Unreal Engine 1」を
1人で書いた人ですが、若い時に雑誌に載っていたコードを書き写して勉強したそうです。それで今の若い人にも、プロのソー
コードとはこういうものだというのを見せたいという願いがあって、ソースコードを公開しています。本当に今のゲーム業界の
事情を憂いてる1人だと思います。（*2）Epic Gamesの創業者兼CEOであるTim Sweeney氏

出村氏：読みやすいコードですよ。「C++」というのは、黒魔術（高度な計算）が多くなりがちな言語ですが、
そういうこともなく、すっきりしていて目的の機能も探しやすい。解読しやすいコードなので、確かにお手本になると思います。

僕は初代のゲームボーイからプレイステーション 2の頃くらいまでゲームプログラマーだったのですが、ゲームプログラミングでは
必ず数学が出てきます。行列とか三角関数とか。もちろん今でもまったく不要になったわけではありませんが、そういう知識の
重要性は薄れてきていると思います。「Unreal Engine」では特にそうです。
http://game.watch.impress.co.jp/docs/interview/20150417_698349.html

初級者から中級者へ昇格する時期は、ほぼどのようなソースコードでも読める程度にプログラミング言語に精通し、
また偉いプログラマーの提唱したデザインパターンも一通り理解したくらいの時期である。

すると、プログラミング言語の持つあらゆる機能と、偉いプログラマーの提唱するあらゆる技術を使わねばならない
という思い込みが発生する。そしてHello Worldにまで崇高なオブジェクト指向や壮大なデザインパターンを
適用しようとしだすのである。

その結果、
* 大量のクラス
* 迷路のような変数渡し
* 底なしに深いネスト
などといった凄いものが生まれる。また、条件分岐に三項演算子を乱用するなどの症状も多く見受けられる。
最終的には第三者にとって読みにくい保守性の悪いスパゲッティコードが生成されることになる。
http://monobook.org/wiki/%E4%B8%AD%E7%B4%9A%E8%80%85%E7%97%85

**デフォルトの名無しさん** · 2015/11/14(土) 14:36:18.15

おっと、軽く探したら#defineはダメだっていういい記事見つかったので紹介

http://d.hatena.ne.jp/takehikom/20140807/1407420548

**デフォルトの名無しさん** · 2015/11/14(土) 16:30:08.93

#define ABC 5 + 10

void func(void)
{
int abc = ABC * 10;
print("%d", abc);
}

このパソコンは算数が苦手になったみたいです。
150と表示されません。

………………死ね！

**デフォルトの名無しさん** · 2015/11/14(土) 16:36:15.32

コンパイラさんがどういうことやってるかわかってない人が

**デフォルトの名無しさん** · 2015/11/14(土) 16:53:07.63

コンパイラじゃなくて、余計なことをやってる
プリプロセッサが原因だけどねｗ

**デフォルトの名無しさん** · 2015/11/14(土) 16:56:04.42

プリプロ　何ですか　それ
な方たちがやってるんでは

**デフォルトの名無しさん** · 2015/11/14(土) 20:11:50.05

>>450
extern constにしておけば実体持ってるライブラリを入れ替えるだけで
piの中身が3.14なのか3.1416なのか3.1415927なのかを切り替えてリンクできる
組み込みなんかではここのセクションに特別な絶対アドレスを振っておいて
Sフォーマットのファイル作ってから後で値を書き換えたりする

**デフォルトの名無しさん** · 2015/11/15(日) 10:36:26.12

>>451
いいこと言うね
使う側からは便利に使える反面複雑な使い方してると解析不可
defineはundefで消せるからコンパイル順通りに解析していかないとそのdefineは別の定義かもしれない

**デフォルトの名無しさん** · 2015/11/16(月) 21:09:30.08

>>458
プリプロセッサだけ通せばいいだけだろ
解析不可とかアホか

**デフォルトの名無しさん** · 2015/11/16(月) 23:26:56.71

>>459
小さい規模ならまだしも業務用のでかいのに毎回やるのは非効率
後続の言語が切り捨てたとおり現状マクロは負の遺産
今の時代はフレームワーク使って読みやすいそこそこのものを短期で作ることが求められてるからね

**デフォルトの名無しさん** · 2015/11/16(月) 23:43:11.58

今時の言語にプリプロとか無いよな

**デフォルトの名無しさん** · 2015/11/17(火) 04:44:48.22

>>459
プリプロセッサを通した結果に対して、
コンパイラがエラーを出したとき、

プリプロセッサを通す前のコードみても意味がわからんし、
通した後のコードは自分が書いたコードじゃないし。

プリプロセッサを通した結果に対するエラーから、
プリプロセッサを通す前のコードをどこをどう直せばいいのか
そのつながりを人間が判断するしかなく意味不明になるんだよ。
人間が頭の中で逆プリプロセッサをしなくちゃいけなくなる

**デフォルトの名無しさん** · 2015/11/17(火) 19:22:30.78

>>462
IDEと相性がわるいからね

**デフォルトの名無しさん** · 2015/11/17(火) 20:09:29.80

>>463
IDEはまだましよ。
そういう変則的なものであっても頑張って対応してるから。

問題はテキストエディタを使ってる場合。
そういう細かいところの対応までできてないからなぁ。

**デフォルトの名無しさん** · 2015/11/21(土) 13:08:19.06

Ｃ ( or C++ ) のソースで

#if 0

#endif

でコメントにするのはやめて欲しい。

**デフォルトの名無しさん** · 2015/11/21(土) 13:34:03.37

SublimeTextなどを使って範囲選択して
一気に行頭に//を入れたほうがいい。

**デフォルトの名無しさん** · 2015/11/21(土) 19:54:17.89

>>466
え，便利じゃないか？

**デフォルトの名無しさん** · 2015/11/22(日) 00:13:36.89

>>465
理由を述べよ。
単に嫌うのは、食わず嫌いと一緒。

**デフォルトの名無しさん** · 2015/11/22(日) 00:20:00.47

>>468
自分で考えろ。
考える前に聞くのはバカ。

**デフォルトの名無しさん** · 2015/11/22(日) 00:23:37.90

>>469
単なる食わず嫌いか、納得した。

**デフォルトの名無しさん** · 2015/11/22(日) 00:25:10.28

>>470
バカのうえに早合点のトンチンカンで三冠王だな。

**デフォルトの名無しさん** · 2015/11/22(日) 00:27:24.52

俺の考えが正しいことが証明されたな。
俺の考えはググった程度じゃわからんよ。

**デフォルトの名無しさん** · 2015/11/22(日) 18:12:36.68

>>465
この方式はテキスト直編集や文字列検索の側面から懸念される
しかしメリットもあってコードの切り替えがしやすい
ifdefなら複数箇所修正も一気に元に戻すことも可能
誰かの修正でも消した人間がやってくれていれば修正当時の状態に戻せる
また修正が重なると//はインデントずれるがifの方はズレの発生もないメリットもある
俺はそのコードを検証等で使用する可能性があるかどうかで使い分けてる

**デフォルトの名無しさん** · 2015/11/22(日) 20:44:55.89

デメリットもブロックコメントと同等かそれ以下だと思うがな。
まぁ、ネストが重なるとわかりにくくなるから1レベルに限定されたコメントの方が
いいという意見もあるだろうけど。

**デフォルトの名無しさん** · 2015/11/23(月) 11:31:07.22

うちは//も複数行にわたるブロックコメントも禁止だし
コードのコメントアウトは#if 0 ～ #endifが推奨になってる
Eclipse使ってればこっちの方が楽

**デフォルトの名無しさん** · 2015/11/23(月) 12:46:13.70

>>475
その規約をどうにかしたほうがいいんじゃないか

**デフォルトの名無しさん** · 2015/11/23(月) 17:25:09.75

#if 0じゃ意味が判らんから定数使えや、とエスパーしてみた

**デフォルトの名無しさん** · 2015/11/23(月) 17:28:56.89

またそれかｗ

定型句は意味がわかるから問題ないんだよ。

**デフォルトの名無しさん** · 2015/11/24(火) 00:07:51.39

#define NOUSE 0

#ifdef NOUSE
　　：
　　：
#endif

**デフォルトの名無しさん** · 2015/11/24(火) 01:12:38.90

NOUSEってなんや？ってなるから意味ない。

**デフォルトの名無しさん** · 2015/11/24(火) 01:16:48.61

#if 1 // どっちにしようかな
//速いけど詠み難いコード
#else
//遅いけど判り易いコード
#endif

**デフォルトの名無しさん** · 2015/11/24(火) 07:23:59.50

バージョン管理システムのチケット番号でifdefしてるのは見たことあるわ。
果たして本当に、それでそのチケット番号の状態に戻るのかは誰もやってないと言う。

**デフォルトの名無しさん** · 2015/11/24(火) 19:08:07.34

>>482
同じ個所弄ったらネストしていくのか…？

**デフォルトの名無しさん** · 2015/11/25(水) 21:24:16.64

>>482
戻るかどうかは二の次
一番重要なのはどんな修正をしたかということ
自分はいなくなってもコードは10年20年先の人間も目にすることがあるのだから
バージョン管理でやればいいという声もあるが果たしてそれ20年後に見れるか疑わしい
国際標準でなければ廃れると見たほうがいい
やっておいて損はない

**デフォルトの名無しさん** · 2015/11/26(木) 02:18:49.76

> バージョン管理でやればいいという声もあるが果たしてそれ20年後に見れるか疑わしい

絶対確実に見れる。

**デフォルトの名無しさん** · 2015/11/26(木) 02:19:46.90

見れるというのは読めるということ。

無駄な情報ばかりで、重要な事がわからなければ、
それは「見れない」という。

**デフォルトの名無しさん** · 2015/11/26(木) 02:23:40.75

見れるというのは探し出せるということでもある。

ある事柄に関する修正は、一箇所で終わるとは限らない。
複数ファイルを同時に修正することがある。

複数のファイルに分散された、ある事柄に修正をもれなくすべて確実に
把握できる保証がなければ、それはどんな修正をしたかがわからないということ。

これはファイルのコメントなんかじゃ絶対にわかりっこない。
それはバージョン管理ツールでなければ不可能である。

**デフォルトの名無しさん** · 2015/11/26(木) 02:36:19.49

20年後の人「なんだこの糞コードは・・・当時でもバージョン管理くらいあっただろ！？」

**デフォルトの名無しさん** · 2015/11/26(木) 02:42:53.30

クソコードとバージョン管理に直接の関係はない。
だが、バージョン管理を使えないような奴は
クソコードを書くというのは大体あっている。

**デフォルトの名無しさん** · 2015/11/26(木) 06:03:03.13

>>484
CVSは25歳
SVNは15歳
Gitは10歳

バージョン管理ツールでやればいいな

**デフォルトの名無しさん** · 2015/11/26(木) 07:12:00.03

>>482
バージョン管理システムは手段であって、
本来はその改修モジュールの対応前、対応後のソース一式がまとまってれば文句はないんだよ。
対応後の一式があれば、それは次の対応前の一式だし。
そこをサボって1つのファイルに前後を入れるから意味がわからなくなる。

**デフォルトの名無しさん** · 2015/11/26(木) 10:10:24.97

>>491
小さいアプリならそれでいいだろうけど、
複数人が開発している大きなアプリだと、

1. どうやって各自の変更をまとめるのか？
2. 改修は何百、何千となるが（少なくともバグの数と機能の数以上になる）、それだけの数の「一式」を欲しいのか？

それを実現してくれる手段がバージョン管理システム

**デフォルトの名無しさん** · 2015/11/26(木) 10:34:31.16

>>492
大規模開発してるけど、
各自の変更自体は、そもそもがバージョン管理システム以前の仕組みとして、
変更仕様書書いてスタンプリレーして台帳化までしてるので問題ない。

それだけの数の一式、と言えども、サブシステム毎には別れるし、その中でのモジュール毎にも別れる。
あるモジュールの、rev xとrev yは持っておく、って事だよ。

出荷は、モジュール単位でも出せるけど、基本はサブシステム毎で、さらに言えばパッケージ毎の定期出荷にのせるべきだな、うちは。
サブシステムA ver 1.1は
　モジュール1 rev 1
　モジュール2 rev 1.1
で出来てて、
パッケージ ver 1.2は
　サブシステムA ver 1.1
　サブシステムB ver 1
で出来てるって台帳がある。

実現は紙で1990年代から出来てる。
それを便利にするのがバージョン管理システム。
手段じゃない。道具。

**デフォルトの名無しさん** · 2015/11/26(木) 11:38:27.52

楽したつもりで道具に使われてる奴等多すぎ

**デフォルトの名無しさん** · 2015/11/26(木) 12:23:36.36

言っとくが楽してるつもりは一切ないからな

**デフォルトの名無しさん** · 2015/11/26(木) 13:09:36.25

>>493
では聞くが、

その台帳を検索するのに、どれだけの時間がかかるのか
考えたことはあるかね？

思い出すだろう？大量の台帳の山から
その時の情報を探すのに数日かけたことを。

**デフォルトの名無しさん** · 2015/11/26(木) 13:12:08.20

>>493
ソフトウェア会社なのに、それをコンピュータで
実現してないってのがダメな所だよなｗ

自分の仕事も効率化出来ない（コンピュータ化できない）
会社に他社の仕事の効率化なんてできっこないわけさ。

それをコンピュータ化したのがバージョン管理ツールだからね。

**デフォルトの名無しさん** · 2015/11/26(木) 13:16:44.70

>>494
> 楽したつもりで道具に使われてる奴等多すぎ

>>495
> 言っとくが楽してるつもりは一切ないからな
だよなｗ同じことができる道具。それがあって、
楽できない道具を使うの（手動で管理ｗ）が偉い！って思っちゃう。
体育会系かよｗ　エクセル使うとズル呼ばわりする老害と一緒だ。

同じ道具なら、より効率的に早く楽にできる方がいいじゃん？
バージョン管理ツール使えば、台帳なんかで情報を調べるだけじゃなく、
その時のソースコードに戻すこともまで簡単にできる。

一番重要な事をお忘れか？

最終的に九州から北海道まで歩いていけるから問題ない？
それだけでは全然足りない。どれだけの時間がかかるまで考えてこそプロ。

**デフォルトの名無しさん** · 2015/11/26(木) 13:19:52.08

まあ、あれだよな。

使える形で保存されてないデータは、使われない。
使える形で保存されているならば、使われる。

使われないデータをたくさんためても
自己満足程度の意味しかないわけで。

**デフォルトの名無しさん** · 2015/11/26(木) 13:30:59.58

>>498
それで新幹線と飛行機と船で行けたとして、
「着くのが早いから」って理由で飛行機に乗るのはいいと思うけど
「マイル貯めるために」とか「ボンバルディアの機材こそ至高」ってのは
なんだかなあ、って話っしょ
こういうのはその時にベターなもの使えばいいの

**デフォルトの名無しさん** · 2015/11/26(木) 15:44:00.39

>>500
例え話はわかった。具体的にはどういうことかって話だ。

バージョン管理を使わないと凄く非効率だから
殆どの場合はバージョン管理ツールを使う方がいい。

ただしバージョン管理を使えないという呆れるほど技術力が低くて
使えないものを大量に生成し多くの無駄に時間がかかって、あとで
自分らが苦しむだけなんだが、それを許容するのならば、
手動で管理しするのがベター（笑）ってことだよね。

**デフォルトの名無しさん** · 2015/11/26(木) 15:44:29.61

>>490
VSSやCVSやSVNやら今使ってるの皆無だろ
以降の際に履歴捨ててるだろうし
標準化されない限り結局は短命
Gitも20年先使えてるかわからんしな

**デフォルトの名無しさん** · 2015/11/26(木) 15:44:54.51

>>496
>>497
何言ってるんだ…
実現自体は昔から出来ている、それを便利にするのがバージョン管理システム、と言っているだろ。うちでも使ってるよ。
台帳自体もそっから今は自動で作ってる。便利だよ。
2000年代前半は内製システムだったけど、今は普通にバージョン管理システムとチケットトラッキングシステムだよ。

そもそもリリースノートは台帳から作るからリリースノート見ればわかるし、
わからなくて台帳をなめて、それでもわからなくて、
各文書の山から検索しないとダメな事自体、発生したらヤバい。
同様に、台帳の表題をあやふやにしてると痛い目に遭う。

検索したらわかるっしょ、と適当にする奴居るけどね。
今でも、サーバ、ネットワーク全部落ちてもサポート程度は回る程度に台帳も文書も刷ってるよ。
お陰様で震災でもなんとかなった。

**デフォルトの名無しさん** · 2015/11/26(木) 15:54:46.61

>>502
使ってないだけで、使える。

移行の際に履歴を切り捨てるのは、お前の問題であって、技術の問題ではない。

他に標準化されているものなどない。
紙の管理？ソースコードのコメント？どれも標準化されてない。
今のデファクトスタンダードがgit

Gitから移行することはあっても、Gitがなくならないことは
1982年（33年前）に登場したRCSがまだ使えることからも
歴史が証明してくれている。

**デフォルトの名無しさん** · 2015/11/26(木) 16:42:28.92

20年が短命ならOSは夭逝だな

**デフォルトの名無しさん** · 2015/11/26(木) 18:24:28.50

>>504
うちはパッチ当ててでも使うだろうな。
多分デファクトスタンダードはあるけど、
デファクトスタンダードなんてどうでも良いと思うよ。
管理できれば良いんだから、無理に流行りに乗らなくても。

あと、gitはおそらく向いてないな。うちには。cloneに時間やたら掛かりそう。

**デフォルトの名無しさん** · 2015/11/26(木) 18:51:30.63

> 管理できれば良いんだから、

だからまたｗ

管理できるのは最低限の条件で、
それを素早く確実にやるのがプロでしょ。

出来ればいいんでしょじゃないってｗ

> あと、gitはおそらく向いてないな。うちには。cloneに時間やたら掛かりそう。
ん？ cloneするのは最初の一回だし、ネットワークが遅いなら
特定のディレクトリからでもcloneできるが。

**デフォルトの名無しさん** · 2015/11/26(木) 20:14:42.11

>>504
使ってないなら見てないんだから活用できてないわな
大きな修正にはバージョン管理は当然としてソースにも履歴を残してリスク軽減が当然だと思うんだけどな
そのバージョン管理のソフトも必要なときには使えなくなってる可能性を考えるべきよ
その履歴が標準化されてれば将来もコンバートできたりするんだろうがな
何かに過信してリスク分散もできない会社のシステムなんて怖くて使えないわ

**デフォルトの名無しさん** · 2015/11/26(木) 20:32:29.36

>>508
卑怯ですね。

バージョン管理ツールには、凄くいろんなことを求めて
それが出来ないと悪く言うくせに、

最初から何も出来ないものは、出来なくても文句言わないんですか？

> 何かに過信してリスク分散もできない会社のシステムなんて怖くて使えないわ

リスク管理っていうのはね。コストを考えなきゃだめなの。
ソースに履歴を残すことのデメリットを計算に入れてないから、
あんたの考え方は、考えるに値しないの。

**デフォルトの名無しさん** · 2015/11/26(木) 20:54:13.06

>>507
何言ってるかわからん。
バージョン管理システムに反対してるつもりはない。使ってるし。
ソースにコメントで残す事を肯定もしてない。
素早く確実に出来るに越したことは無いよ。

出来れば良いんだよ。手段なんだから。
やらなくて良いことをやらないと決めるのもプロの仕事。
そう決めるにあたって、もちろん使ってみたり選定したりしてるけどね。
その選定や決断や調査にも工数かかるの。≒お金なの。
知らんで言ってるわけではない。

cloneするのは最初の一回、な。
常駐が入れ替わる度に数ギガのトラフィックか。

空論も良い所。
一回まともな体制のある程度の規模の開発に関わったらどう？

**デフォルトの名無しさん** · 2015/11/26(木) 20:59:18.56

お、このスレでは日頃のストレスをぶつけ合えばいいのか？

**デフォルトの名無しさん** · 2015/11/26(木) 21:13:24.35

>>509
悪く言うつもりはないよ
ただあまりに頼りすぎてるとそれがダメになった時に崩壊するってこと
原発然りデータ分散保存してなかった会社然り
コストカットをやり過ぎた結果が全電源喪失なったの忘れたの？
東日本大震災あってコストカットのために東京にしかデータ残してなくて全データ喪失しましたで顧客は納得するの？
二重に安全策を行っておくくらい基本じゃないか？
余談だが俺の会社に20年前のバージョン管理の履歴残ってるプロジェクトひとつもない

**デフォルトの名無しさん** · 2015/11/26(木) 21:17:07.03

なんかいきなり原発の話しだしてきワロタｗ

それとはぜんぜん違うだろう。

**デフォルトの名無しさん** · 2015/11/26(木) 21:26:25.45

コストを削った代償の話で何も的を外してない
二重の安全策を怠った最も悲惨な事例だよ
高台に電源装置置いとけば事故は防げたんだから
過信といえばまだ二十年もたってないがアップルが経営危機に陥っていた時期に誰が10数年先にマイクロソフト抜いて世界一の企業になると予測できたか？
世の中本当に何が起こるかわからないよ

**デフォルトの名無しさん** · 2015/11/26(木) 21:36:45.91

大きく的はずれだね。
必要ないと思っているものを削減するのと
必要あるものを削減するのとではぜんぜん違う。

また今度は関係ないアップルの話しだすし。
次はISISが戦争を始めるとかいいだしそうだ

**デフォルトの名無しさん** · 2015/11/26(木) 21:55:52.71

原発おじさんはVCSの謎の突然死よりも
部下がこのスレに書き込んでいないかを心配した方が良いと思う

**デフォルトの名無しさん** · 2015/11/26(木) 21:58:43.37

言いたいのは未来を予測できない以上二重以上の策を提供すべきということ
その必要かどうかはこの先ソースを保守する人間が判断するのであって今の人間が決めれることじゃない
20年前のプロジェクトの修正履歴見れるか試みたらすぐわかる話

**デフォルトの名無しさん** · 2015/11/26(木) 22:23:35.43

サンプルでないコーディングで
foo だ bar だ hoge だのと

**デフォルトの名無しさん** · 2015/11/26(木) 22:40:27.99

>>512
うち、20年前のはコメントでの変更履歴がまだあるわww
未だ動いてるのが凄いんだけど。

**デフォルトの名無しさん** · 2015/11/26(木) 23:09:16.39

>>519
うちもコメントやifdef等で残ってるのがある
修正入る部分にこれがあると何となく当時の背景が見えてくるから助かってる
バージョン管理は次々鞍替えして数年分しかない
どこが早く履歴の標準規格化してくれたらもっと分かりやすく差分や経緯を見れるんだけどな

**デフォルトの名無しさん** · 2015/11/27(金) 07:13:44.65

> 修正入る部分にこれがあると何となく当時の背景が見えてくるから助かってる

過去のバージョン見ればいいだけでは？
コミットログを見れば、何をしたのかもわかるし。

**デフォルトの名無しさん** · 2015/11/27(金) 07:14:59.83

> どこが早く履歴の標準規格化してくれたらもっと分かりやすく差分や経緯を見れるんだけどな

差分の見方とコミットログの書き方を勉強しようよｗ

一体、何を標準化しろと言ってるのかわかんね。
お前なら、どういう規格を作るのか言ってみなさい。

**デフォルトの名無しさん** · 2015/11/27(金) 07:29:24.45

>>521
もちろん過去のバージョンと台帳と突き合わせて見ればいいんだろうけど、
そこに変更が入っている事、がソース変更時に読めるのはわかりやすいよ。
今でもチケット番号だけ書いてる。
チケット番号書いとけば、コミット時に拾ってくれて、チケットに対象として載るしね。

**デフォルトの名無しさん** · 2015/11/27(金) 07:45:03.01

> そこに変更が入っている事、がソース変更時に読めるのはわかりやすいよ。
ほぼすべての行に変更は入る。最初から何万行というコードが一気に出来上がるわけじゃない。

> 今でもチケット番号だけ書いてる。

ソースコードには、コードの意味ではなくてなぜそうしているか？を書く。

変更の理由という形ではなくて、なぜそうしたのか？を書かなければいけないほど
重要なことであれば、その理由を書いた上でチケット番号に関連付けるのは普通。

その場合は、コメント（チケット番号）は変更した理由という履歴ではく、
現在の姿として、なぜそうしているかという形で書けばいい。

変更したものを全部残すという考え方をしていると、現在のコードではなく
過去に存在し今は存在してないコードに対しての履歴まで残ってしまうだろ。
不要な履歴コメントは消すべきだ。

**デフォルトの名無しさん** · 2015/11/27(金) 08:24:51.55

>>524
何が言いたいかわからん。
関数の頭のブロックにもチケット番号列挙してあるんだけど、
古すぎるコメントはチケット番号だけ残して消せば良いんだよ。

何故そうしているか、はコーダさん用のコメントだよね。
それらは本来、変更仕様書に書いてあるべき内容。
重要なことも何も、ソース改修はすべて重要な事だからチケット切って文書化すべき。

何故そうしているか、だけでは片手落ちも良い所。
○○年度○月○○法改正により計算方法が変更になり、下記の計算方法で計算する必要がある
　以下計算式　資料　No.xxxxx Pp y-z及び…
なんて完璧にコメント書いてくのも、文書の方に書けと言いたくなる。

一切残さない、もありなくらい。

**デフォルトの名無しさん** · 2015/11/27(金) 08:44:05.48

1998年度○月○○法改正により計算方法が変更になり、下記の計算方法で計算する必要がある
　以下計算式　資料　No.xxxxx Pp y-z及び…

これは消していいだろう？

**デフォルトの名無しさん** · 2015/11/27(金) 08:47:54.68

>>525
> 何が言いたいかわからん。

ソースコードに余計なコメントを書くな。
変更履歴も書くなって話だよ。

仕様は仕様書に書いてあるんだから、
documentディレクトリの○○テキスト参照って書けばいい。
仕様が新しくなったら、新しい仕様のファイル名に書き直すだけ。

修正のたびに行を増やす必要はなくなる。

**デフォルトの名無しさん** · 2015/11/27(金) 10:41:14.78

>>526
1998年度以前のデータが二度と確実に入って来ないのであれば消しても良いと思うけど、基本は残すべきだと思う。もちろん文書に。
コメントとして処理内容を書くのであれば、これくらい書かないと片手落ち。
不足のあるコメントは余計なコメントに等しいよ。

>>527
だから、チケット番号で良いって言ってるんだけど。
文書載せられないようなトラッキングシステム使ってたらすまん。

**デフォルトの名無しさん** · 2015/11/27(金) 12:04:27.10

そもそもチケットがない

**デフォルトの名無しさん** · 2015/11/27(金) 16:09:25.59

>>523
ソースコードに書かれたチケット番号をBTSが拾ってくれるの？
というか拾って何になるのか判らないけど

**デフォルトの名無しさん** · 2015/11/27(金) 16:31:27.16

チケット＝作業、作業が終わるタイミング＝コミットなのだから、
チケット番号（≒Issue番号）はコミットログにつけるもんだと思うが？
特に重要な事に関しては、Issueに対してソースコードで注釈入れるけどな。

Issue駆動で開発すると

1. 新たなIssue（バグ報告や機能追加など）を作成する
2. それに対してのプルリクエストを作る
3. そのプルリクエストに1つまたは複数のコミットが含まれる。
4. そのプルリクエストをマージするとIssueが閉じられる。

という流れになる。

またプルリクエストっていうのは（Issueもだけど）、掲示板みたいなもので
それに関しての情報を時系列に会話するように記録できる。

最終的な修正内容をプルリクエスト（会話部分じゃなくて主文）に書いてそれをコミットすれば、
ソースコードのコミットログとして修正内容がバージョン管理される。
あとから修正を追いかけたいときはコミットログを見れば修正内容がわかる。
リンクも記録されてるから、コミットログからプルリクエストにもIssueにたどり着けるって寸法

これがgithubを使った主な開発のワークフローね。

**デフォルトの名無しさん** · 2015/11/27(金) 17:35:57.29

>>530
拾ってくれるよ。コミット時に。
ソース管理もバグトラックも出てくる帳票も全部連携してる。
コミット時にも書けるけどね。
どの関数に手を入れたかわざわざ手で書かなくても良くなってるのと、
ソースとリリースノートだけ読んでもある程度わかるように。

あと、逆にリリース用チェックアウトした時にリビジョン等のスタンプも押される。

**デフォルトの名無しさん** · 2015/11/27(金) 18:19:01.79

手動でソースコードに変更履歴書いて
古いコードを残す文化とまるで違うｗ

**デフォルトの名無しさん** · 2015/11/27(金) 18:29:07.73

>>532
チケット番号←→コミットログ←→変更ファイルで芋づる式に取り出せる情報なのに
人間が変更ファイルをマーキングして周ってるのか
本人が言ってるならそうなんだろうけど随分変なやり方してるね

**デフォルトの名無しさん** · 2015/11/27(金) 20:07:14.94

>>534
正確には変更ファイルにマーキングしてる訳じゃないよ。
変更箇所にマーキング入れてるだけ。

いつでもdiff取れるわけではないからね。

**デフォルトの名無しさん** · 2015/11/27(金) 20:15:00.15

> いつでもdiff取れるわけではないからね。

いつでもdiff取れるようにしなさいよｗ
あほだなぁ。

**デフォルトの名無しさん** · 2015/11/27(金) 20:41:52.19

>>535
納得した
そういうやり方ならありかもね

つってもソースコードから参照されてるチケットが陳腐化してないか
一々管理しなきゃならない不毛さを思うと
その時間でコメントを真面目に書けよって思うけどねｗ

**デフォルトの名無しさん** · 2015/11/27(金) 21:17:32.03

>>521
その時コミットログ見れればそれでベストだが環境移行等で見れなくなった時の話
>>522
差分やコミットログをどんな環境でも見れるためのファイルフォーマットだよ
ファイル仕様が決まれば別のバージョン管理ソフトも必ず対応するからOS変わろうがツール変わろうが将来見ることができるだろう
コードが理解不能になって作り直しってのはよくあるからな

**デフォルトの名無しさん** · 2015/11/27(金) 21:34:46.43

> その時コミットログ見れればそれでベストだが環境移行等で見れなくなった時の話
見れなくならないように、ちゃんと環境移行すればいいだけ

> 差分やコミットログをどんな環境でも見れるためのファイルフォーマットだよ
差分はgit diffでテキスト形式に変換される。
gitじゃなくてもすべてテキスト形式に変換できる。
テキスト形式が見れない環境など無い。

**デフォルトの名無しさん** · 2015/11/27(金) 21:59:12.67

>>539
同じところにも存在してればなんとかなるかもしれんが配置変わったり消したりするのは普通に発生する
その時見れないのでは話にならない
古いプロジェクトやったことある人間ならわかると思うが修正履歴が完全に残ってすぐ見れるなんて夢物語
ドキュメントなんてないしあっても嘘八百
ソース=仕様ってのしかお目にかかったことないわ
10年くらい放置されてて突然手を加えるとなったときには開発環境が動かせないとかなw

**デフォルトの名無しさん** · 2015/11/27(金) 22:03:24.34

>>536
そりゃまあ、もちろんそうだけどね。それが実現するなら構わんけど。
地震が起きて、停電は起きるわ、窓ガラスは割れるわ、
支社とネットワークが上がらないわ、端末の何割かが壊れるわ、
なんやかんやで大変な事になっても
「今差分取れないし履歴も読めないのでわかりません、復旧まで待ってね」って投げちゃえるなら全部電子媒体で持ってて、必要な時に必要な分を随時取り出してもいいだろうね。

**デフォルトの名無しさん** · 2015/11/27(金) 22:07:56.50

>>541
火事になって会社焼けたら困るなら、
別の所にあるHDDとコンピュータを使えばいいのでは？

**デフォルトの名無しさん** · 2015/11/27(金) 22:09:31.08

紙媒体だと、燃えたら全損だからな。
バックアップも取れないだろうし。

**デフォルトの名無しさん** · 2015/11/27(金) 22:10:31.74

>>540
だから、デジタルで記録された、現在動いている
ソースコード以外役に立たないんだよｗ．
いくら紙の資料があっても、それが最新とは限らないからね。

**デフォルトの名無しさん** · 2015/11/27(金) 22:11:26.12

>>540
> 古いプロジェクトやったことある人間ならわかると思うが修正履歴が完全に残ってすぐ見れるなんて夢物語

古いプロジェクトからずっとバージョン管理してるわｗ

修正履歴が残ってないのは、バージョン管理していない頃と、
紙媒体で履歴を保存していたものだけ。

**デフォルトの名無しさん** · 2015/11/27(金) 22:14:12.17

地震でてんやわんやですが、
「差分取れるし、履歴も読めます。ただ、沢山の紙の資料の中から
探すのに時間がかかるのでちょっと待ってください。
パソコンを直すよりも時間がかかりますがねｗｗｗ」

**デフォルトの名無しさん** · 2015/11/27(金) 22:16:58.51

俺なら、地震で仕事にならないなら、
別の場所に支社があるんだろう？
そこに仕事まわすだろうな。

デジタルデータなら共有も簡単なので、そっちで差分見ればいい。
紙に保存した資料に頼ってるから、余計大変なことになってるわけで。

命の危険もある中で、地震で散らかっている倉庫を探しまわって
仕事をする必要はない。優先順位を考えれば当然そうなる。

**デフォルトの名無しさん** · 2015/11/27(金) 22:28:38.44

>>545
紙で履歴保存してた頃にソース記述しとけば今でも見れたわけよ
俺は履歴は現行ソースと同等レベルで重要と思ってる
履歴がなくてコメントもろくにない中データ保存に分割してよくわからん計算してる理由わかるやつなんかそうそういないわ
わかった時には脱帽したよフロッピー先輩w
履歴あればすぐにわかったんだろうがな
今の時代にデータ保存にそんなことしない無理すぎた

**デフォルトの名無しさん** · 2015/11/27(金) 22:47:37.06

つランプ型秘密分散法

**デフォルトの名無しさん** · 2015/11/27(金) 23:01:18.56

>>542
火事になっても大丈夫なように複写は他の所にも保管はしてあるよ。

>>543
お前コピー機も知らないの？

>>544
それは管理の仕方次第

>>546
探さなくても台帳、リリースノート、変更仕様書、等々キングファイルに綴じてあるからすぐ見つかるよ。

>>547
サブシステム毎に担当わかれてるからね。
こっちの命の危険なんか関係ないよ。
客先にはどんどん怪我人搬送されてたり、自家発電切れそうで縮退運転始まったり、
それこそこっちが一人二人死んだ位どうという事は無いよ。ただの労災。
命を預かる物作ってるのに、その責任に自分の命を代えられないほど情けない人間でもない。

**デフォルトの名無しさん** · 2015/11/28(土) 00:28:53.24

支社があるような会社の運用ではないように見えるのだが

**デフォルトの名無しさん** · 2015/11/28(土) 08:03:00.10

老害ってほんとうに嫌なものだ。