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

私は新しい開発者です-これが私の最初のプログラミング職です。 私の問題はこれです：私たちは使用しますgit-私はブランチからブランチを切り取り、develop割り当てられたマイナータスクの作業を開始します。私は経験が浅いので、とても遅いです。ブランチをdevelop他のブランチにマージする準備が整うまでに、多くの変更を行って競合を解決するのは圧倒的です（実際、作業を破棄してタスクをやり直すのは簡単なようですが、もちろん持続可能なソリューションではありません） ）。 どうすればこれを克服できますか？「コーディングが上手」以外の方法を使用できますか？私は来週、これを上司に報告するつもりです。

223 git  software  branching  merging 

ハードウェア/ソフトウェアインターフェースおよびオペレーティングシステムに関する初心者向けコースでは、多くの場合、ハードウェアの一部をソフトウェアに、またはその逆に置き換える方が良いかどうかというトピックが出てきます。接続できません。

90 interfaces  operating-systems  software  hardware 

Murray Gell-Mannが、Richard Feynmanがどのように多くの困難な問題を解決したかを尋ねられたとき、Gell-Mannは、Feynmanにアルゴリズムがあったと答えました。 問題を書き留めます。 真剣に考えてください。 ソリューションを書き留めます。 ゲルマンは、ファインマンが別の種類の問題解決者であり、彼の方法を研究することから得られる洞察がなかったことを説明しようとしていました。中規模/大規模のソフトウェアプロジェクトの複雑さを管理することについても、同じように感じています。優れた人々は本質的にそれが得意であり、何らかの方法でさまざまな抽象化を積み重ねて積み重ねることで、無関係な問題を引き起こすことなく全体を管理可能にします。 ファインマンアルゴリズムは偶発的な複雑さを管理する唯一の方法ですか、それともソフトウェアエンジニアが偶然の複雑さを抑えるために一貫して適用できる実際の方法がありますか？

74 design  project-management  software  complexity 

たとえば、Autodesk Mayaの規模と複雑さのコード、2千万から3千万行以上のコードについて話しています。 必要に応じて開発をフリーズした場合、単一のバグがなくなるまで、すべてのバグを実際に修正できますか？バグのないシステムの存在に対する賛否両論は何ですか？ 修正するたびにバグが増えるという考えがあるため、それは真実ではないと思います。 バグとは、UIの最も単純なタイプミスから、回避策のないより深刻な予防バグまでを意味します。たとえば、特定のスクリプト関数は法線を正しく計算しません。また、回避策がある場合でも、問題を解決する必要があります。したがって、提供された関数を使用する代わりに、この特定のことを手動で行うことができますが、その関数はまだ修正する必要があります。

71 programming-practices  bug  software  complexity 

潜在的な顧客やユーザーが製品をテスト実行できるようにするために、無料試用版とフリーミアムモデル（つまり、機能が制限された機能や削除されたソフトウェアの無料版）との継続的な議論があります。私の研究では、無料試用版は、ソフトウェアを使用する個人のユーザーエクスペリエンスの利点と、販売と使用の最大化の両方の面でベンダーの利益の両方を実現する方法であると結論付けることができます。無料試用版ソフトウェアには、無料試用期間の長さなど、ユーザーの使用を大幅に最大化できる多くの要素があります。 「フリーミアム」の研究で繰り返し出てくるキーワードの1つは「フラストレーション」です。多くの個人は、一部の機能が利用できないソフトウェアを使用する代わりに、ソフトウェアをアンインストールすることを選択しました。同時に、これらのユーザーは「有料」機能を使用する機会がありませんでした。彼らには知られておらず、ソフトウェアを販売している独自のベンダーに隠されているため、Proの機能がもたらすメリットを知りません。最初にそれらを使用する必要がなければ、ユーザーは自分が何かを「必要とする」感覚を持っていることを知りません。これは、無料試用モデルの次のポイントに私を連れて行きます。 無料試用版ユーザーの意見は、「Pro機能なしでこのソフトウェアを使用することは想像できません」です。これは、「ユーザーが最初に持っている感覚を理解するまで、何かが必要なことを知らない」という点に戻ります。「フル」バージョンの機能を使用するために14日間の猶予がある人は、そこに提供されている機能を持たない、または使用しないと想像できないと言いました。そのため、14日間が過ぎたとき、彼らは完全な機能を経験したことがない人よりもお金を使い果たす可能性が高くなりました。無料トライアルの期間も、ユーザーに永続的な印象を与える重要な要素です。Visual Website Optimizerが実施した実験では、14日間の無料トライアルと30日間の無料トライアルでは、サインアップとインストールの数は同じであるが、14日間のトライアルの使用率は102％増加したことがわかりました。 言及する別の非常に重要な点は、「有用で完全に機能する製品の無料バージョンを提供すること」が非常に重要であることです。完全に機能する無料試用版はメディアの報道に効果的であり、新しいソフトウェアやソフトウェアベンダーに対するこの宣伝は非常に重要です。 もう1つの関連する側面は、ユーザーがフィードバックを提供することの重要性です。完全に機能する期間限定無料トライアルでは、ユーザーがフィードバックを提供できることを考慮してください。 ソフトウェアにとって重要なもう1つの機能は、テレメトリックデータ、つまりユーザーがソフトウェアを使用する方法に関する定量的かつ包括的なデータの必要性です。法律は米国の場所と世界によって異なるため、使用統計の一部は法的な灰色の領域に分類される場合があります。この法的問題に対処する1つの方法は、匿名の使用統計を収集するためのオプトイン機能を使用することです。オプトイン機能とは、統計情報の収集をオフにするオプションをユーザーに提供することを意味します。同時に、ユーザーは匿名の使用状況情報の収集が何を行うかを十分に認識している必要があります。どのデータを収集するか、「私たち」がそれを使って何をするかをユーザーに明確にし、いつでも簡単にオフにすることが重要です。ユーザーの個々のアクティビティの追跡など、より詳細な統計情報については、法的問題につながる可能性があります。Eclipse IDEは詳細な使用統計を記録しますが、ユーザーの完全な同意によって記録します。法務チームと同意書を作成する必要がある場合があります。 Eclipse Usage Information Collectionは、次の情報を収集します。1.システムによって開始されるプラグイン。2.キーボードショートカットを介してアクセスされるコマンド、およびメニューまたはツールバーを介して呼び出されるアクション。3.エディターの「ビュー」にフォーカスが与えられたとき。4.使用されているソフトウェアのバージョン、使用されているオペレーティングシステムなどのシステム情報。5.内部エラーの説明。 緊急停止装置 ソフトウェアのキルスイッチは、初期データを記録し、ソルトで暗号化して管理できます。無効な日付になると、つまりユーザーが変更しようとすると、ソフトウェアが無効になります。別のオプションは、インストール時にインターネット認証を行い、その日付を中央のWebデータベースに記録し、アプリケーションを開くたびに日付を確認することです。 ソフトウェアを無効にすると、重要なDLLを削除できます。レポートを生成するために支払う必要があるオプションは考慮できません。 既存のソフトウェアに無料試用版を実装することに興味があります。私は最後の14日間の試用を計画しています。14日目に、私のソフトウェアはユーザーに有料版の代金を支払うか、それを使用できないという結果をもたらすように促します。無料試用版は完全にロック解除されています。つまり、すべての有料機能があります。 しかし、私のジレンマは、試行終了ソリューションのために何をすべきかを実装する「最良の」方法に関するものです。重要なDLLを削除しますか？インストールまたは使用時にユーザー認証システムを使用していますか？使用する最初の時間と日付をソルトで暗号化し、無効な日付（つまり、最初の日付を変更しようとする）である場合、ソフトウェアを無効にしますか？ ソフトウェアを無効にするための効果的な手段は何かを知りたいです。

52 software  development 

卒業（2005年後半）以来、私はc ++ソフトウェアエンジニアと同じ会社で働いていました。1年前、私はソフトウェアアーキテクトとして昇進しましたが、資格の取得とバグの修正、レベル2サポートにますます関与するようになりました。 私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったのかを把握するために費やしました。30％が他のバグを修正し、残りの（存在する場合）開発者のスパゲッティコードをレビューします。 私はこの製品を嫌い、この会社の出口戦略について考え始めました。 この状況で私にできることは何だと思いますか？他のソフトウェアアーキテクトはまだコードのバグを修正していますか？

45 architecture  teamwork  software 

事例：私は会社で働いており、配列で大量のデータを処理するPythonでアプリケーションを作成しています。私は現時点でこのプログラムの唯一の開発者ですが、おそらく他のプログラマーによって将来（1〜3年）に使用/変更/拡張される可能性があります。私はおそらく直接その場にいませんが、時間があれば電子メールでサポートを提供するかもしれません。 そのため、関数型プログラミング（Haskell）を学んだ開発者として、たとえば次のようなフィルタリングを解決する傾向があります。 filtered = filter(lambda item: included(item.time, dur), measures) コードの残りの部分はオブジェクト指向です。私にとっては、はるかに単純で美しいため、このように解決したいのはほんの一部のケースです。 質問：今日このようなコードを書いても大丈夫ですか？ FPを作成/学習していない開発者は、このようなコードにどのように反応しますか？ 読みやすいですか？ 変更可能ですか？ 行が何をするのかを子供に説明するようなドキュメントを書くべきですか？ # Filter out the items from measures for which included(item.time, dur) != True 上司に聞いたところ、「FPは黒魔術ですが、うまく機能し、最も効率的なソリューションであれば、使用しても構いません」と彼は言います。 これについてのあなたの意見は何ですか？非FPプログラマーとして、コードにどのように反応しますか？コードは「グーグル可能」であるため、その機能を理解できますか？これに関するフィードバックをお待ちしています。

43 python  functional-programming  software  company 

誰もがソフトウェア開発のレガシーコードについて語っていますが、過去10年間に、コードベースを悪いものとして表現するために使用される用語を聞いたことがあります。 プログラマにも同様に強力な意味合いを持つこの用語はどこから生まれたのでしょうか？ この用語を開拓したソフトウェア開発に関する本が必ずあるはずです。「レガシーコード」という用語の起源を特定したいと思います。

28 terminology  history  software  legacy-code 

あなたが会社で働いていて、あなたがしていることは彼らのためにソフトウェアを開発しているとしましょう。あなたは全体像を知らないか、わずかかもしれません。あなたが持っているのは、問題追跡システムを介して割り当てられたタスクです。タスクが与えられ、タスクがそれらを説明するように動作させ、送り返します。2つの整数を追加するのと同じように： function add(a,b){return a + b;} しかし、後でプロジェクトが進むにつれて、addより複雑になるにつれて、パラメーターを追加して値を返す関数だけでなく、何らかのアーキテクチャが必要になっていることに気付くでしょう。しかし、あなたはそれを知りませんでした。そもそも、彼らが必要とするのはその単純なことだけでしたadd。addがそれほど複雑になるとは思わなかった。 プロジェクトはより多くの機能を備えて進行しますが、そもそもこれは期待していなかった機能です。そして最後には、既存のコードを壊したり書き換えたりすることを避けるために、ハッキングを積み重ね続け、関数のレイヤーを重ねます。 これらの状況にどのように対処しますか？「最低開発者」としての技術的負債とどのように戦いますか？ 明確化： あなたは「実装者」であり、階層の最下位です。 問題は見えますが、問題については発言権がありません。 技術的な負債を定量化したり、ツールを探したりするわけではありません。 3番目の「重複」について リファクタリングとリライト-あなたはあなたのタスクにロックされています。あなたは余分に行うために支払われていません。 アーキテクチャの概要-システム全体は知っていますが、アーキテクチャについてはわかりません。 コードフリーズ-電話ではありません。あなたは管理者ではありません。 モジュール化-アーキテクチャのアイデアはありません。モジュールは要件の変化に応じて変化します。 自動テスト-なし。

20 architecture  software  scalability  maintainability  technical-debt 

私たちは約200人の開発者で構成される組織であり、特定の日にリリースされる予定の1つの製品（リビジョン管理Gitを使用）で継続的に作業しています。 開発者が非常に多いため、各チームに約10人の開発者がいる「クロスファンクショナル」チームを作成しようとしています。その結果、組織内に約20の開発チームができます。 メインリポジトリ内の製品の継続的な「高水準」（開発者がプルするとき、製品が少なくともコンパイル可能であることなど）を維持したいので、何らかの品質ゲートを使用したいと思います。 質問の言い方が少しわかりませんが、単一の製品に取り組んでいるこのような大規模な開発者グループの開発方法論に関するアドバイスを得ることができるかどうか疑問に思っています。 私たちの意見では、スペクトルの一端は各開発者がメインリポジトリに直接コミットできるようにすることですが、開発者/コミットの数が多いため、「メインリポジトリ」が常に壊れた段階にある可能性があることを恐れていますコミットごとに厳しい「品質ゲート」を持つことはできません。 スペクトルのもう一方の端は、（メインリポジトリ）に3つのプルソースのみがあり、これら3つに少数の信頼できるプルソースのみがあるツリーまたはピラミッド構造のようなものです（Linus Torvalds / Linuxが行うと思います）しかし、そのような構造では、変更が「メインリポジトリ」に入るために登るには長いチェーンがあると感じています。さらに、マージの競合が発生した場合、「元の開発者」以外の別の開発者に問題が発生します。 この背景情報と意見をすべて述べた上で、非常に多くの開発者に推奨される開発方法論をどのように学び、読むことができますか？大規模な組織（Microsoft、Facebook、Ubuntuなど）はどのように開発を構成していますか？

19 agile  workflows  software  development-methodologies  gitflow 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 Stephen Schachによると、「古典的およびオブジェクト指向のソフトウェアエンジニアリング」、第6章： モジュールは、プロシージャ、関数、またはメソッドが呼び出される方法で呼び出すことができる単一のコードブロックで構成されます これは非常に曖昧で広いようです。だから誰もそれを明確に説明し、要件をモジュールに分割する方法の実際の例を示すことができますか？ありがとう。

18 software  modules 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 7年前に閉鎖されました。 GNU GPL、BSDライセンス、MITライセンス、LGPLなど、あらゆる種類のソフトウェアのライセンスを見てきました。「John Doeの汎用ライセンス」など、新しいソフトウェアライセンスを作成するプロセスは何ですか？

17 licensing  software 

企業が許可されたライセンスのオープンソースアプリケーションを取得し、アプリケーションの広範な部分を修正し、新しい機能を追加し、バグ修正を適用することにより、それからクローズドソースアプリケーションを開発した場合... ライセンス要件を無視しています... 移行はどのように行われ、異なるライセンスを選択する以外にそれを防ぐために何ができますか？ 会社の（倫理的または社会的）責任は何ですか？（例：オープンソースプロジェクトに戻ることは倫理的なことです） オープンソースバージョンとクローズドソースバージョンの両方が利用可能な場合、競合はどの製品に影響しますか？ 過去にこれを（成功または失敗のいずれかで）行った企業または製品の例はありますか？これらのプロジェクトに対するコミュニティの態度はどうでしたか？

16 open-source  software  closed-source  proprietary 

ですから、私が取り組んでいるプロジェクトは今、無期限に凍結されます。プロジェクトが再びフリーズ解除された場合、そのプロジェクトが私または現在のチームのメンバーに割り当てられない可能性があります。実際、以前に凍結した後、プロジェクトを継承しましたが、プロジェクトの基本的なニーズを理解するのに役立つ前のチームには何も残っていなかったため、プロジェクトをよく知るために多くの時間を無駄にしました。私の質問は、私たちの後の人々がプロジェクトのニーズ、私たちがやったこと、なぜやったのかなどを最もよく理解するのを助けるために何をすべきだと思いますか。このプロジェクトで動作する他のトラックへのいくつかのトラック。 すでに行ったいくつかの手順： 技術文書（完全ではありませんが、少なくともいくつかあります）。 ソース管理システムの履歴。 プロジェクトのどの部分を改善する必要があるのか​​、そしてなぜそうするのかについての見積もり。 ユニットテストの束。 私たちがやったすべてのチケットで問題トラッカー（EDIT） 私たちがすでに準備していること、他に何ができるかについてどう思いますか？

14 project-management  software  knowledge-transfer 

アジャイル手法を使用してアプリケーション全体を書き直さなければならないとしたら、どうしますか？ 現在のシステムの動作に基づいて、多くのユーザーストーリーを作成できると思います。そして、それらを小さな反復で実装します。しかし、これは私たちが前方に要件を持っているという意味ではないでしょうか？ また、いつリリースを開始しますか？アジャイルは、早期かつ頻繁にリリースすべきだと言っていますが、完全な書き換えが完了する前にリリースすることはあまり意味がありません。

13 agile  scrum  software  extreme-programming  rewrite