SSブログ
プログラマー現役続行 ブログトップ
前の10件 | -

バックエンドサービス開発で当たり前に行ってきたこと [プログラマー現役続行]

2000年以降に継続的インテグレーションが広まっていき、今ではCIということで当たり前に行われています。Go言語でウェブサービスのバックエンドサービスを開発するようになって6年ほど経過していますが、日々の開発の中で私自身が当たり前と思って行ってきたことがいくつかあります。
  • ローカル実行:自分の開発用マシン(MacBook Pro)で、開発しているサービスの自動テストをローカルで実行できる
  • カバレッジ:テストを実行した結果、どの行が実行されなかったかをカバレッジで確認できる
  • 並列実行:Go言語の`testing`パッケージの`t.Parallel()`を使って並列にテストを実行することで、テスト対象のサービスに並列にリクエストを処理させる
  • 長時間ランニングテスト長時間ランニングテストができる
これらすべてができないとバックエンドサービスが開発できないわけではありません。そして、次のように反論されるかもしれません。
  • ローカルで実行できなくても、CIですべてのテストを実行できています
  • どの行が実行されていないかを確認しなくても、CIですべてのテストがPASSしているので問題ないのでは?
  • 逐次的にすべてのテストがCIで実行されてPASSしているので問題ないのでは?
  • ローカルで長時間ランニングテストをしなくても、CIでテストが1回PASSしているので問題ないのでは?
おそらく、この反論に対して相手が納得する説明を行うのは容易ではないです。なぜなら、私自身が当たり前に行ってきたことが何をもたらすかは、実際に行ってみてどのような問題を見つけるかを経験してみないと、容易に納得できないからです。
コメント(0) 

Hotfixとテスト失敗 [プログラマー現役続行]

何らかの緊急の障害に対して、Hotfixとして緊急に修正がリリースされることはよくあると思います。そのHotfixリリースのPull Requestを見たときに、既存のテストの修正が含まれていない場合、次のことが起きていることが分かります。
  • 修正に該当する部分の機能をテストしているテストコードが存在しなかった。存在していればそのテストが失敗するので、一緒に修正されているはずです。
  • 既存のテストが存在しないため、既存のテストに追加/修正を加えるといった再現テストの作成ができなかったし、新たに作成する時間もなかった。
緊急なので、後者も仕方ないです。しかし、リリース後に不足しているテストコードを作成したいものです。ソフトウェアエンジニアなら、後からでもよいので、テストを追加する習慣を身に付けるようにしてください。
コメント(0) 

伸ばすのが難しい能力(4) [プログラマー現役続行]

2003年以降のデジタル複合機のコントローラソフトウェア、2017年9月からのウェブサービスのバックエンド開発をテストファースト開発によるソフトウェアの自動テストを長年行ってきて、バックエンド開発については「WEB+DB PRESS Vol.134」の特集1「実践API設計」としてまとめました。デジタル複合機のコントローラソフトウェア開発については、過去にカンファレンスなどで話しています。

これらの長年の開発で気付いていなくて、最近気付いたことは、次の2つの活動は強く関連していることです。
  • API仕様をきちんと書く
  • そのAPI仕様に基づく、自動テストコードを作成する
ウェブサービスで、バックエンドがフロントエンドに提供するAPI仕様をきちんと書き、そのAPI仕様に基づいて自動テストコード(E2Eテスト)を作成する行為で説明したいと思います。

自動テストがない

API仕様に基づいて、そのエンドポイントを直接呼びだして行うE2Eテストコードがない場合、API仕様をどれだけきちんと書いて、修正や追加の際に更新することのモチベーションはあるでしょうか?

API仕様をきちんと書かずに開発している場合、フロントエンドの開発者は、適当に仕様を推測して試してみたり、バックエンドの開発者に(Slackなどで)問い合わせたりしながら開発を続けていることが多いでしょう。

このような開発であると、バックエンド開発者にはAPI仕様を書くというモチベーションはありません。仮に書いたとしても、長期的にきちんと保守するというモチベーションもありません。

仮に、バックエンド開発者が書いた自動テストコードがあるとしても、それがすべての機能を網羅しているのか、あるいは足りないテストがあるのかは、その開発者以外は分かりません。ひょっとしたら、その開発者も分かっていないかもしれません。

あるべき開発サイクル

記事「実践API設計」で明示的には述べていませんでしたが、バックエンドでAPIの新たなエンドポイントを追加する場合、あるべき開発サイクルは次のようになります。
  1. 新たなエンドポイントを定義して、その仕様(正常な動作だけでなく、エラーも含めて)を記述して、PR(Pull Request)のレビューをフロントエンド開発者に依頼する。フロンドエンド開発者は仕様から不明な点があれば、不明な点を明確にした内容を仕様に反映してもらうようにフィードバックする。
  2. API仕様のPRの内容をフロントエンド開発者がレビューして問題がなければ、承認する。
  3. バックエンド開発者は、API仕様に基づいて、そのエンドポイントを呼びだしてテストするE2Eテストを作成しながら、実装を行う。
  4. テストコードの作成と実装が終われば、PRを他のバックエンド開発へレビュー依頼する。
  5. レビューを依頼されたバックエンド開発者は、API仕様を確認して、E2Eテストで仕様が網羅されているか、漏れはないかを確認した後、実装をレビューして確認します。もしE2Eテストに、仕様に書かれていない動作がテストされてる場合、API仕様の更新を要求することになります。
このような開発サイクルが回っている場合、API仕様を書かないということはなくなります。ここで重要なので、API仕様に基づいて、エンドポイントを直接呼びだすE2Eテストを書けるフレームワークが整備されていることになります。

さらに、このような開発サイクルが回っている開発組織へ新たな開発者が参加しても、この開発サイクルを逸脱した開発を行うことはできません。なぜなら、API仕様や実装のPRが承認されないからです。その結果、その新たな開発者は、参加する以前の開発経験に関係なく、API仕様を書いてE2Eテストを開発することを経験することになります。

しかし、多くのソフトウェア開発組織は、そのようなE2Eテストフレームワークがないため、「自動テストがない」で述べたような状況で開発が進められてしまうことが多いと推測されます。そして、そのような開発組織でしか働いたことがない開発者は、API仕様を書くという習慣を身に付けないままとなります。
コメント(0) 

伸ばすのが難しい能力(3) [プログラマー現役続行]

伸ばすのが難しい能力(2)」の状況から、技術負債を返却して、API仕様ファースト開発への手順については、「実践API設計」で述べています。

WEB+DB PRESS Vol.134

WEB+DB PRESS Vol.134

  • 出版社/メーカー: 技術評論社
  • 発売日: 2023/04/22
  • メディア: Kindle版

記事では書いていませんが、「第5章 API仕様の技術的負債の返済」で述べている返済を実行する上での課題は、多くのソフトウェアエンジニアは、経験したことがないことなので、そのメリットを十分に理解できないことです。そのため、実際に行ってみる強い動機を持って、実践できる開発者はとても少ないと思います。

このような状況を改善にするには、私の経験からは、「やってみせるしかない」ということです。私自身がウェブサービスに本格的に従事し始めたのは、2018年6月にメルペイ社へ入社して、加盟店様向けのマイクロサービスを一から開発することを担当したときです。

「第3章 API仕様ファースト開発」で説明している手順で開発しました。その大枠の手順は、次の図(第3章の図1)で示されています(詳しいくは記事を参照してださい)。

図1 API仕様ファーストでの開発順序
03_01.png

初めてのウェブサービス開発ではありましたが、この手順が私にとっては素直な手順であり、これを実施して最初のマイクロサービスを開発しました。

その後、メルペイ内では、チームを移動していくつかのマイクロサービスの開発に従事したのですが、その多くが以下の状態でした(「第5章 API仕様の技術的負債の返済」参照)。
  • サービスのAPIに対する仕様が記述されていない
  • サービスのAPIをテストする自動テストが存在しない
単体テストは多数あっても、開発しているマイクロサービスが提供するエンドポイント(gRPCのRPCエンドポイント)を直接呼び出してテストするテストコードが存在しないという状況でした。

そのため、新たなチームへ移動するごとに「第5章 API仕様の技術的負債の返済」で述べている内容を繰り返し、一緒に開発している他の開発者にも実践してもらうように働きかけてきました。

ただし、E2Eテストフレームワークの構築は、私自身で行いました。そうやって作成したE2Eテストフレームワークは、どのマイクロサービスからも使えるように独立したライブラリとして退職前には構築しました。

このような活動の結果として、最後にいたチームでは、既存機能の修正や新規機能の追加に際しては、かならずきちんとしたAPI仕様を記述し、そのエンドポイントを呼び出すE2Eテストを作成するということを普通に行ってもらえるようになりました。

ここでの重要な点は、残念ながら「API仕様ファースト開発」はやってみせないと広がらないということです。カウシェで働き始めてから一年近くなりますが、カウシェでも今では定着しています。
コメント(0) 

伸ばすのが難しい能力(2) [プログラマー現役続行]

ウェブサービスは、フロントエンド(iOS、Android、ウェブブラウザ)とバックエンドから構成されます。バックエンドが提供する機能は、APIとして定義され、フロントエンドから呼び出されます。

この場合、「APIを定義する」行為にはいくつかのレベルが存在します。話を単純にするために、バックエンドのAPIがgRPCで定義されているとします。その場合、フロントエンドが呼び出すAPIは、protobufとして.protoファイルに定義されます。その.protoファイルに定義されるAPIにいくつかのレベルが存在します。

次は、最低限の定義のみの例です。呼び出すrpcやmessage定義が定義されているだけです。
service Greeter {
  rpc SayHello (SayHelloRequest) returns (SayHelloResponse) {}
}
message SayHelloRequest {
    string name = 1;
}
message SayHelloResponse {
    string message = 1;
}

実は、このレベルの定義だけで開発されているウェブサービスは多いと思います。その理由として以下のものが考えられます。
  • フロントエンドとバックエンドを同一のエンジニアが開発しているので、この程度で分かるから問題ないと考えてしまう。
  • フロントエンドのエンジニアからの問い合わせには、都度、Slackで回答しているから問題ない。
API仕様をきちんと記述することは開発スピードを落としてしまうので省いてしまうことが正当化されているように思われるかもしれませんが、実はそうではありません。その証しとして、サービスをローンチした後で時間的余裕が生まれてものこの状態が続くからです。

サービスを短期間で開発し、顧客に価値を提供し、サービスの価値を検証するためには、この程度の仕様で十分と考えて開発が進むと、結果的に、将来のサービスの成長を大きく阻害する技術的負債を積み上げていきます。

そもそもの原因は、「APIを定義するという行為は、この程度でよいという認識のエンジニアによって作成される」からなのです。

つまり、「伸ばすのが難しい能力」で述べた経験を積んでいないエンジニアが開発することにより、この状況は発生しているとも言えます。

続き
コメント(0) 

Kindle版『プログラマー”まだまだ”現役続行』 [プログラマー現役続行]

2010年9月4日に発売された『プログラマー”まだまだ”現役続行』ですが、8月1日よりKindle版がリリースされます。

プログラマー”まだまだ”現役続行 (技評SE選書)

プログラマー”まだまだ”現役続行 (技評SE選書)

  • 作者: 柴田 芳樹
  • 出版社/メーカー: 技術評論社
  • 発売日: 2010/09/04
  • メディア: 単行本(ソフトカバー)

目次は次の通りです。
第1章 ソフトウェアは「人」が作る
第2章 プログラマー現役続行
第3章 論理思考力:現役続行に必要な七つの力(1)
第4章 読みやすいコードを書く力:現役続行に必要な七つの力(2)
第5章 コンピュータサイエンスの基礎力:現役続行に必要な七つの力(3)
第6章 継続学習力:現役続行に必要な七つの力(4)
第7章 朝型力:現役続行に必要な七つの力(5)
第8章 コミュニケーション力:現役続行に必要な七つの力(6)
第9章 英語力:現役続行に必要な七つの力(7)
第10章 コードレビューのすすめ
第11章 若い人たちへ
第12章 30代,40代の人たちへ

コメント(0) 

三年間の在宅勤務 [プログラマー現役続行]

コロナがきっかけで2020年2月18日から在宅勤務(WFH:Work From Home)を始めて、ちょうど二年が経過しました。二年前と一年前の記事は、以下の通りです。
この一年間を簡単に振り返ります。

7回目の転職

大学院を修了して1984年4月に富士ゼロックスに就職してから7回目となる転職を、2022年10月にしました。年賀状も、先輩からは再雇用が終わりました、後輩からは定年を迎えましたというものが増えてきました。8社目となるカウシェでも、メルペイのときと同様に、ウェブサービスのバックエンドサービスをGo言語で開発をしています。Go言語との付き合いも13年となります(ちなみに、Javaは27年)。

メルペイおよびカウシェで私なりに工夫してきたバックエンドサービスのテストについては、4月下旬発売の雑誌に記事として掲載される予定です。雑誌の記事を執筆したのは、「Software People, Vol.8」(2006年3月発売)以来なので、17年振りとなります。

技術書の翻訳

この一年間では、幸い2冊の技術書を翻訳して出版することができました。

スーパーユーザーなら知っておくべきLinuxシステムの仕組み

スーパーユーザーなら知っておくべきLinuxシステムの仕組み

  • 出版社/メーカー: インプレス
  • 発売日: 2022/03/08
  • メディア: Kindle版
PDF版は、出版社のサイトから購入できます(こちらです)。

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

  • 出版社/メーカー: オライリージャパン
  • 発売日: 2022/08/03
  • メディア: 単行本(ソフトカバー)
PDF版は出版社のサイトから購入できます(こちらです)。

技術書の翻訳としては、『Go言語による分散サービス』でちょうど20冊目となりました。現在、21冊目となるGo言語に関する書籍の翻訳を行っていますので、夏以降に発売になるかと思います。

オンライン読書会

この一年間もいろいろとオンライン読書会を主催してきました。
基本的に月1回、土曜日の午後1時から午後5時までの4時間のオンライン読書会ですが、継続して実施することで、一冊の本を読み切ることができます。「横浜Go読書会」は、Go言語に関する書籍を読む読書会です。「技術書読書会」は、特定の技術に関する技術書ではなく、ソフトウェアカルチャーやソフトウェアエンジニアとしての心得的な技術書を読む読書会です。「技術書読書会2」は、基本的に私が翻訳した技術書を読む読書会になっています。

技術教育

この一年は、『Effective Java 第3版』研修を1コースだけ実施しました。月に1回で、合計6回に分けて、各回で指定された範囲を事前に読んで、疑問点を質問表に記入してもらいます。研修当日はその質問に回答していくという形式の研修です。休憩ごとに気分転換に『Java Puzzlers』のパズルを解いてもらいますが、正解する人はあまりいません。

『Effective Java 第3版』は、多くのJavaプログラマが読んでいると思いますが、詳細まできちんと理解して読めている人は少ないのではないかと思います。以前は、オンライン読書会として、「Effective Java 第3版読書会」を主催していましたが、参加者があまりにも少ないので、現在は開催していません。

健康面

2020年6月20日(土)に急性心筋梗塞で救急搬送されて以降、薬と食事制限を続けており、週に5,6日は自宅での30分間のエアロバイクも継続しています。お酒も、基本的には一日おきです。

30代から50代まではずっと、健康診断や人間ドックでの血液検査でさまざまな値が悪かったのですが、現在はほとんどすべての検査項目が正常値に収まっています。また、長年、人間ドックでは超音波エコーによる「脂肪肝」の所見があったので、過去2回の人間ドックでは「脂肪肝」の所見はなくなりました。

在宅勤務という働き方

1984年に就職した頃は、ソフトウェア開発を行うには、会社に行くしか選択肢はありませんでした。ソフトウェアの開発環境はすべて会社にしかなかった時代です。1990年代には、電話回線を使って会社のコンピュータへ入って、自宅から簡単な作業ならできたりもしたのですが、基本は会社へ出社でした。そして、2020年初めにコロナの感染が広がる前まで、出社していた訳です。ただし、その頃は、何かのときには自宅から普通に作業できる環境にはなっていました。しかし、体調不良とか、雪で交通機関がマヒしているとかでない限り、出社でした。

そして、コロナによる在宅勤務が始まり、それが長期間となったため、2018年の入社当時は原則出社であったメルカリも「YOUR CHOICE」という制度を導入するまでに変わっていきました。

現在勤めているカウシェでも、基本的に在宅勤務を続けていますし、入社してからまだ一度も出社していません。在宅勤務における一番の問題はコミュニケーションだと思います。しか、在宅勤務という働き方が、後退して出社するという時代に戻ることはなく、コミュニケーションの問題は今後さまざま方法や技術により緩和されていくと思います。

社会全体が在宅勤務になることはありえませんが、ソフトウェア開発は、その性質上、在宅勤務が可能な領域が多いと思います。コロナが収束しても、おそらく今後もずっと在宅勤務を続けていくだろうと思います。
コメント(0) 

今日から8社目 [プログラマー現役続行]

今日(10月1日)から、私にとって8社目となる新たな会社で働き始めます。ただ、今日は土曜日なので、実際には3日(月)からとなります。

1978年4月に、当時としては全国でも数少ない情報工学科(九州工業大学)に入学してから、すでに44年が過ぎました。高校生のときに、なぜ情報工学科を選択したのかあまり覚えていませんが、一般家庭の多くに電卓さえなく、コンピュータに触ったことがない人がほとんどだった時代でしたので、コンピュータを学びたいと思ったのかもしれません。当時、情報工学を提供しているのは、九州では、九州大学と九州工業大学だけでした。私は、情報工学科の第8期生だったと思いますので、九州工業大学では早くから情報工学科があったことになります。
※ 現在は、当時なかった飯塚キャンパスに情報工学部があり、戸畑キャンパスの工学部には情報工学科はありません。

大学生の頃、60歳過ぎまでソフトウェア開発に従事しているとは想像できませんでした。社会人になっても、多くの同期が30歳過ぎぐらいにはソフトウェアを開発しなくなっていく中で、私自身はソフトウェア開発を続けていたいと思っていました。36歳で最初の転職をしたのですが、その後は、実際にソフトウェア開発をしたり、管理職をしたり、あるいはプレイングマネージャとして両方を行ったりしてきました。

メルペイでは、一人のソフトウェアエンジニアとして4年4か月働きました。Covid-19により、2020年2月18日から在宅勤務となり、その後は昨日(9月30日)の退職日を含めて2回しか出社していません。そして、この間に、世の中の働き方が変わり、フルリモートで働くことが可能な会社が増えました。

今後も在宅勤務で働きながらソフトウェア開発を続けることになります。今の時代は、通勤することなく、どこからでも、何歳までもソフトウェア開発を続けることが可能になったとも言えます。私自身は、正直なところ、何歳まで働くのか分からないですが、いつまでもソフトウェア開発を楽しめるように健康でいたいと思っています。

「で、どこの会社で働くの?」・・・来週金曜日までには、おそらくアナウンスします。
コメント(0) 

外部発信よりも内部共有・実践 [プログラマー現役続行]

エンジニアが集まって、LTを行ったり、20分から30分程度の発表を平日の夜に行うというのは、いつ頃から広まっているのか定かではありませんが、この10年間で確実に広まってきています。さらに、コロナ禍により、オンライン開催も加わり、広く行われるようになりました。

一方、Advent Calendarといったtech blog(技術文書)を公開することも多く行われています。企業内の開発で得た知見を、オンラインで説明しながら話したり、tech blogとして公開することは、今日のIT業界では、当たり前のように行われています。これらは、すべて外部へ向けての発信です。

外部発信することで、その企業の技術力を発信することにもなり、エンジニアを惹き付けることにもなります。私自身もTech Talkで話をしたり、tech blogを書いてきました。このような情報発信は、今後も多くのIT企業やスタートアップで行われていくと思いますし、ソフトウェア業界で知見を共有する上でとても有益だと思います。

このような情報発信を外部から見てみると、発信されている知見がその企業で広く共有され、ベストプラクティスと思われるようなことは、その企業内で広く実践されていると思いがちだと思います。しかし、本当にそうなっているのでしょうか?

多くのIT企業やスタートアップでの情報発信は、「外部へ発信」することが目的であり、「知見を社内で共有する」ことは目的ではなかったりするのではないでしょうか。得られた知見やベストプラクティスなどは、外部へ発信するのではなく、内部で共有して実践することが、企業にとっては本来優先順位が高くあるべきだと思います。その上で、外部発信することで、業界全体へ貢献することになります。

おそらく、このような状況になるのは、外部への発信を促進する責任を持つチームやグループが組織内にはあるけど、内部での共有や実践を促進することに責任を持つチームやグループが存在しないからではないでしょうか。あるいは、個々のエンジニアにとって、そのような活動をすることが責務ではないからかもしれません。あるいは、一人のエンジニアとして強く推進するのにはかなりの努力が必要な場合があるからかもしれません。

組織として何らかの活動をしないと、さまざまな知見やベストプラクティスが、属人化したものとなってしまい、たとえそれらが外部へ積極的に発信されていていも、組織内で広く共有されいなかったり、実践されていなかったりするのではないでしょうか。
コメント(0) 

手動テストだけのソフトウェアは腐っていく [プログラマー現役続行]

1990年代までのソフトウェアテスト

1990年代までのソフトウェア開発におけるテストは、手作業で目視確認が主流でした。今日のようにテスト駆動開発で、自動テストを書くという習慣はありませんでした。いくつかの書籍から、本当でそうであったかを引用すると次の通りです。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

  • 出版社/メーカー: オーム社
  • 発売日: 2014/07/26
  • メディア: 単行本(ソフトカバー)

著者のMartin Flowerは、この本の中で次のように述べています。
テストの実行は確かに簡単になりました。しかしテストの実行は簡単になってもテストは依然として極めて退屈なものでした。これは、コンソールに出力されるテスト結果を私がチェックしなければならないためです。

Clean Code アジャイルソフトウェア達人の技 (アスキードワンゴ)

Clean Code アジャイルソフトウェア達人の技 (アスキードワンゴ)

  • 出版社/メーカー: ドワンゴ
  • 発売日: 2017/12/28
  • メディア: Kindle版

この本で、著者のRobert Martinも、次のように述べています。
この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。

Coders at Work プログラミングの技をめぐる探求

Coders at Work プログラミングの技をめぐる探求

  • 出版社/メーカー: オーム社
  • 発売日: 2011/05/25
  • メディア: 単行本(ソフトカバー)

『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。
「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」
それに対して、Joshua Blochは、

「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」

という話をしています。

1週間半費やしてその原因が何であったかというと、彼が書いたコードではなくて彼が書いたコードが使っていたミューテックスのライブラリにバグがあったっていうことです。それに対してインタビュアーが、

「そのミューテックスの作者がテストを書いていればバグは見つかったはずで自分が1週間半デバッグすることはなかったのにと思いますか?」

と聞いています。
インタビュアーの質問に対するJoshua Blochの回答は次の通りです。
頭に入れておく必要があるのはこれが90年代初期の話だということです。十分なユニットテストを書いていないということで、そのエンジニアを非難しようという気は全く起きませんでした。
1990年代は、このような時代だったのです。実際、私自身も、テスト駆動開発を行うようになったのは、2003年からです。

手動テストだけのソフトウェアは腐っていく

私自身は、1980年代、1990年代といくつかのプロジェクトに従事してきました。そのほとんどが、新規開発プロジェクトでしたが、後継の商品が開発されないものがほとんどでした。結果、手作業でテストしていたにも関わらず、開発されたソフトウェアが長年にわたって肥大化する前にプロジェクトが終わってしまい、ソフトウェアが腐っていくといことをあまり実感していませんでした。

2000年以降も新規開発プロジェクトにいくつか従事したのですが、一方で、既存のソフトウェアの修正などのレビューも多く行ってきました。さまざまなソフトウェアをレビューしていくなかで、分かったのは、「手動テストだけに頼っているソフトウェアは、年々腐っていく」ということです。
  1. 手動テストだけに頼ってテストされており、すべての機能のテストに多くのテスターと長い期間を必要とする
  2. 機能が毎年追加されたり、修正されたりしている
1.に関しては、最初は少人数で短期間であっても、機能追加が行われるごとにテスターの人数が増えて、テスト期間が長くなっていきます。

すべての機能を一通りテストする工数が増大してくると、追加された機能やバグ修正された機能だけをQAがテストして、リリースしようとします。そうなると、機能の追加やバグ修正の際に、次のことが(マネジメントから)要求されるようになります。
  • 既存の機能のコードには一切変更を入れない。たとえ、新規機能で追加されるコードと共通化できるコードがあっても、共通化が既存の機能のコードの修正になるなら、共通化は行わない。
  • バグを修正する場合も、修正コードを追加した結果、仮にif文のネストが深くなったり、caseラベルの処理が長くなったりしても、関数化やメソッド化によって既存の機能のコード変更になる場合、関数化やメソッド化は行わない。
つまり、既存の機能のコードは、一切触らないし、リファクタリングもしないまま、次のようなコードが生み出されていきます。
  • 似て非なるコードが多くある。つまり、既存の機能のコードをコピーしてきて、一部を修正しただけのコードが増えていく。
  • if文のネストがとても深くなっていく。
  • caseラベルの処理が長くなっていく。さらに、その処理にネストが深いif文が書かれる
  • 一つの関数やメソッドが長くなっていき、その中のローカル変数のスコープが広くなって、実質的にグルーバル変数のようになってしまう。
このように腐ってしまったソースコードは、エディタで開いた瞬間、そっと閉じたくなるものです。
コメント(0) 
前の10件 | - プログラマー現役続行 ブログトップ