テーマ、知りたいこと
プログラムの作り方なんて、個人の自由でいいですよね。
他所の環境では、コードレビューではどんな突っ込みが入るか聞いてみたいです。
背景、状況
このようなif文を作りました。
if Dir.exist?("/hoge") else return "ディレクトリが存在しません" end
すると、このように直せと言ってくる人がいるかと思えば、
if !Dir.exist?("/hoge") return "ディレクトリが存在しません" end
このように直せと言ってくる人もいます。
unless Dir.exist?("/hoge") return "ディレクトリが存在しません" end
どうでもいいじゃんと思っているのですが、なぜに、そんな細かいことをいちいち突っ込んでこられなきゃならないのかと疑問に思っています。
皆さんはどのように思われますか。
回答37件
#1
総合スコア13851
投稿2024/11/29 02:02
編集2024/11/29 02:03複数で開発しているコードの書き方の基準を決めておくのが有用であることは一般的に正しいと認識されているところだと思います。
googleなどの大きなところのコーディング規約は見ることができますし、pythonにはpep8という規約があります。
書き方を統一することで、他のメンバーの書いたコードも(比較的)ストレスなく読むことができ、結果としてコードの品質を上げることにつながると思います。
ただ、質問のような状況が1つのプロダクト/チームの中でのことであるならば、コーディング規約を作って統一することを提案すべきでしょうね。
#2
TakaiY
なるほど、大きな組織になれば色々とお約束ごとがあるのですね。
#3
総合スコア560
投稿2024/11/29 02:10
コーディング スタイル は linter 等により 自動チェック できる範囲で チェックするべきかと思われます。
ruby なら rubocop あたりで。
https://github.com/rubocop/rubocop
もしも、独自のルールを追加したいのであれば linter に実装できる範囲でするべきです。（自動適用できれば誰も文句は言わないでしょう。
#4
juner
こいうツールは知りませんでした。
#5
総合スコア1750
投稿2024/11/29 02:29
編集2024/11/29 02:31例示されたコードでは、if と else を分けているのは、双方で別の処理が存在するのを示唆しているように見え、処理の実装漏れではないか、という疑いが生じます。
どうしても、この形式でやる必要があるなら
Ruby
1if Dir.exist?("/hoge") 2 # 何もしない 3else 4 return "ディレクトリが存在しません" 5end
と、処理がないことを主張するコメントで、実装漏れの疑いを払拭する必要があるかと。
なので、修正指示は妥当だと思います。
修正の２案、if ! と unless ですが、否定記号は、見落としやすいので、その防止策になっているのではないかと。
もちろん、きちんと読めばわかりますが、誤読を減らすことで、理解が早まり、不具合も減るでしょう。
趣味だけの指摘と切り捨てて良いものではないと思います。
本来、コードレビューで、これらの指摘がなされ、統一する意義を認識してもらうのが、正解だと思うのですが。
#6
総合スコア116843
投稿2024/11/29 03:36
個人で自分のために作っているなら自由にしてください。
もしそうでなくチームでやっているならチームの方針に合わせてください
誰かに依頼されてやっているなら依頼主の「直せ」は絶対です。どんな不条理でも対応してください
#7
YT0014
yambejp
方針には従わなくてはいけないのは仕方がないですね。
#8
総合スコア122
投稿2024/11/29 04:45
編集2024/11/29 04:47コードレビューは単に可読性を図るに留まらず、最適化の検討、冗長性の確認、潜在的なオーバーヘッドの発見など、コードの安全性を保つための様々な意見交換の場です
その指標がコーディング規約であり、全てのコードは一定の規格に則っている必要があります
特に可読性と冗長生は最適化とトレードオフの関係にあります
都合上やむ追えない部分でネストを追加する際など、全体的なコード改修による仕様変更を鑑みて、無駄な冗長性は可能な限り省きたいところです
なので、一見不要に見える修正も、保守性の観点では重要な工程となります
個人で開発する上では全てを自身の管理下に置けばいいわけですが、チームで開発する場合はなるべく簡潔なデザインを目指す方が効率的と言えるでしょう
#9
nanashi123
なるほどです。
#10
総合スコア907
投稿2024/11/29 09:28
すごい気持ち分かります。
仕事だと思って割り切るしかないんじゃないですかね
#11
a.com
なぐさめのお言葉ありがとうございます。
#12
総合スコア348
投稿2024/11/30 16:00
コーディングの仕方は個人の自由でいいと思いませんか
個人の自由でいいと思います。
以下蛇足
例に挙げられているソースについて
上から順に1, 2, 3とすると、
全員が同じ記述に合わせるなら1の方法が一番無難だと思います。
2, 3の方法は、if, elseの両方があるときに書き方がまた違ってきますが、1の方法は常にこの方法でしか書けないので、いろんなところでifという条件分岐を使用して、ぱっと見でソースが見やすいというのは1の方法だと思います。
コメントでTrueに処理がないときに処理をしないと書くというルールを設けるのであれば、逆に見づらくなるので、そもそも、テストを書いてTrue側の処理がなくても正常に動作することを保証したほうがいいと思います。
コメントを書くとしたら、
// 存在しなければ処理を行う if Dir.exist?("/hoge") else return "ディレクトリが存在しません" end
みたいなコメントのほうがまだ有益だと思います。
コードを指摘するという行為について
正直、2, 3の方法で書けというのであれば、なんらかのエビデンスがないといやがらせと感じるのに十分な指摘だと思います。
例えば、2, 3の方法が共通仕様書Aで推奨されているので、その書き方に合わせてくださいとか、
そういう説明もないのなら、ミスしたわけでもないのに、した仕事にケチをつけられるのは納得がいかなくて普通だと思います。
ただ、それを指摘するということは1の書き方をみて、「いやがらせか、このコードは」と感じたのかもしれません。
それは人それぞれの感性なので答えは出ないと思います。
そもそもソースコードを書くという仕事について
プログラマの仕事はいわばソフトウェアを作って、ユーザーを喜ばせることである意味製造業だと思っています。
ただ、プログラマの場合プログラミング言語をもちいて設計書を作るだけであって、実際に商品を作ったりコピーしたりするのはコンピュータなので、そこがニュアンス的にずれがあるかもしれません。
ソフトウェア開発という仕事は依頼者が求めた製品を作るという仕事でありますが、ほとんどの場合依頼者の言った通りに作るよりもこちら側からいくつか提案してそのように実装したほうが、結果的に依頼者が依頼した製品よりもよりよくなって依頼者は喜ぶかと思います(というかそこが仕事の肝)。
おそらく契約の面でいえば、依頼者が言ったとおりにソフトを作ればお金にはなると思うのですが、ほとんどの場合は喜ばせるためにそういったサービス(厳密にはお金をとってもいいが)を付け加えることになり、
製造業＋サービス業みたいな立ち位置になるんじゃないかと思います。(広義の意味で厳密かは知りません)
そんな中で、コードをこのようにして書いてください、とうのは製造的な側面というよりはサービス的な側面です。
しかもそのサービスの相手が、金銭が発生する相手ではなくて、同僚に対してそのようなサービスをしないと、ということになり、エスパーでもないのにあとからこの書き方に合わせろとか言われても、なんでそこまでってなるのもおかしくはないと思います。
サービスという言葉をあえて使いますが、これはニーズがどこの誰にあるのかという観点の話で、
ユーザーはより快適に使いたいというニーズを持っていますが、
会社は継続的な開発を行いたいというニーズを持っているかもしれません。そのために共通仕様が必要になることもあると思っています。
私の環境について
私の会社は特に大きな会社でもないですが、
仕事終わりに同僚と飲みに行ってこの質問にあるような話になった際は質問者さんと同じように、自由でいいし、他人のソースには口を出さないという意見がスタンダードでした。
サービスという話でもしましたが、人間関係というか、仕事をする上で他人がどう考えているかという話は大事ですが、会議や投票でその意見を洗い出すということはしませんよね。
だからこそ、古い文化ですが、飲み会のようなもので親睦を深めてお互いの仕事に対する意見を出し合うということが一つ対処法としてあるのだと思います。
飲み会なんて残業みたいで嫌な人ばっかりな時代だと思いますが、やっぱりメリットもあると思います。
#13
総合スコア23
投稿2024/11/30 16:11
書き方を統一すると似た雛形探すのにも使えるし何かと都合が良いんだよねぇ
#14
utm.
色々なご意見がありますね。些細なことでいざこざを起こしたくなので、自分はいちいち反論せずに、言わせておいてスルーです。
#15
ryojiaraki
それはあるでしょうね
#17
総合スコア4211
投稿2024/12/01 06:12
仕事ではなく趣味でやっている場合は、責任もないし好きにして良いですが、今回は仕事でのお話と解釈しました。
仕事としてやるなら、コーディング規約やコードレビューがあるならそれに従うのは当然です。
そのような決まりがない場合でも、現実的にはチームで働くのであれば合意形成は必須です。
自分のコードを同僚が修正する場合もあればその逆もあります。
そのためにはある程度の決まりがないとコードの修正が困難になったり品質低下に繋がります。
コードは会社の資産です。人員が入れ替わっても安定して運用するためにもコードの書き方が統一されているのは大切です。個人の感想で済む話ではありません。
#18
総合スコア11996
投稿2024/12/01 09:20
編集2024/12/01 09:32このように直せと言ってくる人がいるかと思えば
（中略）
このように直せと言ってくる人もいます。
…っていう話だと，
「何かしらの統一されたルールに従え」という意味合いで言われているようには見えない．
であれば，個人の自由で良い気がします．
「あるルールに従ったコードを書くこと」っていう仕事をしていてその中で言われた話なのであれば，理由は「ルールだから」という話で明確かと．
そうじゃなくて単なる個人の感想とか好き嫌いとかいうレベルの話なのであればその意見を受け入れるか否かも含めて好きにやれば良いであろうと．
#19
チームのコーディング規約などであったとしても、それには従わないということですか？
自分のチームにそういう人がいたら困りますね。
いや、そういう意味ではなく、チームの規約があれば従いますが、
それとは関係なく、たんなるクレーマーのように言ってくるだけであれば、
スルーするという意味です。
#20
#17
チームのルールがあれば従わざるを得ませんが、そもそも、自分が例にしたif文程度でも、他所の会社でも細かくルールってされているものなんでしょうか。自分の環境が細か過ぎなだけなのかが分かっていません。
#21
総合スコア13851
投稿2024/12/01 10:31
たんなるクレーマーのように言ってくる
自分が例にしたif文程度でも、他所の会社でも細かくルールってされているものなんでしょうか
if文で否定の判定をどのように記述するかについては、質問にもあるようにいろいろな流儀があり、バグの元になることもよくあるので「そんなことまでルール化するのか?」ととらえるようなものではないと思います。
これまででも明文/非明文含めて取り決めていたプロジェクトは多くありました。
一つのチ＿ムでレビューアによって言うことが違うのは問題があるので、そういうことがあれば、クレーマ扱いするのではなく、チームでの意見の統一を図ったほうがいいと思います。
#22
総合スコア11996
投稿2024/12/02 01:56
（この意見交換を，ご自身が在籍している場所でやれば良いのでは）
#23
#22
会社の外部の意見を聞いてみたくてここに投げてみました。
#24
総合スコア160
投稿2024/12/02 02:19
編集2024/12/02 02:24コーディングルールを決めるのはいいと思いますが、ツール等で自動化出来る程度の範囲じゃないと、徹底するのはまあまあしんどいです。人数増えてくると、ルール決めた人が全部レビューするって訳にもいかないですし、pyon_kiti_jpさんの遭遇したようなレビュワーによって判断基準が分かれるみたいな事に遭遇する可能性もあります。
うちのとこはルールは必要最低限だけでガチガチには決めてなくて、機能さえ満たしていれば、実装の仕方についてはよほど酷くなければ直せとは言いません。（機能満たせるか怪しかったり、異常対処が不十分な箇所については当然口は出しますが）
まあ、結局のところ会社やチーム、環境次第でしょう。納得がいかなければ社内で話し合いや交渉してみたり、それが無理そうなら転職したり独立したり環境を変えるのも選択肢です。
#25
総合スコア116843
投稿2024/12/02 02:35
編集2024/12/02 02:35社会人としてチームでやっている中で、コーディング方法が複数ある場合は、「どちらに合わせるべきですか？」と自分発信でプロマネに聞くのが正しいです。そこで「どちらでもいい」と回答をもらっているならドキュメントに「日時、指示者を具体的にして、この方式についてはどちらでもいいという指示があった」ことを残しておくべきです。あとでなにかトラブルがあったとして「君のソースは汚い」といわれたときに「指示いただいてた通りやっています」と言えるので。逆にわからないから自分の判断でやりましたというのはプロ意識の欠如でしかなく、問題があったときはすべてご自身の責任になりますのでご注意ください
#26
総合スコア21203
投稿2024/12/02 02:36
例題の文章でいうとunless使うのが一番良いかと思います
人間は文章を左上から読むので、左上に何するかが明示してあると理解が早くなるし、
普段から左に何をしたいかを書く癖をつけておくと良い習慣となるでしょう
これも私個人の意見で表記揺れの原因になりますね
こういう知見をまとめたのがコーディング規約ですが
大抵の場合は「理由までは書かれてない」のでなんでそうなるねんってなって
「あれば渋々従うけど、無きゃ従わん」となるのは至極当然な話ではあります
コーディング規約があっても、それに従ってないコードがしれっとmasterブランチのコードに紛れ込んでて
「お前らはホンマ……そういうとこやぞ」って思う現場もありますね
好き勝手思うように書いてみて
後で読み返して、読み辛いわってなって
じゃあ今回はこう書いてみよう
百聞は一見に如かずといいますし
人間は皆等しく愚かなので経験に従えば良いと思います
#27
#28
総合スコア45
投稿2024/12/02 23:26
個人開発なら好きにしていいと思います。個人開発であれば、今のコードを改修する際に分かりづらいと感じても、被害を受けるのは将来の自分だけなので。
したがって、チーム開発という前提で話します。
ruby
1if Dir.exist?("/hoge") 2else 3 return "ディレクトリが存在しません" 4end
この形で最初に実装していると、今後のアップデートや仕様変更で、ディレクトリがある場合の処理が if 節の中に継ぎ足されていくことがあり得ます。特に、この部分を次に触るのがガード節のパターンを知らないレベルのジュニアであれば尚更です。
そうすると、
ruby
1if Dir.exist?("/hoge") 2 // ディレクトリがある場合のすごく長い処理 3else 4 return "ディレクトリが存在しません" 5end 6// ディレクトリがある場合の処理は本当はこっちに書いてほしい(けどそうならない可能性が上がる)
となる可能性があり、この形式だと if と else の位置が離れすぎることによって、else がどんな条件の if に対応するのか確認しづらくなり、可読性が下がります。
一方で、初手で
ruby
1if !Dir.exist?("/hoge") 2 return "ディレクトリが存在しません" 3end
と書いておいた場合、他の誰かや、未来の自分がディレクトリが存在する場合の処理をつけ足す場合、素直に
ruby
1if !Dir.exist?("/hoge") 2 return "ディレクトリが存在しません" 3end 4// ディレクトリがある場合の(長い)処理
と書ける可能性が上がると思いますし、
「ガード節」のパターンを知らない人が万が一 else 節を付け足したとしても、
ruby
1if !Dir.exist?("/hoge") 2 return "ディレクトリが存在しません" 3else 4 // ディレクトリがある場合の(長い)処理 5end
という形になって、エラー系の打ち切り処理はこれ以上長くなることが考えづらいですから、if と else の位置が離れすぎることによって可読性が下がることを予防する一定の効果があります。
もし、「ガード節」パターンのことをご存知でなければ、このキーワードで検索してみてください。
最後に理屈的な話をします。
現代のソフトウェア開発では、自分の書いたコードが「最終版」になる分野はほとんどないはずです。なので、「今自分が書いた処理は将来誰かによって必ず書き換えられる」ということを前提にコーディングする方が、継続開発の全体からするとスムーズな場合が多いのです。
「将来書き換える誰か」は必ずしも他人ではなく、「半年後の自分」や「5年後の自分」かもしれませんが、少なくとも僕は半年前に仕事で書いたコードの経緯を他に手掛かりなしで完全に思い出せないですし、5年前の自分なんて何考えてるかわからん、もはや別人だと思います。
なので、「次にここを触るのはエンジニアデビューしたばかりの素人だ。それでも分かるように。」という意識を前提にコーディングする。その考え方のなるべく最大公約数的な部分を具体的に書いたのがコーディング規約だと思います。
コーディング規約に定めのない書き方については、各エンジニアの良心によってコードの品質を担保する必要が出てきてしまいます。
「次にコードの付け足しがされるときどうなりそうか」をなるべく考えると、今回のようなパターンは2つ目か3つ目のような書き方が有利といえるはずです。
#29
総合スコア11996
投稿2024/12/03 01:18
編集2024/12/03 01:27（素人意見です！）
件のコードが早期returnなのであれば，当然ながらその後ろ側には「ディレクトリが存在する場合の処理」が何かしら書かれているわけで，修正作業者が「ガード節」なんて言葉を知っていようがいまいが，「既存のコードを読んでから修正する（修正方法を考える/決める）」という当たり前のことをする限り，唐突に意味不明な形のコード修正をするなんて事態にはならないんじゃないかと想像するけど，どうなんだろう？
（既存の処理と新規追加する処理との間での順序関係とか，考えないわけにはいかないだろうし）
そもそも，分岐の書き方なんて修正の際に（その時々での見やすいと思われる形に）変更され得るのではないのだろうか．
例えば，分岐が２パターンだからifで書いてたところが分岐数が増えたならば異なる書き方の実装に変えるかもしれないし，２パターンのままであっても両パターンのコード量が逆転するのであれば見た目の順序を逆転させるかもしれない．
（何なら，将来に修正作業にあたる者は「宗教的に早期returnは絶対に認めないぞ！」という思想の持ち主かもしれない！？）
個人的には，そんな細かいところで将来の未知の修正に備えてどうのこうの…とか考えない（し，未知すぎて考えられない）かなぁ．
#30
総合スコア20
投稿2024/12/03 01:35
今更ですが、私目線でアドバイスさせてください。
同じ動作を得るとしても、例のようにコーディング＝書き方は複数ありますよね。
コードレビューの際、「なぜそう書いた？」と質問された場合、その正当な理由を答えられるようにコードの一行一行に考え＝思想を込めなさいと後輩には伝えています。
それなりの年月をプログラミングや不具合対応などに費やしてきた方々なら、他者のコードを見てなんとなくその人の考え方や意図を汲み取ることができるものです。
（勿論、規約があれば最終的には規約に従ってください）
ちなみに多くの方々が言われているように否定は捉えにくいので私も以下は用います。
vb.NET
1If Dir.Exist("/hoge") Then 2 'なにもしない 3Else 4 Return "ディレクトリが存在しません" 5End If
#31
総合スコア45
投稿2024/12/03 01:36
もっともですし、そんな頓珍漢な修正を上げてくる人のほうがコードレビューで指摘されるべきだとは思います。
でも、世の中は既存のコードをちゃんと読んで意図を汲み取ろうとしてくれる人や、その技量のある人ばかりではないのです。。。
既存のコードを読んでから修正する（修正方法を考える/決める）」という当たり前のことをする限り，
これができない人がいっぱいいるのです。
そもそも，分岐の書き方なんて修正の際に（その時々での見やすいと思われる形に）変更され得るのではないのだろうか．
それもそうですが、早期 return を前提にすれば、2つ目の書き方の場合は else 節を外して中身を外に出すだけで済みます。
他の分岐を加えるにしてもネストレベルがかさみにくいですし、差分も見づらくなりにくいと思います。
個人的には，そんな細かいところで将来の未知の修正に備えてどうのこうの…とか考えない（し，未知すぎて考えられない）かなぁ．
あらゆる可能性に対して絶対やれって話ならきついですが、今回の早期returnのような典型パターンに関しては、僕より前の人たちにも同じことを言ってる人がいっぱいいる話なので、ベストプラクティス/アンチパターンも色々と出回ってますし、どの形式をチームでの規約として採用するかを決めてもいい部分だと思います。
#32
総合スコア34
投稿2024/12/03 04:16
どの書き方が正しいかについては正解はないと思います。
チーム開発前提で話をさせていただくと、チームで合意出来るかどうかだと思います（納得出来るかは別）
コードレビューについてはレビューア、レビューイお互いに敬意を持って取り組むべきかと思います。
私のチームではレビューアについては指摘内容の意図を必ず書きルールが決まっている場合は、ルールがあるのでこう書いて欲しいですというような言い回しで命令口調な指摘は禁止しております。
ルールについても、異論があればチームの合意の上で、ルールを変えることを推奨しています。
また、クレーマーじみた指摘はスルーもおすすめできません。
恐らく開発プロセスにコードレビューが組み込まれているのかと思いますが、指摘してもスルーされるとレビューアは不快に感じ、レビューの承認がされなかったり、後回しにされたりする可能性があり、そうなると割り振られたタスクが完了せず、投稿者さん自身に不利益が出るかと思います。
仕事に感情を持ち込むなよと思いますが、人がレビューをする以上仕方ないことだと思います。
私自身も色々な現場を経験しましたが、クレーマーの様な人はどの現場でもいました。
その際は、この人はそうゆう言い方しか出来ないんだなぁと割り切っていました。
#33
総合スコア348
投稿2024/12/03 04:56
確かにパターン1のやり方はその理由のほかにも、
Pythonではpassが必要、Rubyでは後置IFなどの自然言語に近い書き方が好まれる、そもそも1の書き方は一般的ではない、という観点からわかりづらいことがあるかもしれないですね。
(自分はRubyを触ったことがないです)
ただ、ご指摘のように長いコードが入った際に見づらいという話は長いコード自体が見づらいという話であって、早期リターンなどの回避方法もあるとは思いますが、文脈として関係がない長いコードはprivate methodに退避して、それを呼び出す形にすれば、コード改修がしやすくなるかと存じます。
ifの書き方の問題で、好きに改変していいのであれば、どちらにせよ以下のようなコードは変数の依存関係が分かりづらく、コード改修が困難になる恐れがあります。
// (長い)処理1 if !Dir.exist?("/hoge") return "ディレクトリが存在しません" end // ディレクトリがある場合の(長い)処理2
改善案1
// (長い)処理1を呼び出す encapsulatedMethods1() if !Dir.exist?("/hoge") return "ディレクトリが存在しません" end // ディレクトリがある場合の(長い)処理2を呼び出す encapsulatedMethods2()
共通化するなら自分はパターン1の方法を推しますが、そうでなく個人がある程度自由にやるならパターン1のメリットは一貫性と人間の認知の問題でしかないので、2, 3の方法が良いと思います。
特に知見の深くない人は1のパターンは受け入れづらいかとも思うので。
また、運用上の理由から否定条件のほうが直感的な場合もあります。
#34
総合スコア63
投稿2024/12/03 06:29
このレベルなら別にどっちでもいいやと思いますが、
ものによってはアルゴリズムまずかったり、バグがひそんでたりするので、
コードレビューの良し悪しはケースバイケースです
コードレビューを行わないならば、単体テスト等でソフトウェアの品質を補填するしかないのですが、
そこまでマメなテストを行っているかどうかもありますし、
基本テストまで行って問題が発覚すると、手戻り工数が必要となります
工数削減のためにも、コードレビューはあった方がよいかと思います
#35
総合スコア1467
投稿2024/12/03 10:45
ご質問の例に限らず、個人の自由を認めると、その人しか読めないコードが生産されちゃうリスクがありますよね。
そういったコードにバグがある場合は、当人が直してくれるならまだいいんですが、既に辞めちゃったり、異動で別の人が引き継いだ場合などで、苦労することになります。
そういったリスクを無くすにはどうしたら良いでしょうか。
私も自由に書きたい方なんですが、レビュー以外の良い対策が分からないんですよね。。。
なので、郷に入ってはなんとやらで、つまらないレビューを受け入れてます。
#36
総合スコア3
投稿2024/12/06 14:34
チームの趨勢に従うが吉．レビューでも雑談時でも随時でも「このスタイルは嫌」と言って，自分の意見を言うのは，大事．ルールに固執するとバグり易いこともあるので，’改善’は必須．周りの意見を聞こう．受け答えしてる中で，使える奴とか，いつか追い出してやる奴とかの見極めも出来るしね．
んで，既出だけど，半年後の自分は他人と思って書くのは大切．現役時代は，午前3時の自分が理解できるように書いてた．チームのルールはそういうのも含んだ知恵の宝庫．何故を考えると勉強になる．
#37
総合スコア58
投稿2024/12/10 05:57
皆さん書かれていますが、コードの保守性を担保するにはある程度ルール化する必要があると思います。
なので、チーム開発においては自由より（良いコードにするための）ルールは必要だと思います！
一方でそれがread.meに記載されているかや、そこまで差異を感じない場合は、今後の効率なども考慮してチームで方針を決めていったほうがいいと思います。
そうすることで新規参画のキャッチアップもできますし、レビューの効率化にも繋がります。
linterを入れるのも大切ですね
新規参画してきた人が違和感を覚えるルールは適切ではないので、そういったツールを用いて一般化するのは大切だと思います
長々書きましたが、そういったことを乗り越えるとチーム開発の楽しさを感じれると思うのでがんばりましょー
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。