背景

• codingcheckというWEBのコードチェックサービスがモバイルアプリには対応していない

目的

• 中途面接の時にコードを見て実力を判断する

課題

【課題】
1. 既存アプリのリファクタリング
<https://github.com/yumemi-inc/ios-engineer-codecheck>
上記リポジトリーのREADME.mdを熟読した上課題に取り組んでください。

2. 新規アプリの作成（新卒／未経験者のみ）
<https://ios-junior-engineer-codecheck.yumemi.jp/>
上記のページを熟読した上課題に取り組んでください。

中途／経験者は、1を、新卒／未経験者は1もしくは2をいずれか選んでいただきます。

【提出期限】
本日より1週間後

締め切り

• 原則1週間

フィードバック例

• 不合格の場合もコーディングチェックの結果のフィードバックは比較的丁寧に行い候補者体験を大事にする
• 未来のゆめみのファンになってもらう為
• 以下は具体的にフィードバックとして実施している参考例

良かった点

• 細かいコミット粒度
• 後半からブランチ運用も取り入れられた
• CocoaPodsを利用している
• // MARK: でファイルのセグメンテーションを作っており、構造が見やすい
• データ処理の排他処理がきちんと行われている

改善点

• DerivedDataが.gitignoreに入ってないため、環境によっては大きな差分が入る
• テストがない
• 長い文章入れると、出力は全部見れるが入力の文章がカーソル動かさないと全部見れないので、UI面ではまだ改善の余地がある
• protocolによる抽象化があるが、それらの抽象化が活用されていない；protocolの定義が意味をなしていない
• 数多くの型定義があるが、VC側は結局微妙にFat；画面レイアウトも管理しているし、微妙にドメイン層の処理もある
• 各種 Error の case がUpperCamelCaseで定義されており、Swift API Desing Guidelinesに反している

その他

• 用件と達成した機能の割には部品設計が複雑すぎた

next

• コメントと実装に乖離：変換実行後、正否に関わらず、入力文章に対する Cell が TableView に挿入されます → .failureではprintのみ
• protocol宣言があるが、実体を直接利用している