ソフトウェア工学

多くのソフトウェア開発者が、アップグレード後にアプリケーションを破壊する関数の名前を変更するなど、多くのことを変更することにより、オープン/クローズの原則に違反するのはなぜですか？ この質問は、Reactライブラリの高速バージョンと継続バージョンの後に私の頭に飛びつきます。 短い期間ごとに、構文、コンポーネント名などに多くの変更があります。 Reactの今後のバージョンの例： 新しい非推奨の警告 最大の変更点は、React.PropTypesとReact.createClassを独自のパッケージに抽出したことです。どちらもメインのReactオブジェクトを介して引き続きアクセスできますが、いずれかを使用すると、開発モードのときに1回限りの非推奨警告がコンソールに記録されます。これにより、将来のコードサイズの最適化が可能になります。 これらの警告は、アプリケーションの動作には影響しません。ただし、特にconsole.errorを失敗として扱うテストフレームワークを使用している場合、フラストレーションが発生する可能性があることを認識しています。 これらの変更はその原則の違反と見なされますか？ Reactのようなものの初心者として、ライブラリ内のこれらの高速な変更でどのようにそれを学ぶのですか（とてもイライラします）？

74 design  object-oriented  javascript  reactjs  upgrade 

linuxdevcenter.comのStephen Figginsによるこの2003年の記事では、Bram CohenのBitTorrentは「すべてを修正」デザインパターンを使用していると説明されています。 どちらもBitTorrentを把握するのを難しくしますが、研究に値するあまり一般的ではないアプローチは、Cohenのi等性の使用です。プロセスを複数回適用してもそれ以上変更されない場合、プロセスはprocess等です。Cohen氏は、「すべてを修正」と呼ばれるデザインパターンを使用すると言います。これは、何が変わるかを実際に気にすることなく、多くの変更に反応できる機能です。彼は、「あなたは起こった出来事に注意し、そしてこの非常にwritten等な方法で書かれたすべてを修正する関数を呼び出し、起こっているかもしれないことをすべてクリーンアップし、ゼロからすべてを再計算する」と説明する。べき等性は困難な計算を簡単にしますが、少し複雑になります。コールが変更される場合、それが常に明確になるとは限りません。事前に知る必要はありません。関数を自由に呼び出すことができますが、 これは一見するとかなりいいですね。 ただし、べき等の「すべてを修正」関数を呼び出すと、効率を犠牲にしてシステムの堅牢性を向上させ、潜在的に収容システムを混乱させる可能性があります（慎重に計画して実行するプロセスを好む可能性があります）。 ただし、以前に使用したとは言えません。また、彼のアプリケーションのソースをオンラインで見つけることはできません（ただし、これに基づいていると主張するこのソースは見つかりました）。また、この記事以外で参照することもできません（そして、私のgoogle-fuはかなり良いと思います）が、SOApatterns.orgで「べき等機能」のエントリを見つけました。 このアイデアは別の名前でよく知られていますか？ 「すべてを修正」デザインパターンとは何ですか？長所と短所は何ですか？

74 design-patterns 

私が見たほとんどのアーキテクチャは、関数呼び出しの前にコンテキストを保存/復元するために呼び出しスタックに依存しています。プッシュおよびポップ操作がほとんどのプロセッサに組み込まれているのは非常に一般的なパラダイムです。スタックなしで動作するシステムはありますか？もしそうなら、それらはどのように機能し、何のために使用されますか？

74 computer-architecture 

したがって、アジャイルは初めてですが、テスト駆動開発ではありません。大学の私の教授は、テスト、コード、そしてテストのアイデアについてすべてでした。理由がわかりません。私の観点からは、多くの初期費用であり、おそらくコードが進化するにつれて変更されるでしょう。 これが私がTDDを想像し、それが私を混乱させる理由です。TDDの請負業者として家を建てる場合。 すべての仕様（ストーリー）を教えてください。 仕様の承認を取得します。 すべての仕様を検査に分解します（今後参照してください）。 検査官に電話してそれらの点を見て、今私は検査に失敗していると教えてください（ありがとう）。 家を建て始めます。 インスペクタを毎日コールバックします（2/100を渡します）。 ああ、私の理解に問題があったので、今度は9つの検査を追加して、27を変更する必要があります。 1/109を渡すインスペクターを呼び出します。 畜生。なぜインスペクターはこのようなものではないのでしょうか...ああ、そのメソッド名を更新しました... さらにビルドします。 UGGGGHHHHのその他の変更により、いまいましいインスペクタを更新できます。ああ、私は失敗していません。 もう終わった？ さて、それは奇妙なことかもしれませんが、すべてのメソッドをどのように知るべきか、そしてコードがそこに来るまでどのように機能するかはわかりません。99％の時間、戻ってユニットテストを更新する必要があります。ただ逆に思えます。 より適切と思われるのは、DDTまたは開発主導のテストです。これは、コミュニティが忘れてしまったことのように思えます。 私の理解では、家のDDTは次のようになります。 すべての仕様（ストーリー）を教えてください。 仕様の承認を取得し、それらを分割します。 ユニット（基礎）を開始します。 トリッキーなロジックのメモ（コメント）を取ります。 最後に次のユニットの検査を開始します（テストを作成します）。 見つかった問題を修正し、再度検査します。 このユニットが次のユニットに移動することを承認しました。 私たち全員が正直であるならば、それはより人間的で、開発者とビジネスに集中しているとは思わないでしょうか？変更をより速く行うことができ、オーバーヘッドなしでTDDが作成されるようです。

74 agile  tdd  development-methodologies 

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

74 design  project-management  software  complexity 

各ステートメントでswitch（多くの言語の）構造を使用する必要breakがあると誰が決定しましたか（また、どの概念に基づいていましたか）？ なぜ次のように書かなければならないのですか： switch(a) { case 1: result = 'one'; break; case 2: result = 'two'; break; default: result = 'not determined'; break; } （PHPとJSでこれに気づいた;これを使用する他の多くの言語がおそらくあります） switchがの代替である場合if、なぜと同じ構成を使用できないのifですか？すなわち： switch(a) { case 1: { result = 'one'; } case 2: { result = 'two'; } default: { result = 'not determined'; } } 現在breakのブロックに続くブロックの実行を妨げると言われています。しかし、誰かが本当に現在のブロックと後続のブロックを実行する必要がある状況に遭遇しますか？しなかった。私にとっては、break常にそこにいます。すべてのブロックで。すべてのコードで。

74 conditions 

私は16歳です。私は高校を始めようとした約1年前にプログラミングを始めました。私はプログラミングの仕事に就きますが、できる限り多くのことを学ぶために最善を尽くしています。最初に始めたとき、私は本からC ++の基本を学び、そこから自分で物事を学び始めました。今日、私は1年前よりもずっと経験を積んでいます。高校はプログラミングについて価値のあることを（おそらく）教えてくれないので、自分で勉強しなければならないと知っていました。 ここでの質問は、自分でプログラミングを学ぶことはどれほど重要ですか？

74 learning  self-improvement 

... 再スローせずにキャッチするのは本当に間違っていることに同意しますが、次のような構造を使用すると信じています。 try { // Stuff } catch (...) { // Some cleanup throw; } RAIIが適用されない場合に受け入れられます。（質問しないでください...私の会社の全員がオブジェクト指向プログラミングを好むわけではなく、RAIIはしばしば「役に立たない学校のもの」と見られています...） 私の同僚は、どの例外がスローされるかを常に知っておく必要があり、次のような構造を常に使用できると言っています。 try { // Stuff } catch (exception_type1&) { // Some cleanup throw; } catch (exception_type2&) { // Some cleanup throw; } catch (exception_type3&) { // Some cleanup throw; } これらの状況に関して、十分に認められた良い慣行はありますか？

74 c++ 

私が直面している問題は次のとおりです。 プロジェクトマネージャーからの引用： こんにちはSparkさん、多くの異なるiOSアプリケーションに使用できるフレームワークを開発するタスクを割り当てています。要件は次のとおりです。 UIの操作に使用されている親指または指の太さを検出できる必要があります。 この情報を使用して、UIのすべての要素を自動的に配置およびサイズ調整する必要があります。 親指を大きくするには、要素を画面の中央近くに配置する必要があります。 親指を小さくするには、要素を画面の角に近づけて配置する必要があります。 親指を大きくするには、すべてのフォントを小さくする必要があります。（この場合、大人を想定しています。） 親指を小さくするには、すべてのフォントを大きくする必要があります。（この場合、若い人を想定しています。） 概要： このフレームワークは、ユーザーフレンドリーなユーザーインターフェイスをプログラムで作成するために必要です。フレームワークは、必要な数のプロジェクトで使用できるように開発される必要があるため、開発者にとっても使いやすいものでなければなりません。 私はこのタスクを与えられた開発者なので、私の質問は次のとおりです。 これらの要件が少しばかげていることをどのように説明できますか？ 実際のプロジェクトの開発に専念する方が良いと説明するにはどうすればよいですか？ これが可能であったとしても、そのようなものを開発することはお勧めしません。 このプロジェクトに礼儀正しく、優しく、敬意を持ってノーと言うにはどうすればいいですか？ 3年の経験を持つ開発者であっても、これは不可能かもしれないことをどのように説明できますか？

74 project-management  iphone  frameworks  ios  requirements 

Cプログラムの実行中、データはヒープまたはスタックに保存されます。値はRAMアドレスに保存されます。しかし、タイプインジケーター（intまたは、char）はどうでしょうか。それらも保存されていますか？ 次のコードを検討してください。 char a = 'A'; int x = 4; ここで、Aと4がRAMアドレスに保存されていることを読みました。しかし、何についてaとx？最も紛らわしいのは、実行がacharとxintであることをどのように認識するのでしょうか？とは、RAMのどこかにintあり、char言及されていますか？ 値がRAMのどこかに10011001として保存されているとします。私がコードを実行するプログラムである場合、この10011001がaであるかどうかをどのように知ることがcharできintますか？ 私は理解していないことは、それはそれがあるかどうか、アドレスなどの10001から変数の値を読み取ると、コンピュータが、知っている方法ですintかchar。というプログラムをクリックすると想像してくださいanyprog.exe。コードはすぐに実行を開始します。この実行可能ファイルには、格納されている変数がタイプであるかどうかに関する情報が含まれていますintかchar？

74 c  data 

最近、Webアプリケーションを実行している人はすべてにMVCを使用したいと考えています。ただし、このパターンを使用するように説得することは困難です。一般的な考え方は、プログラムを表すフロントエンドからバックエンドロジックを分離することだと理解しています。一般的に、ビューは常にある程度コントローラーに依存しているようで、最終的にはモデルに依存します。コントローラーを追加することで得られる利点がわかりません。「これがアプリケーションの設計方法だ」という誇大広告をたくさん読んだことがありますが、どこに行くべきかがまだわからないかもしれません。私がMVCについて他の人と話すときはいつでも、誰がどのカテゴリに属する​​かについて異なる考えを持っているようです。 それでは、なぜMVCを使用する必要があるのですか？フロントエンドをバックエンドロジックから分離するだけでMVCを使用すると、何が得られますか？（このパターンのほとんどの「利点」は、インターフェイスを実装から分離するだけで得られ、別の「コントローラ」を持つ目的を説明できません）

74 design-patterns  mvc  rationale 

ストレスに対処することを学ぶことは、あらゆる仕事で働きながら健康を維持するために不可欠です。必要なサブタスクは、ストレスの原因を認識して制限することを学ぶことです。 しかし、毎日のグラインドの中で、ストレスの原因を認識することは難しい場合があります（特にプログラマーなどの集中的で集中的なペルソナの場合）。 プログラマーはどのような種類のストレッサーに注目すべきで、どのように管理できますか？

74 development-environment 

あなたの経験では、Javaの1つのクラスには何行のコードが多すぎるかについての有用な経験則は何ですか？ 明確にするために、行数は特定のクラスにあるべきものとそうでないものに使用する実際の標準にさえ近いものではないことを知っています。クラスは、適切なOOP哲学（カプセル化など）を念頭に置いて設計する必要があります。そうは言っても、経験則はリファクタリングの考慮事項の有用な出発点を提供することができます（つまり、「うーん、このクラスには> n行のコードがあります。ある時点でリファクタリングされます」）。 反対に、おそらく、OOP設計を順守し、長さにも関わらず読み取りと保守が可能な非常に大きなクラスの例に遭遇したことはありませんか？ これは、関数ごとの行に関する、重複しない関連する質問です。

74 java  programming-practices  refactoring 

私は最近、インタビューのために、Python、PHP、Rails、ASPを彼らのスキルの一部として挙げたプログラマーを雇いました。しかし、インタビューでは、彼らはインタビュー対象者が制御構造と基本ロジックが何であるかを十分に知らなかったため、デモチュートリアルをほんの数回しか従いませんでした。 だから私の質問はこれです：どの時点であなたは正確にあなたの履歴書に技術を追加することができます。すべての基本概念をデモンストレーションできる場合、便利なプログラムを作成できる場合、または30秒ごとにドキュメントを参照しなくても快適に使用できる場合です。 これが過度に主観的であるとは思わないので、フィードバックに基づいてベースラインを簡単に確立する必要があります。

74 skills 

採用プロセスに関与している人（マネージャー、インタビュアーなど）として、1〜2年ごとに転職した候補者についてどう思いますか？ 更新皆さんのすべての入力、いくつかの本当に素晴らしい反応、すべての投稿の良い情報に感謝します。私は過去5年間で現在3つの仕事に就いており、自分のポジションがどこにも行かないと感じているので尋ねました（フルタイムではなく、そもそもポジションが契約されていたはずです）。 ここでの私の唯一の選択肢は、私が本当に興味のないことや新しい仕事を探していることをやっている別のチームへの移行のように見えますが、最近の仕事の履歴はすべて短期間です。

74 communication