GUIプログラマーは他のプログラマーに比べて過度の利点がありますか?


23

マネージャーや顧客は、自分が見ることができるものに感謝するのは簡単です。

私は、設計原則やその他のプログラミングのイディオムについて最低限の知識しか持たない平均的なプログラマーである多くのGUI開発者を見てきました。ただし、プログラマーが印象的な外観のユーザーインターフェイスを作成できる場合、これらの欠点は、特に経営陣と顧客によって特に気づかれません。私が知っている多くのGUI開発者は、保守できない悪いコードを書くことを犠牲にしてGUIを美化するのに何時間も費やしています。

一方、APIやビジネス機能、またはデータベースコード(SQLなど)を開発する中間層プログラマーは、具体的に示すものが何もないため、不利です。おそらく、コードレビューアまたはアーキテクトは、コードの優雅さ、優れたデザイン、スケーラビリティなどを高く評価するかもしれませんが、外の世界にとっては何の意味もありません。あなたのコードは何年も壊れることなく実行でき、維持が非常に簡単で、優れたパフォーマンスを発揮しますが、滑らかなGUIのような「すごい」を引き出すことはありません。

私の意見では、これに対する帰結は、GUIプログラマーが良いクリーンなコードを書くためのモチベーションが低いということです(そして、私はこれに重く賛成するつもりです)。

編集:ここでは、GUIプログラマーによって、本格的なWeb / GUIデザイナーではなく、Javaスイングプログラマーなどのフロントエンドプログラマーであることを説明する必要があります。

コミュニティの他のメンバーは同意しますか?


6
フォント、ラベル、色、およびすべてを移動するための「愚かな」ユーザーリクエストで苦しむ必要があるのは誰ですか?あなたは善と悪を共にします。
ジェフ

@ジェフO:非常に本当です。データ構造に割り当てるメモリの量や、インデックスを作成するデータベーステーブルの列の選択を批判するユーザーはいません。
dan04

2
レイアウト(Swing、GWT、HTML、CSSなど)を処理する必要があるのは非常に苦痛であるため、それを処理する必要がないことは利点です。
Uri

@ dan04:科学の上級ユーザーと協力してみてください。彼らはいUIを喜んで使用し、データベース構造をめぐって何年も費やします(通常、古いスクリプトがそれを使用しているため、インデックス付けできない古いクラフトを保持しようと試みます)。Grr…
ドナルドフェローズ

ベーシストとバンドの残りの部分の違いのようなビット。バックグラウンドで多くのインポート作業を行いますが、他のベーシスト以外は誰も気づきません。
ゴードン

回答:


21

私はあなたの主張を見ていると思いますが、考慮すべき反対の問題もあると思います。

基本的に、UIはエンドユーザーの「顔に見える」アプリケーションの要素であるため、UI開発者はアプリのより深いレイヤーで作業するチームメンバーよりも高い可視性を享受することを提案していると思います。

確かに、私はより高い可視性があるかもしれないことに同意します。たとえば、UI要素に取り組んでいる開発者は、エンドユーザーとより頻繁に対話する可能性があります(おそらく、人間とコンピューターの対話の側面に焦点を当てているため、十分な理由があるためです)。

それでも、問題がある場合でも、より高い可視性が作用すると思います。たとえば、エンドユーザーは、そうでない場合でも、「GUIの問題」として問題を報告する可能性が非常に高いです。

すべてが認識に要約される可能性があり、成熟した組織は、作業するアプリのどのレイヤーからも独立して、さまざまなチームメンバーの価値、美徳、弱点を認識できる必要があります。成熟した組織は、「UI開発者」や「ビジネスレイヤー開発者」などの区別を超えて移動している可能性があります。とにかく全員がチームメンバーであり、おそらく異なる専門知識を持っていることを認識していますが、常に専門知識の分野でお互いを教育しようとしています。


1
そして、ほとんどの企業が誰が最高のプログラマーであるかを調べるためにユーザー調査を行うわけではありません。
-JeffO

1
+1。私はGUIで作業しており、「問題」があるときはいつでも、それが受信トレイに表示されます。問題の原因が下から来ることを「証明」する責任は私にあります。GUIプログラマーは、これらの美しいAPIの「純度」とユーザー要件の混乱を両立させる必要があります。
ベンジョー

10

プログラマーをまったく扱っていない人にとって、私は彼らがこの種のものを信じると自信を持って言うことができます。バックグラウンドで行われる作業の量はわかりません。表示されるのは、ボタン/テキストボックス/メニュー/ [GUI要素の挿入]の束と、ボタンが開始したことを達成するのにかかる速度です。だから、最初は、GUIの人はもっと好きです。

その人プログラマーを扱う場合、それは少し異なります。あなたが言ったように、スケーラブルにしたり、保守を容易にしたり、アルゴリズムをより意味のあるものに書き換えたり、その他のメンテナンスタイプのタスクを実行した場合に気付くでしょう。この種の人は、すべてのプログラマーを等しく見ます。

途中でそれはあなたの行動に依存します。この場合、速度が重要な要素になります。フォームが処理および保存されるのにかかる時間の記録の前後に表示でき、改善があれば、あなたは平等です。100台のクライアントから負荷のかかった状態でアプリを表示し、サーバーが溶けていることを表示してから、すべてが正常なバージョンを表示することができれば、あなたの平等です。等。


要するに、それは人とあなたが何をするかにかかっています。


8
過去5年間かそこらでインフラストラクチャ(SIPスタック)に取り組んでいる人として、+ 1-ほとんどの人はあなたが何をしているのか分からず、機能していないもの以外は特に目に見えません。配管工事について、あなたはどのくらい考えていますか?
フランクシェラー

6

私の会社の「UIエキスパート」として(デザインだけでなく、すべてのUI開発を担当している)、ストーリーの一部が欠落しているかもしれません。私はUIを担当していますが、バックエンドやデータベースなどにも取り組んでいます。私はすべてをしています(私たちは小さなチームです)。[C#およびASP.Net WebFormsの開発]

まず第一に、はい、それは人々に直面しているので、非技術者がGUI開発者の仕事を評価することははるかに簡単です。非技術者にとって、GUIはアプリケーションです。欠点は、GUIが何か問題が発生したときに最初に非難されることです。

第二に、フロントエンドの開発は、バックエンドよりもはるかに挑戦的でした(あいまい/複雑なアルゴリズムは別として)。守るべきものはまだまだあります。ステートレス(アプリはWeb上にあります)、ブラウザは一貫して動作しません(JavaScriptライブラリは天の恵みでした)など。この複雑さの大部分は私が持っているフレームワークによるものです(ASP.Net WebForms)で動作し、すべての困難なものは将来問題になりません。

全体として、バックエンドの問題よりもUIの問題を解決するのがずっと困難でした。


5

私は2つの理由でGUI開発が嫌いです。

  1. 私はグラフィカルな芸術よりも論理的であり、その結果、UIは常に苦しみます。
  2. UIはロジックに基づいていないため、ユニットテストはほとんど意味がありません。

しかし、結局のところ、私のコードはエンドユーザーに(おそらく、プロジェクトスポンサーに対して)、UIに精通している平凡な開発者のコ​​ードよりも高く評価されると思います。 。


4

(おそらく)@TheLQの答えを少し拡大するには、「ビューアー」にも依存すると思います。

私は、プログラミングのバックグラウンドを持っていないいくつかの上位レベルのマネージャー/スーパーバイザーでいくつかの経験をしました。一部の人はプログラミングしないことに感謝していますが、クロムとハブキャップはエンジンやシャーシと同じくらい重要であることを理解しています。

そして、UIのシズル以外のメトリックを気にしないいくつかの上位レベルのマネージャー/スーパーバイザーの経験があります。重要な場合は、よりUI指向の開発者であると述べることもあります。

私見、あなたは糞を磨くことができず、高速で信頼性がありながらyetいアプリは、見た目も機能も良いアプリよりもはるかに悪いことを知っています。それはすべて見る人の目にあり、ある程度、あなたはあなたと同じ資質を評価する人々のために働くことによって、あなたが望む光で見られる力を持っています(あなたが何をするかに関係なく)。

編集:私は追加するかもしれません、低レベルのアイテムでより快適に作業する人であると、UIチームと同じくらい一生懸命働くとき、私はうんざりしました。それは、システムがただ動いた」。しかし、私が言ったように、私は監督者がすべての分野で作業が必要であることを知っていることを知っています。


3

UI開発者は「ジュニア」開発者であるという一般的な推測があると思います。UIの人が先輩と見なされた場所に出くわした1つのケースしか考えられません。

とはいえ、UIはアプリの他のどの部分よりもずっと難しいと思います。そして、私はUXデザインについて話しているのではなく、コーディングについて話しているのです。数百ではないにしても数十、または考えられるシナリオを考慮しなければならない場所に、他にいくつの領域をコーディングしますか?画面のサイズを変更するだけでも、数十個の要素で何が起こる必要があるのか​​を把握する必要がある場合、王室の痛みになることがあります。これは主に、「800x600をサポートする必要がある」というガイドラインがあり、HD解像度以外のものを使用しないUXデザイナーがいる場合に発生します。

それで、彼らがより多くの露出のためにより良いものを得るならば、彼らはおそらくそれに値します。通常、彼らは良い受信側よりも間違った受信側にいることが多い。


3

多くの場合、GUIプログラマーはプログラマーチェーンの最下位にいるという考えがあるようです。VSのボタンをフォームにドラッグアンドドロップするのはどれほど難しいでしょうか?何、それをプログラムするのに一週間かかりますか?いくつかのバーを描画しています。ですから、ボタンドラッグをしているGUIプログラマーも恐ろしいコードを書かなければならないという考えに驚くことはありません。

GUIプログラミングには、いくつかのユニークな課題があります。データのロード中にGUIをアクティブに保つマルチスレッド。これは、スレッドセーフで適切なコードにつながります。パフォーマンスは非常に重要です。再びアプリケーションを制御できるようになるまで2分間待つのを好む人はいません。再利用性も大きな問題になります。10個の同様の画面を作成する必要がある場合は、コードを適切に構成することをお勧めします。これにより、コードが改善されます。そしてもちろん、優れたGUIを作成すること自体が課題です。

しかし、一部の人にとっては、ボタンをアプリにドラッグするだけです。一部の人々と同様に、ビジネスロジックは「メッセージを解析してDBに入れる」に過ぎません。


2

彼らがそうすることは明らかだと思います。おそらく一流の開発者の家は免除されますが、他のほとんどは免除されません。

先月、マネージャーがあなたに何をしたかと尋ねると、クールなGUIを簡単に表示できます。クールなAPIを示すのは難しいです。とても厳しい。APIのクールさは、実際に使用することによってのみ明らかになります-一目では理解できません。


1

内部システムのあらゆる種類のハッカーやショートカットを回避できます。GUIを扱うとき、その自由はありません。内部APIに矛盾がある場合があり、修正するのが難しすぎるため、コーダーが対処することを期待します。顧客に同じことをさせようとすることはできません。そのため、ある意味では、ユーザーに表示されるコンポーネントを処理する必要がある人々は、実際にはより高い基準に従う必要があります。


1

簡単な理由の1つとして、「はい」と言います。私がこれまでに話した人は皆、インターフェイスが滑らかなので素晴らしいと思いますが、そのすべてを可能にするのはその下の仕事だけです。


1

観客次第です。私は多くの金融アナリストと仕事をしており、彼らの優れたGUIデザインのアイデアは、1つのフォームにジャムできる限り多くのフィールドを持っているものです。真剣に、私は75-100を話している。彼らは常にもっと欲しいデータ中毒者だ。最近、ロードに45秒かかる可能性のあるいくつかのストアドプロシージャのパフォーマンスを改善しました(時間の始まりから加重平均を計算します)。30秒になりました。私はすごいと思っています、時間の3分の1を削減します それは私の履歴書の明細でなければなりません。誰も気づきませんでした。作業を続け、15-20になりました。顕著な変化。みんなとても幸せでした。私は今でもGUIは憎むべきものだと思っており、この役に立たないがらくたを取り除くと、2秒でロードされ、

したがって、ユーザーに本当にあなたを愛してもらいたいのであれば、最高のユーザーインターフェイスはインターフェイスではないことを覚えておいてください(誰がそれを言ったか覚えていたでしょう)。これらのすべてのデータを見たいと思った後、私のアナリストは、彼らがすべてのデータ入力を行うのがホラーであることに気付きました。


1

アプリケーションのUIパーツのテストは悪夢です。

周囲のすべての人は、アドバイスをしたり、どのように行うべきかを要求したりする能力があると感じています。

システムが正常に動作した後、誰かがその美徳を誰が誤って思い出したとしても、誰が何をしたのかを誰も覚えていないでしょう。

しかし、どのようなエラーが見られる場合(一部は常に起こる)、有罪判決をされた最初の男がGUIプログラマになり、ユーザは、単に他の人を見たことなかったん!

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.