アカウント名:
パスワード:
確実な方法は、ソースの一部を見せてもらうこと。一目瞭然です。
#部分的には勉強になるときもあるが、#元ソースの出来がよかったためしがない。
ある程度の規模のシステムならソースなんて全部読んでいられない。ごく一部のダメコードが広範囲に影響する事もあるし。
それより、開発ツールを聞いて、コード解析レポートを提出させて、「テストの」デモをさせた方がいい。アプリのデモだけでは駄目。ちゃんと動く部分しか見せないから。
xUnitを使っていれば、コードカバレッジがわかる。静的コード解析ツール(Code Sniffer, Mess Detector等)を使っていれば、コード規約違反やダメコードの有無がわかる。CIツール(Jenkins等)を使っていれば、テストが自動化されているかどうかがわかる。
あと質問者はコードについてだけ聞いてるけど、実際にはミドルウェアも気にしないと駄目。とっくに開発が終わってたりコミュニティが小さいフレームワークやストレージエンジンを使ってると、保守ができない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
百聞は一見に (スコア:0)
確実な方法は、
ソースの一部を見せてもらうこと。
一目瞭然です。
#部分的には勉強になるときもあるが、
#元ソースの出来がよかったためしがない。
Re:百聞は一見に (スコア:1)
ある程度の規模のシステムならソースなんて全部読んでいられない。
ごく一部のダメコードが広範囲に影響する事もあるし。
それより、開発ツールを聞いて、コード解析レポートを提出させて、「テストの」デモをさせた方がいい。
アプリのデモだけでは駄目。
ちゃんと動く部分しか見せないから。
xUnitを使っていれば、コードカバレッジがわかる。
静的コード解析ツール(Code Sniffer, Mess Detector等)を使っていれば、コード規約違反やダメコードの有無がわかる。
CIツール(Jenkins等)を使っていれば、テストが自動化されているかどうかがわかる。
あと質問者はコードについてだけ聞いてるけど、実際にはミドルウェアも気にしないと駄目。
とっくに開発が終わってたりコミュニティが小さいフレームワークやストレージエンジンを使ってると、保守ができない。