彼らが自分の過ちやピアレビューから学べないとき。
私達はある時点で皆緑です。ただし、上手くならない、または上手く行こうとしない場合は、悪いプログラマーです。
自分が何を知らないかわからず、調べることにまったく興味がないプログラマ。
大きな警告サインは、彼らが「カーゴカルト」プログラマーであるかどうかです。つまり、彼らは何かをしますが、知らない理由彼らはそれらのことをします（それは単に"マジック"）。 Eric Lippertによる素晴らしい投稿 here 。
記事から：
コードの機能は理解しているが、コードの機能は理解していないプログラマ。
私にとって大きなヒントは、彼らがあなたや他のプログラマーの開発の質問をするときに、彼らが自分でそれを理解するためにまったく努力をしなかったことを明確に示しています。
結果は、彼らが情報を内部化していないことを示す同じプログラミング質問を複数回行うときです。
FizzBuzzの問題を解決するのに長い時間がかかるとき。
新しいテクノロジーや言語の学習を拒否し、すでに知っていることに固執するプログラマー。
補遺：（ダッシュのコメント欄に追加）
これの延長は、ある技術の機能のサブセットを知っているが、それについてこれ以上何も学びたくないという人々です。プログラミング言語、エディター、その他のツール...
チームメンバーが ネガティブプロデューサー の場合。
|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0
悪い開発者のために、チームの他のメンバーはより多くの仕事をしなければならないことを意味します。 [〜＃〜] nnpp [〜＃〜]
彼らが The Daily WTF を定期的に生み出すものを生み出すとき。
彼らは物事を行うためのより良い方法があることを知っているが、時間が許されている場合でもそれらを行うことを拒否します。
個人的には、少し前に作成した自分のコードを見て、問題を見つけられないプログラマーは、いい人ではないと思います。 「しばらく」は経験に応じて変化する可能性があります...数週間から最大で1年程度です。
コードに関する警告を無視し、エラーのみを気にする人。
私が小さめの店のチームリーダーだったとき、割り当て直さなければならなかった人が何人かいました（私も私の直属の上司も、 赤いテープ 文書の山。）または現在の契約の終了時に契約の更新がないこと。列挙されたタイプのいくつかは他のチームリーダーでも機能し、ほとんど同じ見方をしました。私の本の「悪いプログラマ」カテゴリに人々を連れて行ったもの：
- 過去に訓練不能または骨化した
「プログラマ」が新しいシステム、新しいツール、または展開されているものを吸収できないと思われる場合は、トレーニング/教育がどのように行われてもかまいません。上記のトレーニングを頻繁に繰り返す必要があります。
「プログラマ」が10年または15年前に使用したテクノロジーまたはコーディングパラダイムのみを知っている場合。それでそれで十分でした、それで彼らはなぜ変わるべきですか？ - カウボーイコーダー
計画を立てずに最初にコーディングする人。 「今すぐ修正しなければならないため」、プロダクションコードやデータにテストされていない変更を加え、「修正」が失敗したときに驚いた「プログラマ」。
また、カウボーイは間違いなくチームプレーヤーではありません。臭いチームは必要ありません。 - 天候ベーン
この「プログラマー」は「テクノロジーdu jour」に夢中になり、すべての新しいフレームワーク、言語、方法論、または新しいものすべてを確認し、 hotとして - 「ビッグブレイン」
この「プログラマ」は彼の才能と能力を確信しているので、プロジェクトにあまり意味のないことが行われます。 例：標準ライブラリを「システムにとって非効率なため」に書き直すか、当面の問題に適さないツールや手法を導入します。 例：メインフレーム環境でのLISPまたはForthの紹介。 - LOC a。 サンドバガー
この「プログラマ」は、難読化と誤った方向付けを使用して、 a。 LOC：支払われるコード行。この状況で、ページごとに、構造とロジックが重複して画面ごとに表示され、段落または制御変数の名前のみが変更されて行数が増えるようになっているコードを見ました。 - 不可欠な専門家
問題を解決するためのドメイン知識を持っている「プログラマ」。ただし、問題についてすべてを「知っている」ため。実際のところ、もし彼らがバスにぶつかったら、組織全体が崩壊してしまうでしょう。 {観察：彼らが通常不可欠であると思う人は通常です。 （誰かがこの格言の出典を知っていますか？）} - パスタシェフ
この「プログラマ」はスパゲッティコードを専門としており、構文的に実装されたIDEがなければ従うのが難しすぎる識別子を使用しています。 例（IndexI1O0、Index1I0Oなど）. - サマーインターン-特にサブタイプの歩行災害
私の古い店は、高校や大学の後半のインターンを何人か雇っていました。ある部門で、一部の機器の使用状況を追跡するために小さなデータベースが必要でした（現在、これは前向きで、dBase IIIを使用していた）。男は夏の間ずっとコードを書いていましたが、大学が秋に始まったときには行われていませんでした。彼は1週間の延長を取得し、次に2週目を取得しました。 2週目の終わりに、彼のプロジェクトを引き継ぎ、システム開発に戻して完成させるために派遣されました。彼は私に彼がやったことを見せて、それから未完成の部分を見せました。うまくいったのは素晴らしいアイキャンディでしたが、アプリケーションは だった 不完全な。フォーマットされたフロッピーの新しいボックスを開いてコピーを取得したとき、彼は「ちょっと待って、テストファイルを削除させて...」と言い、何も言う前に彼はたくさんのファイルを削除しました。
疑わしい種類であり、私が自分の店に戻ったときに彼のアプリケーションがほとんど目立たないことに気付いたので、私は部門に戻り、ノートンを引き出し、削除したファイルを元に戻し、削除しようとしました。たとえ不完全であっても、いくつかの追加のロジックを見つけます。
私は見つけました、悪い論理ではなく、悪い振る舞い。彼が使っていたPCに接続されているプリンターは、デイジーホイールプリンターでした。通常マウントされる文字セットは、スイスのバリアントでした。削除されたプログラムの出力は、名前、住所、DOB、いくつかの文字コード、およびいくつかのタイプのID番号を出力します。フォーマットとレイアウトが気になりました。複数の人々のすべての生年月日はかろうじて合法的な飲酒年齢でした。十字形のディレクトリで調べたところ、ほとんどのアドレスはありませんでした。印刷物を上司に見せたところ、彼は私を見て「運転免許証ですね」と言った。私はそうしたと言った。そのため、Xeroxの隣のゴミ箱にある透明素材がすべて削られたのです。私たちの悪い男の子は、彼と彼と彼の友人の年齢を彼らの運転免許証で調整するためにオーバーレイを作りました。当局に報告しました。彼はnotの最後の2週間の支払いを受け取りました。
これらは、私が一緒に作業しなければならなかったいくつかの悪いキャラクターです...
/ s/BezantSoft
当然のことながら知識や能力の欠如は別にして、プログラマがコードを読みにくく、かつ/または必要以上に保守しにくい場合、プログラマは悪い人です。
今後のテクノロジーに適応できない
他の誰も彼のコードを読むことができないとき。あなたがどれだけ明るいかは関係ありません。プログラマーは島ではありません。
プログラマーには、ソロとチームの2つのカテゴリーがあります。
悪いソロプログラマーは
- 単純なタスクを完了するのに時間がかかりすぎた人。
- 自分で何をしているか調べられない人。
- 今日コーディングされたものを数日で忘れてしまい、自分のコードベースをうまく維持できない人。
- 要件に対応できない人は変わります。
悪いチームプログラマーは、以下を含む悪いソロプログラマーのカテゴリに分類されます。
- 他のチームメンバーと調整できない人。
- 批判を歓迎しない人。
- 他の人に役立つ方法や他のチームメンバーから利益を得る方法を知らない人。
- 読みやすいコードを書くことができない人。
- 他の人に読みやすくするためにコメントしない人。
詳細に注意を払わず、常に「機能するので、そのままにしておきます。ログ内のこれらの例外はすべて重要ではありません」モードになっている人。
私の経験における大きな警告サインは、彼らがハックについてコメントしないときです...
あなたは私が何を意味するかを知っています：あなたがそれを行うためのより良い方法が単にないのであなたが非常にハックをすることを強いられているとき。
優れたプログラマーは、そうする必要があることを嫌い、そのようなハックを行うことをどれほど嫌うかをインラインコメントに入れますが、選択の余地はありません。悪いプログラマーはハックを入れるだけでコメントはしません。
彼らが答えを知らないことを認めたくない、および/または物事を調べたくない。
あなたがそれを知らないなら、あきらめないでください-それを理解して、それを成し遂げてください。
rightを繰り返し行う方法を示し、繰り返し簡単に行うだけです。
プログラマーがたくさんのコードを書くとき、明らかに静かです。非常に大きな関数、おそらく行またはコードブロックをコピー/貼り付け、必要に応じてさらに多くを使用するなど。これは、プログラマが自分のやりたいことを実行するための標準関数を知らないために、ほとんどの場合それができないためです。
私は質問を閉じた重複したトピックからここに私の答えを移動しています あなたが悪いプログラマーであるかどうかを認識できますか？ 私が私の応答を作成していたときに他のトピックが閉じられていました。私の回答は、他の質問者が言った質問をより直接的に扱っており、それを理解すればよりよく読めます。
はぁ！私の一部は既に忙しいこのトピックに追加したくありませんでしたが、私の他の部分は勝ちました！なぜ勝ったのか。なぜ私はこの特定のマルチログにさらに多くの単語を追加するのが面倒なのですか？まあ、ある程度、これまでの多くの解説者とは少し違う見方をしているかもしれないからです。
バイナリはコンピュータでうまく機能します。「1」または「0」、「オン」または「オフ」です。これらの有名な2つの状態を使用して、多くの情報を抽象化およびエンコードできます。しかし、「良い」または「悪い」、「正気」または「非常識」、「良い」または「悪」、「賢い」または「愚かな」「脂肪」など、人間の問題にはあまりうまく機能しない傾向があります。または「薄い」、「生きている」または「死んだ？」この種の二極化した評価は常に、思いやりのある人間を私の一部にひどく満足させていません。私が適用することを選択した測定スキームによって、私は通常、そのような明確なコントラストに対する答えは、実際には、どちらか一方の極ではなく、一方の極と他方の間の連続体に沿ったどこかにあることに気づきます。
私はかなり長い間、この分極化傾向と戦ってきましたが、私の個人的な解決策は、そのような評価に3つの単語を適用するほうがはるかに便利だということです：「どの程度！ 「
だから、あなたの質問への私の答えは、あなたがそれを言い換えることを提案し、これをあなた自身に尋ねることです：「私はどの程度私は悪いプログラマーですか？」または、さらに良いことに、「私はどの程度私は優れたプログラマーですか？」真実を追求すれば、「悪い」プログラマーと「良い」プログラマーの間の連続体のどこかに自分がいるかもしれません。次に、このパスに沿ったおおよその位置を特定できれば、おそらく「良い」端にいくらか近いポイント、つまり近い将来に自分を見つけたいポイントを特定できます。
そのポイントを遠くに設定しなければ、おそらく後端をギアに入れ、その方向に動かし始めることができます。この単純なヒューリスティックアルゴリズムを何回か繰り返し実行すると、プログラミングが忙しくなりすぎて、この質問を再度行う必要が出てきます。ああ、そしてキーボードでドキドキするコードをできるだけ早くそして頻繁に開始すれば、おそらくより速く進歩するでしょう。そして、あなたがたまに少し休憩を取るなら、あなたの仲間によって書かれたいくつかの高品質のコードを読んでください！ダイナミックなオープンソース開発の今日では、学ぶべき無料の絶妙なコードが不足していません！
だから、私はあなたに「どの程度」という私の3つの短い言葉を試してみて、どれだけ良い方向に進むことができるか見てみることを強くお勧めします。
SOLID、DRY、OOPなど）の原則を知らない人。特定のテクノロジーを知るのではなく、プログラミングの原則と基礎をよく理解することが重要です。基礎がしっかりしているものは、新しいトピックを簡単に学ぶことができ、より良いコードを生成します。
悪いプログラマーと初心者プログラマーを区別する1つのことは、彼らが働いている言語とAPIで好きなシステムを実装するという頑固な主張です。
私はかつて、以前の開発者がカスタムdbfアクセスライブラリの上に階層化されたAshton Tate DBase III + apiの大規模なセットを（Javaで）再実装したシステムを継承しました。 Javaコレクションフレームワークは使用されませんでした。
これは、彼がDBase III +（またはおそらくクリッパー）アプリのように見え、動作するJava/swingアプリを作成できるようにするためです。
このシステムで彼が書いたアプリにはライトバーメニューがありましたライトバーをオプションに移動すると、下部にボタンの列があるフルウィンドウフォームが開きます。それは1980年代にさかのぼる小さなタイムマシンのようなものでした。
その男は明らかに熟練した開発者でした。彼は、そのプロジェクトの時間枠でシステム全体を自分で作成できることを十分に知っていました。また、他のいくつかの内部システムで再利用することもできました。
しかし、彼のコードは彼が取り組んだシステムの機能を誤用したという点で、ひどいプログラマーでした。彼は、Java/Swing/SQLを学ぶよりも、疑わしい利点のカスタムライブラリに3か月を費やすことに前向きでした。
「出来ない」と言う人。
私の意見では、それはすべて問題解決に関するものであり、ツールは実際に作業を行うよりもはるかに関連性が低いはずです。 MS-Accessまたはアセンブリ言語を使用して解決する必要がある場合、それは「それを行うことができない」という問題ではなく、時間とお金の問題です。
警告サインは、物事を行うためのアカデミックで「適切な」方法に焦点を合わせすぎており、作業を完了することに十分に焦点を合わせていません。
彼が言語の構文だけを知っていて、アルゴリズムの基本的な概念を知らない場合。
彼らは多くの有益なことをするが、ほとんど生産しないとき。
割り込みやマルチタスクをよく理解していない組み込みプログラマ。また、ビットフィールドを操作する必要があるが、それらの論理演算やシフトを把握していないプログラマー。
即時認識信号は、「なぜそれが機能しないのかわからない。すべてを正しく行った」と誰かが言っています。
！（スマートで物事を成し遂げる）
今日、多くのプログラマーは、この複雑さはプログラム内でよく理解されている少数のテクニックのみを使用することによって管理するのが最善であると信じています。彼らはプログラムが持つべきフォームについての厳格なルールを作成しました、そしてそれらの間でより熱心な人は悪いプログラマーとしてこれらのルールを破る人を非難します
他の場所からコードをコピーして貼り付けるだけで、実際にコードがどのように機能するかを理解していないプログラマーは、悪いプログラマーとして知られています！私は通常、JavaScriptでこれを確認します。
プログラマーがプログラミングが苦手な唯一の方法は、他の人の話を聞くのをやめることだと思います。
プログラミングは情報に関するものです。耳と目を大きく開いておく必要があります。
プログラマーは本にぶつかり、一生懸命に努力することによってのみ改善することができます。ただし、同じことを何度も学ぶのではなく、新しいことを学ぶことにも焦点を当てる必要があります（特定の分野/業界で新しい経験を探す）。
幸運を。