背景

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

目的

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

課題

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

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

中途／経験者は、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宣言があるが、実体を直接利用している ----------------------------------------