入社二ヶ月経ちました

前職を数ヶ月で辞めて転職活動して、意外にすんなりと転職活動を終えてた。普通に転職活動をしてみて、一社内定頂いたけど辞退した。 今働いてるところは、前回の転職活動で意識高いエントリを書いたらメールくれたベンチャー。

前回の転職活動では、力が欲し〜とか自分より凄い人が居るところで働きたい〜とか言ってたけど、今回は、如何に自分が楽しく働けるか、もしくは自分が楽しいように変えられるかを重視してた。

今の会社、社員数は20人に満たないから、わがままじゃなくて妥当性を持って変えようとすれば変わりそうな感じで、そこらへんについてはストレスが少ない。

本当は入社一ヶ月くらい経ったあたりで社名を明かしてそれなりにひと目に付くような文章書こうと思ってたけど、炎上の火消しにぶっっっこまれてマジで糞な感じになってるから、こんな感じで、なんか適当に書いてる。

僕より前に入社したエンジニアは、わりとギークっぽい感じで面白そうな感じ。ただ、マネジメントを出来る人間が少ないのと、開発フローが自称アジャイルのカウボーイコーディングなので、そこらへんが原因で炎上が発生している感じがする。

火消しに投入されたプロジェクトのコードがマジで糞でリファクタリングするより作り直したほうが早いってレベルなんだけど、納期も迫ってるから実装のついでにリファクタリングをすることで精神を保ってる。

新規に追加されるコードも、良くないと感じるコードが多いんだけど、何故良くないのか、どう変えれば良いのかを説明出来ていない。良くないけど説明できないし時間もないからとりあえず放置で！みたいに言って、そのコード周辺を触れる機会があったら大幅にリファクタリングするみたいな感じになってる。コードレビュー等のコミュニケーションを経て、良くないコードを直せれば良いんだけど、説明できないから実際にリファクタリングしました！みたいなのは暴力的であまり好きなやり方じゃない。

なので、マーチン・ファウラーのリファクタリング本読んだり、結城先生のデザインパターン本買ったりしてる（まだ読んでない）。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

増補改訂版Java言語で学ぶデザインパターン入門

開発フローについては、ゆるふわな感じでGithub flowを導入してプルリクエスト＆コードレビューを必須にすれば、ある程度はどうにかなるんだけど、プロジェクトマネジメントは一朝一夕でどうにかなるものじゃないからどうしたもんかなーって思ってる。

マネジメントみたいな上のレイヤーに興味はあるんだけど、それを始めたら自分がコードを書けなくなるので、あまり手を出したくない。だから書籍読んだり、実際のプロジェクトから学んで、コード書きつつマネジメントしてる人間を叩いて伸ばす感じの運用をしたい。

一人のfailをその人だけのfailにしないで、プロジェクトメンバー全員のfailに出来るようなプロジェクト進行が出来れば、全員が足りないところを補い合って上手く行くと思う。だから情報共有とか、プロジェクト内でのコミュニケーション方法とかも考えたほうが良い。アジャイルサムライを読んで、感銘を受けたのは「プロジェクトメンバー全員が良いプロダクトを作るために何でもやる」みたいな姿勢なんだけど、難しい。

一人のfailをみんなのfailにするの、コードレビューがその一環だと思ってて、コードレビューをしておけば他人が書いたコードを他の皆が把握出来るし、品質もある程度担保できる。他人が書いたコードでバグが起こっても、書いた人間しか直せないみたいな事が無くなると思う。なので、レビュー無しにコードをマージする人間は、その周辺コードで起こったバグや開発を全て担当したほうが良いと思う。というかしろ。

ちょいちょい今のプロジェクトに対する憎悪が湧き上がるから各トピック切り抜いたら幾つかエントリ書けそうな気がした。

色々書いたけど、全体的に見れば（今のプロジェクトはマジで救いようが無いレベルで本当に糞だけど）概ね楽しく働いてる。

あと、フレックスタイム制でコアタイムが14時〜17時なので、出社がめっちゃ楽。

エンジニアはサーバーサイド、クライアントサイド、スマホネイティブなどなど多岐にわたって必要としているので、14時出社に興味がある人は@gin0606に連絡下さい。

興味なくても酒とか飲みましょう。