[Tokyodebian-2009] Debian勉強会51事前課題

[chomy]

はじめまして、初めて参加します中尾と申します。
遅くなりましたが、参加のための事前課題を提出します。

gitをいまいち理解していないので、patchを生成する事ができませんでしたので、
原稿を以下に添付します。

よろしくお願いします。
--

\begin{prework}{中尾圭佐}
\preworksection{私のDebianワークフロー}
私はDebianに貢献しているわけではないで、Debian開発の開発工程はもっていま
 せんので、普段の作業工程を記述します。

１：まず、必要とされている機能を見付けます。見つけ方は、ボスから指示があった
 り、手作業でやっていていらついたとき、簡単な作業でも毎日やっていること
 に気付いたとき等によく見付かります。

２：どうやったら、その機能が実現できるかを考えます。個人的にこの段階が一番楽しい
 です。

３：この機能が本当に必要か考えます。

４：必要ならば、本当に実装して良いか考えます。私がいる職場は、放射線が出
 たり、100kVの高電圧がかかっていたりするので、放射線管理上問題がないか安
 全上問題がないか検討します。

５：一番楽しい段階が終ったこともあり、本当に私が実装すべきか考えます。

６：私が実装すべきという結論が出た場合、ぶつぶつ文句を言いながら、実装し
 ます。

７：時々Debugします。テストファーストとか、自動化はできていませんが、ユニットテストを行います。

８：だいたいできたら、職場のみんなに見せびらかします。そうすると色々コメ
 ントが出てくるので、それに対応します。運用が大変なら、修正します。


\preworksection{こう改善したい}
改善したいことは、私以外の誰かが、書いたコードをメンテナンスできるように
することです。そのためには：
１：バージョン管理システムを導入する
２：ユニットテストの自動化を徹底する
３：ドキュメント、資料、コメントをちゃんと残す
が必要だと考えています。

私の職場では、コードの所有権のようなものが心理的に存在しています。バージョン管理システムを導入する事で
所有者のコードを残しつつ、所有者以外の人がコードを取得でき、また修正する事ができます。これにより
コードの所有権の意味を曖昧にすることができあます。

ユニットテストの自動化を実現する事で、コードの所有者以外の人がコードを修正した場合、
その修正が他に影響を及ぼさない事を確認する事ができます。このことは他人のコードを修正すことの
心理的障壁を下げることにつながります。

さらにドキュメントを残す事で、トラブルの時、修正する時に非常に有用な情報を提供する事ができます。
時が進み、開発時何を考えていたか、当時どのような必要があってこのような実装したか、このような記録は、
どこを捨ててどこを残すかという判断に必要な情報になります。

私がいなくなっても、私が書いたコードやシステムがちゃんと維持でき、状況に
応じてメンテナンスできるように、以上のことを改善したいと考えています。
\end{prework}