サーバサイドからクライアントをやるようになっての心境の変化
久しぶりの執筆です。
最後の執筆から大分ブランクもあり、以前やっていたエンジニアリングにも大分変化があったため、振り返りをしつつ、サーバサイドからクライアントをやるようになっての心境の変化を執筆できればと思います。
時系列から読み解く
- 2021年 ~ 2023年前期
現在の会社に入社。入社した会社に配属された部署では、社内サービスを中心にRailsを用いたサーバサイドの開発を行っていました。
当時、2022年後半から上手くいっていない時期があり、かなり煮詰まっていた時期でもありました。
- 2023年後期 ~ 現在
ここから、クライアントの事をやるようになりました。正直、2022年後半から煮詰まっていた時期から、諸事情によりクライアントのことをやることになり、かなりの危機感もありました。
作業内容から読み解く
サーバサイド
- Rails、JavaScript中心の新機能開発やサイトの保守
- 社内サービスのインフラリプレース
- k8sにリプレースして、インフラアーキテクチャをコードで管理するようになり、ここからGCPやk8s, Terraform, Ansibleなどを使っていました。
クライアント
- Unityフレームワークの作成
現在、弊社ではクライアントアプリで利用する多種多様な決済サービスの文化、処理の違いを内部的に吸収し、会社の共通のルール・作法に基づいた課金処理ができるような仕組みを提供しています。
この仕組みを提供するために、Unityで開発したフレームワークを日々改善しています。
- C++, Obejective-Cで書いた課金処理をC#から呼び出すプラグインの作成
プラットフォームの中には、C#で書いたプログラムをそのまま利用することが出来ず、違う言語でコーディングしビルドしたものを、C#から呼び出すようにしないといけません。そのプラグインを書いていました。
- その他、デバッグ作業
本番環境で発生した問題を再現することも踏まえ、デバッグ環境を用意していたりもしました。
技術要件から読み解く
サーバサイド
Ruby on Rails (5年～)
JavaScript (5年～)
GCP (3年～)
Terraform (偶に)
Ansible (偶に)
クライアント
Unity (初めて)
C# (初めて)
C++ (初めて)
XCode (初めて)
Objective-C (初めて)
実際に利用した技術を纏めてみました。何をどれくらいやったかなんてのはあまり関係ないですが、何かの参考になれば。
クライアントのことをやるための準備作業
正直言って、特に何かに特化してやっていた訳じゃないです。
ただ、黙々とデバッグ環境を用意しつつ、Unityアプリをデバッグ環境にインストールして、動作検証して、バグを修正、ビルドして再度インストールして動作検証を繰り返していたらいつの間にか出来ていました。
後、クライアントのためにやっていた準備という訳ではないですが当時中々難しい状況となっていたため、これが出来なかったらもう終わりかなという(自分の中で)状態になっていたため、それでも何とか這いつくばるために毎日、基礎的な勉強を振り返るように大学院の授業を見直すみたいなことはしていました。
クライアントとサーバサイドを比較して
不安定(色んな意味で)
ネットワーク通信が途中で途切れたり、それによって取得したデータに不足があったりと言った、安定した処理が行えるサーバと違って、かなり不安定でした。
不安定なのは仕方ないで納得できたのですが、その不安定さを実際にデバッグ環境で再現することが一番難しかったです。
クライアントをやるようになって良かったこと
CPU使用率やメモリ使用率など、リソースについてよく考えるようになった
勿論、サーバサイドやっていた時も考えていなかったと言えば嘘ですが、それまでサーバのスペックを上げればいいと考えていた事柄が、事実リソースが限られている環境を目の当たりにして、リソースを大事にするコーディングの方法はよく考えるようになりました。
スレッドセーフ、非同期、同期の処理についてよく考えるようになった
先程の不安定とも被る話ですが、どうすれば安心・安全なシステムを作れるかという意味で、上記の３つの事柄はコードを書きつつもよく考えるようになりました。
クライアントとサーバサイド両方やるようになって思い知ったこと
その言語を使ったことがない、主流にしている言語とは違う言語になったとしても、基本シーケンス図と仕様書さえあれば、言語が違えど書けるようになります。
多分、これが0→1の新規開発だと、シーケンス図のような部分的なシナリオに対してどういう流れになるのか見定める図とは相性悪いので、また違う話になるかもしれませんが。
その時は、また新規開発と相性が良い設計図で書けばいいだけの話なので。
しかし、その設計案で書いたものを実際に本番で動かした時に、その時は想定していなかったトラブルや問題が発生するため、その場合は応用力が試させるかと思われます。
では、その場合どうすれば良いのかという解決策として私なりの持論として出したいのは
- 基礎を守ろう
- 現場の環境に敏感になろう
- 人の要求に対して、ノイズを発生させないようなレスポンスを返そう
- 基本、反論しないようにしよう
- 再現する環境を用意しよう
の５つは非常に大事にしていきたいです。
当然っちゃ当然なのですが、これさえやっておけば大体上手くいくので、今本当に幸せです笑
これからやること
サーバサイドやらない訳じゃないけど、クライアントの方を重視していきたい
C++ はもうちょっときれいに書きたい
一応、私が書いたC++は動くのですが、そんなに良いコードじゃないので、コーディングスタイル決めるところから始めていきます。
ただ、C++のコーディングスタイル実はそんなに多くないことと、ハードウェア中心で使っているC++で決められたコーディングスタイルをソフトウェアに持ってこようとすると、かなり乱雑なコードになるので悩ましいです(そもそも標準ライブラリを容易に使えないようなハードウェアでも統一したコーディングを目指すために書いているスタイルもあるので、納得感はありますが)
今はこのIPAの組込みソフトウェア開発向けコーディング作法ガイドを読みながらC++のコーディングスタイルを考えている最中です。
iOSのプライバシーマニフェスト対応
これも、私が対応することになりそうです。
まとめ
この記事が誰かの役に立てば。特に駆け出しのエンジニアの方々が実際に、現場に入ってみてのギャップを埋められるようなものになれば、一つの解決策として役立てれば、この記事を書いた効果もあるのかなと考えています。
それでは。
Discussion