Skip to content

Instantly share code, notes, and snippets.

@tune

tune/gist:3911829

Created October 18, 2012 13:34
Show Gist options
  • Star 20 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tune/3911829 to your computer and use it in GitHub Desktop.
Save tune/3911829 to your computer and use it in GitHub Desktop.
Download ZIP
C/C++言語 開発環境
Raw
gistfile1.md

Windows/Linuxで両方で動作する成果物を想定。 有償のツールは理解が得られる方が稀なので除外。

仕様書

外部仕様

Word/Excelが手軽だけど差分が追いにくい。 Markdown+PandocかSphinxでPDF提出がいいかな?

内部仕様

きちんと書いてあればDoxygenで十分だと思う。 Cしか対応していないみたいだけどdocuriumの方がgitとの親和性が高くて(tag付された結果をまとめて解析してくれるみたい)出力結果も今風にできてる。

インセプションデッキ

作っておくと上司/部下/協力メンバで方針を合わせやすい。

開発

ソースコード規約・整形

規約は組織ごと、プロジェクトごとに決まりがあるのでそれに従う。読みにくいコードを書く人がプロジェクトに含まれる場合はリーダブルコードを経費で買って読ませる。それでも直らなかったら直るまでレビューし続けるかソースコードを触れないように遠ざける。

整形はuncrustifyが痒いところに手が届いてよさそう。設定ファイルを作りこんで使いまわすのが良い。

文字コード

VisualStudioがBOMありじゃないと動かないのでUTF-8(BOMあり)一択。 最近のgccだとBOMありでも動くらしいけど、古いgccの場合はビルドスクリプトにBOMの削除ルーチンを仕掛けておけば良い。

コンパイラ

  • VisualStudio
  • Eclipse + CDT
  • gcc
  • llvm-clang
  • etc...

指定されたものを使う。

警告は最大限出すようにし(/W4 or -W -Wall)、地道に警告が出ないよう対処していく。 警告数が0になった段階で警告をエラーとして扱うようにする。

VisualStudioは独自のコンパイラしか使えないのかと思ってたけどMakefileも扱えるらしい(青の部隊 505小隊 ULZ - VisualStudio攻略)。 アサインされたプロジェクトでVisualStudioしか使ってなくても　VS -> VS+Makefile -> Eclipse+CDT+Makefile -> ... と段階を踏むことでマルチ環境でビルドできるように持っていけるかも。移植性があるように実装されてないとだめだけど。

好みの問題だけど、コンパイル結果の出力は色付けしたほうがいいかも。エラーはエラーらしく真っ赤に表示されるべし。

Version Control System

Subversion以前のVCSは時代遅れ。 gitのリポジトリ管理はRhodeCodeがおすすめ。インストールがgitlabとかと比べて簡単そうだし、コードレビューも流行りのプルリクエスト形式でできるようになるし、誰でもリポジトリ作り放題!

運用方法はさておいて、ビルドが壊れるコミット/テストが通らないコミットは許さないようにしたい。 git+hookスクリプト+Jenkinsで可能なのはわかるんだけど、どうしたら手軽に実現できるのかが分からない。

Gitのhookスクリプトはbleis-tiftさんのがよさそう。

.gitignoreはgithubから持ってくるのがベター

Issue Tracking System

RedmineでもJIRA(有償)でも。Tracはマルチプロジェクトがデフォルトで扱えないのとリリーススピードがいまいち遅いので割引。コミットはチケット番号と必ず関連付けるようにする。

Pivotal Trackerクローンのfulcrumでもいいかも。

Continuous Integration

JenkinsでOK。 最初はローカルPCで動かして、慣れてきたらサーバを用意してくるので十分。 ビルドスクリプトはJenkinsに保存できるけど、バッチファイル/シェルスクリプトを用意してJenkinsから叩くほうがビルドスクリプトの修正履歴も管理できていいらしい。

VisualStudioの場合はDebugとReleaseは最低限、gcc+makeの場合もうっかり壊れやすいオプションの組み合わせはテストする。

ソースコード検索

milkodeが鉄板

性能・品質評価

メトリクス集計

SourceMonitor以外にいいのがない… 定期的にメトリクスを取る方法を模索中。

見るべきメトリクスは下記の3つ。

  1. 総行数
  2. ネストの数
  3. 関数の複雑度

総行数はプロジェクトの規模感を知るため。 ネストの数が多いと綺麗にかけていない可能性大。 関数の複雑度が高いところからリファクタリングを行うこと。どんなに複雑な処理でも30ぐらいまでは改善可能だと思う。

カバレッジ

Linuxのgcov以外に選択肢がない… orz 解析結果の可視化はlcovじゃなくてgcovrがよさそう。Coverture形式の出力を経ることでJenkinsでもきれいに表示させることができる。

静的解析

脆弱性やバグを見つけるタイプ、C++だとcppcheckがあるけど、C向けには鉄板ツールが無い気がする。いくつか見つけたけど実戦投入できてないので効果は不明。

コードの重複を判定するのに重きをおいた静的解析ツール。こっちも実戦投入してないので詳細不明。

メモリアクセス系のチェックはvalgrindが鉄板だけどLinuxじゃないと動かない。

バグ密度/バグ予測

Gitを使っていればGoogle謹製ツールのbugspotsの恩恵に預かれる、Subversion版もあるけど。

パフォーマンス

gprofしか知らない…

テスト

単体テスト

単体テストはLogicをテストする。

手動でデバッガ止めるなんてアホ、xUnit Framework以外に選択肢はない。 どこでも使える無難なのはcUnit/CppUnitだけどあまり評判は良くないみたい。GoogleTestが今なら使えるか?

今現在xUnit Frameworkの仕組みが入ってないなら一番簡単な箇所(例えば2つの値を交換するとか)の関数に対して1つだけテストを足せば良い。1つテストを書くほうがテストを増やしていくよりもずっと難しい。

結合テスト・システムテスト・受け入れテスト

結合テスト・システムテスト・受け入れテストはFeatureをテストする。

ツールはBDD(Behavior Driven Development)用のフレームワークを使うのがいいかも。

swigを使ってRuby製のツール(CucumberとかCapybara)を使うことはできないか?

その他/評価待ち

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment