この記事は エムスリー Advent Calendar 2018 14日目の記事です。
こんにちは、エムスリーエンジニアリングGでエンジニアをしてます、新卒一年目の三角です。
クリスマスまで毎日更新され続けるであろう弊社アドベントカレンダーは、内部の私から見ても大変刺激的なネタ盛りだくさんでお送りしていますが、今回は会社の事業や技術の話とは少し離れてビジュアルプログラミングのお話です。
続きを読むコードレビューを支える『褒め文化』
コードレビュー、好きですか？
エンジニアリンググループの山口です。
クラウド電子カルテ「エムスリーデジカル」を開発しています。
今回は、チームに根ざしている『褒め文化』についてお話しします。
※この記事は、エムスリー Advent Calendar 2018 13日目の記事です。
『褒め文化』とは
簡単に言えば、コードレビューで褒める文化です。
とても簡単です。
とても簡単なのですが、前職(SIer)ではこういった経験が全く無かったため*1、join直後は（良い意味で）驚いたのが印象に残っています。
*1:品質担保のみを目的としていたという背景もありますが
18分59秒をめぐって日本標準時の歴史をひもとくことに
この記事は エムスリー Advent Calendar 2018 12日目の記事です。
こんにちは。エムスリー エンジニアリンググループの三浦(@yuba)です。基盤開発チームというところで各サービスチーム共用のシステムの開発保守に携わっており、そこで見つけた面白い動作を掘っていったら意外な知識にたどり着いたという話をいたします。
化けた日付はどこから来た？
あるサービスの管理画面の動作を検証していたときのことです。バリデーションの振る舞いを確かめるためにいくつかテストケースを作りながら実際の動きを試していたところ、不思議な現象を見つけました。
次のように日時入力をするところで年の欄を空のままにして送信したところ⋯
次のようにおかしな日時が設定されたのです。
0013年？ 18分59秒？ 入力した覚えのない数字が3つも紛れ込んでいます。 これが C で書かれたプログラムなら何か不定値を拾ってしまうバグでもあったかと疑うところですが、このサービスはScala製です。案の定動作に再現性もあります。なんらかの出所があって生成されている日時データだということです。では一体どこから来たものなのでしょう？
続きを読むRubyistも読めない？ 超難読Rubyコードの読み方
エンジニアリンググループのowlです。好きなマスコットはGopherくん、好きな言語はRuby！ なので今回もRubyについてお話します。
ところでRubyistのみなさんはRubyKaigi 2018に行きましたよね？ とても良いイベントでした。エムスリーもスポンサーとして参加していましたが覚えていますか？
さてRubyKaigiで最も盛り上がった発表はなんでしょうか。様々な発表が挙げられると思いますが、有力な候補の一つはイベントの最後に行われた TRICK 2018 (FINAL) でしょう。TRICKとはTranscendental Ruby Imbroglio Contest for rubyKaigiの略であり、『超絶技巧 Ruby 意味不明コンテスト in RubyKaigi』のことです。
このコンテストではまともに読むことが出来ない上に何の役にも立たないという前衛芸術のような傑作Rubyコードが綺羅、星の如く生み出されて来ました。
- 螺旋状にアニメーションしながら文字列を表示するQuine*1 (mame)
- 日本語でコードがどのように動作するのかを説明し、しかもその日本語がコメントではなく動作に必要なコードの一部であるQuine (yhara)
- 68文字で作られたテストフレームワーク(colin)
- 3Dのクリスマスツリーをアスキーアートで描写して回転させながら雪を降らせる(tompng) などなど
全ての投稿作はGithubで公開されているのでぜひ実行してみてください。 https://github.com/tric/trick2018
しかし、意外にもこれらの難読コードが丁寧に解説される機会は稀でした。そこで今回は難読Rubyコードを初心者にも理解できるように噛み砕いて解説したいと思います。
*1:Quine： 自分自身のコードと全く同じ文字列を表示するコード
Sansan× M3 Tech Night ～レガシーシステムに立ち向かえ！～ を開催しました
エンジニアリングGでAskDoctorsやゲノム関連サービスの担当をしている愛宕(あたぎ)です。
エンジニアとして働き始めて以来、レガシーシステムと関わることの多い人生を送ってきました。レガシーシステムの難解なコードを読み解こうとした末「こういう意味だったのか！」と気づいてアハ体験を得る瞬間は、意外と嫌いではないです。
今回はそんな私が、先日11/22に、Sansanさんと弊社が合同で開催させて頂いた「Sansan× M3 Tech Night ～レガシーシステムに立ち向かえ！～」の技術勉強会に参加してきたので、そのレポートになります。
なお、この記事はエムスリーアドベントカレンダー 10日目の記事です。
発表内容
(以下、敬称略)
急成長するシステムに追いつくためのインフラ改善への取り組み(Sansan株式会社 大澤秀一)
サービスの成長に開発体制が追いつかず、負債が蓄積されていく、というのもしばしば聞く話です。 そんな中で、リリースサイクルを高速化かつ安定化していくか、という事についてのインフラ観点でのお話でした。
例えばステージング環境の不足など、私自身も前職含め幾度となく体験した事がありますが、SansanさんはTerraformで環境構築を行う事で解決しており、どこの会社でも共通の課題なんだなと思いました。
デプロイの度に障害が起きるシステムを安全にした話(エムスリー株式会社 小本健司)
属人化し、手動で行なっていたためにトラブルが絶えなかったデプロイをいかに自動化し安全にしていったかというお話です。
印象に残っているのは、「最初に不格好でも手順書する」ということでしょうか。テキストのリリース手順書というのは一見泥臭く古めかしいものではありますが、 すぐできて効果も高いものです。一旦そういう最低限のことから始めて、少しずつデプロイの自動化を進めていくという、現実主義的なアプローチが共感持てました。
詳しくは以前このブログのこちらのエントリーでも紹介されています。
フロントエンドをきちんとSPAにしたい！(Sansan株式会社 青山修平)
複数のReactコンポーネントに対して単一のグローバルなCSSができてしまい、それをいかにしてコンポーネントごとに独立させていったか、というお話でした。
改善の方法もさることながら、改善のためにまとまった期間（二ヶ月）と専任のエンジニアがアサインされていたというお話を聞いて、やはり抜本的な改善にはまとまったリソー ス取るのが大事だな…と改めて思いました。
レガシー化しても困らないためのコーディング(エムスリー株式会社 中村貴志)
<
「自分たちが作っているものもいつかはレガシー」になるという視点から、では自分たちの書いているシステムをなるべくレガシーにしないためにはどのようにコードを書けば良いか？ という実践的な話でした。
レガシーになることの要因を「コードを読んでも仕様・意図がわからない」「他との依存関係・影響範囲がわからない」という事に絞り、実例を交えながら改善案を説明されていました。どれも「見たことあるわ…」「書いたことあるわ…」というものばかりで、遠い目をしながら聞いていました。
レガシーと正しく向き合う(Sansan株式会社 藤井洋太郎)
レガシーと正しく向き合う from Yotaro Fujii
www.slideshare.net
主にチームの文化作りの話で、「負債を助長するコミュニケーションは何か？」など、負債が生み出される背景についてよく分析されていました。レガシーなコード が増えるのを防ぐための文化作りの方法が、「知見の蓄積と共有」「負債の削減が価値あることという共通認識を作る」「行動している人へのサポート」「行動した人への称賛」 という観点で語られていました。会社を問わず普遍的に実践できるアイデアばかりです。
当日の様子
会場はSansanさんの素敵なオフィスをお借りしました。勉強会のテーマはレガシーシステムですが、オフィスはレガシーとは程遠い、とてもお洒落なオフィスです。会場は開始前から熱気に包まれ、最終的に席が少し不足するほど多くの方に来ていただけました。
まとめ
実は当日、別の場所でも同様のテーマの勉強会が開かれていたそうで、これは単に偶然だと思うのですが、実は密かに関心が高まっているテーマなのでは？ とも思います。我々 の働くWeb業界も次第に歴史が長くなり、メンテナンスしなければならないシステムも増える一方なので、実は、地味なように見えて密かに熱いテーマなのかもしれません。 今回の勉強会に参加しただけでも、自分と同じような課題を抱えている人が多くいたので、なおさらそう感じました。機会があったらまたこういう会参加したいですね。
We are hiring
エムスリーでは、共に医療 × テクノロジーの未来を切り拓いてくれる仲間を募集中です！
社内輪読会でScala関数型デザイン&プログラミング第14章の練習問題を解いたので解説します
エンジニアリンググループの松原です。 社内で4月から続いているScala関数型デザイン&プログラミング輪読会で、14章を担当したので復習も兼ねてその練習問題について解説記事としてまとめます。 ちなみにこの輪読会ですが、14章に到達した現在も誰一人として脱落することなく続いております(2人が USA 出張、1人が育休なのですが、これは仕方がないので脱落と呼ばないことにします)。 私を含めちらほら心を折られている人がいるような気配もありますが、Scala に強い人が参加していることもあって何とか続けられています。
なお、この記事は エムスリーアドベントカレンダー 9 日目の記事です。
続きを読む業務未経験でエンジニアになった私がエムスリーで学んだ、やっておいた方が良い3つのこと
この記事はエムスリー Advent Calendar 2018 8日目の記事です。
こんにちは。エムスリー エンジニアリンググループの川俣です。
最近驚いたことは、勉強会*1でLTしてプロテインをもらったことです。
※注 プログラミングの勉強会です。
私は、今年2月に6年務めた消防士から業務未経験でエンジニアに転職しました。
今回は同じようにエンジニアに転職する方に向けて、「転職前にやっておけばよかったな」と思ったことをお伝えします。
1. 他の人が書いたコードを読み込んでみる
業務未経験でエンジニア転職をする方が最初に従事する業務は、0-1での新規開発ではなく、 既存システムの改修・運用だと思います。
そのような時、まず向かい合わなくてはならないのが、誰かが書いた何千何万行ものコードです。
大変恥ずかしいことなのですが、入社前まで他の人が書いたコードを真剣に読み込んだことがありませんでした。なので最初任された既存システムのリニューアル案件では、処理が全く追えず大変苦労しました。
事前に他の人の書いたコードを読み、処理を理解する力を身につけていれば、そこを抵抗感なく乗り越えられたかなと思います。
TRY
GitHubに公開されているOSSのコードを読んでみよう。
RubyだったらGitLab、サーバーサイドKotlinだったら最近話題のKtorなど色々あります。最初は理解できないと思いますが、業務になったら自ずと挑戦することになります。まずはGitHub上でコードを追うだけでもやってみると良いと思います。
2. コードレビューを受けてみる
独学で個人開発ベースで学習していると抜けがちなのが、コードの品質です。
私も入社前まではコードの品質など全く意識せず、「動けば良い」で作っていました。なので今、昔書いたコードを読み返すと大変ひどいものだった愕然とします。
業務で初めてプルリクエストした際など、レビューの指摘が多すぎてGitLabのコメント欄が固まりました....
品質を高めるためには、何よりコードレビューが有効だと思います。個人開発でもコードレビューを受けて、早めにコードの品質に意識を向けて置くと、業務でより本質的な学びを得ることができると思います。
TRY
エンジニアの知り合いがいればコードレビューを依頼してみよう。
また、自動のコードレビューサービスもおすすめです。
sider.review
その他、紹介するまでもない程有名ですがリーダブルコード*2*3を読み、自分のコードを自分でレビューしてみるのも良いと思います。
3. ユニットテストを書いてみる
私は入社前までにも個人で色々開発していたものの、ユニットテストを書いたことがありませんでした。モック？スタブ？なにそれ？という状態でした。
業務で書くコードでは品質を担保するためにユニットテストが必須です。
丁度先日、入社当初に自分が書いたコードからバグが発生し、一日障害対応に追われました。そのバグ混入の原因の一つが、ユニットテストで要件をカバーしきれていなかったことでした。そのような事態を起こさないためにも、事前にユニットテストを書く習慣を身つけておくと良いと思います。
TRY
個人開発のシステムでユニットテストを書いてみよう。
ユニットテストを書くことが、自分のコードを見直すきっかけにもなり、リファクタリングも進むと思います。また、テスト駆動開発*4という素晴らしい本もあるのでそちらを読むこともおすすめです。
おわりに
以上、私が思う業務未経験からエンジニアに転職する上で、やっておいたほうが良いことでした。
今もまだまだ力不足で躓くこと多々ありますが、エンジニアという仕事に、日々充実感を感じています。
もっと異業種からエンジニアに転職して、活躍する仲間が増えれば良いな思っています。
We are hiring!
エムスリーでは、共に医療 × テクノロジーの未来を切り拓いてくれる仲間を募集中です！ ご応募お待ちしています。
