プログラム基礎

>>30
C++じゃないとどうしてもダメだというような組み方してるの？（開発効率・開発スタイル的に）
それとも拡張子がcppになってるだけの、ほとんどcみたいな組み方なの？

C++で開発チーム組んだ場合、よほどしっかり各種取り決め（もしくは監督・管理）
しとかないと悲惨な状況になりかねん気がする。
随時デスマ状態だと思われるゲーム開発現場だからこそ、皆勝手なスタイル
でソース書いてる気がして。

気がするばかりの質問sage

>>62
＞C++じゃないとどうしてもダメだというような組み方してるの？
Yes, みんなあまり抽象化はうまくない(というか、知らなさそう)みたいなので
「OO のテクニックを駆使して使いこなしている」とまでは言えないけれど、クラス単位にまとまっている事で
複雑度の管理やモジュールの独立化には成功してる。
それなりに巨大で複雑なプログラムなので、C++じゃなかったら名前空間の汚染と
グローバル変数の蔓延だけでも手におえないくらい大変な事になってただろうと思う。
C 風の関数はほとんどないね。ユーティリティ関数的なものがいくつかあるくらい。

＞C++で開発チーム組んだ場合、よほどしっかり各種取り決め（もしくは監督・管理）
＞しとかないと悲惨な状況になりかねん気がする。
芯がしっかりしてればそんなでもないと思う。メインの腕と統括力の見せ所ですかね。
クラスっていうわかりやすい管理区分があるので、混乱はむしろCより少ないだろうし、
インターフェイスだけしっかりしていれば錯乱状態の人がグチャったの書いてても後から取り返しきくし。

開発の中で手戻りが発生した場合も、クラス単位、モジュール単位での入れ替えとかだと
そんなに混乱はおきないんだよね。はっきり言っていい事尽くめ。

と言いたい所なんだけど、唯一にしてクリティカルな問題がひとつ。
「人材の確保」
これは企業力なりなんなりでカバーできないとどうしようもないですね。
Cしかできない人をC++の現場にアサインしちゃ、本人も周りも迷惑というか
困り果ててしまいますし、なまじCならできるって人間を忙しい仕事の中に
放り込んで「徐々に覚えてくださいね♪」なんて言ったって今までのやり方を
かえられるわけがないし。
(え〜上の立場の方々はCしかしらん人をC++の仕事に放り込む場合には
十分な学習時間を取ってあげてください〜みんなの迷惑です〜〜)

そんな感じ。

>>63
＞クラス単位にまとまっている事で
＞複雑度の管理やモジュールの独立化には成功してる。
この点は分かるけど、

＞それなりに巨大で複雑なプログラムなので、C++じゃなかったら名前空間の汚染と
＞グローバル変数の蔓延だけでも手におえないくらい大変な事になってただろうと思う。
Cってある意味単純な分、static宣言の徹底やソース分けの工夫だけで問題回避
出来るんじゃなかろうかと思った訳です。

CPPでの懸念点は、スキルが足りないくせに無理に
＞「OO のテクニックを駆使して使いこなしている」
された場合かなと思いました。
またさらに、スキルの足りない別の人間がそのソースを見たりする場合、スパイラル状態かなぁと。

＞開発の中で手戻りが発生した場合も、クラス単位、モジュール単位での入れ替えとかだと
この点についても、さっき書いたCの開発スタイルならば同じ事かなと。

漏れは本格的なチーム開発を経験したことがないので、あくまでも妄想ですが（ｗ

一番恐いのは自称「C++マスター」のオナニープログラム。
まあここまで来ると言語関係ないけど…現場でオナニープログラム組める余裕はないか（藁

>>64
＞＞それなりに巨大で複雑なプログラムなので、C++じゃなかったら名前空間の汚染と
＞＞グローバル変数の蔓延だけでも手におえないくらい大変な事になってただろうと思う。
＞Cってある意味単純な分、static宣言の徹底やソース分けの工夫だけで問題回避
＞出来るんじゃなかろうかと思った訳です。
いや、多分想定されてるのよりもっと酷い状況です。
グローバル変数への依存からくる再入不可能関数なんかが続出して
書くに書けない、何か書いてもエンバグせずに動くかどうかわからないっていう状況になると思います。
(C++ご存知のようなので釈迦になんとかですが、
この状況をC++なら何故回避できるかといえばオブジェクトがオブジェクトを持つみたいな形で
「状態」を管理できるので、再入不可能や、副作用系の挙動が最小限に抑えられるからです)

＞CPPでの懸念点は、スキルが足りないくせに無理に
＞＞「OO のテクニックを駆使して使いこなしている」
＞された場合かなと思いました。
影響が全体に及ぶ場合はすぐに発見できるので早期に芽を摘むことができるでしょうし、
独立したモジュールの中での事であれば「テメェこの中の事は責任とってやれよ」で
他のモジュールとのインターフェイスだけしっかりさせれば無問題ですね。

(本文が長すぎますなので切ります。)

(続き)
>>64
＞またさらに、スキルの足りない別の人間がそのソースを見たりする場合、スパイラル状態かなぁと。
絶対理解できないから問題ありません(^^;
チーム内で良著に関する会話等をして技術的基盤を安定させるのもいいかもしれません。
(現場で使うのはまだちょっと…なレベルの話題の時に、声の大きな人が「それはまだ現場で使うのは無理があるよね！」
と釘を指すのをお忘れなく。最近だと Modern C++ Design とかは要注意書籍でしょうか^^;)

＞＞開発の中で手戻りが発生した場合も、クラス単位、モジュール単位での入れ替えとかだと
＞この点についても、さっき書いたCの開発スタイルならば同じ事かなと。
これは…私がやり方が下手だったのかもしれないですね。
以前は手戻りっていうと他の部分まで書き直さなきゃいけない事が多くて
OOPL 使うようになってから楽になった部分だったと思っていたのですが。

＞一番恐いのは自称「C++マスター」のオナニープログラム。
メイン以外だったら上述の通りで問題なしですので。
メインだった日には、サポートされる方々の冥福をお祈りします。

と、ゲーム業界以前の仕事でおもいっきりオナニープログラムで３人月無駄にした男の意見でした(^∇^;