Julio Biason 氏の『30年のソフトウェア開発で苦労して学んだこと』が面白い。

私が普段の仕事で意識して心がけていることをまとめる。 すべてを常に実践できているわけではなく自戒を込めて。 普段考えているのは個人としてチームとしていかに生産性を高めるか。 理想は携わったプロジェクトはすべて技術的に成功させるである。 実際は技術的に成功してもビジネス上成功しないとお金が入ってこないのだが、 あいにく語れることは何もない。

プロジェクトマネージメントやチームワーク系で一番好きな本は トム・デマルコとティモシー・リスターの『ピープルウェア』である。 読む必要はなく、その副題がすべてである。 「ヤル気こそプロジェクト成功の鍵」 ヤル気を挫く原因となるものは排除しよう。

プランニングでの心がけ

ソフトウェア開発は開発者が思っているよりも莫大なコストがかかる。 大抵は開発者の見積もりの3倍は工数が掛かる。 せずにすむならば、しないのが最善である。 作る必要もないのに始めてしまっているプロジェクトをいくつか思いつくのではないだろうか。

基本設計やフレームワーク選定など 開発の方向性の間違いは他の生産性向上の努力が軽く吹っ飛んでしまうほどに、時間を無駄にしてしまう。

プロジェクト開発当初にチームの技術者全員が合意した開発の方向性が その後間違いであることが徐々に判明した場合は仕方がない。 当時の人類の知識ではその判断が最善であり、 そのことに気づくために時間が必要であったと諦め、新しい方針で作り直すしかない。

しかし、失敗する方向性は開始時点ですらチーム内で意見が分かれることもよくある。 技術者同士の意見の対立は各自がよりプロジェクトを成功させるために考えた結果起きる。 頭ごなしに一方的に決めてしまうと、 不本意な方針を選ばされた側はやる気が損なわれる。 また、プロジェクトが失敗すれば自分の正しさが証明されたことにもなるため、やる気が起きない。

各技術者が成功すると信じる方針で開発するのが望ましい。 20%ルールのように各自の自由な方針で開発する。 まとまった時間を確保してプロトタイプする。 チーム内で意見の別れたグループ同士でコンペする。

プロトタイプで起きる失敗は 結局商品品質を達成できるかが分からないことである。 プロトタイプを作って動いているので行けるだろうと判断すると、 完成間近の QA で商品品質を達成できない。 製品実績のある技術を使うのが無難である。

新しい技術を学びたいだけの理由でそれを新規プロジェクトで採用しようとする人がいる。 技術者が自分のキャリアをよくしたい気持ちは理解できるし、 時代遅れの技術だと採用面で不利になる。 しかし、失敗できないプロジェクトで流行りの技術に飛びつくのは諌める。

チームワークでの心がけ

当然だが個人よりもチームの生産性を上げることが重要である。 必要なときは個人の成果を犠牲にしてチームの生産性を優先する。

ビルドシステムが不安定だったり低速だったりするとチームの生産性に影響する。 個人的な経験上、やりたがる人が少ないためにビルドシステムは放置されがちである。

ビルドブレイクやクラッシュバグを混入させるとチームの生産性に影響する。 即座に対応する。 自分の変更ではなくても、状況次第では自分の作業を後回しにして対処する。

帰宅前や有給休暇前にはリポジトリに変更をコミットしない。 コミットしたい気持ちを抑えるのが難しいのはよく分かる。 なぜなら、今すぐコミットしないと、後日に最新をマージするためにコンフリクト解決して、テストし直しになるから。 しかし、ぐっと我慢する。

チームの生産性向上のためのツール作成などは専属チームが望ましい。 しかし、大抵の現場は開発者が片手間でやっているだろう。

プログラミングでの心がけ

元記事の “Data flows beat patterns” には大いに同意する。 データの流れを把握することで コードの全体像を掴むことができる。

もうひとつ大事なことがレイヤーを理解すること。 移植レイヤー以外で OS の API を呼んだり、 上のレイヤーが直に下のレイヤーの API を呼んだりすることは layer violation と言われるやってはいけないことである。

元記事の ‘Keep a list of “Things I Don’t Know”’ にも同意。 ソフトウェア開発スキルを高める上で勉強は欠かせない。 ソフトウェア開発の技術力は知識量と論理的思考力である。 わかないことを百個、千個と潰していくと技術力が向上する。

論理的思考力が重要であるが、残念ながら向上する方法はないように思う。 当たり前のことをじっくりと考える。 限界的練習で向上できるのかもしれない。

元記事の “Code style: Follow it” も同意。 コードスタイルは「まわりのコードに従う」。 本来ならばこれだけで十分なのだ。 コードをみただけで複数人で開発した形成が残ることや、 ましてや誰が書いたか分かってしまうようなことは恥ずかしいことである。

バグが見つかるので dogfooding する。

デバッグ中にそのバグが混入した変更のチケットを見ても知りたい情報がなかったり、 自分の変更に数年後にバグが発覚したがなぜそのようなコードを書いたか全然思い出せなかった経験はだれしもあるだろう。 記憶はすっかり消えてしまうため、 ドキュメントやバグトラッカーに情報を残す。 立ち話で議論した内容も忘れないうちに文字に起こしてバグトラッカーに情報を残す。

ドキュメントはソースコードのそばに置く。 コードと同じディレクトリ置いて、コードを変更したときに必要ならば同時にドキュメントも変更しレビューを受ける。

API デザインでの心がけ

元記事での “Don’t use Booleans as parameters” と “Be explicit with what you use; sleepForSecs and sleepForMs” が API デザインについてである。

boolean の件は Qt の API Design Principles にも同じ話がある。

これらは根源は同じで、 API を使う側をどのようなコードにしたいかを意識して API を設計することである。

コードレビューでの心がけ

コードレビューにおいて 実は理解してもいないのに LGTM したパッチがバグを引き起こしてバツの悪い思いしたことがある。 わからないことはすべて質問する。 思いつきも書き記しておく。 理解してもいないのに LGTM しない。 そうすることで記録が残る。 くだらない質問であってもパッチ作成者は質問に答えることで自分の間違いに気づくこともある。