cutmail's blog

write the code

スキル見合いという悪習

業務委託などの形式で仕事を募集している会社などをみていると、報酬の欄に「スキル見合い」と書かれているのをみることが稀にある。

スキル見合いとは要するにその人のスキルに合わせて報酬を決めて契約するということだ。

では、そのスキルとはどうやって判定するのだろうか。

だいたいの場合では、募集をしている企業側の担当者の主観で決められることが多いのではないだろうか。

業務委託という性質上、面接に近い厳密なコーディングテストを実施することは難しいはずだ。

業務を委託しなくてはならないくらいなので、スキルを判定することができる人材もそこまで揃っていないケースも多い感じはする。

では、どうしていくべきだろうか。

「スキル見合い」という誰も幸せにならないやり方を捨て、まずはどれくらいの金額であればその業務が気持ちよくできそうか提示してみよう。

もし金額が合わなければそこで終わってしまうかもしれないが、業務の内容を調整したり、金額を交渉したりそれぞれが歩み寄ることが大切だと思う。

企業側にだけ都合の良いやり方は捨て、仕事を請ける側も気持ちの良い習慣が根付くことを願う。

iOSアプリのコードレビューで見ているポイント 2020年5月版

比較的大きめな規模のiOSアプリのコードレビュー をする機会がよくあるため、 どういった点に注意を向けてレビューしているかまとめておこうと思う。 以下は主にGitHubのPull Requestベースでレビューをする場合を想定している。

非コード編

1. 該当のissueがリンクされているか

Pull Requestを出した背景となるissueがあればそのリンクがDescription欄に貼られているか

2. 変更点が簡潔に書かれているか

コードを見ればいいのだけど、変更した内容を簡潔に書かれているとコードレビュー する前にある程度把握することができるので書きましょう

3. スクリーンショットが添付されているか

UIの変更を伴う修正の場合はスクリーンショットを付けた方が良い。 スクリーンショットに関してはいくつか見る箇所があって、

  • レイアウトが崩れていないか
  • 該当のissueの要件になっているか

4. CIが通っているか

CIが導入されているのであれば、CIのステータスがGreenになっているか

コード編

5. 新しくファイルを追加する場合、適切なGroupに配置されているか

比較的規模の大きいアプリであれば、暗黙的なGroup分けの仕方が存在していると思うので、適切なGroupに配置するか、新しくGroupを切りましょう

6. 目的の修正と関係ないファイルが変更されていないか

よくあるのが、CocoaPodsの Podfile.lcok がなぜか更新されていたり、 関係ないStoryboardで差分が出てしまってコミットされているケース。

後から変更を履歴を追いたい時に不要な変更があると原因の特定が難しくなったりするため、そもそも意図しない変更以外はコミットしない方が良い。 使っているXcodeのバージョンがチームで違っていたりすると、Storyboardを開いただけでdiffが発生したりするので注意。

7. ファイル名、クラス名が適切か

そのファイル名やクラス名を見ただけで役割が推測できたら良い。 できなかったら不適切な名前を付けている可能性が高い。

8. インデントが崩れていないか

プロジェクトが採用しているインデントのルールに沿って改行やインデントされているか。

9. 変数名が適切か

その変数の型と役割を表す名前になっているか。

let image: UIImageView

例えば上の例だと、宣言している箇所ではまあわかるが、他の箇所で image が参照されていると、 UIImage の変数なのかと思えてしまう。

let imageView: UIImageView

とした方が理解しやすい。

10. 循環参照していないか

特にクロージャーを使っている箇所で self が循環参照していないか。

11. 小さい画面の端末が考慮されているか

iPhone SEなど解像度が低い端末で実行した時に崩れたり、意図しない表示にならないか。

12. Forced Unwrapping(強制Unwrap)を使っていないか

実行時にクラッシュしてしまうためOptionalを使いましょう。

13. ライブラリを導入する際は、導入目的が明確か、メンテナンスされているか

UIKitで目的が達成できるのであればライブラリは使う必要はないと考えています。 また似たようなライブラリがあった際は、なぜそのライブラリである必要か説明があった方がいいです。

14. Dark Themeを導入していれば、Themeの切り替えで意図しない表示になっていないか

Storyboard上で容易に切り替えて確認できるので確認しましょう

15. print文などをDEBUGフラグ確認なしに使って、不必要なログを出力していないか

APIのレスポンスなど不要なログは出力しないほうが懸命です。 SwiftyBeaverなどのライブラリを使うのも手です。

まだまだレビュー観点はたくさんあるんですが、 他にもこういう観点でコードレビュー しているなどあれば、コメントもらえると嬉しいです。

49インチウルトラワイドモニターを買った

リモートワークの環境を整えるために大きめなディスプレイを買うか!ということで、せっかくなら大きいのが良さそうということで 49インチのディスプレイを買った。

使ってみた感じとしては、大きすぎることもなくXcodeのウィンドウを3個くらい表示していても全然問題ないという感じ。 今のところ快適。

難しい問題を難しくしない

ある機能を作るときに、複数の画面に分割する過程や、システム上の都合で仕様がさらに複雑になるケースがある。
 
ユーザーは強烈なインセンティブがない限り複雑な仕様は理解してくれない
 
そう思った方がいい。

Notionを使い始めている

Notionというサービスがある。 日本でも使い始めている人がちらほらいて、前から気になっていたのだけどついにちゃんと使い始めてみることにした。 以前はInkdropというアプリを使っていたが、Chromebookで動くアプリがない(Androidアプリがなぜかインストールできなかった)ので、他のツールを探していた。

Notionは、一言でいってしまえばノートアプリなんだけど、データベースやギャラリーなど、多くのテンプレートが用意されていて、 単なるメモアプリにとどまっていない。

f:id:invent:20200123195555p:plain

テンプレートがたくさん。 自分で作ることもできる。 f:id:invent:20200123200034p:plain

また、Workspaceみたいな概念があり、メンバーも招待できるので、 要はesaKibelaみたいに社内ドキュメント共有みたいなことも全然できる。

Slack連携の機能もあるので、ドキュメントが投稿されたら通知をするみたいなこともできるみたい。

Notion自体はまだ小さいスタートアップみたいなのだけれど、可能性のあるサービスなので使っていてみようと思う。

2019年に買ってよかったもの

こういうエントリ書くの初めてなんだけど、今年は買って良かったものがたくさんあったのでいくつか紹介したいと思う。

まずはルンバ。 最上位モデルだとルンバが集めたゴミを最終的に紙パックまで吸引してくれてほぼゴミに触れることがなくなった。 部屋のレイアウトを覚えてくれるので、効率よく掃除をしてくれる。 またアプリからスケジュールを登録することができるので、毎週月水金の朝に自動で掃除させるとかができる。

Apple Watchを初めて買った。 これを買ってからiPhoneを見る機会が圧倒的に減ったのと、寝るときにつけてると睡眠の状態を可視化することができてすごい。 またApple Payに対応しているので、Apple Watchだけを持って外に出ても全然問題ない。最高。

このエントリもPIxelbook Goで書いている。 基本的にChromeが動くだけのノートPCという感じだが、Xcodeが動かないくらいであとはあんまり困っていることはない。 Linuxもbeta版だが一応動くので、シェルで開発したり、Android Studioも動く。 本体も軽いのでちょっとした旅行などに持っていくのにすごくいい。 残念ながら日本へは直送していないので、僕はAmazon.comで買ってPlanetExpressで転送してもらった。

もともとはMagic Mouse2を使ったいたのだけど、指が腱鞘炎になってしまって他に良いマウスがないかなと思って探して見つけたのがこれ。エルゴノミクスで、手に負担の少ない状態で操作ができる。

Macbook Proの下につけるスタンド。 以前は厚紙っぽいのを使ったいたのだけど使ううちに曲がってきてしまって、探して見つけたのがこれ。 プラスチック製なので上部で高さもちょうどよい。 スタンドをつけることで熱も逃がせて良い。

他にも追記するかも。