TOP > IT・テクノロジー > やめた方が良いコーディング・設計、アンチパターン - Qiita

やめた方が良いコーディング・設計、アンチパターン - Qiita

115コメント 登録日時:2019-01-20 09:14 | Qiitaキャッシュ

# 目的レビュー時にアーとなる、お話にならない設計をまとめていきたい。自分のためというより、話が通じないレベルの設計を言語化したい。プログラミング言語関係なく、WEBサービスを作る時の、コーディング・設計の基本アンチパターン......

Twitterのコメント(115)

もともと評価良くない人がそういうコードを書く分には「まあしゃあない」って感じやねんけど、まわりの評価が良いけどコードがえげつないってパターンが一番辛いんよな。
「(平のJavaScript)ソース内に<div>要素などを書き、HTMLに挿入して組み立てる」の項目にもやもやしたものを感じる.../
Swiftでは一部賛同できないところや分からないところがあるけど、全ソフトウェアエンジニアに読んでほしい
—-
最近思うことがある記事だった。
言い訳なく精進します。
例外処理が適当だったため問題につながったケースこの前体験したわ /
コード書いててうまくいかない時にやってたこと沢山ありました。
反省します。
駆け出しエンジニアさんが「駆け出し」を卒業する為に目を通しておきたい記事ですね…😌
気をつけたいっすなぁ、、、
流石にやらんやろみたいなのも沢山あるが、反面教師にしよう、、
怖い。「クソコード耐性の高いベテランプログラマ」にならないように頑張りたいです・・・。一刻も早くテスト前提のコードを書く能力を身につけたい。
一番厄介なのは罪を罪と認識できず何年も罪を量産している「クソコード耐性の高いベテランプログラマ」である。
やめた方が良いコーディング・設計、アンチパターン
クソコード耐性が強いとクソコードを生成しやすい… 気をつけねば
途中まで読んだ。結構読み応えあるボリュームなのであとでまた。 /
最近の言語知らないから勉強になる /
インデントとか改行を

レビューするチームへ

アドバイスしたい

エンジニアなんだから
自動化しよ

① gitでコミットする時のフックで自動フォーマットする

② エディタをVScodeで共通化して設定もソースコード管理する
あー確かにと思える内容が沢山書いてる...
超大作だ。
これも人気があって記事自体が基本的な内容だけどとてもいい内容なのですが、いかんせんコメント欄が(以下略)
やはりQiitaにはコメントのミュート機能が欲しいぞ。
過度に抽象化して失敗したわかる() ::
定期的に読みたい。
こういうの読むと自分のコーディングがいかほどのヤバさか不安になる。
ニュース&utm_campaign=fc7b63803d-Qiita_newsletter_346_01_30_2019&utm_medium=email&utm_term=0_e44feaa081-fc7b63803d-34486157
いくつかの問題に関してはテストコードをきちんと書けば改善可能なのでレビューする条件に「テストコードがパスしている」を追加してほしいな。 / “
うんうん、よくわかる。罪深いコードを見るとなんとも言えない気持ちになるよなー。
データ構造に合った処理を書くべきであって、再帰が悪みたいな風潮はどうにかならないかな。

不要な再帰処理
よく読もう。忘れがちなことって多いから
この記事を読んでいて共感しました。
本当にソースコピペのみのプロジェクトが実在するんですよ。
僕は今、苦しめられている。
なかなか、考えるところだ!
「私の経験上、循環的複雑度が50を超えると読めなくなるしバグが増える。100を超えると仕様自体も分からなくなり、1からの作り直しも難しくなる」ここすき☺️
あとで熟読しよう。
定期的にこの記事見てみよう。
みんなよんでほしい
リリースの項目は特に要注意!

短期的にはかかる工数は少なくても、長期的には工数は数十倍に膨れ上がる!
ただし、スタートアップでプロダクトの検証のために早くリリースしたい場合はちょっと状況が変わるかなという感じ。
少なくともコピペ野郎は絶対に読むべし。
リリース時期を言い訳にして、問題のあるコード・設計力の低いコードをマージしようとする

ごめんなさいとしか言えない.... //
やめた方が良いコーディング・設計、アンチパターン - Qiita
レビュー時にアーとなる

レビュアー
クソコード耐性低くしなきゃですね。
(Scala) 暗黙の型変換 implicit def を乱用する
> 発狂するのでやめて。現代ではもう使わないことが推奨されています。
普通に書いて下さい。普通に関数を呼んで下さい。暗黙の型変換を使うのはやめて下さい。
なるべく気をつけよう
肝に命じた
名前の付け方とかね
数字とか名前と違う内容とか
ほんまにやばい奴は急にキレだすからやめてほしいよね!
反省していきます。
本当に本当にいい記事だ
明日は我が身なので普段からちゃんと気をつけような
とてもいい記事だった
笑えないのでアレ
世の中には二種類の人間がいる。クソコード耐性が高い人と低い人だ。「クソコード耐性が高い人」はクソコードを生成しやすい。なぜならそれをクソコードを思わないからである。
読んでて笑いながら悲しくなってきてる
これ、OJTにだいぶ叩き込まれたなあ。入社時に配属されたとこはいいチームだったなぁ。
7割ぐらいは意識できてるかな。残りはまだわかってない部分もある。今後意識していこう。
比較的クソコード耐性低いタイプなので見つけ次第全部直しちゃう。
「保守する人の気持ち、後に改修する人の気持ちを考えてほしい。」
まずは自分が、どれだけ汚いコードを書いているかを自覚せねば!
現場で実際にあった事例が割とある。。
既に動いている場合、どうリーダーに改善を相談すべきか毎回悩む
自分もクソ成果物を生産しないように極力注意しないと...
やめた方がよいコード設計 |
たしかに「クソコード耐性が高い人」は存在する。Qiitaの記事で共感するなんて久々だ。 -
クソコード耐性が高い人が問題と言うのはその通りだなぁ。制御系出身だと、この程度のネストはなんとも思わない人多い気がするので、こういう話怖いんだよなぁ。「複雑なネスト」って少しだけ主観的だから、みんな自信持てなくてクソコードですみません、とか萎縮してたりなー
なんでJavaのジェネリクスが型不定可能機能なんだ? とか引っかかるとこもあるが、ほとんど同意できる。ただ、良く知っているとこは甘く、そうでないところは辛いみたいなとこはおもしろい。
いろいろ思うところはあるけどクソコード耐性は高いほうがいいんじゃないかな? /
イキってQiitaでポエム書いてコメントで突っ込まれるパターンだ /
結構共感した。
他にサービス初期からマイクロサービス化するのはオーバエンジニアリングだと思う。
サービス初期はそもそもビジネスロジック、もしくはビジネスモデルさえも固まってないから、マイクロサービス化はむしろ足を引っ張る可能性が高い。
長めだけどわからないワードがすごく多いけど読むべき。
前の会社では常識的に行われている部分もあり、また「これでいけるようになったし、使えばいいじゃん」的な考えを持ちかけていたので反省。
なんかいろいろごめんなさい。
パターンの概説に価値判断が入っていると訳が分からなくなる。 /
"罪である。"がテンポ良くてすき
『例外を投げずにそのまま別のデフォルトデータを入れて返せばいい。いったいなぜ例外を投げて、使用側という上の階層で処理する必要があるのか?』そこはnullableではないのかなあ
「IntやBoolなどを使わず、Stringで全て表現しようとする」
笑ってしまった笑
jsやphpなど動的型付け言語であっても型の意識は大事。というか、そもそも何のために型があるのか。
というお話で。
なんかレベルがバラバラで微妙かな・・・。
理想論が混じっている
やめた方が良いコード記述・設計 () 耳の痛い話、自分も気をつけないと
まあ大体理解/納得できる。保守・改修の際にそのコードを読むのは君じゃない、っていうのは意識すべき。言い方の問題はあるだろうけど直さない奴はとことん直さないからなあ。 / - Q…”
全部のアンチパターンに出会ったことあります:
概ね同意できるがいくつか疑問符が付く感じだった。まあ過去の経験や環境によって感覚が違うことはあり得る。Web で再帰が必要ないと言い切っちゃうのは、DOM 辿って何かするとか書いた事無いのかな、とか。 / “やめた方が良いコーデ…”
多少口調が強いし、めちゃめちゃ漢字多いけど言っていることはかなり基本的なことでとても勉強になる
新人を良くしたいという気持ちはあるけど伝え方が少しきついんだろうなとさっきの記事交えて思う

>>
マイクロサービスAでinsertしたデータを、マイクロサービスBでupdateする
だ、だめなの…?

やめた方が良いコーディング・設計、アンチパターン
3年前に書いた分岐アンチパターンという記事にいいねがたくさんついていて、なんでや!?って思ったけど、下記で紹介されていたからっぽい。紹介されるくらいまとめられていてよかった😊
記事開いた瞬間の期待値より共感度が高かった
大半は納得。マイクロサービスはやってないけど、それはそうだよねと思う。
ファイル最後の改行は意識してなかった…VSで作成したファイルも確かに改行が入ってる。
今メンテしているコードを最初に書いた人に読んでほしい
序盤の序盤「ファイルの最後で改行しない」でアウトになってしまった私。気を付けよう。
>
それな!それだよ!いつでも誰でも簡単に調達できるお手軽な言い訳 “リリース時期を言い訳にして、問題のあるコード・設計力の低いコードをマージしようとする” / 『やめた方が良いコーディング・設計、アンチパターン』Qiita
私のクソコード耐性が低いのは、複雑なコードを読解する処理能力や、それを一時記憶するための脳のメモリー不足が原因だと思ってる。
プライベートは好きにしてもらっていいけど、仕事はちゃんと書いてほしいですよね。
双方の落とし所程度は
容赦なく正しいことを言って人を傷つけてしまうタイプかな /
わかっていても読んで肝に命じておいた方がよいこと
まず喧嘩口調をやめたほうがいい
“レビュー時に嫌な思いになるのかを「クソコード耐性が高い人」は察して”それができんからクソコードを書く、ということを耐性が低い人も察するべき。 /
マジでそう思う。
あと、文法エラーが残っているままリポジトリにコミットする奴とか、テストせずに本番環境にリリースする開発チームとかは、この記事の範疇ではないけど、存在する。
グサグサ刺さる🔪
明らかにint型だと予想できるデータが文字列の数値だった時のだるさ
あー感がすごくよくわかる。そんなプルリクが上がってきたら、教育とか、仕事の任せ方、成果物の合意について、瑕疵があったと受け止めるのが建設的 /
大罪言いすぎて怖い
「○○しない」のはよくない、という話になっていてどうしてほしいのか何度か戸惑った。Scalaの型パラメータ使うなの話がよくわからなかった。 /
”WEBサービスに再帰処理が必要な理由が全く理解できない”
そうだね
これがお客さんの見えるところに張り出されてたら、俺はその会社に発注するのは辞めるな・・・。
うっ……頭が……
Githubで毎回ファイル最後に改行コードが表示されるのがウザい
わかりすぎる。
アンチパターンの方が推奨パターンより刺さりやすいのはわかるが、やめた方がいいアンチパターンの羅列は二重否定で分かりにくくなるというアンチパターン。 /
当たり前のことを、当たり前にできるって素敵なことですよね💫
>JavaScriptソース内に<div>要素などを書き、HTMLに挿入して組み立てる

JSXの否定に近い気がして笑っている
はてぶにあがってた。これは良いね

【 - Qiita】
例外処理をロジックとして扱ってるところは一箇所あるので明日治そう
わかる。インデントやファイルの最後で改行の件はcommit前にdiff見れば気づくはずで、キレイなdiffになっているか確認するクセをつけると良い。 /
"ローカルで開発できない"
/
「不要な再帰処理は大罪である。」んー //
2~3個おれもやっててすみません!わるいのはわかってるんだけどね。。
いい内容だと思うけど、goのinterface{} とScala java のジェネリクスが同じ扱いなのは、ん?という感じ。 /
再代入の説明は微妙。再代入はするしかないケースもある。どう言う時再代入がダメかを示さないと、結局再代入使うなと言うのは押し売りに過ぎないと思われて再代入されてしまうと思うよ。
又吉イエス的表現(笑)にしたくなるのも頷ける良記事。「IntやBoolなどを使わず、Stringで全て表現しようとする」とか… 「JavaScriptソース内に<div>要素などを書き、HTMLに挿入して組み立てる」は本当にやめてほしい
よいまとめ。状況/スタイル/ポリシーによらない絶対悪。プロと言えないレベル。こういうのをなにかの手段であぶりだせれば良いのに /
以上

記事本文: やめた方が良いコーディング・設計、アンチパターン - Qiita