技術職の転職事情

某転職エージェントの人と話したことをメモ

僕の転職モチベーション

  • このまま今の会社にいると実践的な技術から離れざるをえない
  • できればずっと現場で働きたい
  • 今すぐは考えてないが数年以内には・・・

メモ

転職先について

  • 事業会社からSI/コンサルへの転職は少ないらしい....
  • 事業会社からベンダ・メーカも少ないらしい ....
  • 事業会社 -> 事業会社が多い
  • 他業種でかつニッチな業界はやっぱり転職しづらい
  • 汎用的なスキルは持っておく

技術の定年について

  • 今は40前後までやっている人はいる。
  • ただし、技術色のつよい会社が多い
  • 管理職じゃなくても今の給与水準は保てる会社もちゃんとある
  • 技術色の強くない会社はやっぱり30歳過ぎたあたりから管理職へシフトする傾向

他もいろいろ話したけど、身の上話なので割愛

今後の方針

  • 求人は見るべき
    • 最近はAIでリコメンドするので、プロフィールや経歴、希望などは埋めるとマッチ度や高待遇のところが出されやすい
    • もちろんAIで出しきれないのでアドバイザも活用
  • 求人をみた上で現在の自分とのギャップを把握して、転職する時期までにギャップを埋める行動を！

感想

  • ほぼわかりきってた話ではあった
  • 企業事情とかも加味して提案してくれるのは、キャリアドバイザーのアドバンテージという感じ
  • 現場でプロ人材（⇔ジェネラリスト）を続けられるかは企業次第なので諦めなくてもいいかもとわかっただけでもGOOD

【Rust】トレイト名の後にコロン(:)でトレイトがつく構文

※この内容は The book に記載の内容です。

こういうやつ

pub trait FuturesAsyncWriteCompatExt: futures_io::AsyncWrite {  // <-- ここ！
    /// Wraps `self` with a compatibility layer that implements
    /// `tokio::io::AsyncWrite`.
    fn compat_write(self) -> Compat<Self>
    where
        Self: Sized,
    {
        Compat::new(self)
    }
}

その名も「スーパートレイト」

selfが別のトレイトの機能を実装していることを前提とする時にこのように書く

上記の場合、FuturesAsyncWriteCompatExtはfutures_io::AsyncWriteが実装されているstructに実装されることを前提としますよ。ということ

the bookが普通にわかりやすいので復習はこちら

doc.rust-jp.rs

あとがき

以前は、他人のコードを読んでいて、初見の構文にであった時に何て調べればいいわかなかった 今はChat GPTがあるから初見でもなんとかなる。いい時代になった。

【Rust】静的型付けやnull安全、例外の排除はテストを削減するのか?


Rustの特性に以下の３つがある

  • 静的型付け言語
  • null安全
  • 例外がない

これらはテストを容易にするとかコードの品質をあげるとか言われているが、 具体的に何がさせるのかを自分なりに解釈する

静的型付け

静的型付けの利点は以下

  • 変数や関数の型が事前に宣言または推論されるので、コンパイラがコード内の型エラーや型不一致を検出できる（実行前に気付ける）
  • コードの理解がしやすくテストケースの洗い出し、責任範囲が明確になる
    • 関数やメソッドの型シグネチャが明示されるのでドキュメントとしての役割が期待できる

つまり - コードの 理解がしやすいので実装が捗る - テストケースが明確になり無駄なテストが減る - 静的解析と型推論による高速なコーディング

である

テストというよりもプロセスの向上かな 普通に動的型付け言語でもリンターの充実や静的解析できるようになってるので、特別なメリットではないかも

null安全

null安全であることの利点は以下

  • nullに関連する問題を心配する必要がない
  • コード内でnullチェックにあたる条件分岐を書く必要がない。
  • コード内でnullの可能性が排除され、特定のエラーケースを考慮する必要がなくなる
  • コードがシンプルになり、

つまり、

  • テストが合理的かつ簡素になり、テストコードの保守性が増す。
  • 条件分岐が減り、テストの量とコードカバレッジが向上する
  • 無駄な心配事を排除し、テストの焦点を機能やビジネスロジックに集中させることができる
  • バグの要因が減るから品質向上

のである。

例外がない

例外が代わりに、「回復可能なエラー」と「回復不能なエラー(panic!)」に分けられる。他の言語は区別がない そしてResult型が存在する なので、

  • 何をどうハンドリングするべきかが示唆される
  • エラーが起こる可能性を知ることできる

つまり、

  • コードの設計時にエラー条件とハンドリングを考慮でき、エラーの可能性を限定できる
  • テストの範囲を絞ることができ、テストコード量を削減できルトともに、品質があがる

のである

まとめ

品質とテストが向上する！！

【Rust】引数にboolが必要な時に何に対するtrue/falseなのかがわからない

Rustにはデフォルト引数がない

引数でboolを渡したいとき、そのtrue/falseは何の値なのかはエディタの注釈機能を使わないとわからない（そもそもそんな関数を書くなというのはさて置いて）

githubとかで見た時になんやねんとなる

個人的な解決策としてはenumを使って以下のように書く

enum isFoo {
    True,
    Falsex
}

fn func(flg: isFoo) {
    // do something
}

fn call_func() {
    func(isFoo::True) // <- 呼び出し元のコードだけで何なのかわかる
}

ただし、bool型ではないので条件式等で使うにはもう１ステップ欲しいのが欠点

個人的Rust langを勉強するならこれは知っておけ

Web