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

守・破・離(1) [プログラマー現役続行]


終章「技術の伝達と個人の成長」より
 茶道や武道の世界には、「守・破・離」という教えがあります。これはその人のレベルに応じて、それぞれの段階でどのようなことを実践すべきかを示したものです。三つの段階を簡単に説明しておくと、「守」は決まった作法や方を守る段階、次の「破」はその状態を破って作法や型を自分なりに改良する段階、そして、最後の「離」は作法や型を離れて独自の世界を開く段階です。
 一般的には、すべての学習は真似から始まります。手本に従ってそれと同じようにすることを求められるのです。これがまさに「守」です。
 決められていることを生真面目に守るこの段階は、繰り返しも多く非常に面倒だし、なによりもやっているほうは面白くもなんともありません。そのためそこで我を通して自己流でいきたがる人がいます。しかし、自分の土台をつくるためには、素直に手本を真似るほうが結果として早く進歩することができます。
 実際、初期の段階で我慢して手本の真似を徹底的に繰り返していると、そのうちに手本と同じようにやることの意義や、手本から外れたときに生じるデメリットが理解できるようになります。ここまでくると「強制されて仕方なく守っている」というより、「自ら望んで守っている」という状態になります。やっていることの内容や価値を自分なりに理解しているので、自分の意思で率先して手本を守るようになるのです。
 ところで、世の中にはこの状態で満足してしまう人がたくさんいます。そのような人は、当然のことながらそれ以上の進歩はありません。
 本当に楽しいのはここからです。この段階まで来た人は、自分で創意工夫をしながらいろいろなことが試せるようになります。内容を理解しているため、従来の方法よりもっといい方法はないかと自分で探すことができるからです。そのような能力があるのに何もしないのはもったいないことです。
 そして、この状態がまさに作法や型を破る「破」の段階です。基本的には、作法や型を手に入れて、そこからさらに出ようと意識して行動した人だけが進歩を続けられるのです。もちろん、このときの試行錯誤はしっかりとした経験と根拠に基づくものなので、初心者があてずっぽで行動するのとはまったく違います。決められた道から外れても、それによって致命的な失敗を犯す危険性は極めて低いし、むしろこのときの行動はより効率的で合理的な方法の創出につながらう可能性も大です。
残念ながら、普通の企業におけるソフトウェア開発では、お手本として優れたソフトウェアが存在することは少ないです。実際には、悪いお手本が蔓延し、経験の浅い若手などは、その悪いお手本を真似する(コピーする)ことが多く、結果として、「守」の段階から抜け出せなかったりします。そして、次の「離」への段階へほど遠いものとなってしまいます。

たとえば、次のようなJavaのコードを見かけることがあります。
if (null == x) {
    ...
}
C/C++言語では、本来x == NULLと書くべきところを間違ってx = NULLと書いてしまってもコンパイルが通ってしまい、誤ったコードを書いたことに気付かないので、NULL == xと書くように指導された人も多いかと思います。しかし、最新のコンパイラであれば警告してくれます。「コンパイル時のワーニング(-Wallと-Werror)(2)

Javaでは言語仕様が異なりますので、そもそもif (x = null)と書いたらコンパイルエラーです。なぜなら、xboolean型ではないからです。もし、C/C++言語からの習慣で、Javaでもそのように書いているとしたら、その人は、とても次の「離」の段階にはいけないと思います。また、Javaでもそのように書くように指導している人も同じです。


スポンサーリンク





技術書のレビュー(3) [プログラマー現役続行]


短期の依頼ですが、この本もレビューすることになり、レビューを始めました。この『Core Java』は初版から第9版まで読んだことはないです。もう、書き終えたようで、すべての章が送られてきました。

4月からレビューしている『The Go Programming Language』は、Brian KernighanとAlan Donovanによる執筆が続いています。

The Go Programming Language (Addison-Wesley Professional Computing Series)

The Go Programming Language (Addison-Wesley Professional Computing Series)

  • 作者: Alan A. A. Donovan
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2015/11/02
  • メディア: ペーパーバック



スポンサーリンク





コードレビューの視点 017 [コードレビューの視点]

防御的にプログラミングされているかに注意する

防御的プログラミングに関しては、過去に書いているこちらを参照してください。

書いたコードが正しく呼び出される限り、防御的プログラミングのためのコードは余分なコードのように思えてしまうかもしれません。しかし、様々なモジュールを結合してソフトウェアを作り上げていくと、常に正しく呼び出される保障はありません。

16年ぐらい前の話ですが、当時、ある若いエンジニアのコードをレビューした時に、引数の値の異常値を検査していなかったので、そのことを指摘したことがあります。その時の彼の回答は、「そのような異常値は、仕様書に書かれている正しい値の範囲外であり、そのような値が渡ってくることはありません」でした。

それに対して、「仕様書に書かれた通りの範囲の値が渡されるのは、すべてのデバッグが終わった時なので、検査をするコードを入れなさい」と返事したような気がします。

実際、防御的プログラミングは、それを行ったことによる効率的な障害調査を経験してみないと、必要性を実感できないものです。そのため、強制的に防御的プログラミングをさせる必要があるかもしれません。

ソフトウェアの品質を高める1つの方法として、コードレビューでは、防御的プログラミングを行っているかに注意を払う必要があります。


スポンサーリンク





講演予定「レッツゴーデベロッパー2015」 [プログラマー現役続行]

7月25日(土)に仙台で開催される「レッツゴーデベロッパー2015」で話をします。詳細については、下記のリンクを参照してください。


私の話の内容は、次の通りです。
柴田芳樹氏
タイトル
ソフトウェアエンジニアとして心がけてきたこと」
概要
プログラマー”まだまだ”現役続行』の 内容のきっかけとなる出来事を交えながら、ソフトウェアエンジニアとして何を心がけてきたかを中心に話をします。 特に、若手のソフトウェアエンジニアを育成するために、行ってきたこと、感じたこと、考えていることについて話をします。


コードレビューの視点 016 [コードレビューの視点]

ボクシングに注意する

Java言語に限った話ですが、不注意なボクシング/アンボクシングに注意する必要があります。

Javaが1.4の頃からプログラミングしている人であれば、自動ボクシングが言語仕様として存在しない頃からJavaを使用していわけですから、Booleanクラスとboolean型の違いを分かっていると思います。しかし、Java SE 5.0以降からJavaでプログラミングを始めた人は違いが分かっていない人が増えてきていると思います。

5.0は、2004年9月にリリースされていますので、すでに10年以上が経過しています。そのため、基本データ型(byte, short, char, int, long, float, double)とラッパークラス(Byte、Short、Character、Integer、Long、Float、Double)の違いを分からないままプログラミングしている人がいるのではないでしょうか。そのため、コードレビューなどで、以下のようなフィールド宣言を見かけたりします。
Boolean flag = false;
この場合、どうして「booleanではなく、Booleanなのですか?」という質問に対して、質問の意図を理解できないようであれば、ボクシングを理解していないと思って間違いないでしょう。

不注意なボクシングは、使用するメモリ量の増加や性能低下になってしまいます。その仕組みについては、初心者でもしっかりと理解しておくことが必要です。ボクシングに関しては、拙著『Java 2 Standard Edition 5.0 Tiger』の第2章「ボクシング/アンボクシング」を参考にしてもらうとよいかと思います。

コードレビューの視点 015 [コードレビューの視点]

意図しない継承に注意する

Java言語でクラスを設計する場合に、継承されることを想定していなくても、実際には継承可能なコードを書いてしまうことが多いです。たとえば、次のコードを考えてみてください。
public class Point {
    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() { return x; }
    public int getY() { return y; }
}

このようなクラス宣言をした場合には、このクラスの使用方法は、1つではありません。単純にインスタンスを生成するだけでなく、クラスを継承して別のクラスを作成するという使用方法や、さらに、メソッドをオーバーライドして使用するなどができてしまいます。

ところが、コードレビューで、このようなコードを見かけたときに、「継承を前提とした設計なのですか?」と聞くと、「継承されることは想定していません」という返事が返ってくることがあります。Java言語では、継承できないように書くには、さらにクラスをfinal宣言するとかprivateのコンストラクタだけにするとかの手間をかけないといけないため、意図せずに継承可能なクラスを書いてしまうことが多いです。

しかし、継承される前提の設計でなければ、そもそも継承できないように書くべきです。コードレビューでは、その点を注意しなければなりません。特に、公開APIとなるようなクラスでは、なおさら注意する必要があります。

コードレビューの視点 014 [コードレビューの視点]

可視性に注意する

プログラミング言語の多くは、モジュール化を行うための何らかの言語仕様上の仕組みを持っています。たとえば、Java言語やGo言語であればパッケージ(package)をまとまりとして扱います。APIの観点で言えば、パッケージ外に公開されるのか、パッケージ内に隠蔽されるのかという違いとなります。

Java言語では、何らかのIDEを使用している人がほとんどだと思います。その結果、新たなクラスを作成する場合、デフォルトではpublicと宣言されたクラスが生成されたりします。

コードをレビューしてよく指摘するのは、「このクラスはパッケージ外から使用されることを想定しているのですか」ということです。つまり、「クラスをpublicと宣言しているのですから、外部から使用するという設計ですよね」という質問になります。

しかし、「パッケージ外から使用されることは想定していません」と回答されることがあります。パッケージ外からの使用を想定していないのであれば、そもそも、使用できないように最初から書いておくべきなのです。

可視性に注意することは、クラス宣言だけでなく、メソッド宣言にも適用されます。public宣言されたクラスだからといって、すべてのメソッドがpublicというクラスは少ないはずです。

コードレビューでは、設計上の意図がきちんと反映されているかを確認する必要があります。特に、その意図の記述が使用しているプログラミング言語により可能ならば、きちんとその言語の機能を使用すべきです。その一つが、可視性を正しく記述することです。

JAL工場見学へ行きました [その他]

貯めているマイルを使って参加できるJAL工場見学へ6月12日(金)に、妻と二人で行きました。


マイルを使った工場見学には、2種類があるようです。
  • スタンダードコース(2,000マイル/一人)
  • ナイトサファリコース(3,000マイル/一人)
通常の無料のJAL工場見学は、半年先の予約なのですが、このマイルを使用したJAL工場見学は、先着順に予約できます。私も予約したのが5月23日でしたが、約3週間後の6月12日に見学したことになります。

スタンダードコースは、昼間に開催されるもので、無料のJAL工場見学と内容は同じようです。ただ、記念品がもらえます。通常のJAL工場見学の内容は、次の通りです。

【通常/スタンダードコース】
  • 展示エリア(30分)
  • 航空教室(30分)
  • 格納庫見学(40分)
展示エリアもおそらく解説してくれるのではないかと思います。ナイトサファリコースは、内容が少し異なっています。

【ナイトサファリコース】
  • 展示エリア(15分)
  • 航空教室(30分)
  • 格納庫見学(75分)
展示エリアは、自分で勝手に見るだけですので、集合時間である16時45分からの15分間が上記の15分のようです。16時に到着したので、それからすぐに展示会場やショップをゆっくりと見学することができました。つまり、ナイトサファリコースでは、16時頃に行くことをお勧めします。格納庫見学が終わったあとは、展示会場やショップも消灯してしまっていますので。

航空教室が17時から開始され、17時30分から1グループ12名の4グループに分かれて、それぞれのグループは整備士さん2名に引率されて格納庫見学です。予定では75分とありますが、私が行ったときは、90分の見学時間でした。

幸運なことに、政府専用機が整備のために格納庫にあり、目にすることができました。そして、見学が終わる頃には、政府専用機(ジャンボ)の重量を測っていました。

(おそらく、40分の格納庫見学とは異なるのではないかと思いますが)単に見るというのではなく、その夜の国際線の便として実際に使用される767が見学用に準備され、様々なところが開けてありました。預けられた荷物を収納する部分には階段を上がって中を見ることができましたし、車輪の前のカバーや尾翼の付近の下のカバーは開けられいました。そして、単に外から見るだけではなく、その767に乗り込んで、操縦席も見せてもらい、操縦席に座ることもできました。操縦席は、結構窮屈な感じでした。

格納庫全体を回りながら見学するのですが、格納庫の出口では、ひっきりなしに着陸する航空機を目の前でみることもできました。

初めて行ったJAL工場見学でしたが、とても良かったです。必要なマイル数は増えますが、「ナイトサファリコース」がお勧めです。写真撮影に制限は全くありませんでしたが、格納庫見学で撮影した写真は、ブログ、Twitter、Facebookなどでは公開禁止となっています。

P1050042.JPG
展示エリア入り口

P1050043.JPG
歴代のスチュワーデスの制服

CHbeXB1UAAAndx9.jpg
記念品とその箱、入館カード、パンフレット


教育と場(まとめ) [プログラマー現役続行]

過去に書いた記事です。
最後の「教育、場、権限」をそのまま抜粋しておきます。
転職してから気づいたことなのですが、私自身のソフトウェア開発の経験をもとに会社の中で若手のエンジニアの成長を後押しするには、次の3つの条件が揃っている必要があります。
  • 教育 - 基本的に知っておいてもらいたい事柄を技術教育や勉強会という形式を通して教えてく。
  • - 教育で教えたことを、設計レビューやコードレビューなどの日々のソフトウェア開発活動全般を通して指導していく。それにより、教育では伝えきれない部分を伝えていく。
  • 権限 - 日々のソフトウェア開発での指導ができる組織上の権限。
教育を受けただけで、日々のソフトウェア開発で実践指導されなければ、身につくことはないかもしれません。教育をすることだけが自分の仕事だと思っている人であれば、教育したという事実で満足するかもしれません。しかし、私自身は、場が与えられなければ教育の効果がないということを感じています。

日々指導するには、ソフトウェアの開発組織ライン上の権限が必要となってきます。たとえば、チームを構成するメンバーでもなくそのチームリーダでもなければ、チームリーダが指導しないことをそのチームのメンバーに指導することは簡単なことではありません。

つまり、若手技術者の育成には、「教育、場、権限」が必要だということになります。そうでなければ、ソフトウェア開発を何年経験していても、中途半端な技術者が増えるだけかもしれません。


前の10件 | -