3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

[読書]IT業界の病理学

3
Posted at

こんにちは。今日はいつもの小ネタではなく、一風変わって書籍紹介のような記事を書いてみたいと思います。たまにはこういうのもいいんじゃないかなとw

書籍情報

350_130970.jpg

ざっくり概要

IT業界というよりはシステム開発界隈の様々な事例を、「症例」という視点で捉え、それぞれの症例に対して、その症状、原因、治療法、予防法、という視点で記事が書かれている、というものです。

少々曲解かもしれませんが、わかる人にはわかるシステム開発あるある本と言い換えてもいいかもしれません。

目次

  • 1章 開発の病気
  • 2章 レビュー・テストの病気
  • 3章 保守・運用の病気
  • 4章 マネジメントの病気
  • 5章 業界の病気

個人的に刺さった話題の抜粋・所感

個人的に「おっ」とか「ギクッ」となった話題を抜粋して、私なりの感想を交えて紹介してみたいと思います。

1章より「絶対にさわれないソースコード」

1000行オーバーのメソッド、命名規則・ソースコードの記述ルール・開発標準がなくカオス、コピペされたコードの嵐(同じコードが色んなところに直書き)、全体を把握している開発者が一人もいない、という どこかで聞いたことがあるようなないような話 がテーマです。うっ、頭が(

主な原因として考えらえることは、時間がなかった という点に集約されています。正直身もフタもないとは思いましたw

時間がないゆえに

  • とにかく動けばよい
  • テストも書くヒマがない
  • リファクタも後回し

ということが 積み重なった結果 絶対にさわれない、というかさわりたくないソースコードが生まれてしまった、ということが要旨と考えられます。

また、そもそも時間がなかったことの背景 として、ソースコードの整理や教育に対する投資を、直接利益を生まないという理由で経営者より軽視されている、という背景も少なくないようです。

で、気になる治療方法ですが、第一声に この病気を治療するのは非常に困難です。 と書かれています。とんでもねぇ難病ですね。

根治治療は難しく、地道な対処療法しかないのが現状です。その最初のステップとしては、自動でも手動でもよいのでテストを書こう ということが挙げられています。目的や期待される効果として、

  • 現行のシステム動作・振る舞いを把握するため
  • 変更しても壊れていないことを随時確認するため
  • これにより リファクタリングの心理的障壁を下げるため

というものです。そもそもテストを書くことにもある程度の慣れや技術が必要なので、テストを書く練習を研修などに取り入れていくといいのかな、と私はぼんやり考えました。

ちなみに予防法としては ソースコードの実態を開発中に常に把握する ということが挙げられています。前述の1000行超えメソッドが無いか、など例えるならそういう話です。

「ステップカウンタ フリー」等で検索すると、規模を計測する助けになるツールなどが実はネットにけっこう落ちていたりします。興味がある方はぜひ探してみてください。

2章より「全部そろってからレビュー」

レビューの粒度が大きすぎることによるデメリットや問題点にフォーカスしたトピックです。
大きすぎる粒度のレビューの主な問題点としては

  • そもそもレビューに大きな時間がかかり、レビュアーに負荷がかかる
  • レビューの精度を保てず、下手すると重大な問題点を見逃しかねない
  • もしフェーズの後半に大きなレビューを集中して行い、修正項目もたくさん出ると今度は修正する時間が足りなくなる

という点です。かくいう私にもレビュアー、レビュイー両方の立場で多少身に覚えがあります(苦笑)

こちらの原因は単純にレビューの粒度を細かくすればよい、とは限らないことがここでの興味深い点でした。もし成果物の最終的な品質をレビューしたい場合、逆に全部そろわないとレビューにならないからです。

ここで大事なポイントは 何をレビューしてほしいのか(あるいはレビュアー的には何をレビューしたいのか) という目的をはっきりさせ、それに対して 予めレビューの計画・予定を立てておく ことです。

実はこれはレビュアーにも非常に大事なところで、レビュー時にどこまで踏み込むのか という点も考慮できる意味でも事前に計画を立てておくことは大きな意味があります。

これからレビューすることもしてもらうことも両方あると思いますが、この章は短いながらも非常にポイントが高いという印象を受けました。

感想

とりあえず気になったものをかいつまんでみました。全体的な印象としては、正直大手の業務系システムを想定した状況が多いかな?と感じました。ただ、中には汎用的に参考になる記事もありましたし、書籍自体は通勤の合間にサクサク読めてしまう程度の文量でわりととっつきやすく、「これは参考になる」と思えたところだけをうまくパクって活用するだけでも違うんじゃないか、ということが読了後の印象でした。

もし気になったという方は試しにレジに持っていってみてはいかがでしょうか。

本稿へのツッコミ、感想、単にひとことなどあればお気軽にコメントください。

ではまた。

3
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?