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