タグ付けされた質問 「evaluation」

30
優れたプログラマであるかどうかを知る方法はありますか?
ほとんどの人がそうであるように、私は自分の分野で自分が平均より少し上にいると考えています。私は良い報酬を得て、昇進を得ました、そして、私は良い参照を得るか、または仕事を得ることで本当の問題を経験したことがありません。 しかし、私が一緒に仕事をした最悪のプログラマーの多くは、彼らが最高のプログラマーだと思っていることに気付くのに十分な時間を過ごしました。他の悪いプログラマーに囲まれている悪いプログラマーは、最も自己欺lude的なようです。 私は確かに完璧ではありません。私は間違いを犯します。締め切りに間に合わない。しかし、私は「他の優秀なプログラマー」と同じくらいの数の骨頭の動きをしていると思います。問題は、「他の優秀なプログラマー」を「私のような人」と定義することです。 だから、プログラマが何らかの合理的な自己評価を行う方法はあるのだろうか?自分の仕事が上手か下手かをどうやって知るのですか? または、善と悪のような用語の定義があまりにも不明確な場合、プログラマーは自分の長所と短所を正直に特定し、前者を活用して後者の改善に取り組むにはどうすればよいでしょうか?
301 evaluation 

13
他のおそらく有害な機能とは対照的に、なぜevalのような機能は悪と見なされますか?
ほとんどの現代言語(何らかの方法で解釈される)には、ある種の評価関数があります。このような関数は任意の言語コードを実行します。ほとんどの場合、文字列としてメイン引数として渡されます(異なる言語はeval関数により多くの機能を追加する場合があります)。 特にサーバー側のソフトウェアでは、悪意のあるコードをプロセスに実行させる可能性があるため、ユーザーがこの機能を実行することを許可しないことを理解しています(編集、つまり任意のユーザーからの任意の入力を直接または間接的に取得して渡されますeval)。そのようにして、チュートリアルとコミュニティはevalを使用しないように指示します。ただし、evalが便利で使用される場合が多くあります。 ソフトウェア要素へのカスタムアクセスルール(IIRC OpenERPには、ir.rule動的なPythonコードを使用できるオブジェクトがあります)。 カスタム計算および/または基準(OpenERPには、カスタムコード計算を可能にするようなフィールドがあります)。 OpenERPレポートパーサー(はい、私はあなたをOpenERPのものでおかしくしていることを知っています...しかし、それは私が持っている主な例です)。 一部のRPGゲームでのスペルエフェクトのコーディング。 したがって、それらは適切に使用されている限り、有効に使用されます。主な利点は、この機能により、管理者が追加のファイルを作成してそれらを含めることなくカスタムコードを記述できることです(ただし、eval機能を使用するほとんどのフレームワークには、ファイル、モジュール、パッケージなどを指定して読み込む方法があります)。 ただし、大衆文化ではevalは悪です。システムに侵入するようなものが思い浮かびます。 ただし、ユーザーが何らかの方法でアクセスすると有害になる可能性のある他の機能があります:リンク解除、読み取り、書き込み(ファイルのセマンティクス)、メモリ割り当てとポインター演算、データベースモデルアクセス(SQLインジェクタブルのケースを考慮しない場合でも)。 だから、基本的には、ほとんどの時間を任意のコードが書かれていませんが、適切かどうか見て適切に(リソース、ユーザ、環境、...)は、コードが悪であるとさえ経済的影響につながることができます。 しかし、eval関数には特別なものがあります(言語に関係なく)。 質問:他の危険な要素に同じ注意を払うのではなく、この恐怖が大衆文化の一部になるという歴史的な事実はありますか?

17
マネージャーは、人が良いプログラマーか悪いプログラマーかをどのように知るのですか?
プログラミングチームや部門を行うほとんどの企業では、コードを設計および作成するプログラマーと、管理作業を行うマネージャーで構成されます。単にコードを書いていないことを除けば、マネージャーは通常、チームが開発したコードを見さえせず、作業マシンに適切なIDEがインストールされていないことさえあります。 それでも、マネージャーは、人がうまく働いているか、何かを担当するべきか、特定の開発者を最も重要かつ責任のあるタスクに割り当てるべきかを判断する必要があります。最後になりましたが、マネージャーは通常、四半期ごとのボーナスを割り当てます! 上記を効果的に行うには、マネージャーは、もちろん他の特性の中でも、その人が優れたプログラマーであるかどうかを知る必要があります。問題は、彼らがそれをどのように行うのかということです。 彼らは人々が書いたコードすら見ていませんし、プログラマーが開発するコンポーネントの品質を直接評価することもできません...ほとんどの場合! その秘密は何ですか?

11
基礎数学はプログラミング言語によってどのように効率的に評価されますか?
プログラミングの背後にある理論にますます関与していくにつれて、一見単純なことに魅了され、umb然とするようになります。 Q:これはどのように機能しますか? A:そうだから! 私はこの実現が嫌いです!私は知識が大好きで、それに加えて学習も大好きです。それが私の質問につながります(それは広義の質問ですが)。 質問: 基本的な数学演算子はプログラミング言語でどのように評価されますか? 現在の方法はどのように改善されましたか? 例 var = 5 * 5; 私の解釈: $num1 = 5; $num2 = 5; $num3 = 0; while ($num2 > 0) { $num3 = $num3 + $num1; $num2 = $num2 - 1; } echo $num3; これは非常に効率が悪いようです。高い係数を使用すると、このメソッドは非常に遅くなりますが、標準の組み込みメソッドは瞬間的です。加算を繰り返さずに乗算をどのようにシミュレートしますか? var = 5 / 5; これはどのように行われますか?文字通り5を5つの等しい部分に分割する方法は考えられません。 var = …
22 math  evaluation 

3
最適化アルゴリズムの最適性を評価する一般的な方法はありますか?
最適化アルゴリズムの最適性を評価する一般的な方法はありますか。たとえば、NPハード問題またはNP完全問題を解くアルゴリズムなどです。 これまでに私が思いついた唯一の方法は、アルゴリズムの結果を既知の最適解と比較することです。 そうでない場合、いくつかの特別な問題のための特定の方法はありますか? 編集明確にするために:最適性とは、結果が最適解の結果にどれだけ近いかを意味します。

2
軽量アーキテクチャの評価を行うための良い方法は何ですか?
技術的なアーキテクチャのトレードオフ分析手法(ATAM)や、よりビジネス指向の費用便益分析手法(CBAM)などのアーキテクチャ評価手法に精通しています。ただし、これらの方法はかなり大規模です。いくつかのブレーンストーミングセッション、プレゼンテーション、トレードオフを説明する多数のシナリオの開発などを規定します。特定のサイズのプロジェクトには役立ちますが、通常は内部プロジェクトやデスクトップアプリケーションには大きすぎます一握り(またはそれ以下)の開発者によって開発されましたが、それらは小さいですが、かなり急な品質制約(パフォーマンス、スケーラビリティ、適応性)を持っています。 過去に私が使用した典型的な方法は、1人の開発者(またはチームに1人いる場合はアーキテクト)にアプリケーションの一般的なアーキテクチャを考えさせ、それをチームの残りのメンバーとホワイトボードで話し合うことです。簡単に描画して理解できる疑似UML表記。これは通常、アーキテクチャーのフィードバックといくつかの反復につながります。しかし、それは少し非公式になりがちで、後で間違った決定になる可能性のあるあらゆる種類の仮定が行われる傾向があります。 ATAMような方法は、典型的には、誰もが、少なくともアーキテクチャは、正確に何に同意するまでの議論につながる、アーキテクチャについて深く考えるようにすべての利害関係者を強制的です。 軽量の先行アーキテクチャ評価を行った経験がある人はいますか?もしそうなら、良い習慣は何ですか?

3
概念実証のシュートアウトを行うための最良の方法は何ですか?
私たちの会社が管理しているソフトウェアの新しいリリースに備えて、私はスケーラビリティの問題を解決するための本当に良いアプローチであると私が信じるものに取り組んできました。私は、紙面上のデザインが実際に私が望んでいることを検証するために、概念実証をまとめるつもりです。チームに説明すると、上司は反対の提案をしました。これは、問題のある領域を説明する方法に一部影響を受けています。上司はまた、代替案を評価するために2つの概念実証を行うという私の提案を受け入れました。 それでは、概念実証のシュートアウトを実行するための最良の方法は何ですか?ソリューションの評価に使用している客観的基準と主観的基準の両方があります。リンゴとこれらのかなり異なるアプローチのリンゴを比較していることを確認したいと思います。 スループットとサイズに関する要件があります。つまり、1秒あたり特定の数のオブジェクトを処理し、そのレートを1時間維持する必要があることがわかります。 スケーラビリティを評価する必要があります(コアを追加したり、オブジェクトの数を増やしたりして) 開発のしやすさ(主観的)を評価する必要がある アルゴリズムを理解するのがいかに簡単かを評価する必要があります(主観的) 私は物事がどのように傾くかについて私の理論を持っていますが、それが私の結果に影響を与えたくありません。このプロセスで客観性を維持する方法に関するあらゆる意見、および私が検討する必要があるかもしれないことは、大いに感謝されます。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.