やまぐ雑記。

SIerからこんにちは。趣味グラミングはよそでやってます

SIerで、どうすれば邪悪なコードを減らせるのか？

SE 読み物

※多少ぼかしていますが実話です。

邪悪なコードたち

こういうコードに遭遇することがあります。

private boolean customerName() {
    boolean returnValue = false;
    // 姓がnullでない かつ 名がnullでない のとき、trueとする
    // 当てはまらない場合、falseとする
    if (this.SEI != null && this.MEI != null) {
        returnValue = true;
    } else {
        returnValue = false;
    }
    return returnValue;
}
  • customerNameというメソッド名で処理が想像できない。
  • returnValue変数の存在意義がよくわからない。
  • コメントは必要だろうか。条件式を日本語化しただけのように見える。
  • SEI, MEIは定数なのだろうか。
  • else節でfalseを代入する必要はあるだろうか。

頭が痛くなります。

あるいは、こんなコードに遭遇することもあります。

public String 顧客情報を登録する(
    String 姓,
    String 名,
    String 姓カナ,
    String 名カナ,
    SeibetsuEnum 性別区分,
    String 生年月日,
    String 郵便番号,
    String 都道府県,
    String 住所＿１,
    TelEnum 電話番号＿１＿種類,
    String 電話番号＿１,
    TelEnum 電話番号＿２＿種類,
    String 電話番号＿２,
    …
    (あんまり長いので省略)
    …
    String 勤務先名称,
    String 勤務先所属,
    String 勤務先役職,
    String 勤務先郵便番号,
    String 勤務先住所
    ) {
    // 引数の情報を使ってDBにデータを登録する
    (以下省略)

引数を贅沢に使った美味しいスパゲティです。私は食べませんが。

ストレス、ストレス、ああストレス！！

ああ、思い返すだけでもストレスが溜まってしまうようなコードたちです。

炎上しているプロジェクトほど、こうした邪悪なコードを見かけます。

どうすれば、炎上したままこうしたコードを減らせるでしょうか？

まだ、完璧な答えは持っていません。悪い答えと、ちょっとマシな答えはあります。

悪い答え

  • コーディングチェックリストを運用する。
    • だいたい形骸化してやらなくなるか、やったことにする。
  • きちんとレビューをする。
    • そんな余裕があったらとっくにやっている。

ちょっとマシな答え

  • 機械的なチェック、例えばcheckstyleやFindBugsを使う。
    • 完璧ではないが、レビューするよりは大分コストが小さく済む。
      （個人的には「Javaの一般的な命名規約だとか、"参照型変数"くらいは知っててよ…！」という思いではある）
  • チェックリストをほんの数項目だけ用意する。
    • 頻出部分を厳選して用意して、まず60点を目指す。
  • レビューは諦めるが、たまにコードを見て直接本人と話す
    • 「本人のスキル向上（教育）」という側面で、レビューまではいかないけどちょっとでもやる。
  • リーダブルコード（オライリー本）をそっと置いておく。
    • 「この本で読んだ内容なんですけど」と言うとすんなり受け入れてくれたり、興味を持ってくれたりする。

完璧な答え

あったら教えろください。

余談: 「三現主義」

富士通の行動指針には、こういうセクションがあります。

三現主義 … 現場・現物・現実を直視して行動します

「レビューをちゃんとしろ」「チェックリストをちゃんと運用しろ」「ちゃんと」「ちゃんと」…
…現場を見ていれば、こんなセリフはとてもじゃありませんが言えません*1。

作業量を増やさずに、品質を上げる。
または、品質を維持したまま、作業量を減らす。

こういう考えをもって、じゃあ、何ができるだろうか？ と考えるようにしないと、いつまでも溝は埋まらないままです。

*1:言っている方は非常に多いですが…

Demo or Die（SI現場でいろいろ作った話） - Fujitsu Advent Calendar 2016 13日目

SE 読み物

Fujitsu Advent Calendar 2016 13日目の記事です。

ワクワクする夢の技術ではなく、ドロドロした現実の現場での話。

Demo or Die

Demo or Die ―デモを見せられないアイディアは、死んでいるのと同じ。
MITって大学のメディアラボのスローガンだ。うちの研究室はこの文化でやってるよ。

大学教授の言葉がずっと印象に残っています。動かさなければ意味は無い、と。
小学生の頃からプログラミングが楽しくて、社会に出てもその道で人を幸せにしたいと考えていました。

入社して

配属、そして疑問

いわゆる"客先常駐型"の、開発プロジェクトごとに人が集まる現場に配属。

言語はJava、人数は約60人。既に稼働し、改修や保守を行うフェーズでした。
たくさんの人の役に立てるシステムに携われるんだ、とワクワクしていました。

ほどなくして、不思議に思うことが出てきます。

  • 配属初日、偉い人に「SEは体力だからな！」と言われる。
  • "自動化できそうな手作業"がたくさんあって、しかし手作業のまま続けている。
  • 問題が起きると、解決せずに"避ける"ための面倒なルールを作る。
  • Software Designやオライリー本を出すと、値段を見てびっくりされる*1。

…ここは本当にIT企業なのか？
まずは、自らがITをもっと活用すべきでは？ と思うくらい、"泥臭さ"の漂う現場でした。

葛藤、のち行動

嫌だ、どうにかしたい。でも、新人に何が出来るのか。
入ったばかりの新人の意見など取り合ってくれません。そもそも誰に意見をすればいいのやら。

そんなとき、『Demo or Die』を思い出しました。
そうだ。つべこべ言わずに実際に動かして、見せつけてやろう。よりよく出来ることを証明してやる。そんな意気込みだったと思います。

Demo 1: Alt+Tabキーの早打ちをやめる ~試験結果の一覧表示~

ユニットテストは、実行結果を1ファイルずつ開いて確認する面倒なものでした*2。

テスト仕様書(Excel)、エクスプローラ、それにテキストエディタを素早く操作するスキルが求められました。皆、フルHDに満たない解像度のディスプレイでAlt+Tabキーを酷使していました。

違うやり方を作ってしまう

実行結果を下記のような表形式にまとめて出す、というGUIツールを作りました。

テストNo 実行日時 終了ステータス エラー情報
test-01 12/13 9:45:15 00 (正常) -
test-02 12/12 9:45:17 91 (システムエラー) (例外発生)
test-03 12/12 9:45:18 11 (チェックエラー) 項目: ID, NAME

言語はJava、GUIツールキットはSWT。起動すれば表示は自動更新。
テストを実行したら、あとは表示が更新されるのを待つだけになりました。

反響

幸いだったのは、OJTのトレーナーがいたことと、新しいものに抵抗を示さない人が一定数いたことでした。

「新人がこんなの作った」「なにこれ、めっちゃ楽じゃん。ちょうだい」
ツールは徐々に浸透し、プロジェクトの便利ツールフォルダにめでたく入りました。

Demo 2: ビルド、ビルド、ビルド！ ~自動ビルド~

2年目にして製造サブリーダという謎の立場になりましたが、
ソースコードの管理やビルドにあたって、いくつか問題が起きていました。

  • コミット漏れなどでリポジトリ上のソースがビルド出来なくなっても気づかず、別の誰かが困ってようやく発覚する。
  • テスト用サーバへデプロイする資産をPCでビルドするのに10分掛かる。
  • 誰かが時折古いソースでビルドしたものをデプロイしてしまい、別の誰かのテストが突然失敗しはじめる。

これらの問題を"回避"するために設けられたルールは窮屈なものでした。

「フォルダ全体でリポジトリと差分チェックし、コミット対象を洗い出すこと」
「PCでビルドする前に、リポジトリとの差分チェックを必ずやること」

たった1行、条件式の不等号を逆に修正するだけでも大変な作業量でした。

どうしてこんなことになってしまったのか。

そもそもデプロイ資産のビルドって各自でやる必要あるっけ？

答え：ない。まっっっったくない。

「継続的インテグレーション」が外で叫ばれる*3中、テスト用サーバで自動ビルドさせようと考えました。
が、常駐先PCはネットワーク的に外と隔離されており、Jenkins等は導入できません。

しかし、幸いなことにテスト用Linuxサーバにrubyが入っていました。
WEBrickという標準ライブラリを使用して、Webサービスを立ち上げられるのです。

メールを全員に出しました。
「自動ビルド、はじめました。もうPCでビルドする必要はありません」
ビルド結果のメール通知機能も備え、失敗にすぐ気付けるようになりました。

f:id:yamaguchi-39:20161210203521p:plain
(※再現イメージ)

自動ビルドの利用はスムーズに進みました。誰だって楽をしたいですからね。

Demo 3: 探し回るのをやめる ~ファイル名検索エンジン~

複数のファイルサーバに数十万ファイルが散らばっていました。
当然、Windowsのファイル検索機能は役に立ちません。

「手順書、探しても見つからなくて。どこにあるんですか？」
「えっとね、このフォルダじゃないな…　ここ…でもないか。じゃああっちかな…　ああ、あった、ここだよ。フォルダのパス、メールで送るね」

こんなやり取りもしばしば。
表面上は「1分のロス」ですが、作業の中断(コンテキストスイッチ)は集中が途切れてしまうので、実質1分じゃ済まないのでは… と思っていました。

ファイル"名"検索エンジン

Namazuのような全文検索システム*4がほしい。
そうでなくとも、単にファイル名を検索できるだけでも、便利になるのでは？

レビューに飽きてコーディング欲が限界に達し、土曜日に出社して
再びRubyとWEBrickライブラリを使ったWebサービスを作成しました。

ファイルサーバへの接続はmount.cifs、ファイル名のインデックス化はfind。
Excelファイルに限って、JavaとApache POIライブラリ*5で全文検索に対応。

ひと目でどんなサービスか分かるよう、ロゴはGoogleそっくりに。

f:id:yamaguchi-39:20161210202655p:plain
(※再現イメージ)

「すごいね。別のファイルサーバも検索対象にできる？」
これまでと違い、製造工程以外の方からも好評でした。

季節ごとにロゴを変えたり、いいね！に相当する"ハラショー！"ボタン*6を追加したりと、ちょっとした遊び心を付け加えました。

波及

これらの"Demo"は、最小限のメンテナンス手順を記して引き継ぎました。
私がプロジェクトを離れてからも使われていると聞いています。

嬉しかったのは、こんな言葉でした。

「私もツールを作ってみようと思って書いてるんだけど、ここどうしたらいい？」
「影響調査は機械的な方法、例えば全文検索でやろう」

私のやってきたことが、ちょっとだけ周囲に"響いて"いるようでした。

プログラミングで人を幸せに出来ているか？
少なくとも、現場はちょっとだけ幸せになったはずだ、と思っています。

別のプロジェクトに移ると、前のプロジェクトでお世話になった方がいました。
「前のプロジェクトで動かしてたアレ、ここでも動かさないの？」

or Die (限界)

と、偉そうに書きましたが、すべて順調かというとそうではありません。

失敗したDemoは倍以上ありますし、そもそも変化はとても小さなものです。
大きな変化を起こすには… おそらく、面倒なプロセスが山ほど。

このまま現場に居続けて、現場を変えることにこだわる必要はあるのだろうか。
そういう考えがあるのも確かです。

いいアイディアなら、さっさとやってしまえ

私は名言を都合よく使うことが大好きです。

Step Back and Automate, Automate, Automate
面倒でも自動化できることは自動化する
Cay Horstmann (ケイ・ホルストマン)

Kevlin Henney編 (2010)『プログラマが知るべき97のこと』
和田卓人監修, 夏目大訳, オライリー・ジャパン．

プログラマの三大美徳は「怠惰」「短気」「傲慢」です。
目の前の機械を活用して、楽になる。そのための手間は惜しみません。

If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission.
いいアイディアなら、さっさとやってしまえ。許可を得るよりも謝るほうがずっと簡単だから。
COBOL開発者 Grace Hopper (グレース・ホッパー)

やってみたいことがあるなら、とりあえず、やってみませんか？

*1:技術書に縁のない方も少なくありませんでした

*2:「JUnitテストは書くのが大変だから」とのこと

*3:「知ってますか？」と聞くと皆だんまりです

*4:脱線するけどNamazuしか思い浮かばないのが悔しい

*5:Microsoft Office形式のファイルを読み書き出来るライブラリ。ただしバージョンが古かったので、xlsx形式の解析はオレオレライブラリを作成

*6:通じたの1割くらいだった

SEになる新人さんに言っている3つのこと

SE 読み物

SEといっても、新人さんには極力プログラミング・単体試験を最初にやってもらっています。

そんな新人さんに呪文のように言っていることが3つあります。

エラーメッセージはお友達

エラーメッセージ読んだ？
エラーメッセージはお友達。原因を教えてくれているのに、見ないなんて勿体無いよ？

プログラムがうまく動かないことなんて日常茶飯事です。
そういう時は、まずエラーメッセージを読む。

「エラーメッセージ」なんて嫌な名前が付いていますが、実際は「ヒント」です。
もう大ヒント。そこに答えがあると言っても過言じゃないくらい。

"よくわからんけど適当に直したら動いた"だけは、ご法度。
知識にならないので、後で苦労します。

定時だよ、さあ帰ろう

定時だよ。終わってない？　終わってなくても帰ろう。
でも、きちんと今日を振り返って、明日は今日よりちょっとだけ上手く出来るようになろう。

「終わらないので残業します」という新人さんもいますが、「ダメ」って言います。
単位時間あたりの生産性を高め、定時で終わらせる、ということにこだわります。

難しい。残業をするよりも定時で帰るほうが遥かに難しい。工夫のしどころです。

現場はとにかく"残業は当たり前"という空気で満ちています。
そういう空気を少しでも変えていきたい、という思いもあります。

（私の場合、そうしたところで給料や評価に結びつくことはほとんどありませんでしたが…　それが一番問題かもしれません）

それキーボードでやってみよう

ちょっと待って。戻して。キーボードでやってみよう。
Excelで次のシートに進むには、Ctrl+PageDownキー。はい、やってみて。

新人さんの一挙手一投足はとにかくよく見ます。
横で普通に作業をしているフリをしますが、視界にきっちり入っているので見ています。

「キーボードで操作したほうが早いかも」と思ってもらえるまで、
申し訳ないけれど、キーボードで出来そうなマウス操作はじゃんじゃん止めます。

1年もするとキーボード操作が当たり前になっていて、
私の知らないショートカットを使うようになっています。結構焦ります。

ということで、私が新人さんに言っている3つの呪文でした。
もっと良い呪文があればお待ちしています。