私は、ジュニア (そしておそらくシニア) のソフトウェア エンジニアによって行われるよくあるエラーと不適切な仮定について調査を行っています。
最終的に修正された、最も長く保持されていた仮定は何ですか?
たとえば、整数のサイズは標準ではなく、言語とターゲットに依存すると誤解しました。ちょっと恥ずかしい言い方ですが、そんなところです。
気さくに; どのような確固たる信念を持っていましたか? また、その仮定をおよそどのくらいの期間維持しましたか? それは、アルゴリズム、言語、プログラミングの概念、テスト、またはプログラミング、プログラミング言語、またはコンピューター サイエンスに関するあらゆるものに関するものです。
長い間、私は他の誰もがすべてのプログラミング概念 (設計パターン、最新の新しい言語、計算の複雑さ、ラムダ式など) を超熟知していると思っていました。
ブログ、スタック オーバーフロー、プログラミングの本を読んでいると、すべてのプログラマーが直感的に知っているはずの事柄について、自分が後れを取っているように常に感じていました。
私は、自分の知識を、1 人の個人ではなく、多くの人々の集合的な知識と効果的に比較していることに気づきました。これは、誰にとっても非常に高いハードルです。現実世界のほとんどのプログラマーは、自分の仕事を遂行するために必要な知識のキャッシュを持っており、彼らが苦手または完全に無知な領域をいくつか持っています。
人々は自分が何を望んでいるのかを知っていました。
私は長い間、人々と話し、彼らが問題やワークフローについて説明し、それをコードに入れて自動化すると思っていました。それが起こるたびに、彼らが望んでいると思っていたものが、実際には望んでいたものではないことがわかりました.
編集：ほとんどのコメントに同意します。これは技術的な回答ではなく、質問者が求めていたものではない可能性があります。プログラミングだけに当てはまるわけではありません。それは私の最も長く保持されていた仮定でもないと確信していますが、これを行ってきた10年の短い年で私が学んだ最も印象的なことでした. それは私の純粋なナイーブだったと確信していますが、私の脳がどのように配線されているか、そしてビジネスの世界に入る前に私が持っていた教えと経験により、私は自分が答えたことをするだろうと信じるようになりました。コードとコンピュータを使って人々の問題を解決できるようになるだろうと。
この回答は、プログラマー以外が私が話していることを理解している/気にかけているというロビンの回答に似ていると思います。それは、アジャイルで反復的なインタラクティブなプロセスとしてビジネスを学ぶことです。それは、プログラミング コードの猿であることと、ソフトウェア開発者であることの違いを学ぶことです。この 2 つには違いがあり、この分野で本当に優れているとは、構文やタイピング速度だけではないということを理解することです。
編集：この回答はコミュニティウィキになり、この回答に動揺した人々をなだめ、私に担当者を与えました。
プロファイリングなしでパフォーマンスの問題がどこにあるかを知っていること
関数/メソッドからの出口点は 1 つだけにする必要があります。
非プログラマーが私が話していることを理解していること。
そのバグのないソフトウェアは可能でした。
そのプライベート メンバー変数は、クラスではなくインスタンスに対してプライベートでした。
静的タイピングはキーボードの前でじっとしていると思いました。
開発を始める前に問題を完全に理解できること。
賢い人は常に私より賢い。
私は間違いを犯したときに本当に自分を打ちのめすことができ、しばしば自虐的であると言われます. 私はかつて多くの開発者に畏敬の念を抱いていましたが、彼らはXについて私よりも多くのことを知っていたので、彼らは私よりも多くのことを知っていたと思い込んでいました。
経験を積み、より多くの人に会うにつれて、彼らは特定の主題について私よりも多くのことを知っていても、必ずしも私/あなたよりも賢いとは限らないことに気づき始めました.
この話の教訓:自分が提供できるものを過小評価してはいけません。
長い間、私は悪いプログラミングは辺境で起こったものだと思っていました..正しいことをするのが普通だと思っていました。最近、私はそれほど素朴ではありません。
できるだけ抽象化する方向に進むべきだと思いました。あまりにも多くの機能が絡み合っているため、私はこれで大打撃を受けました。
今は、物事を可能な限りシンプルに分離するようにしています。何かを抽象化するためのリファクタリングは、何かを抽象化する方法を予測するよりもはるかに簡単です。
したがって、私はそれらすべてを支配するフレームワークの開発から、仕事を成し遂げる機能のスニペットへと移行しました。次の大きなものを開発するのは自分だと素朴に思っていたときを除いて、振り返ることはありませんでした。
その女性はコンピュータープログラマーをセクシーだと思っています...
ソフトウェアの品質がより多くの売上につながること。時々そうですが、いつもではありません。
すべての言語が（ほとんど）平等に作られていること。
かなり長い間、選択した言語は、開発プロセスの難しさとプロジェクトの成功の可能性に大きな違いをもたらさないと考えていました。これは間違いなく真実ではありません。
仕事に適した言語を選択することは、他の単一プロジェクトの決定と同じくらい重要/重要です。
コメント/コードの比率が大きいことは良いことです。
コードが自己文書化されるべきであることに気付くのに少し時間がかかりました。確かに、ここにコメントがあると、コードを明確にできない場合や、何かが行われている重要な理由がある場合に役立ちます。ただし、一般的には、そのコメント時間を変数の名前変更に費やす方がよいでしょう。よりクリーンで明確になり、コメントがコードと「同期しなくなる」ことはありません。
そのプログラミングは不可能です。
冗談ではありませんが、私はいつもプログラミングを学ぶのは不可能だと思っていました。そして、コードに近づいたとき、私はそれを理解できませんでした。
それからある日、私は座って基本的な初心者向けチュートリアルを読み、そこから自分の道を歩み始めました。そして今日、私はプログラマーとして働いており、そのすべての瞬間が大好きです。
加えて、プログラミングは簡単ではないと思います。それは挑戦であり、もっと学ぶことが大好きで、プログラミングの問題を解決することほど楽しいことはありません。
「On Error Resume Next」はある種のエラー処理でした
そのプログラミング ソフトウェアには、高等数学の強力な基礎が必要です。
コーディングを始める何年も前から、良いプログラマーになるには、高度な代数、幾何学、微積分、三角関数などに精通している必要があると常に言われていました。
10年後、私は中学2年生ができなかったことを一度だけしなければなりませんでした.
その最適化 == アセンブリ言語での書き換え。
私が最初にアセンブリ (BASIC から来て) を本当に理解したとき、コードをより速く実行する唯一の方法は、アセンブリで書き直すことだと思われました。コンパイラが最適化に非常に優れている可能性があり、特に分岐予測などを備えたCPUでは、人間が妥当な時間で行うよりも優れた仕事をすることができることに気付くのにかなりの年月がかかりました. また、アルゴリズムの最適化に時間を費やすことは、高水準言語から低水準言語への変換に時間を費やすよりも優れた成果をもたらす可能性があります。また、時期尚早の最適化は諸悪の根源です...
日付の年の要素を 2 桁として格納することは、開発者の世代全体を苦しめた仮定であったと言えます。2000年に吹き飛ばされたお金は、かなり恐ろしいものでした。
挿入/バブルソート以外のことは、まったく単純な闇の魔法でした。
そのXMLは、真に相互運用可能で人間が読める形式のデータ形式になります。
その C++ は、本質的に他のすべての言語より優れていました。
これは、私が大学で数年前に友人から受け取ったものです。恥ずかしいほど長い間持ち歩いていました（今赤面しています）。それが何であるかの亀裂を見ることができるのは、それを2年ほど使用した後でした。
完璧な人はいません。常に改善の余地があります。
プログラムを作成することは、クラスで教えられていることとまったく同じだと信じていました...人々のグループと一緒に座って、問題を検討し、解決策を考え出すなど.代わりに、現実の世界は「ここにあります.私の問題、私はそれを解決する必要があります」と言って、10分後に別の問題が発生し、解決策を効率的に計画する時間がなくなります.
CSクラスで紹介されたとき、主流のデザインパターンは素晴らしいと思いました。その前に趣味でプログラミングを約 8 年間行っていましたが、優れた抽象化を作成する方法をしっかりと理解していませんでした。
デザインパターンは魔法のように感じました。あなたは本当にきちんとしたことをすることができます。その後、関数型プログラミング (Mozart/Oz、OCaml、後に Scala、Haskell、Clojure を介して) を発見し、言語の表現力が十分ではなかったため、多くのパターンが単なるボイラープレート、または追加の複雑さに過ぎないことを理解しました。
もちろん、ほとんどの場合、何らかのパターンがありますが、表現言語ではより高いレベルにあります。現在、私は Java で専門的なコーディングを行っていますが、パターン マッチングや高次関数の代わりに、ビジター パターンやコマンド パターンなどの規則を使用しなければならないときは本当に苦痛です。
プログラミングを始めて最初の数年間は、1K バイトが技術的には 1000 バイトではなく 1024 バイトであることを理解していませんでした。なれ。
その条件は次のようにチェックします。
if (condition1 && condition2 && condition3)
不特定の順序で実行されます...
プログラミングは、一人でやればもっと速く、もっとうまくできるだろう。
「プロジェクトは2週間で完了します」
と
「実装には2時間かかります」
コメントなしで自分のコードを理解できること!!!
必要になると思いました。
当時私が新人として持っていた1つの仮定は、この分野でより多くの年数を持つ人々は自動的により優れた開発者であるということでした。
PythonやRubyのような動的に型付けされた言語は、大規模なプロジェクトでの使用に適していません。
お恥ずかしい話ですが、私は長い間、参照型と値型の違いがよくわかりませんでした。別のメソッドでオブジェクトを変更するには、ref キーワードを使用する必要があると思いました。
これは、知っておくべきだった C# の最も基本的な概念の 1 つです。
これは本当に恥ずかしいことですが、プログラミングの方法を学び始めたとき、私を満足させるものは何もありませんでした. 私はビデオゲームを書きたかった。これらすべての本が私に書きたがっていた些細な小さなプログラムではありません。だから私は簡単に 10 章を飛ばして、基本を無視できると決めました。
だから私は基本的に変数を無視しました！
問題は、慣例からのキーワードを認識できなかったことです。
Car car = new Car(); //good
Car test = new Car(); //wrong must be lowercase car!
for (int i = 0; i < 10; i++) //good
for (int test = 0; test < 10; test++)//wrong must be i
私はこれを 1 年以上行い、3000 行の三目並べゲームも作成しました。インターネットで 150 行の三目並べを見つけるまで、私はその時点で自分の素晴らしさに興奮していました。それから自分が馬鹿だと気づき、最初からやり直しました。
そのプログラミングは簡単です。
Unix と Linux の OS が適切に設計されていること...おそらくこれを認定する必要があります(!)
第一に、この見解は次のような反自明論によって強化されます。
それらはよく設計されていてよくできていると言う方が正しいかもしれませんし、確かにそれらの一部はそうです。以下は、よく行われていないことの例です。
全体として、操作には不必要な専門知識が必要です。というか、そこそこの理解しかない知識の多さ。
すべてが悪いわけではありません。Linux は政治的に優れており、ビジネス ニーズによって損なわれることはありませんが、悲しいことに、技術的な高みの多くが失われています。
私が大学を卒業して最初に始めたとき、私はより多くの上級開発者が彼らが何をしているかを知っているだろうと思っていました. 少年は私が間違っていた....
わかりました、私はかなり早くプログラミングを学びました。私は14歳かそこらでした。そして、私はあらゆる種類のクレイジーな信念を持っていましたが、正確なタイミングについては聞かないでください。それはずっと前のことだからです.
わかりました。私はしばらくの間、Java で「同期」という用語を使用すると、Java がこの厄介な同期の問題を解決してくれると信じていました。
私は少なくとも半年、おそらくそれ以上の間、静的型付けがパフォーマンスを向上させると信じていました。
何かを解放すると、メモリがOSに返されると信じていました。
malloc の呼び出しは、OS に十分な空き容量があるかどうかを確認することに要約されるため、malloc は安価であると考えていました。
私は長い間、Java は他の言語の長所と短所をすべて念頭に置いて構築され、他の言語の最良の特性を取り入れて間違いを排除する「完璧なブレンド」として構築されていると考えていました。
LinkedLists が ArrayLists よりも優れているケースの数を大幅に過大評価していました。
しばらくの間、NP 困難性は、INSTANCE を効率的に解決できないことの証明であると考えていましたが、これは自明な誤りです。
旅行代理店のウェブサイトで最適なフライト プランを見つけるには、「巡回セールスマン問題」のせいで時間がかかると思っていました。
もっと思いつくかもしれません。私がそれらのそれぞれにどれだけ固執したかわかりません。ごめん。
PS:
ああ、わかりました、これはそれほどゆっくりではありませんでしたが、初心者が時々これを行うのを見ているので、興味があるかもしれないと思いました: また、不確かな数のものを保存するには、それぞれに新しい変数を宣言します。したがって、ベクトルとして宣言する 1 つの変数 a を使用するのではなく、変数 a1、a2、a3、... を作成します。
以前は、アプリケーションの作業の大部分は実際にはプログラミングであると信じていました。場合によってはこれが正しいと確信していますが、私の経験では、実際にコーディングするよりも、調査、文書化、議論、分析に多くの時間を費やしています。(私はレーザー ベースのセンサーを操作するソフトウェアに取り組んでいますが、ハードウェアを制御する最善の方法を決定することは、そのためのコードを記述することよりもはるかに困難です。)
私はまた、プログラマーが肩越しに見渡して (通常は) 隣にいる人に質問できるオープンな環境が、プログラマーのチームが解決策を打ち出すのに最適な環境であると考えていました。チームの有無にかかわらず、暗い孤独な部屋の方が生産性が高いことがわかりました。
私が卒業したとき、プロとしてのプログラミングは大学でのプログラミングのようなものだと思い込んでいました。つまり、入力と期待される出力が与えられ、変換を行うブラック ボックスに入力するように求められます。実際には、入力、出力、およびブラック ボックスを把握する必要があります。
私は、マーケティングとセールスの担当者が人類の惨劇であるとは考えていませんでした。
それは9時から5時までの仕事です
ライブに入る前に欠陥がないことは可能です。
P2 の欠陥でさえ、時々未解決のままになることがあります。
そのコードレビューは時間の無駄です。
それらが完全にオプションであった会社から、義務付けられている (監査さえされている) 会社に移行したことで、私はそれらの有用性を理解するようになりました。最も些細な部分であっても、コードに 2 番目の目を向けると、次のことが可能になります。
A ) 些細なことで失敗しても恥ずかしくない (たとえば、些細なコード レビューがあれば、前職では顧客に何百通ものメールをスパム送信することはできなかったでしょう)
B ) そもそも知らなかったことを教えてくれる (私は現在の仕事で新しいライブラリを学んでいます - 必然的に大企業で、誰かがあなたが抱えている問題に遭遇し、より良い仕事を解決してくれました)それは - どこを見ればよいかを知るだけの問題です）
C ) 少なくとも、自分以外の誰かが物事がどのように機能するかを知っていることを確認してください。
最終的に、私は以前の仕事よりもここに提出したコードに満足しています。当時はすべてを知っていると思っていました:)
if 条件がすべての行で評価され、次のようなコードを記述した場合:
Dim a as Boolean = True
If a Then
Console.WriteLine("1")
a = False
Console.WriteLine("2")
Else
Console.WriteLine("3")
End If
出力は次のようになります。
1
3
私は優れたプログラマーでした！
その .NET 構造体 (C# および VB.NET) は、クラスと同様に参照型でした。
私は、.NET 1.0 が登場する直前または直後のある時点で、その知恵の一部を「受け取りました」(どこから来たのかわかりません。ゼウスの眉からアテナが生まれたように、私の頭から完全に湧き出たのかもしれません)。約 4 か月前に Jon Skeet によってその概念の乱用が取り除かれるまで、それを保持していました。
ありがとうジョン。
PSプログラミングとは関係ありませんが、私も（約5分前まで）「アポロはゼウスの額から完全に飛び出した」と信じていました。
そのバイトと文字は実質的に同じものでした。「ASCII」は、バイト値を画面上のグリフにマッピングする方法にすぎませんでした。
Unicodeについて読んだことで、本当に目が開かれました (ただし、まだ完全には理解していません)。
ある日、自明ではないコード/システム/その他のものを構築するのにどれくらいの時間がかかるかという現実的な考えが浮かぶでしょう。
私は、Win32 アプリケーションをプログラムするのに十分だと思っていました。
また、コマンドラインは「時代遅れ」であるため、すべてのプログラムに GUI が付属している必要があります。
私はSOを読んで、どんな仕事も成し遂げることができます。
このオブジェクト指向は、常にソース コードを設計するための最良の方法であり、今後もそうなるでしょう。
データベースのパフォーマンスを向上させるために必要なことは、データベースを第 3 正規形にすることだけだと思いました。
That this:
SomeClass object(initialValue);
and this:
SomeClass object = initialValue;
were guaranteed to be equivalent in C++. I thought the second form was guaranteed to be interpreted as if it had been written as the first form. Not so: see C++ Initialization Syntax.
TI-83 でプログラミングしたとき、変数をそれ自体に割り当てることはできないと思っていました。そのため (これが TI-BASIC ではなく C コードであることを無視して) 書く代わりに
c = c + 1;
私は書くだろう
d = c + 1;
c = d;
私が知ったとき+=、++それは私の心を吹き飛ばしました。
そのIDEはより高速になります。
私がまだ問題を抱えていることのいくつかは、次のような誤解です。
常にコードを最適化する必要があること。それを書く前に熟考すべきではないと言っているわけではありませんが、読みやすさを犠牲にしてでも、各ステートメントからあらゆるパフォーマンスを絞り出す方法についてよく考える必要があります。
そのXML名前空間（またはさらに悪いことに、整形式）は、XML名前空間なしで実行しようとするよりも何らかの方法で困難です。
W3Cでも、非常に一般的な失敗です。
私の誤った仮定: 改善の余地は常にいくらかありますが、私の場合、私はできる限り優れたプログラマーです。
大学を出たばかりの頃、私はすでに 6 年間 C プログラミングをしていて、「構造化プログラミング」についてはすべて知っていました。
10年後、私は考えていました。 .
どういうわけか、私はいつも本当に上手でしたが、常に以前よりもずっと良くなっています.
それから間もなくお金が落ち、ついに「いくらか」の謙虚さを手に入れました。学ぶべきことは常にあります (Haskell のような純粋関数型言語で適切なプログラムをまだ作成していません)。
3 秒以内に無限ループを実行できるコンピューターが登場するだろうと誰かが確信したとき、私は 10 歳だったと思います。
C ++では、長い間、純粋仮想メソッドの定義を与えるときにコンパイラーがユーザーを拒否することをいじっていました。
自分が間違っていることに気づいて驚いた。
抽象クラスに純粋な仮想デストラクタのデフォルトの実装を与えるように他の誰かに言うとき、彼/彼女は大きな目で私を振り返ります。そして、ここから長い議論が続くことを知っています...それはC ++初心者の間でいくらか広がっている一般的な信念のようです（私も自分自身を考えているので..私はまだ学んでいます！）
私は、少なくとも 6 年間、すべての問題には必ず 1 つの解決策があると確信していました。
複雑さの異なる複数のアルゴリズム、空間/時間のトレードオフ、OOP 対関数型対命令型、抽象化のレベル、決定不能な問題をまったく認識していません。その至福に満ちた素朴さが壊れたとき、それは可能性の世界を開き、ただ座って物を作ることにドアを閉めました。1つを選んで実行する方法を理解するのに長い時間がかかりました。
古い手続き型プログラマーとして、趣味のプロジェクトで初めて Java でプログラミングを始めたとき、私は OO をよく理解していませんでした。インターフェースのポイントを本当に理解せずに多くのコードを書き、すべてを継承階層に強制することでコードの再利用を最大化しようとしました. 私のコードは機能しましたが、今ではその初期のものにひるみます。
動的言語について読み始め、学ぶのに適した言語を見つけようとしていたとき、Python の重要な空白について読んだことで気が遠くなりました。それは嫌いだと確信していました。しかし、最終的に Python を学んだとき、それは私が本当に好きなものになりました。私たちは通常、どの言語でも一貫したインデント レベルを持つように努力しますが、見返りはありません (視覚的な読みやすさ以外)。Python では、インデント レベルに関して以前よりも多くの努力をしていないことがわかりました。Python は、他の言語で中かっこなどを使用しなければならなかったことを処理しました。これで、Python がよりクリーンに感じられるようになりました。
こんばんは
私はコードを設計して書くだけです。
要件の収集、文書化、またはサポートはありません。
乾杯、
私たちソフトウェア エンジニアは、ユーザーが本当に求めているものを理解できます。
唯一のローカリゼーション/国際化の問題はメッセージの翻訳です。
私は以前、他のすべての言語 (ロケールの概念はありませんでした) は、単語と文法を除いてすべての点で英語に似ていると考えていました。したがって、ソフトウェアをローカライズ/国際化するには、ユーザーに表示される文字列を翻訳者に翻訳してもらうだけで済みました。それから私は気づき始めました：
今日でも時々、私を驚かせる国際化の問題について読むことがあります。
コメントが多いほど良いです。私は常に自分のコードをできる限り読みやすくしようと努めてきました。主な理由は、私が見逃したバグを修正するのはほぼ間違いなく私だからです。そのため、過去数年間、私は段落ごとにコメントを書いていました。
最終的に、どんなにきちんと構造化されていても、コメントが増えても価値がなく、実際に維持するのが面倒になるポイントがあることに気づきました。最近では、私は目次と脚注のアプローチを取っています。
以前に整数の昇格に遭遇したことはありません...そして、「z」はこのコードで255を保持すると考えました：
unsigned char x = 1;
unsigned char y = 2;
unsigned char z = abs(x - y);
z の正しい値は 1 です
私はそれをプロとしてやりたいと思っている駆け出しの開発者です。これは私が愛していることであり、これは私がかつて持っていた意見のリストであり、短い経験から学んだことは間違っています。
ユーザー インターフェイスをロジックからまったく分離しない場合に発生する恐ろしい混乱は容認でき、誰もがソフトウェアを作成する方法です。
複雑さや抽象化が多すぎるということはありません
ワンクラスワンの責任 - 私はこの概念を実際に持ったことはありませんでした.それは私にとって非常に形成的でした.
寝室でコーディングしているときは、テストは必要ありません。
私が行っているプロジェクトにとってはやり過ぎなので、ソース管理は必要ありません
開発者はすべてを行います。アイコンをデザインし、見栄えの良いレイアウトを作成する方法を知っている必要があります
Dispose は必ずしもファイナライザーを必要としない
あらゆるタイプのエラーが発生するたびに、例外をスローする必要があります
例外はエラーの場合であり、多くの場合、失敗を示す値を返すだけで問題ありません。私は最近これを理解するようになりました、私はそれを言っていて、まだはるかに長い間例外をスローしています
バグがまったくないアプリケーションを作成できます
私は以前、Internet Explorer 6 のボックス モデルは、他のブラウザーとの互換性を壊すためだけに MS が思いついた愚かな考えであると考えていました。
多くの CSSing は、それがはるかに論理的であり、ページ デザインのメンテナンス (ブロックのパディング/ボーダー/マージンの変更) をはるかに簡単にすることができると確信しました。
物理的な世界について考えてみましょう。A4 ページのパディングまたは境界線の幅を変更しても、ページの幅は変更されず、コンテンツのスペースが縮小されるだけです。
その後藤は有害です。
今、私たちは継続するか中断します。
「いつか」実装を切り替えたい場合があるため、高度な実装固有の機能を使用しないでください。私はこれを何度も繰り返しましたが、ほとんどの場合、切り替えは行われませんでした。
OO は必ずしも非 OO よりも優れているとは限りません。
オブジェクト指向は常に優れていると思っていましたが、関数型プログラミングなどの他の手法を発見し、オブジェクト指向が必ずしも優れているとは限らないことに気付きました。
現在人気のある$記号は、java/javascript識別子の一部として違法でした。
多くのRSSフィードを購読し、多くのブログを読み、オープンソースプロジェクトに参加することが重要です。
本当に重要なのは、コーディングにもっと時間を費やすことだということに気づきました。私は多くのブログを読んでフォローする習慣があり、それらは豊富な情報源ですが、すべてを吸収することは本当に不可能です。バランスの取れた読書をし、練習にもっと重点を置くことが非常に重要です。
登録 オープンソース、私は人気がないのではないかと心配しています。私はオープンソースに参加してみましたが、そのほとんどは.NETに参加しています。多くのオープンソースプロジェクトが適切なアーキテクチャにさえ従わないことに私は愕然としています。.NETの1つのシステムが階層化アーキテクチャを使用していないのを見て、データベース接続コードがコードビハインドを含む至る所にあり、私はあきらめました。
そのバイトコードを解釈する言語 (C# や F# など) は、機械語コードに直接コンパイルするリセット - ボタン - ホッグよりも低速です。
まあ、私がそう信じ始めたとき（80年代）、それは本当でした. ただし、C# の場合でも、「その内部ループを .cpp ファイルに入れると、アプリが高速になるのではないか」と疑問に思うことがありました)。
幸いなことに、いいえ。
悲しいことに、私は数年前にそれに気づきました。
マネージャーが自分の話していることを知っていること。
私の学校教育が私を現場での仕事に備えさせること。
プログラミングの特定の言語/トピックについてすべて知っていると思っている。不可能です。
私は自分がかなり良いプログラマーだと思っていました。その地位を2年間保持した。
真空で作業すると、部屋を簡単に満たすことができます :-D
その C++ は、世の中で最もクールな言語でした。
言語を学ぶことは、構文と標準ライブラリの最も一般的な部分を学ぶことです。
プロジェクトのWinForms（GUI）がアプリケーションの他の部分の4倍のメモリを使用していることに後で気付くために、ビジネスレイヤーが使用するメモリの量を減らすために何日も費やすことができました。
「ダックタイピング」は、最初に聞いたときは実際には「ダクトタイピング」だと思っていました。これは、人々がよくダックテープと言うのと同じです。「ダックタイピング」は間違っているように聞こえましたが、「ダクトタイピング」は奇妙な種類の意味を持っていました（一緒に石畳のタイプ）。
つまり、私が書いたコードの所有者である私は、それを理解したり触れたりする必要がある唯一の人です。
開始しなかったプロジェクトを決して終了しないこと。
本当にばかげているようですが、規模が圧倒的だったので、たくさんのプロジェクトを延期しました。プロジェクトのモンスターを完成させたばかりで、その範囲を理解していたら、私は決して始めなかっただろうと気づきました。しかし実際には、最も複雑なシステムでさえ、個別の定義された部分に分割すると非常に単純です。しかし、マクロレベルで見ると、すぐに圧倒されます。
関数の最初に使用するすべての変数を定義する必要があること (Pascal スタイル)。
コーディングを開始する前に、関数で使用されるすべてのリソースについて考え、それらを定義する必要があると信じていました。これはおそらく、最初の言語が Pascal であり、それが要件であったためです。その後、C に移行したとき、「すべてが最初に定義される」ように、ループ内スコープを無視して、それらのループの外側のループ内でのみ使用される一時変数を定義します。
すべてのリソースを事前に定義することはヒイラギの牛ではなく、コードの可読性にとってスコーピング自体が非常に重要であることを理解するのに数年かかりました。
C++ を使い始めた頃 (かなり前)、私は Java の学者に囲まれていました。Java に対する C++ の利点を尋ねられた場合 (通常、私は不自然であると却下しようとする質問ですが、そのとおりです)、C++ が参照とポインターを提供したことを回答に含めます。Java の担当者は信じられないような顔をして、参照はポインターであると提案し、私を笑い飛ばして部屋から追い出しました。私は、C++ では参照とポインターが異なると主張しました。
そして、公平を期すために、私は正しかった。参照とポインターは、意味的にも構文的にも異なります。残念ながら、私は自分の主張を誤った考えで裏付けました。つまり、根底にある実装が異なっていたということです。
aがストレージのない型エイリアスであるのと同じように、標準化により、参照は構文内の名前エイリアスであるというのが私の確固たる信念でした。typedef
参照はオブジェクトではなく、ストレージがなく、「名前」から「オブジェクト」への複数の最上位マッピングを提供しているだけだと確信していました。その点で、ファイルシステムのソフトリンクのようなものだと思いました:
Code: int a = 3; int& b = a;
Names Objects Memory
+-----+ +-------------+ +-------+
| a |---->| | | |
+-----+ | | | |
| int |---->| 3 |
+-----+ | | | |
| b |---->| | | |
+-----+ +-------------+ +-------+
もちろん、最適化がこれにつながる可能性がありますが、参照にはストレージがあります。構文がプログラマーからそれを抽象化するために最善を尽くしたとしても、それらは別個のオブジェクトです。
言うまでもなく、最適化がオフになっているコンパイラーが参照をポインターとして実装する可能性があり、逆参照操作が必要になる可能性があることを知ってがっかりしました。実際には、ファイルシステムのハードリンクに類似したものを作成していたのです。
Code: int a = 3; int& b = a;
Names Objects Memory
+-----+ +-------------+ +-------+
| a |---->| int |---->| |
+-----+ +-------------+ | |
| 3 |
+-----+ +-------------+ | |
| b |---->| int& |---->| |
+-----+ +-------------+ +-------+
標準 C++ では、参照を実装する方法を実際に指定していないため、私の理論は一部のツールチェーンに当てはまる可能性がありますが、主流のコンパイラにはありません...そしてそれは確かに標準には記載されていません。
長い間 (約 5 年間)、私は PHP がうまくいくと思っていました。
私はアルゴリズムを知っていると思っていました。そして、Topcoder.com に参加しました
SQL WHERE 句での整数のビットごとの比較は、クエリ パフォーマンスに関して実質的に無料です。
たまたま、これは最初の 50 万行ほどに当てはまります。その後、非常に国連フリーであることが判明しました。
SQL やリレーショナル データベースに不慣れな手続き型の開発者/プログラマーは、SQL の操作方法や使用方法についての正式なトレーニングや理解を必要とせず、リレーショナル データベースの操作にはSQL For Dummiesのようなものをざっと読むだけで十分であることOracle & SQL Serverのように。
Oracle や SQL Server などのリレーショナル データベースに格納されたデータを処理するアプリケーションで発生するエラーの多くは、リレーショナル データベースの言語の理解不足や使用方法が原因であることが非常に多くあります。SQL .
私が以前働いていたソフトウェア ベンダーは、開発者が必要とするのは SQL For Dummies の本かそれに類するものだけであり、リレーショナル データベースの問題を処理するための十分な準備が整っているという考え方を持っていました。このベンダーのクライアントが数百ギガバイト単位のデータベースを所有しているため、この SQL 知識の欠如がマイナスの方向に戻ってきています。ルックアップや更新、挿入のパフォーマンスが悪いだけでなく、実際の障害となるのはデータベース自体の実際の設計です。
当時、開発リーダーが SQL とリレーショナル データベースを、アプリケーションを構築する際に使用した言語と同じレベルの敬意を持って扱っていれば、これらすべてを回避でき、現在のコストを大幅に削減できたはずです。
SQL は重要ではないとして片付けないでください。しばらくの間、場合によっては何年もそれを回避できるかもしれませんが、最終的には、データベースを完全に再設計しないと進歩できない限界点に到達し、その時点でコストが最も高くなります.
プログラミングはジュニア向けであり、最高のプロジェクト マネージャーはプログラミングができない人です。
プログラムを 100% 完成させてバグをなくし、それを「完成」と報告するという仮定。多くのバグがある場合、最初に市場シェアを獲得するために、会社がプログラムをリリースしたい場合があります。
人々がベスト プラクティス、さらには一貫性を気にすること。
誰もが問題に対して可能な限り最高の\最も適切なコードを生成したいと考えています...
初期のほとんどのパーソナル コンピュータには、プログラムのロードと保存用のカセット テープ インターフェイスがありました。当時、私はコンピューターを持っていませんでしたが、コンピューターに関係のあるもの (主に雑誌) を手に入れることができるものはすべて読みました (これは 70 年代後半で、私にはインターネットがありませんでした)。どういうわけか、プログラムはカセット テープから直接実行され、コンピュータに RAM がある唯一の理由は、プログラムの実行中に変数を格納するためであるという印象を受けました。コードがジャンプ命令を実行しなければならない場合、どういうわけかテープを正しい位置まで巻き戻したり進めたりして、そこから続行すると考えました。
そのASCIIはバイナリとは異なる方法で保存されました
コンピューターサイエンスの学校を卒業したら、仕事を始めて、学校で学んだ知識を実際の世界のアプリケーションに役立てることができます。(オペレーティング システムとプロローグの学習に 4 年間の人生を無駄にしたくありません)
物事には常に「正しい」方法があるということ。私は大学を出た後、あまりにも長い間この思い込みを持ち続けていました。
もちろん、タスクを完了する方法は常にたくさんあることに気づきました。どの方法にも必ず長所と短所があります。入手可能な情報を見て判断し、それを上司に正当化できることを確認してください。
私はK＆Rを読んでCを学びました。残念ながら、私はそれを一言一句読んでおらず、いくつかのことを見逃していたに違いありません。自分のバージョンのmallocとcallocを作成しました。これは、既存のライブラリにリンクできることに気づかなかったため、仕事から仕事へと持ち歩いていました。誰かがついに私がそのようなものをカートに入れている理由を私に尋ねるまで、私はこれを数年間行いました。
そのPythonは非実用的で迷惑な言語であり（初期のコードについてのコメントをまだ読んでいて、それについて不満を言っています）、C++は唯一の真のオブジェクト指向言語でした。
私はとても間違っていたので、まだ恥ずかしがっています。
C /C++のifステートメントの評価順序はコンパイラー固有でした。だから書く：
if（pointer！= NULL）&&（pointer-> doSomething（））
評価順序が入れ替わる可能性があるため、安全ではありませんでした。私は最近（何年にもわたってその嘘を吐き出した後）、ANSI-C仕様の一部であり、注文と完全に安全であることを保証できることを知りました。
ジェームズ
私が最も長く抱いていた（したがって最もコストのかかる）誤った仮定は、「ビジネスの要件は正気で合理的であり、私はまだそれらを理解していない」というものでした。
100の緑の仮定が壁に座っており、
1つの緑の仮定が誤って落ちた場合、
99の緑の仮定が壁に座っていることになります。
代わりに：
ハンプティダンピーが壁に座っていた。
ハンプティダンピーは大きな転倒を遂げました、
そしてすべての王の馬とすべての王の男性は、
エフィムが言った、彼はただの技術者です。
OOP の利点は、objectを再利用できることですが、実際には、同じインターフェイスを持つ新しいオブジェクトを作成することで、残りのコードを再利用できます。
実際には、オブジェクトはコードの 2% である可能性があるため、再利用によるメリットは 2% しか得られません。本当の利点は、他のすべてのコードをまったく別のものにすることを可能にする新しいオブジェクトを作成することによって、コードの他の 98% を再利用することです。これで、コードの 98% を再利用できます。何かをオブジェクトとして記述するのに 3 倍の時間がかかります。
たとえば、描画プログラムを持っていて、突然描画できるようにしたい新しい図形ができた場合は、ShapeObject を変更するだけです (インターフェイスは同じまま)。プログラムの他の何も変更する必要はありません。
大学時代から、自分はプログラミングの達人だと思っていました。私はコーディングできたが、他の人はできなかったからです。しかし、入社してから、自分の基本的な無知に気付かされました。自分自身についての私の仮定はすべて間違っていることが判明しました! 知りたいこと、わからないことがすぐにわかる！
つまり、正確な科学を学ぶことによって、限られた社会的スキルを向上させる必要はありません.
大学時代 (90 年代半ば) には、コンピュータ ラボに Windows 3.11 マシンしかありませんでした (奇妙な大学です)。
しばらくの間、私は Windows プラットフォームだけがプロのプログラマーとしての私に関係があり、他のすべてのプラットフォームは歴史的な学術的観点からのみ興味深いものであると考えていました。
学校を卒業し、最新の UNIX と Linux 環境について学んだ後、自分の不自由な学校に怒りと失望を感じずにはいられませんでした。
bash シェルを見たり、emacs や vim について聞いたりすることなく、コンピューター工学の学位を取得して卒業したことが、今でも信じられません。
1 バイトも CPU サイクルも無駄にすることなく、効率的なプログラムを作成することが非常に重要でした。
しかし、より多くの経験を積むと、それはバイトや CPU サイクルではなく、詩のように途切れることのない連続した思考の流れに関するものになります。
基本的に、頑張りすぎないこと。
学校では、プログラミングは「入力を読み取り、データを処理し、出力を書き込む」と教えられます。実際には、処理ステップが存在することはめったにありません。ほとんどのコーディングは、「入力を読み取って出力する」だけです。
一般的には、「ユーザーから読み取り、データベースに書き込む」または「データベースから読み取り、画面に表示する」のいずれかです。これら 2 つのケースは、これまでに行う作業の約 95% をカバーしています。
顧客が望むものを実装することで顧客を満足させます。残念ながら、これは顧客が自分の望むものを知っていることを意味します。
コードが少ないほど良い。これで、読みやすく/理解しやすくするために、コード行を増やす価値がある場合があることがわかりました。
私が他の誰かのために裕福なプログラミングソフトウェアになること
その PHP の mysql_fetch_row は、実行された SQL クエリからデータを取得する唯一の方法でした。
正直なところ、私は mysql_fetch_array を使用せずに Web アプリケーション全体をプログラムしましたが、関数を変更して列を追加するたびに、一連の数値を変更する必要がありました。
正規表現を学ぶと時間を節約できます
そのテストは、先延ばしの別の方法にすぎませんでした。
Linuxでメモリ割り当てが参照を返すかどうかを確認するかどうかは問題ではないことがわかりました。実際には嘘をつき、将来のある時点で実際にメモリを割り当てるか、そうでない場合はプログラムを完全に中止します必要なメモリがあります。
コンピューター サイエンスのカリキュラムで教えられたカルノー マップのプログラミングでは、実用的な用途が見つからないということです。
どういうわけか、かなり注目度の高い/トラフィックの多いWebサイトを多数運営している会社は、実際に彼らが何をしているのかを知っていました。結局、彼らはほとんど無知で、彼らがいた位置にいることが非常に幸運でした。それで、道徳はそうなると思います、
確かなソフトウェアエンジニアリング&&ベストプラクティス！=ビジネスの成功
また....
最も重要なソフトウェアシステム==がらくた
そのJavaは、オブジェクトのコピーを参照ではなく関数に渡します。
つまり、オブジェクトをメソッドに渡してから、何らかの方法でオブジェクトを変更しても、呼び出し元のスコープ内のオブジェクトは変更されないと思いました。私はいつもオブジェクトをメソッドに渡し、それらを操作してから返しました！
それは....ブレークポイントが有効なときにJUnitテストが必要なのは誰ですか？（デバッグモードでアプリケーションをテストする場合）。後で気付いたのは…。
コードの行数が多いほど、ソフトウェアは優れています。
すべてのOOP言語が同じオブジェクト指向の概念を持っていること。
interface！=メソッドのインターフェース。システムプログラミングに適した言語は、[可変]変数をサポートする必要があります。
これは恥ずかしいことですが、C＃で各メソッド呼び出しの値を格納する変数を作成するよりも、メソッド呼び出しをネストしたり、複数のメソッド呼び出しを行ったりする方がメモリ効率が高いと長い間信じていました。
その変数は、実際にはメモリ内の特定の領域の名前にすぎません。
成功するアプリケーションの作成は、プログラマーだけが簡単に行うことができます。ソフトウェアは、使いやすさ、見栄え、ドキュメンテーション、適切なマーケティングにも関係しています。ソフトウェア開発は複数の専門分野にまたがるものであり、1 つの分野で失敗すると、アプリケーションも失敗する可能性があります。
そのシンプルさは、ほとんどの場合、複雑さを打ち負かします。KISS - シンプルに保つ ばかげたルール。
編集：Georgが以下に述べているように、私はこれを逆にしました. 私の心は返信で失われたに違いありません。シンプルさは、正しく使用すればほとんどの場合コードを改善します。
プロジェクトを完了するためにクライアントの仕様が必要だったこと。多くの場合、営業会議とメモ帳から始めます。もちろん、彼らは会議の終わりに締め切りを望んでいます。
自動化と組み合わされたプログラミングの優雅さは、古き良きテストの適切な代替品でした.
8時間ぶっ通しでコーディングするつもりだった。現実的には、私は 1 日 4 時間のコーディング、1 時間はランチ、1 時間はコーヒー ブレーク、2 時間はふざけたり、おしゃべりをしたり、スタックを上下に流したりするのに費やしています。
働く前は、すべてのクライアントは馬鹿で、コンピューターについて 2 つのくだらないことを知らないだろうと思っていました。男の子は私が間違っていました。時々、私たちよりもうまくやれる人からプロジェクトをもらうことがありますが、彼らにはそれをする時間がありません。
私はキュービクルが悪いと思っていましたが、今は大好きです：DIは実際にドア付きのオフィスからキュービクルに移動しました. 開放感が好き。
すべてのプログラマーは運動神経が良いわけではありません。ジムに行くのは私だけだと思っていました。私が働いている場所では、少なくとも 10 人が毎日午前 5 時にジムに行きます。
女性プログラマーはいなくなると思っていました。私たちのリードのカップルは女性です。
そのマーケティング担当者は、あなたが何をしているかを気にかけています。
WTF は常に悪い専門家の証拠です。
実際、私は自分のキャリアを通じてどれだけ多くの WTF をコミットしたかを最近認識していますが、StackOverflow がそれらがソフトウェアの別の指標に過ぎないことを示したとき、私は安心しました。
締め切りまでにそれを終わらせる十分な時間が常にないということです。
よくあるよくない仮定: 「コードの品質は二の次」。さらに悪い仮定: 「コードの品質はまったく重要ではない」。
コードの品質は非常に広い概念です。ここで徹底的に議論しました。
私は常に、優れたプログラマーになるには、システムの内部の仕組みをすべて知っている必要があると信じていました。コーディングを開始する前に、ライブラリ、パターン、スニペットなど、言語について知っておくべきことをすべて知らなかったという事実を恥じていました。まあ、私はもうそれほど素朴ではありません。
一時的な解決策は永続的な解決
策ではありません。つまり、回避策は永遠ではありません:))。
私は自分がプロのプログラマーになるとは思っていませんでした。でも最終的には、プログラミングの方がはるかに簡単で、給料もよかったので、副業として始めたことが私の本業になりました。
最も長く保有されているわけではありませんが、ある時点および数年間、私は:
だから私は高校で「コンピューターコース」を選びませんでした。私は、コンピューターについてはもう十分知っていると思っていました。
後で大学で、私の過ちから：
最後に、そして長い間、私は次のように考えていました。
私がプログラミングを理解すること。SICP の本を読んで、自分が何も知らないことに気づきました。少なくとも今はプログラミングをもっと掘り下げています。
OOP がしばしばより良い解決策を提供する理由を、従来の手続き型プログラマーに納得させることができたこと。
つまり、世界を記述する言語には、複雑なオブジェクトとそれらの関係を記述する能力が必要です。
議論には通常、抽象クラスに関するナンセンスが含まれていましたが、私は「すべての OOP プログラマーが Uni を卒業したばかりで、まだ抽象化に夢中になっているわけではありません」と答えました。または古典的な、「厳密な手続き型プログラミングでできなくて、OOP でできることは何もない」という言葉に対して、私は通常、「できるということではなく、より広範なツールセットがあればできるかどうかです」と答えました。 .
私は、彼らが私と同じレンズを通して世界を見ているわけではないことを受け入れることを学びました.
私の最大の先入観は、自分のやりたいようにプログラミングできるということでした。それからもちろん私は大学を中退し、ばかげたフレームワーク、規則、手順が整備された会社に就職しました。
可能な限りバグのないコードを本当にうまく書けば、それが私ができる最善のことであるという前提。マネージャーは、いい仕事をするよりも、自分のお気に入りになろうとする人を好むことがある.
コードを徹底的にテストした場合、エラー処理は不要です。
以前は、MS 開発者のような一流の開発者のようにプログラミングすることは決してないと思っていましたが、今では、同じかそれ以上のきれいなコードを書くことができると思います。
私のコードが読めないのなら、あなたはその言語を知らないだけです。それに対抗しようとしたいくつかのコードレビューがありました。
コードに魔法をかける時間と場所があり、それがアプリケーションではなくライブラリにあることを学ぶのにさらに数年かかりました。このアプリは、明快さと読みやすさを目的としています。Magic は、拡張メソッドとフレームワークの背後に隠れている場合に最適に使用されます。
コンストラクターで C++ オブジェクトを memset( this, 0, sizeof(TheObject) ) しても、悪影響はありません。
MLやHaskellのような強力な静的型システムがある場合は、それを使用してできるだけ多くの不変条件をエンコードする必要があります。経験を積んで初めて、不変条件を動的にする方がよい場合があることを学びました。
その人々は実際に使用されているテクノロジー（オープンソース/クローズドソース）を気にかけていました。
これは、「標準」環境でソフトウェアを構築したため、すべてのマシン/サーバーで機能するということです。実際に使用されていたいくつかのあいまいなライブラリとサービスをインストールしたことを発見しただけです。そして、その後パッチが適用されたバグを利用したことを発見します。
まったく新しい言語を学ぶことは本当に難しいでしょう。
十分に良いソフトウェアを書くのは簡単な作業だと思いました
仕様は完全で十分です
その 640K は誰にとっても十分なはずです (DOS)。それは何年もの間、多くの人々に広く信じられていました。
初めて 8MB の RAM を搭載したシステムを使用したとき、これは必要以上のものだと思いました。それは、OS (Mac) と、私が使用していたすべてのアプリケーション (Word、Email、Firefox など) を実行しました。
私がコンピュータ (1K のメモリを搭載した ZX81) をいじり始めた 80 年代前半に、基本的に BASIC Poke 命令を使用して、雑誌からゲーム用の一連のマシン コード (人間が読めるアセンブリ言語ではなくバイト) を入力するのに何時間も費やしていました。
一つでも命令を間違えたら、最初に戻って最初から機械語を入力し直さなければならないと思っていました。
そのプロファイリングとパフォーマンス分析は同じものでした。
次に、プロファイラーには、何もないよりはましですが、次のような誤った仮定が含まれていることがわかりました。
ポインターと再帰性を理解するのは、非常に難しいでしょう。
VB6 の整数は、.Net とはサイズが異なります。
そのVB6はビットレベルの操作を行うことができました。
プロのプログラマーはバグのないソフトウェアを作成します。
ID 列に重複する値を含めることはできません: SQL サーバーの ID 列
私たちの開発方法が選択され、使用されたのは、それらが最高の組み合わせであったためです.
その後、私たちが使用するツールは、私たちが思っていたよりも、何を、いつ、どのように行ったかに大きな影響を与えることがわかりました.
そのソフトウェア エンジニアは、現在行っていること、または過去にソフトウェアに対して行ったことについて、常に正直です。
高速の車、ゆるい女性、プライベート ジェット、大胆な冒険のジェットコースターに乗ることになるだろうと思っていました。そのキャリアアドバイザーを手に入れるまで待っててください....
この完全な Unicode サポートは、ソフトウェアをアジア地域に正常に展開するための前提条件でした。
その実行時のパフォーマンスが重要でした。多くの場合、合計解決時間は重要です。
Python を学んで以来、私は静的型付けへの執着から離れました。
私は適切な Web アプリケーションを作成することを知っており、すべてのブラウザーで機能するものを設計しなければならなかったときに、それが私を台無しにしたことは明らかでした。
交換可能な html 要素の id および name 属性。
「name」属性を持つ要素は関連/使用されていることがわかります。POSTなどで参照され、「id」属性はDOM参照に使用されます。
スレッド = プロセス
そのOOPは時代遅れでした:(私は今日までそれを考えていたことを後悔しています.
Windows のそのスレッドは安価です。
これはある程度真実であることがわかりました。スレッドにはある程度のオーバーヘッドがあり、スレッドが生きて満足できる独自のアドレス空間が必要です。そのため、1 つのアプリケーション内で数十のスレッドを処理していることに気付いた場合、すべてを簡素化し、より少ないスレッドに統合する方法を自問します。
私が書いたものはすべて、予見可能な将来のある時点で失敗するだろう.
最終的にすべてがバラバラになるわけではありませんが、プログラミング教育の早い段階で、try..catch ブロックを見つけたとき...すべてをそれらでラップしました....それらが失敗した場合、はるかに大きなものを表すもの私のプログラムが処理するよりも問題 (たとえば、北極と南極の場所が入れ替わっている)
本番環境で「断続的なエラー」を診断することはできません。サーバーを再起動することが唯一の修正方法です。
おそらく、私の ASP コーディングの初期の頃は、もっと真実でした。しかし、メモリ リークやその他の不可解な問題を検出するための優れたプロファイリング ツールが多数あります。Perfmon は、多くの優れた診断データも提供します。さらに、診断ログをアプリケーションにコーディングする必要があります。
中学でアルゴリズムを学んでいたとき、NPCは単なる非多項式の問題だと思っていました。つまり、この問題の複雑さは多項式ほど単純ではありませんでした。大学で計算理論を学ぶまで、自分が間違っていることに気づきませんでした-_-b
コードを作成するのは私だけだと思っています...そのルーチンが必要なときは、自分が何をしたか思い出せず、自分のコードをコピーして貼り付けるだけです。
今、私は誰もがそれをしていることを知っています。
プログラムは、最終的にすべての問題を解決することができます。
その次元 n は、それらが等しい場合、次元 (n+1) のインスタンスです。
そのセールスマンは、顧客の期待を現実的に管理します。(期待を裏切り、過剰に提供する訓練を受けている)
そのソフトウェア要件は、通常、市場調査から得られます。
もちろん、FindBugsとPMDを見ることもできますが、これらは私のお気に入りの落とし穴とトリック (すべて Java) です。
フィールドはオーバーライドされず、シャドウされます。
明示的な super.super アクセスはありません。
コンストラクターが定義されていないクラスには、引数のない暗黙的なコンストラクターがあります。私は今年、これに関連する実際的なエラーを犯しました。
内部クラスの親への参照を取得するには、構文「Outer.this」を使用して、メソッド呼び出しまたは同期を明確にすることができます。
クラスは、C++ の用語では「それ自体の友人」です。そのクラスの任意のインスタンスのプライベート メソッドとフィールドは、静的メソッドであっても、同じクラスの任意のメソッドから参照できます。これにより、私の初期の clone() およびコピー コンストラクターの一部がはるかに単純になります。
保護されたメソッドとフィールドは、拡張クラスの静的コンテキストでアクセスできますが、そのクラスが同じパッケージ内にある場合に限ります。flex.messaging.io.amf が密封されたパッケージではないことを嬉しく思います。
彼はプログラミングを知っていると言っていましたが、それは本当であるに違いありません!
それ：
for (int i = 0; i < myObj.variable; i = i + 1)
次のように最適化されます。
int j = myObj.variable;
for (int i = 0; i < j; i = i + 1)
うわー、毎回実行されていることに気付いたとき、j の代わりに関数呼び出しを配置するのをやめました!
理由：
for (int i = 0; i < myObj.variable; i = i + 1){
if (function_argument == NULL){
myObj.variable++;
} else {
printf("%d", myObj.variable);
}
}
次と同じではありません:
int j = myObj.variable;
for (int i = 0; i < j; i = i + 1){
if (function_argument == NULL){
myObj.variable++;
} else {
printf("%d", myObj.variable);
}
}
任意の例ですが、最適化によって実行がどのように変化するかを見ることができます。
@Kyralessa: アセンブリ/マシン言語のほとんどのプロセッサでは、スタックを良好な状態のままにして、関数が呼び出し元以外の場所に戻る可能性があることに注意してください。実際、これが役立つさまざまな状況があります。私が 6502 で最初に見たバリエーションの 1 つは、Z80 ではさらにうまく機能しますが、印刷されるテキストが呼び出し命令の直後に続く印刷メッセージ ルーチンでした。ゼロ ターミネータの後で実行が再開されます (または、Z80 を使用する場合のわずかな最適化として、ゼロ ターミネータで、ゼロ バイトを NOP として実行できるようにする方が、ゼロ ターミネータを回避しようとするよりもコストがかからないためです)。
多くの最新の言語では、関数には 1 つの通常の終了ポイント (呼び出しに続いて実行が再開される) がありますが、例外をスローして終了することもできます。C でも、 setjmp/longjmp を使用してそのような動作をシミュレートできます。
Javaは遅いです。非常に多くの perl ファンが slashdot regurgitation(sp???) に参加しています。これは悲しいことです。
私は永遠に VB でプログラミングしていたのですが、今は c# です。