Cosenseチームでの開発の進め方
Cosenseチームでの開発の進め方
Cosenseチームのエンジニアのohnishiakira
です
テーマ
具体例を用いながら紹介したいと思います
Cosenseとは？
午前中の
さんの発表を見てください
名前が変わりました
Cosenseチーム
エンジニアは3人
2024年1月からこの体制になった
7月はインターンが一人来ていた
今は大学生
開発スタイル
基本的にはいまどきのソフトウェア開発の流れと同じ
GitHubでソースコードを管理して、
CI/CDがあって、
Pull Requestをマージするとリリースされる
特徴的な部分
相互レビューはしていない
週一で事後レビュー会を行なっている
ここで
のPRを説明してもらっている
issueの管理はGitHubを使わずCosenseで行っている
相互レビューをしていない
shokaiさんはめっちゃ開発が速い
相互レビューだったらはレビューするだけで、開発する時間が取れなくなっていただろう
適切にレビューできていたかもあやしい
ReactやNodeは分かる
Cosenseの設計思想や内部実装についての知識が少ない
ユーザーとしてCosenseを使っていたが、中のことは知らなかった
issueはCosenseで管理
Github issuesは使っていない
Cosenseで各タスクごとにページを作っている
Pull RequestからCosenseのページへリンクを張っている
意外とGitHub issues使わなくてもいけるな
Cosense内でリンクがつながっている分便利
単語にリンクを張っておけば2 hop searchで辿れる
関連する議論や仕様のページがすぐに見つかる
個人的にはCosenseの方が慣れててサクサク書けるので楽
Pull RequestはGitHubのエディタで書いているが、WriteとPreviewを行き来するのが苦手
Cosenseに書いた内容でも、Pull Request単体で見て分かりやすいように書き直している
3倍くらい時間がかかる
開発の具体例
Translation modeの実装
元々はshokaiさんが実装
本文を翻訳できるようになった
その後にが本文以外も翻訳できるようにしていった
本文
ページリスト画面
全部検索結果
文芸的データベース
全文検索結果の翻訳
最初の実装
本文と同じように翻訳文を本文の下に表示
ちょっとわかりづらい
概要が長いとパッと見ても内容が分かりづらい
もうちょっといいレイアウトがないか
色々検討
本文と翻訳文を交互に表示
本文と翻訳文を1行ずつに表示
本文、翻訳文を1行ごと改行して表示
最終的にこの実装になった
違和感がないか
全文検索結果画面でStart translationした時にどうか
意外とどのパターンも違和感なかった
うまくいかなかったこと
QuickSearchの翻訳
他のところは翻訳できるようになってきたので
ここもやりたい
難しくて止まっている
UIのスペースが狭い
本文のように画面に入ったら翻訳するというやり方だと、かなりガクガクしそう
最初にQuickSearchのリストを全部翻訳する
実装はできたので
Helpfeel社内のプロジェクト（9万件）で試す
速攻でDeepL APIのQuotaを突破
いい解決策が出てくるまで寝かせる
これを本番リリースすると、すごい料金になる
全部翻訳しても、ユーザーが全部見るわけじゃない
翻訳文が挿入されてガクガクすると、ユーザー体験がよくないので減らしたい
技術が進歩すると、サクッと実装できるようになるかもしれない
設計思想の話
テーブル表示モード
のアイコン
before
after
設計思想
>アイコンから意味を推論するのはとても難しい
dropdown menuの中にアイコンを置くのは、その項目を特別に強調したい場合だけにする
実際CosenseのUIは、文字だけで説明しているものが多い
アイコンがあった方が分かりやすいと思っていた
ただ街中や別のウェブサービスを使ってる時に「なんだこのアイコン？」「どういう意味なんだろう・・・？」と思うこともまたあった
という感じで、Cosenseの開発は行われています
まとめ
1月から半年超Cosenseの開発に携わってきて
テンプレ構成に従わなくてもいい
ピアレビューをしてないけど、全然上手く回ってる
shokaiさんが全てを把握しているし、かつ少人数だから成り立っているという所はある
あまり一般化はできない
型に合わせてやってるけど、「これ要らんのでは？」というものは一回試しに外してみるのもいいかも
きちんと理解した上で実装することが大事
設計思想
ここはこう実装すればいいだろうと思って実装したけど
設計思想を聞いてなるほど、となって修正する
みたいなことがよくある
後々改良しやすくするために複雑な実装にしすぎない、など
自分がユーザーとして使ってて違和感がないか、使いにくくないか
失敗を恐れない
ユーザーに悪い影響がある部分（サービスが止まるとかデータが漏れるとか）ではもちろんダメだけど
そうでないところはどんどん失敗した方がいい
QuickSearchの翻訳も実際にローカルでDeepL APIのQuotaを使い果たすまで「いやいけるっしょ」と思っていた
これこうやっていいんだろうか・・・
失敗したらどうしよう・・・
その時間で手を動かした方がいい
おわり