Kamil Trzciński の README
はじめに
私の名前は Kamil Trzciński で、Memory チームの Senior Distinguished Engineer として、ポーランドに住んでいます。
私は 2015 年 6 月に GitLab に参加しました。会社に参加するずっと前から GitLab に貢献していました。最も注目すべき貢献は 2015 年初頭の GitLab Runner であり、これがそもそも GitLab に採用されたきっかけでした。
私が GitLab Runner を書くことに決めたのは、Go を学びたかったからです。GitLab Runner はこの言語で書いた私の最初の実際のプロジェクトです。Go は、静的コンパイル（配布が容易）、Docker への素晴らしいサポート、効率的な実行モデル（多くのジョブを並行で実行可能）のため、理想的な選択でした。 加えて、私は常に Drone.io のシンプルさを愛していました。 私はそこからいくつものアイデアを採り、GitLab Runner の初期バージョンに実装し、Docker をふんだんに使えるようにしました。
リンク
何にフォーカスしているか
私の主なフォーカスは Memory チームに関連する仕事と CI/CD 領域に関連する仕事です。 私はこれらのトピックに関連する多くの議論に積極的に参加しています。なぜなら単純にそのトピックに興味があり、有用なフィードバックを提供できると考えているからです。
いつもの 1 日
私は午前 10 時頃 (CEST/CET) に朝食と最初のコーヒーで仕事を始めます。 9 時 45 分のこともあれば、10 時 30 分のこともあります。
朝はほとんど TODO や MR を見たり、昨日から何が起きたかを確認することに費やします。 これは他の人とのコーヒーチャットの時間でもありますが、これらは通常午前 11 時頃に始めるのを好みます。
日中は、ほぼ自分の仕事に集中します。チームや同僚から追加の確認が必要なトピックでランダムに割り込まれることにも、通常応じられます。昼食は午後 1 時から 2 時の間に取ります。
午後は通常ミーティングに占められます。その時間中は MR/TODO をほとんど見ず、ミーティングや Issue・MR の議論への貢献に時間を費やします。
私は午後 5 時から 8 時の間に 1 日を終えます。日や、何かを終わらせることにどれだけ集中しているかによって変わります。
夜遅くまで Slack にいるのは普通のことですが、これは私が働いていることを示すものではなく、コンピューターの前にいて、映画を観たり、趣味のプロジェクトに取り組んだりしていることを示します。
一般的には、平均で 1 日 7.5 時間（昼食を含む）を目標にしていますが、日によって変わります。
仕事のスタイル
私は、自分が熱意を持っているさまざまなアイデアをいつも持っているため、多くのトピックを同時に進める強い傾向があります。
多くのトピックを同時に進めることは、コンテキストスイッチのために難しいこともありますが、私は通常それを大きな疲労とは感じません。 これがその理由です:
- 知識を広げる
- 私はそのトピックに本当に興味がある
- 新しい技術や新しい領域を学びたい
- さまざまなアイデアを試して、実装したらどれだけ複雑になるか見たい
- 既知の問題に対する潜在的な改善を探りたい
- 自分が見た Issue を調査したい
- それをプロダクトへの潜在的改善として見ている
学習プロセスを速める私の方法は、Proof of Concept を作成することです。 さまざまな理由でこれを行います:
- 異なるアプローチを確認するために多くの Proof of Concept を作成する傾向があります
- Proof of Concept に費やす時間をタイムボックス化し、複雑すぎて時間がかかりすぎる Proof of Concept は破棄します
- アイデアを素早く検証するために Proof of Concept を使います
- 実装の複雑さとそのアプローチの潜在的な問題を理解するために Proof of Concept を使います
- Proof of Concept は完璧ではなく、すべてのケースをカバーすることも、マージされることも意図していません
- Proof of Concept は、述べられた問題に対するソリューションの 1 つを示します
- Proof of Concept は、アプローチのパフォーマンス特性を検証するために使えます
- Proof of Concept は、それが作成された前提と制限を一緒に記述します
- Proof of Concept は、アプローチが正しいか、マージ可能な状態にするために必要なステップは何かをさらに決定する良い議論の出発点になります
私は一度に多くの MR を扱うのが好きです。作業を非常に小さなマージ可能なチャンクに積極的に分割し、早めにマージする傾向があります。 4〜5 個の MR が互いに依存してチェーンを形成するように作業を分割するのが私には普通です。継続的なリベースを助けるため、私はすべての重い作業を行うスクリプト rebase-all を使っています。
私の期待
私が行うすべて（自分でも、他人の変更をレビューするときでも）で、与えられた変更の周りのコードを少しずつ改善することを常に目指します。 私のアイデアは、技術的負債の解決に 10〜20% 多くの時間を費やすことで、特別にリファクタリングを行わなくても、コードベースを継続的にリファクタリングできるというものです。 リファクタリングを別途スケジュールすることは、通常は悪いアイデアだと私は感じます。 新機能を実装している間にコードベースを継続的にリファクタリングする方が、私にはずっと簡単に思えます。 私と一緒に働く人には次のことを期待します: 将来私たちの生活を楽にするために、記述されていることより少し多くやってください。
上記へのアプローチの例:
- 発見したが明らかでなかったことについてコメントする
- 既存の実装のアーキテクチャを改善する
- メソッドやテストを書き直して読みやすく、またはより高性能にする
- 発見した問題について Issue を作成する
- この変更の前に、いくつかの側面を改善する小さなマージリクエストを行う
私のフォーカス
自分の仕事をしているとき、または他人の仕事を見ているとき、私が最も気にかけるのは:
- セキュリティ（常に最優先）: 特に認証と認可のコードをすべて見て、車輪の再発明ではなく確立されたパターンが使われていることを確認します
- データ構造: データベース構造が将来にわたって使えること: 私はデータマイグレーションを規模で行うのが最も難しいことだと考えます
- ソリューションのパフォーマンス: 特に実行時間 (CPU/DB 時間やメモリ使用量) に影響する誤用やエッジケースを見ます
- 使用制限: ソリューションがテストされた上限の使用量を定義し、ソリューションの誤用を防ぐ制限を定義します
- 拡張性: 将来ソリューションを拡張できること
- スタイル: 既存のコードと首尾一貫して実装されていること、そして適切な構造（OOM）を持つこと
純粋な実装の側面以外にも、私は次のことを気にかけます:
- ユーザーに愛される UX であること: クリーンで、既存の機能と首尾一貫していること
作業環境
私は常に自宅から働きます。コワーキングスペースで働くのはあまり好きではありません。 椅子と大きなデスクは私にとって譲れないものです。
私は仮想化の大ファンです。すべてのシステムを仮想化し、同じキーボード、マウス、モニターでシームレスに切り替えようとします。仕事と作業環境のできるだけ多くを自動化します。これが、作業環境のすべての側面を制御する 4x4 キーボードを持っている理由です。これは ESP8266 に接続されており、MQTT 経由で Home Assistant にコマンドを送ります。後者は私のすべての照明、PC/Mac、モニター、スピーカー、スイッチを制御し、必要に応じて電源を入れたり一時停止したりします。
使用しているシステムについては。私は作業用システムを常に変える傾向があります: 多くの時間は Mac で作業しますが、3 年以上にわたってデスクトップ Linux も使ってきました。私には Windows を試した短いエピソード（1 週間ほど）もあります。
最近、私は GitLab 関連のすべての作業を Visual Studio Code で行っており、PC 上に仮想化された Ubuntu VM に接続しています。Mac は見栄えの良いデスクトップとして使うだけで、すべての作業はリモートで行います。完全に不変な開発環境のため、私自身の GitLab Compose Kit を維持しています。私は過去 3 年間、これを排他的に使ってきました。
ディスクには鍵を一切保存しません。どこでも認証するために Yubikey を使います。使う各コンピューター用に Yubikey を持っています。
c955a93f)