Noといえることの大事さ | プログラマが知るべき97のこと
Noといえることの大事さ著者: 宮川 達彦 自分でつくったソフトウェアを公開し、利用してもらうことはとてもうれしいものです。利用しているユーザからのフィードバックに耳を傾けることはソフトウェアをよりよいものにしていくためにもとても重要なことです。 一方、ソフトウェアのデザインにおける究極の美しさはシンプルさにあると言われます。有名なUNIX哲学では”Write program that do one thing and do it well”(1つのことをうまくやるプログラムを書け)といわれるように、複数の機能をつめ込まず、単一の機能をもったプログラムを組み合わせて使うことが美とされます。 ここにギャップが生じます。ソフトウェアが人気になり、ユーザが増えるにつれ、「あの機能を追加してくれ」「ここの動作をオプションでOn/Offできるようにしてくれ」という要望が出てきます。実際にそうした機能
Cruft - Wikipedia
This article is about a computing term. For other uses, see Cruft (disambiguation). Cruft is a jargon word for anything that is left over, redundant and getting in the way. It is used particularly for defective, superseded, useless, superfluous, or dysfunctional elements in computer software. History[edit] Harvard Cruft Laboratory Around 1958, the term was used in the sense of "garbage" by student
ハードコーディング - Wikipedia
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2011年7月） 独自研究が含まれているおそれがあります。（2007年4月） 出典検索?: "ハードコーディング" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL ハードコーディング（英語: hard coding）とは、本来プログラム中に記述すべきでないリソース（エラーメッセージなど）を、直接ソースコード中に埋め込むことである。これらは本来、外部ソースから取得するか、実行時に生成するべきものであり、これをソフトコーディング（英語: soft coding）という。 ハードコーディングされたデータを変更するには、ソースコードを編集して実行可能フ
カーゴ・カルト・プログラミング - Wikipedia
カーゴ・カルト・プログラミング（英: Cargo cult programming）とは、コンピュータープログラミングにおいて、実際の目的には必要のないコードやプログラム構造が儀式的に含められているという状態で特徴づけられる悪習である。カーゴ・カルト・プログラミングは、プログラマが、自身が解決しようとしている課題やバグ、明らかな解決策を理解していないことを示す兆候である（ショットガン・デバッギング（英語版）やブードゥー・プログラミング（英語版）も参照）[1]。 カーゴ・カルト・プログラミングは、目の前の問題について経験の浅いプログラマが、他の場所にあるプログラムコードを、その仕組みや、それが本当に必要かどうかを理解することなしに、別の場所にコピーするときに生じうる。 また、他の場所で見つけてきた設計手法やコーディングスタイルを、それが生まれた背景理由などを理解しないまま盲目的に適用した結果
ビジーウェイト - Wikipedia
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2013年12月） 独自研究が含まれているおそれがあります。（2021年7月） 出典検索?: "ビジーウェイト" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL ビジーウェイト（英: busy waiting）とは、プロセスが条件が成り立つかどうかを定期的にチェックする手法の一種。例えば、キーボードからの入力を待ったり、ロックが獲得できるのを待ったりするのに使われる。ある時間だけ遅延させて何かを実行するのに使うこともある。 素朴な実装手法とその問題点[編集] この節は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事
Tester-driven development - Wikipedia
This article relies largely or entirely on a single source. Relevant discussion may be found on the talk page. Please help improve this article by introducing citations to additional sources. Find sources: "Tester-driven development" – news · newspapers · books · scholar · JSTOR (March 2024) In software engineering, tester-driven development, or bug-driven development, is an anti-pattern where the
Feature creep - Wikipedia
Feature creep is the excessive ongoing expansion or addition of new features in a product,[1] especially in computer software, video games (where it should not be confused with Power creep) and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design. The definition of what
ヴィルトの法則 - Wikipedia
ヴィルトの法則（ヴィルトのほうそく、英: Wirth's law）は、ニクラウス・ヴィルトによる1995年に発表された記事A Plea for Lean Softwareにおける議論に由来する警句で、コンピュータのプログラム（ソフトウェア）とハードウェアの成長（growth）と性能のバランスに関して「ソフトウェアは、ハードウェアが高速化するより急速に低速化する」とするものである[1][2]。 ヴィルトはこの言葉をOberonについての彼の著書 (1991) の序文で Martin Reiser が書いた「その希望とは、ハードウェアの進歩がソフトウェアの病気を全て癒すだろうことである。しかし注意深く見れば、ソフトウェアの巨大化と緩慢化はハードウェアの進歩を超えていると気付く」という文章が元だとしている[3]。このような傾向は1987年ごろには早くも明らかになりつつあり、同様のことを先に言及し
ソフトウェアの肥大化 - Wikipedia
ソフトウェアの肥大化（ソフトウェアのひだいか、英：software bloat）とは、コンピュータソフトウェア製品が新しいものほど大きくなり、システムリソース（ディスクスペース、CPU能力、メモリ量）をより多く使うようになる傾向をいう。そのようなソフトウェアをブロートウェア（英：bloatware）とも呼ぶ（英語では elephantware という呼称もある[1]）。また、ブロートウェアという用語は、パーソナルコンピュータにプリインストールされている多数のソフトウェア（その多くはデモや試用版）を指すこともある。 背景[編集] 1970年代ごろまで、ソフトウェア開発は記憶容量の厳しい制限との戦いでもあった。1バイトでも大きさを削り、1クロックでも処理を削って、プログラムが使用可能なリソースの中でより多くのことができるようにすることが重要だった。 この状況は現在では逆転している。リソースの単
)
マジックナンバー (プログラム) - Wikipedia
プログラムにおけるマジックナンバー（英: magic number、魔法の数字）とは、何らかの識別子もしくは定数として用いられる、プログラムのソースコード中に書かれた具体的な数値である。そのプログラムを書いた時点では製作者は数値の意図を把握しているが、他のプログラマーまたは製作者本人がマジックナンバーの意図を忘れたときに閲覧すると「この数字の意味はわからないが、とにかくプログラムは正しく動く。まるで魔法の数字だ」という皮肉を含む。 概要[編集] 次のような理由で、マジックナンバーはプログラム中に含まれないことが好ましいとされる。 その数値の持つ意味がわかりづらい。 数値を変更する場合に、複数の箇所を変更しなければならない可能性がある。 例1 たとえば、消費税が8%の時に、税込価格 (tax-included price) を求める以下のようなソースコードをC言語で書いたとする。 これは、p
Circle–ellipse problem - Wikipedia
The circle–ellipse problem in software development (sometimes called the square–rectangle problem) illustrates several pitfalls which can arise when using subtype polymorphism in object modelling. The issues are most commonly encountered when using object-oriented programming (OOP). By definition, this problem is a violation of the Liskov substitution principle, one of the SOLID principles. The pr
アンチパターン - Wikipedia
ソフトウェア開発におけるアンチパターン (英: anti-pattern) とは、必ず否定的な結果に導く、しかも一般的に良く見られる開発方式を記述する文献形式を言う[1]。その内容は、基本的には、否定的な開発方式の一般的な形、主原因、症状、重症化した時の結果、そしてその対策の記述からなる[2]。 デザインパターンを補完・拡張する関係にあるもので、多くの開発者が繰り返すソフトウェア開発の錯誤を明確に定義することにより、開発や導入を阻害する一般的で再発性の高い障害要因の検知と克服を支援することが目的である[3][4]。 ある問題に対する、不適切な解決策を分類したものをアンチパターンと言う[5][6]。 アンチパターンという呼び方は、アンドリュー・ケーニッヒ（英語版）が1995年に作り出したもので[7]、後に書籍The patterns handbook[8]で再掲された。 ギャング・オブ・フォ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Coding by exception - Wikipedia
Database-as-IPC - Wikipedia
Error hiding - Wikipedia
Feature interaction problem - Wikipedia)
Lava flow (programming) - Wikipedia
Magic string - Wikipedia
Creeping elegance - Wikipedia
Category:Anti-patterns - Wikipedia