■プログラマーの生産性は人により100倍くらい差があるというけれど

　割りとマジだよねと思う出来事をふと思い出したので書いてみる。

　といっても後輩が俺の思ってもいないところでつまづいて、それに俺がカルチャーショックを受けたというだけの話。

　問題の話なんだけど、とある有名サービスのJSON APIを叩いて呼び出し結果を手元のオブジェクトにマッピングするというただそれだけのコードを書くというもの。

　普通に考えて一日もしないで出来ると思うような代物だけど、三日以上悩んで彼はそれでも出来なかった。

　何があったかというと、そのJSON APIは

{ ..., "count": 10000000000000000000000000000000000000, ...}

　という感じで多倍長整数がリテラルとして書かれているのを前提として受け取る仕様だった。

　JavaScriptの通常の整数と違って、JSONの整数リテラルは仕様上大きさの制限の記載がないので、上のようなのも合法。

　で、彼の使ってたプログラミング言語のオブジェクト から JSONの変換ライブラリが、多倍長整数を文字列（""）としてシリアライズするような仕様なことがわかって、彼は行き詰まった。

　そこで何をやり始めたかというと、JSONの整数がそのまま1000000000000000みたいにシリアライズされるライブラリ探し始めたんだけど、それは見つからないまま。

　というわけで「増田さん、詰まってるんですけど……」と言われて助け舟出すことになったはいいものの、彼のコード見るとJSONの抽象構文木クラスがそのまま使えるようだった。

　なので、

String serialiaze(Ast.JsValue value) {
    return switch(value) {
        case Ast.JsNull nullValue-> "null";
        case Ast.JsInt bigIntValue -> bigIntValue.toString();
        case Ast.JsArray arrayValue -> arrayValue.stream().map(v -> serialize(v)).collect(Collectors.joining(", ", "[", "]"));
        // 他のJSONの木についても同様に処理
        default -> throw new RuntimeException("cannot reach")
    };
}

　1時間しない内にこんな感じのコード（言語はJavaじゃなかったけど、だいたいこういう感じ）を書いて無事問題解決。細かいタイポとかあるかもだけど、日記では確認してないのでそれはおいといて）。

　結局、JSONの形が期待と違って、しかも既存のAPIじゃいいのがなかったのに延々API探すことしか出来なかったのが問題解決できなかった原因だけど、このくらいのは割りとちょこちょこある。

　きっと、それから一週間放置しても問題解決できなかっただろうし、どうも同じチームの同僚も問題を解決できなかったようだった。

　最近、APIは叩けるけど、そこでトラブルとどうにもならなくエンジニアにちょくちょく遭遇するんだけど、やっぱりもうちょっと基礎出来てないと駄目だなと思った出来事だった。

　具体的には、再帰が相性が良いプログラムを書けるとか、APIに頼れないときはさっさと自作する頭の切り替えとかもろもろ。

　それと、情報系大学出てるのなら、せめて木構造に対してはサクっと再帰関数くらい書けてほしかったなと思う出来事だった。

Permalink | 記事への反応(2) | 04:01

ツイートシェア