ワルシャワ渡航記 Part40: プロジェクト移動

 　7月からプロジェクトを移動した。1年半ほどSREとして働いていたが、7月からフルスタックエンジニアになった。移動して1ヶ月経ったが、やはり自分はアプリレイヤーのエンジニアの方が向いている。

　SREとして働いていたときは愚痴ばっかり言っていたが、振り返ってみると色々な学びがあった。Big Techの巨大内部インフラについて（アプリがどうやってデプロイされるのか、モニタリングはどうやってされるのか、セキュリティはどうやって担保されているのか、などなど）IT業界の最先端のベストプラクティス的なものに触れることができた。

　新しいプロジェクトではフロント＆ミドルレイヤー担当のエンジニアになった。これからは心機一転、がっつりコードを書いていきたい。

- 最近行ったタリンの旧市街地 -

　

Kさんの教え

　半年間一緒に働いたエンジニアのKさんの教え。

おれたちはソフトウェアを作っている
ハードウェアを作る場合は、綿密な計画、設計無しにものづくりを始めてはいけない。作り直しのコストが非常に大きいからね。でも、おれたちはソフトウェアを作っている。綿密な計画、設計をしているうちに作っちゃった方が早いよね。

必要以上に複雑にするな
ソフトウェアは使ってもらいながら進化していくものなので、最初から複雑にしすぎてはいけない。絶対必要なものに集中してとにかくシンプルなものからスタートせよ。

変更は小さく頻繁に
ソフトウェアの変更は細かく、高頻度に行うべき。一度に多くのものを変えようとするのはよくない。簡単な機能なのにすぐに変更、リリースができないなんて論外。

学びこそ至福の喜び
常に学び続けろ。新しいことを学ぶのがエンジニアの大きな喜びの一つだ。学ぶことをやめてしまったエンジニアに価値はない。

おまえはどうしたいのか
あの人がこう言った、あのチームの人たちはこう言っている、じゃない。
お前はどうしたいんだ？それが一番大事なことだ。

一心不乱に夢中になること
何かに夢中になっているヤツのまわりにいると、こっちもなんだか楽しい気分になってくるぜ。おれの会社の創業者もそうさせてくれるやつだった。

セキュリティと生産性のトレードオフ
セキュリティを厳しくしすぎると生産性が著しく低下する。両者はトレードオフの関係にあるけど、日本では生産性の問題が軽視される傾向にあるみたいだ。

（番外編）マラソン
マラソンはいろんなことを教えてくれる。精神状態をいかにコントロールするか、ペース配分をどうするかなど。

（番外編）やばたん
YABATAN知らないのか？日本語だぜ。若い女の子のことのこと分かってないんじゃないか？

エンジニア日記（4）こんなとこで働きたい

最近、職場の居心地が良い。

居心地は良いのだけれど、楽しくはない。
ココロオドラないのである。

多分こんなところで働くとココロオドルのではないだろうか、と思う職場像を考えてみた。

１．プログラム好きな人がたくさんいる。
２．アジャイルな開発手法を取り入れている。
３．ドキュメントよりもソースが重視される。
４．テストが自動化されている。
５．ROWEを取り入れている。

エンジニア日記（3）1000倍速くなった

　某システムのとある機能が大変に遅かった。
ユーザーからも「遅い。遅い。」と苦情が多発していたらしい。

　中身を見てみた。たしかにこれは遅い。HashSetを使えば高速に処理出来るのだが、ArrayListを使っている。

　書き直してところ、ボトルネックとなっていた処理が1000倍速くなった。

　こういうのって結構あるんじゃないだろうか。僕はred coderでもないし、数学オリンピックの代表選手でもない。しかし、そんな僕にも改良できることが、世の中にはたくさんあるんじゃないだろうか。

エンジニア日記（2）サードパーティのAPIが変わった

　最近、セキュリティ上の関係で使用しているサードパーティのライブラリを急遽バージョンアップすることになった。バージョンアップするとライブラリが提供するコンテナの型や、APIがごっそり変更になってしまい、それらを使用している箇所をすべて書き換えなければいけなくなった。

話を単純化して例を示すと以下のような感じ。もともと

int main() {

    ThirdPartysContainer<string> container;
    container["hoge"] = "fuga";
    cout << container["hoge"] << endl;
    
    return 0;
}

のようにbraketsで要素にアクセスすることができるThirdPartyContainerという（key, value）型のクラスが提供されていた。
しかしバージョンアップすると、bracketsを使ったアクセスが出来なくなり、代わりにgetter/setterを使わなければいけなくなった。

int main() {

    ThirdPartysContainer<string> container;
    container.set("hoge", "fuga");
    cout << container.get("hoge") << endl;
    
    return 0;
}

で、ThirdPartyContainerクラスを使っている箇所を新しいAPIを使うように書き換えろと。
ThirdPartyContainerクラスはいろいろな箇所で使われていて、書き換えるソースは膨大な量になった。さらに、書き換えたソースは動作検証しないといけない。

こんなことにならないようにするためには、サードパーティのクラスを隠蔽して、個々の機能からは見えないようにしておくべきだった。アダプターパターンを使って、将来変更される可能性があるサードパーティのクラスをラッピングしておくべきだったのだ。

template <typename T>
class ThirdPartysContainerWrapper {
    
    ThirdPartysContainer<T> contaier;
    
public:
    
    T getData(const string key) {
        return contaier[key];
    }

    void setData(const string key, const T val) {
        contaier[key] = val;
    }

};

みたいなクラスを作っておいて、個別のクラスからは、

int main() {
    
    ThirdPartysContainerWrapper<string> container;
    container.setData("hoge", "fuga");
    cout << container.getData("hoge") << endl;
    
    return 0;
}

のような使い方をするようにしておけば、改修箇所はラッパークラスだけでよかったのになと。

エンジニア日記（1）工数見積をミスった

工数の見積を誤ってしまった。

一日の労働時間 = 一日の実作業時間

という前提で工数を見積もってしまったのだ。
これは大きな間違いだった。

一日8時間労働する人がいたとする。8時間のうちの1時間はメールを見たり、報告書を書いたりなどの雑務の時間になる。さらに、１時間働いて5-10分程度休憩すると考えると、なんだかんだで1時間である。

一日の労働時間 が8時間なら、実質的な作業に充てられる時間は6時間。
さらに、朝礼とか定例会議とかあるような場合だと、実作業時間は更に減ってしまう。

正確な見積をする場合は、

一日の労働時間 != 一日の実作業時間

をしっかりと認識しておかなければならない。定時に帰れるようにしたいなら、一日の実作業時間 = 6時間で見積らなければならない。