開発スピードが遅い？速い？：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
ソフトウェア開発グループあるいはソフトウェア開発組織の開発スピードが遅いとか速いとはか、何を基準に判断するのでしょうか。 人が単純な作業を行わずに、自動化できる部分を徹底的に自動化した場合、残っている部分が本当の意味では、その組織での開発スピードです。 たとえば、システム全体のビルド作業を手作業で週に一回行っており、開発メンバーは、単体テストも書かずに、高残業をしながら一週間に多くの機能を実装したと報告する開発を考えてみます。もちろん、他のモジュールとのビルドもしていないし、ビルドするのは翌週の月曜日ということになります。これは、80/90年代によく行われた開発スタイルです。 一方で、Jenkinsを使用しながら継続的インテグレーションを行い、自動実行される単体テスト・システムテストを作成しながら、システム全体の機能のデグレードや副作用が起きていないかを常に検証しながら、開発メンバーがあま
項目16 「継承よりコンポジションを選ぶ」: 柴田 芳樹 (Yoshiki Shibata)
Effective Java 第2版 (The Java Series) 作者: Joshua Bloch出版社/メーカー: ピアソンエデュケーション発売日: 2008/11/27メディア: 単行本（ソフトカバー） 1990年代前半から中頃（？）までは、オブジェクト指向と言えば、継承というはやりがありました。特にC++ではインタフェースの概念が言語仕様上なく、すべてをクラスの継承で表現しなければなりませんでした。その結果、すべてを継承で設計し、いわゆる差分プログラミングが良いという考えもあったりしました。 項目16 「継承よりコンポジションを選ぶ」では、次のように述べられています。 メソッド呼び出しと異なり、継承はカプセル化を破ります[Snyder86] 。言い換えれば、サブクラス は適切に機能するために、スーパークラスの実装の詳細に依存します。スーパークラスの実装はリリー スごとに変更さ
いつも受け入れられるとは限らない改善提案: 柴田 芳樹 (Yoshiki Shibata)
社会人となって30年間、様々なソフトウェア開発従事していた経験から言うと、改善提案は上位のマネージャや部門長に受け入れられる場合とそうでない場合があります。その中でも、問題が発生してから、その問題を解決するという改善提案は受け入れられることが多いです。しかし、発生するであろう問題を予測して、それに対して事前に対策を打つという改善提案は、理解されなくて、受け入れらないことがあります。 問題が発生してからの改善としては、ソースコード管理用のリポジトリは用意していたが、開発の終盤までビルドは、一人の開発者のPCでしかできなくて、ビルドを間違いなく行う必要がでてきて、やっとサーバで自動ビルドが一日一回行われるとかです。さらに、コードの品質が悪くてバグがたくさん出るので、FindBugsなどの静的解析ツールを導入して改善しますと言った提案です。しかし、静的解析ツールを導入した時点ではすでに遅く、すべ
初心者レベルの言い訳をしない: 柴田 芳樹 (Yoshiki Shibata)
出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだからと言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。 ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量も質も圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。 1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
