So-net無料ブログ作成
検索選択
前の10件 | -

コードレビューの目的 [コードレビューの視点]

ソフトウェア開発で行うコードレビューは、1つの目的ではなく、様々な目的を持ちます。きちんと機能が実装されているかを確認することは、目的の1つです。しかし、それだけではないわけです。

他の目的の1つとして、作成したソフトウェアエンジニアのスキルレベルを知って、どこが弱いのかを把握し、指導する場でもあるわけです。弱い部分には色々な側面があります。その1つとして、第3者にとって分かりやすく書かれているかも含まれます。

ソフトウェア開発では、ソースコードを作成するだけでなく、様々な成果物があり、それらもレビューされます。たとえば、様々な文書もそうです。書かれた文書が、書いた本人にしか理解できないし、誤解を招くような日本語で書かれているといったことは、レビューを通して指摘し、修正させることを繰り返すことが必要です。その結果、本人のレベルが向上して、誰が読んでも誤解することなく分かりやすく書けるようになるわけです。

もし、担当者が書いたものを何もレビューしなければ、担当者のスキルレベルが低い場合には、役に立たないがらくたの文書が作成されるだけであり、担当者は何年たっても質の低い文書を書き続けるかもしれません。

「コードレビュー」と言っても、行っていないソフトウェア開発組織もあるでしょうし、きちんとしたレビューを受けたり、指導をしたこともなく、ソフトウェア開発をしなくなった管理職もいると思います。その結果、「コードレビュー」をすることに関しては、文書をレビューすることと比べて、時間がかかり過ぎるとか無駄だと思う人がいてもおかしくはありません。

コードレビューには、様々な目的が含まれていますが、ソフトウェア開発組織にとって重要なのは、色々な意味で技術的負債とならないコードにすることと、ソフトウェアエンジニアのスキルレベルを長期的に上げるためということです。


スポンサーリンク





ドコモのdマガジンを契約してみました [その他]

ドコモのdマガジンを契約してみました(ドコモと回線契約がなくても契約できるようです)。

https://magazine.dmkt-sp.jp/
https://www.nttdocomo.co.jp/service/entertainment/dmarket/magazine/

月額が400円(税抜き)で様々な雑誌が読めるということで、契約してみたのですが、確かに多くの雑誌が読めます。コンピュータ関連としては、以下の雑誌が読めます。
  • 週刊アスキー
  • Mac Fan
  • 日経PC21
Mac Fanは、Kindle版でも630円なので、古い号を読む必要がなければ、dマガジンがお得です。ただし、いくつかの制約があります。
  • 雑誌のすべてのページが読めるとは限らない。雑誌ごとに異なります。
  • iOSあるいはAndroid上の専用アプリからしか読めない。PCからは読めません。
  • 保存はできない。読む時は、インターネットに接続されていなければなりません。
書店の雑誌コーナーに行ったような感じで、様々な雑誌から読みたいものを選んで読むことができます。平日は、ほとんど書店に寄ることはないのですが、dマガジンであれば、帰宅してから、その日に配信された雑誌を読むことができます。12月だけでも雑誌の配信日が合計25日です。

いったい、どんなビジネスモデルなのでしょうか?

書籍『私はこうして英語を学んだ 増補改訂版』 [英語]

私はこうして英語を学んだ 増補改訂版

私はこうして英語を学んだ 増補改訂版


1979年に出版された本の改訂版です。初版は、大学生の時に読みました。初版は、ずっと持っていましたが、書斎が手狭になったので、数年前に他の書籍と一緒に処分してしまいました。

大学時代に、私の英語学習にもっとも影響を与えたのがこの本の初版でした。記憶が定かではありませんが、確か小倉の商店街にある書店で購入したような記憶があります。

残念ながら、今では何が書かれていたのかほとんど記憶にないです。その意味で、初版の原文がそのまま掲載されている改訂版を読むのを楽しみにしています。

Podcastで英語のニュース(2) [英語]

Podcastで聞く米国や英国のニュース英語は、速いです。同じニュース番組でも、日本語の放送ではそんなに速くは話さないです。

私の場合、高校まで英語を聞くということは一切ありませんでした。大学生になってから、英語を聞くようになったのですが、大学生の頃のリスニング力は、次のような段階を経ました。
  1. 何も聞き取れずに、ただの音の流れになっている。単語の区切りさえ分からない。
  2. 徐々に単語の区切りが分かるように、耳が英語になれてくる。
  3. 単語は、かなり切れて聞こえるが、何を言っているのか分からない。
この最後の段階になると、語彙と頭から聞いて理解できる文法力が必要になってきます。言い換えると、「読んで分からない英語は、聞いても分からない」という状態に直面しました。

それまでも、英語を読むことはしていましたが、やはり、多読して、多くの英語は読む必要があることを認識したわけです。多読することは、以下の2つのことを達成するために必要だと思います。
  • 頭から読みながら構文を理解して、内容を理解する。
  • 知らない単語に、何度も出会う
昔は、電子辞書もありませんし、Kindleもありませんから、知らない単語に出会うたびに辞書を引いていたら時間がかかってしまいます。そこで、意味をはっきりとは知らないが、前後の文章から意味を推測して読みます。もちろん、推測は間違っているかもしれません。しかし、重要なのは、多読することで、その推測した単語に様々な文脈で出会うことです。そうすれば、その単語を記憶することができますし、何回か出会った後に辞書を引いて意味を確認します。

TOEICの対策本をたくさんこなすよりは、普通のペーパバックなどで自分が好きなジャンルの本を多読する方がよいと思います。私自身も、Sidney SheldonやJohn Grishamなどの小説は多く読んでいました。

最近は、会社でTOEICの点数が昇格基準になっていたりするため、TOEICの点数だけを問題にしている若い人たちが多いです。そのため、TOEICの対策本しか勉強しなかったりしますし、目標とする点数を達成したら、何もしなくなったりします。TOEICの対策本では、有益な情報・経験・感動を英語で得るのは難しいと思います。

Podcastで英語のニュース [英語]

英語とTOEIC(3)」で普段Podcastで聞いている英語ニュースについて簡単に紹介しました。改めて紹介すると、以下のニュースを購読して見たり聞いたりしています。
  • Anderson Cooper 360° Daily (Video)
  • NBC Nightly News (video)
  • NBC TODAY Show (video)
  • CNN Student News (video)
  • GlobalNews
最初の4つは、映像があるニュースです。最後は音声だけのBBCのニュースです。「NBC TODAY Show」は、朝のニュース番組のダイジェストとなっています。米国に住んでいた頃、朝は、2時間のニュース番組を見ていることが多かったです。

CBSの「This Morning」やABCの「Good Morning America」などはよく見たものであり、当時のアンカーやアナウンサーが他の番組で登場すると懐かしく感じます。

Podcastで見たり聞いたりと言っても、ほとんど、ながらです。つまり、他の作業をしながらです。ニュースの英語のスピードはかなり速いですが、TOEICの対策本でリスニングを鍛えるのではではなく、日々のニュースを聞くことで、英語のスピードにに耳を慣らすのが良いと思います。それと同時に多読も必要です。なぜなら、「読んでも分からないものを耳で聞いても分からない」からです。

キャリア・アンカー [プログラマー現役続行]

ウィキペディアでは、「キャリア・アンカー」は、次のように説明されています。
キャリア・アンカーとは、アメリカ合衆国の組織心理学者エドガー・シャインによって提唱された概念。

ある人物が自らのキャリアを選択する際に、最も大切な(どうしても犠牲にしたくない)価値観や欲求のこと、また、周囲が変化しても自己の内面で不動なもののことをいう。
さらに、アンカーの分類として、以下の8分類が説明されています。
シャインは主なキャリア・アンカーを「管理能力」「技術的・機能的能力」「安全性」「創造性」「自律と独立」「奉仕・社会献身」「純粋な挑戦」「ワーク・ライフバランス」の8つに分類した。
  • 管理能力 - 組織の中で責任ある役割を担うこと(を望むこと)。
  • 技術的・機能的能力 - 自分の専門性や技術が高まること(を望むこと)。
  • 安全性 - 安定的に1つの組織に属すること(を望むこと)。
  • 創造性 - クリエイティブに新しいことを生み出すこと(を望むこと)。
  • 自律と独立 - 自分で独立すること(を望むこと)。
  • 奉仕・社会献身 - 社会を良くしたり他人に奉仕したりすること(を望むこと)。
  • 純粋な挑戦 - 解決困難な問題に挑戦すること(を望むこと)。
  • ワーク・ライフバランス - 個人的な欲求と、家族と、仕事とのバランス調整をすること(を望むこと)。
数年前、52歳を対象とした研修で、自分のキャリア・アンカーを調べるというのがあったのですが、確か「技術的・機能的能力」が非常に高かったです。一方で、いわゆる管理職的な仕事は、過去も行ってきてはいます。日本オラクル社時代は、当時のOracle ApplicationsのHRシステムの開発マネージャでしたし、前職のFXISでも開発部の部長でした。しかし、今でもそうですが、「管理能力」はキャリア・アンカーとしては、かなり低いです。つまり、管理職を指向していないということです。

今、振り返ってみると、日本オラクルを退職したのも、FXISを退職したのも、私自身のキャリア・アンカーとは一致していなかったためかもしれません。最近は、私の回りの知り合いの若手のソフトウェアエンジニアで、転職する人達が多いのですが、彼らも「技術的・機能的能力」を指向しているためなのかもしれません。
※ 今年だけで、6名です。私の直接の部下ではありませんが、4名はJava研修の修了生です。

いつも受け入れられるとは限らない改善提案 [プログラマー現役続行]

社会人となって30年間、様々なソフトウェア開発従事していた経験から言うと、改善提案は上位のマネージャや部門長に受け入れられる場合とそうでない場合があります。その中でも、問題が発生してから、その問題を解決するという改善提案は受け入れられることが多いです。しかし、発生するであろう問題を予測して、それに対して事前に対策を打つという改善提案は、理解されなくて、受け入れらないことがあります。

問題が発生してからの改善としては、ソースコード管理用のリポジトリは用意していたが、開発の終盤までビルドは、一人の開発者のPCでしかできなくて、ビルドを間違いなく行う必要がでてきて、やっとサーバで自動ビルドが一日一回行われるとかです。さらに、コードの品質が悪くてバグがたくさん出るので、FindBugsなどの静的解析ツールを導入して改善しますと言った提案です。しかし、静的解析ツールを導入した時点ではすでに遅く、すべての警告を修正することができなかったりまします。そうすると、どの警告を修正するかしないかの分類をしようということになるのです。

一方で、同じ状況で、プロジェクトが開始された時点で、継続的インテグレーション環境や静的解析ツールを導入して、最初からすべての警告を潰していきましょうという提案は、そのような環境を準備するために工数を費やす利点を理解できなくて、却下されたりすることがあります。あるいは、説得するために多くの資料を作成させられることになります。

この場合、問題が発生してからの改善提案は、上位のマネージャに対して「提案活動をした」ということで評価されるでしょう。しかし、予測される問題に対する改善提案は評価されないかもしれません。そうなると、事前に予測される問題を潰すという改善提案を現場はしなくなるわけです。

どのような問題が発生するかを予測するには、予測される問題を過去に経験して、それを解決したという経験がないと、できないかもしれません。その意味で、上位のマネージがそのような経験を積んでいる必要がある訳です。しかし、逆に考えると、そのようなマネージャであれば、プロジェクトが開始された時点で開発環境の整備などをトップダウン的に指示するはずであり、現場が改善提案をする必要がないわけです。これは、マネージャでなくても、中堅のソフトウェアエンジニアに対しても当てはまることです。

私も、ある時、中堅のエンジニアに対して、これから、たくさんの機能を開発していなければならないので、古いCVSを用いた手作業のビルド環境から、Subversionを用いた継続的インテグレーション環境を整備して、単体テストも整備すべきと提案したことあるのですが、「これから開発しなければならない、たくさんの機能と開発環境の整備のどちらの優先順位が高いか精査して、開発環境の整備の方が高ければ人を割り当てます」と言われたことがあります。正直自分の耳を疑ったのですが、議論してもしかたないので、その後、自分と若手の協力会社の2名で開発環境整備して、全面的に移行させてしまいました。

あるいは、別の遅れているプロジェクトでは、遅れを取り戻すために私が手伝えることを5項目ほど列挙して、その中にも継続的インテグレーション環境の構築も含まれていたのですが、すべて却下されたことがあります。残念ながら、そのプロジェクトは、私が予測した通りの問題が多数発生していました。

このようにマネージャや部門長などへのソフトウェア開発に関する改善の提案は、その内容によっては、すんなり受け入れられる場合と、本質的な提案であっても「理解されない」場合があります。

55歳 [時の流れ]

早いもので、すでに55歳になってしまいました。大学一年生の18歳の時に、大学のコンピュータセンターでコンピュータに触れてから、37年が過ぎたことになります。当時は、大学に行かなければ、コンピュータが使用できない時代でした。

今日では、電車の中やスターバックスで、MacBook Airを使用しながら、翻訳作業をしたり、メールを読んだり、プログラミングをしたりと様々なことができます。昔、「Star Trek: The Next Generation」を米国で見ていた1990年頃は、登場するタブレットは、どうやってメインのコンピュータと通信しているのだろうかとか、操作パネルがすべてタッチ式というのは本当に来るのだろうかと思っていましたが、今では、普通に自宅でiPadを使用しているわけです。

1988年から1993年までの米国暮らしでは、日本の両親とは国際電話で話し、2002年から2003までの(短かった)米国暮らしでは、父親とは電子メールでやり取りしていました。そして、ここ2年ぐらいは、iPadのFaceTimeを使用して顔を見ながら両親と話すことが多いです。

昔、Star Trekで見た世界は、一部を除いて、今では実現されているものが少なからずあります。しかし、大学に入った頃と今も変わらないのは、プログラミングは、頭の中で考えたことを、人が手を動かしながら行うということです。パンチカード、ラインエディタ、スクリーンエディタという時代から、マルチウィンドにEclipseやNetBeansなどのIDEへと、プログラミングの道具は、目覚ましく発展しました。しかし、創造的部分は、やはり、人の頭の中で行われるわけです。

その創造的な活動を、何歳になっても続けていきたいと思っています。

継続した学習(4) [プログラマー現役続行]

継続した学習」では、中途採用の面接で私が行っている「継続した学習の習慣の確認」の方法としての、書籍一覧での確認の話を書いています。

継続して学習するという習慣は、非常に重要なのですが、新卒新人で入社した場合には、配属された職場の先輩達の習慣に大きな影響を受けることがあります。先輩が、業務としてのソフトウェア開発を遂行する上での最低限の学習しかせずに、既存のコードの書き方をまねるだけで、細かな点に注意を払わないようであれば、新人で入ってきても、同じような習慣になってしまう可能性が高いです。

その結果が、中途採用を募集しても、ほとんど書籍を読まない人達ばかりが応募してくるという状況かもしれません。あるいは、複写機メーカーということで、そのようなソフトウェア開発者達が応募してくるのかもしれません。組み込みシステムを開発している人達は、必要なプログラミング言語を学んだ後は、新たなことを学ばない傾向が強いと私は感じています(2000年の頃に、実際にアンケートで調査したことがありますが、C言語しか知らない人は、本を読まない人が多い傾向にあるという結果でした)。

同じ会社であっても、所属する組織によっては大きな差があるかと思います。中途採用と同じアンケートを実施したとしたら、おそらく、組織ごとに大きなバラツキがでるのではないかと思います。あるいは、個人ごとに異なる結果になるかもしれません。たとえば、私から影響を受けた人達、特に、1年間の厳しいJava研修を修了した人達とそうでない人達には、学習習慣に大きな差が出ているかもしれません(Java研修では、1年間で合計で約1,000ページの技術書を読まないといけないので、継続して予習を行わないと修了できません)。

テスト駆動開発プロジェクトの経験(5) [時の流れ]

前回からのつづき)

ソフトウェア開発におけるテストの自動化やテスト駆動開発などは、それほど古い訳ではなく、2000年以降に徐々に採用されてきています。そして、今も、自動テストを整備することなく、テストを手作業で行っているソフトウェア開発も多いと思います。

その意味で、社会人となって従事するソフトウェアプロジェクトが、テスト駆動開発になっているのか、手作業でテストを行う開発なのかは、ソフトウェアエンジニアのスキルとして大きなギャップを生み出すかもしれません。

テストファーストでの開発では、最初にAPIを考えることが求められます。たとえば、小さな機能であっても、その機能を提供するAPIをどうするかを最初に考えます。そして、それから、テストコードを作成し、テストが失敗することを確認します。そして、実装を始めるわけです。

特に、これにきちんとした防御的プログラミングとしてのパラメータ値の検査を行うことをAPIに明確に記述することで、そのためのテストも作成します。また、すべての機能をテストするためには、どのようなテストを作成すればよいかを悩みながら考えるわけです。

一方、手作業でテストする開発では、意外とありがちなのは、APIを考えるのですが、正常のパラメータしか渡ってことないという前提で実装を始めて、正常ケースだけを実装してしまうことです。そして、実装が終わったと思った後に、部分的なテストだけを書いて、実装が終了したと判断するわけです。

テストファーストによる開発は、本を読んだら身に付けられるかというと、そうではありません。テストファーストによるテスト駆動開発では、ソフトウェアエンジニアに対して多くのことをきちんと行うことが求められます。APIを考えて、テストを苦労して作成して、それから実装するということを意識して繰り返すことで、無意識に行えるようになるまで開発経験を積んで行く必要があります。そのような状態になって初めて、未経験者に対して指導ができるようになるわけです。

技術的な知識を学ぶのは、書籍を読んだり、ウェッブで調べたりすればできるのですが、ソフトウェア開発では、普段の行動パターンとして、求められることも多くあります(「ソフトウェア開発組織が持つべきカルチャー」)。そのような行動は、実際に自分で経験していく必要があります。

その意味で、最初からきちんとしたテスト駆動開発のプロジェクトとに従事すると、新人であっても様々なことをきちんと行うことが求められ、本人が意識しなくても、強制的に身に付くわけです。しかし、そのような開発でない場合は、数年、あるいは、10年以上もソフトウェア開発を経験して、中堅となっても、テスト駆動開発を推進できないし、しないソフトウェアエンジニアになってしまう可能性は高いです。

Jenkinsを導入していても、ビルドを自動化しているだけ、何もテスト書いていなければ、テスト駆動開発ではないわけです。その意味で、テスト駆動開発の経験を問われた時に、Jenkinsを導入したことがあるという回答では不十分であり、期待する答えではないわけです。
前の10件 | -