GYAOの窓際エンジニア 玉利です。
説明はコードで書くのが手っ取り早い
うちのベトナム人エンジニアは、元PHPエンジニアです。
取引先から動画メタデータのXMLをもらってきて処理するシステムを開発しており、気がついたらこんなコードができていました。この、大陸の地平線に届くレールを列車がスカーンとまっすぐに突き進むような直線的なコード、私は大好きです。
begin
data[:video_filename] = doc.xpath("//XML/to/PATH1").last.content
data[:video_hashsum] = doc.xpath("//XML/to/PATH2").last.content
rescue
data[:video_filename] = nil
data[:video_hashsum] = nil
end
begin
data[:thumbnail_filename] = doc.xpath("//XML/to/PATH3").first.content
data[:thumbnail_hashsum] = doc.xpath("//XML/to/PATH4").first.content
rescue
data[:thumbnail_filename] = nil
data[:thumbnail_hashsum] = nil
end
以下20個くらい続く
まあ、動くから今のところはいいんですけど・・・・ちょっと効率悪いよな。結構こういうのは簡単に片付きます。日本人の依頼側と話すほうがよっぽど大変です。
ベトナム人にはこうやって伝える
週末に考えて、重複部分はヘルパー書いて欲しいなーと思いました。早速メッセしてみます。その場のノリでコード的なものを書きます。
私「タンさん、週末にリファクタリングを考えていたんだけど、XML解析部分にヘルパーメソッドを作ったらどうかな？単なるアイデアなんだけど、メンテナンスが楽になうようにしたいんだ」
btamari MM/DD(Mon) HH:mm:SS
@nthanh Thanh-san, I think about refactoring in this weekend. Do you think can we write a helper to make simple our XML logic?
It's just idea but we had better write better code to our maintenance.
(this is my idea)
# Sample code(Might not work)
def get_xmlpath_helper(xml_obj, xml_path, location)
# location=[first,second...last]
begin
xml_obj.xpath("xml_path").${location}.content
rescue
return nil
end
end
nthanh 1 MM/DD(Mon) HH:mm:SS
Yes, of course
タン「もちろん！」
出てきたクラスメソッドのコードですが、Obj.send()を使ってきたりして、なかなかやるじゃないですか。そろそろメタプログラミングの本をベトナムチームに読ませる時期が来たようです。
def self.get_xmlpath_helper(xml_obj, xml_path, location)
begin
xml_obj.xpath("#{xml_path}").send(location).content
rescue
return nil
end
end
エンジニア同士の会話は、サンプルコードさえ書けば案外簡単です。サンプルコードは動かなくても、なにを期待してるのか通じればそれで良いんです。
クソコードレビュー芸術？
ときたま、そんな技術では解決不可能な、すべてを超越したクソコードが出てくることがあります。うちのチームではなく、隣のチームのPHP案件でした。
ちょうど明日リリースなのに、駐在員の若者が頭を抱えてます。飯くいに行こうよーって話していたのですが、相談されたのが夜7時過ぎ（ベトナム人は夕方5:00きっかりに帰宅します）
「玉利さん、明日リリースのコードなんですけど、これ動くと思いますか？(と、gitのcommit logを見せられる)」
「うーん、commit logじゃレビュー無理だよね。。。。ちょっとまって、 IDE入れよう」
さっそくIDE(IntelliJ)で中身をおいかけてみると、一文字の変数 f が何度も再利用されていました。多分動くだろうけど、一貫していつ壊れるかわからないと思うクソコードです。そして若者も私もとりあえず腹が減ってるんです。腹が減った状態で何かやろうと思っちゃいけません。下手にいじるとトドメを刺します。そして担当エンジニアの顔で判断すると、みるからに面白系の男です。
「えと、彼、前職は組み込み系？メモリをギリギリまで再利用して節約しないと気がすまないタチ？」
「たぶん違うと思います。。。。いままでちゃんとレビューしなかったのは私の責任です」
「そうか。。。。（つまり要注意メンバーね） これ、明日俺が話をするから、飯いこうぜ」 と、近所の中華料理屋に駐在員たちと出かけました。
さて、ベトナム人エンジニアのメンツを潰さないようにうまく事をすすめなければいけません。駐在員が直接話すと禍根を残しかねないので、短期出張の私が話をすることにします。こういうときは問いつめずに大人数で和気藹々とやります。
「シャチョー(Guam Doc, 監督のベトナム語発音ザム ドック。案外日本語に近いのです。)、コードレビュー始めるよ。チーム全員集合！」
「この変数、fじゃなくて、ちゃんと内容が分かりやすい名前付けてあげましょう」
「＊＊＊＊＊（わかりました）」
「あと、変数は使い捨てにしましょう。シャチョー、チリ紙で鼻かんで、チリ紙再利用しないでしょ？」
「＊＊＊＊＊（女性同僚から大笑いされて わかりました）」
「OK,じゃ、至急修正してください。本日夕方リリースです」
こんな感じで話を片付けました。どうやら、チームのリーダー格が介入してくれてざっくりと直してくれたのでサービスローンチには間に合いました。その修正コードも読みにくいんですが。
まともな静的解析ツールを入れておけば即座に指摘してくれそうなものですが、まだ依頼側の日本が精神論なので仕方ないですね。オフショアPHP開発には、PhpStormかIntelliJをオススメしておきます。駐在マネージャーには必須です。チーム内でも過去の負の遺産を解析するのに評判いいです。
この会話テクニックは、中国で働いていた頃に中国人マネージャーから習いました。話芸はQiitaでは表現できないのでGYAOのベトナム開発に転職して来てくれた人には教えます。
さて、夜10時をすぎると広東料理屋では夜の飲茶タイムになります。ベトナムの中華はベトナム人の好みにあわせて砂糖が大目に入っていて、味に切れがないなと思います。でも、日本の一般の店よりはずっと美味しいですよ。
写真 夜の飲茶タイム
