大人数でプログラミングする時に気をつけていること（Java） | DevelopersIO

1人もしくは（すごく能力の高い人だけの）少人数での開発と、大人数での開発ではプログラミングに対して気にするべきポイントに差があるような気がしています。 ここでいう大人数の開発とは、「プログラミングがどれくらいできるのか、自分が把握していない人がコードを書く可能性がある環境」を想定しています。 ここに挙げているポイントは「規模感に関わらず常に気にすべきこと」も含まれていますが、大人数になると特に問題が大きくなりそうなものをピックアップしてみました。 また、レビューに対する工数をすごくたくさんかけられる環境など、開発現場によっては当てはまらないものもいくつか含まれていますが、本記事ではあまり気にせず思いついたものを羅列しています。 本記事では基本的に「レビューでつぶす」という解決方法はあまり考慮していません。粒度によりますが、本当に厳密なレビューフローがないと、どこかのタイミングで読みづらいコ

[cl-gaku]

“人はすでに書いてあるコードを真似する”リファクタリング予定のヤバめの実装が知らん間にコピペで増える

[gabari]

「仕様を書いていないメソッドを見た人が、コメントを書かなくても良い文化である、と判断した上で読むのが辛いコードを書く可能性があるからです」これな。レビューではじくのつらい

[tpircs]

getUserByIdのほうが良い気がするなぁ。あと、最初の話はファーストコレクションは利用しないっていうオブジェクト指向トレーニングに書いてあるやつの一部なので、読んでないなら一読しておくといいと思う。

[Lumin]

とてもよい

[yoshikidz]

ぼくもこんな感じだなー、“人はすでに書いてあるコードを真似する”を担保しようとするレベルは初心者も想定内だろうし意図した通りの真似をしてもらうって考え方でやってるかな。

[mak_in]

C#でも似たようなこと気を付けてる。VBでは特にコピペが捗るので、コメントを滅茶苦茶丁寧に入れてwhy/whatを分かるようにしてる。

[versatile]

？・・・全部 private にして @Data と @Builder つければいいじゃんってそういう話じゃないのか

[diveintounlimit]

“人はすでに書いてあるコードを真似する” ”仕様を書いていないメソッドを見た人が、コメントを書かなくても良い文化である、と判断した上で読むのが辛いコードを書く可能性がある”色々と分かりみが深い

[hdkINO33]

“個人的に最近見た範囲では、テストのコードに関して特に巨大なユーティリティ的な継承元クラスが作られやすいような気がします。”

[GEROMAX]

リソースの問題があるからなかなか難しいけど、一番良いのはアホを見抜いてコード書かせないことだったりする。

[aox]

パソコンの前に行列ができそうですね

[odakaho]

getXxxの中に重い処理を書くやつは滅んで欲しい。「最後にreturnしてるからgetでしょ」じゃねーよ！

[ksugimori]

「責務を明示する」これ最近気をつけてる。全てのロジックを１つのクラスに書いてしまう人はかなりの割合でいるので「このクラスで何をすべきでないか」は始めに明記しておかないとカオスになる。

[mas-higa]

コード読めない人のためにコメント書いてもなぁ。仕様書は書かない文化なのかなぁ。コメントにはせめて Why を書いて欲しいなぁ。

[nutahuate]

read*,get*から始まる関数内で書き込み処理をそもそも書かないで頂きたいのですが...コメントがあっても呼び出し側のフロー見てるときには分からないよこれ...

[hdampty7]

Userとかあっちでもこっちでも使いそうなクラス名を使ってる奴みるとイラっとするせめて○○Userでしょ。

[khtokage]

よい話。こういうの、本質的に複数人で何かやるときは共通することだよね。「コードを読めば自明である」みたいな察してくんになる人が多いけど……

[wozaki]

“そのコードと似たようなコードが増えていったときに極端に複雑さが増すかどうか？ 今省略した手順が、今後増えるコードの複雑さに繋がらないか？”