君の継承の使い方は間違っている - Qiita
オブジェクト指向はプログラミングの基本です。そして、継承はオブジェクト指向の基本的な操作ですから、プログラマーは呼吸をするように継承をできなくてはならないはずです1。 しかしその割に、ダメな継承の使い方をして、スパゲッティコードになるのを実務でしばしば見かけます。 これは、継承の「良い使い方」はデザインパターンとしてリストアップされているのに、「悪い使い方」はまとまっていないせいかもしれません。そこで、自分だったらコードレビューで をつけるような「悪い継承の例」を挙げてみました2。 （この記事は個人的な経験によるもので、理論的な裏付けがあるものではありません。ご意見やオススメ本があれば、コメントをお願いします。また、この記事は随時細かい表現の修正をしています。） TL;DR 継承を使ってはならない Mix-inを使ってはならない super は不吉な兆候 例外条項 インターフェースの実装（
「美しい」にモヤったら「認知負荷が小さい」と言いかえよう - Qiita
プログラミング業界では定期的に「美しいコード」が話題になり、そのたびに炎上が発生します: コードの美しさは実務には関係ない 美しくても動かなければ意味がない 「美しさ」は主観的で、プログラマーの自己満足に過ぎない 汚くたって俺は読める。読めないお前が悪い などなど・・・ 私もコードは美しくあれかしとは思いつつも、 「確かに『美しい』って曖昧だよな」とか、 「どうして = の位置がそろっているのを『美しい』というのだろう？『整然としている』なら分かるけど」とか、 「『可読性が高い』でもいいけど、今一つ『美しい』との違いが判らん」 「そもそも、どうして美しいコードの方が読みやすいと言えるんだ？」 と、割り切れなく思っていました。 ところで、最近の心理学・脳科学ではこんな説があるようです（本当かどうかは知らないよ）： 中野：（中略）美人の顔って対称性が高いって言われますよね。あれは別に体が健康だ
レビュー前に直して欲しい日本語の問題点８つ - Qiita
私はウンザリしています。 「○○対応」は曖昧なのでやめてください。「○○を修正した」の方が直接的です。 こんな指摘を新人が入ってくるたびにコードレビューやドキュメントレビューで繰り返しています。どうも、プログラマー（と言うか理系？）には独特の言語文化があり、みんな同じような分かりにくい表現をしてしまうようです。 「レビューを依頼する前にこれを読んどいて！」と言える記事なり本なりがあれば良かったのですが、良いものが見つけられなかった（ご存知なら教えてください）ので、とりあえずレビューでよく指摘する日本語の文章の問題点や変な表現ポイントを列挙しました。 なお「コメントは必要十分な量を書く」「チケット番号やWikiのURLを書く」といった、良く知られた・日本語に限定されない話題は省略しています。 （※コメント欄などの指摘を受け「補足」を追加） （※タイトル変更。「コードレビュー前に直して欲しい日
レガシープロジェクトを引き継いだ時、最初にするべき７つのこと - Qiita
営業一課で使っている PHPアプリを保守してくれないかな？ ○○さんが１人で作ってメンテしてたやつなんだけど 皆さんは上司からこんな仕事を振られたことはないでしょうか？私は過去に何度か経験した1のですが、こういった仕事はなぜか： 正確な仕様を知っている人はいない（知ってた人は辞めた） テスト計画書・デプロイ手順書・仕様書といったドキュメントは無い ソースコードはもちろんスパゲッティ でも、業務ではガッツリ使われているので廃止できない というレガシープロジェクトばかりでした。この記事では、レガシープロジェクトを引き継いでしまった時に、最初に何をするべきか書いていきたいと思います。 なお、ここで最悪なのは「とりあえず、緊急の不具合から直してしまおう」と、いきなりコードの修正にかかることです。 ※おことわり： この記事では「遵法的な職場の」「PHPやRailsで書かれた」「社員25人が使う」「業
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
