ソフトウェア工学

約6か月間、オープンソースのiPhoneまたはiPadプロジェクトに参加してObjective-Cのスキルを磨くべきだと考えていましたが、それをするたびに巨大なプロジェクトで数千行のコードが表示されます最終的に私は理解できないだろうと自分自身を納得させます。私のコミットはプロジェクト管理者や上級コントリビューターにとっては面倒なものになるといつも思うので、私はいつも最後の瞬間に撤回します。 私の質問は本質的に、中級経験のあるプログラマーがオープンソースプロジェクトに参加するのは面倒ですか？

17 open-source  project 

コーディングを簡素化するために#defineを使用して完全なコード行を定義することは、プログラミングの実践として良いか悪いかについて意見はありますか？たとえば、大量の単語を一緒に印刷する必要がある場合、イライラするタイピングを取得します << " " << coutステートメントの単語間にスペースを挿入します。私はただできる #define pSpace << " " << そしてタイプ cout << word1 pSpace word2 << endl; 私にとっては、これはコードの明快さを加減せず、入力を少し簡単にすることもありません。通常デバッグのために、タイピングがはるかに簡単になると思う他のケースがあります。 これについて何か考えはありますか？ 編集：すべての素晴らしい答えをありがとう！この質問は、繰り返しタイピングを何度も行った後に私に届いたものですが、使用する他の混乱の少ないマクロがあるとは思いもしませんでした。すべての答えを読みたくない人にとって、最良の代替案は、IDEのマクロを使用して、繰り返し入力を減らすことです。

17 c++  coding-style  coding-standards 

なぜ型の弱い言語がまだ活発に開発されているのだろうか。たとえば、書くことができることからどのようなメリットが得られますか $someVar = 1; (...) // Some piece of code $someVar = 'SomeText'; 大きく異なる、型指定されたバージョンを使用する代わりに int someInt = 1; (...) string SomeString = 'SomeText'; 2番目の例で追加変数を宣言する必要があるのは事実ですが、それは本当に痛いのでしょうか？コンパイル時に型の安全性を強制し、型キャストの落とし穴を回避するため、すべての言語が厳密に型指定されるように努めるべきではありませんか？

17 weak-typing 

最近、私はHohpeとWoolfのEnterprise Integration Patterns、Thomas ErlのSOAに関する本を読んでおり、Udi Dahanらによるさまざまなビデオやポッドキャストを見てきました。CQRSおよびイベント駆動型システム。 私の職場のシステムは、高い結合に悩まされています。各システムには理論的に独自のデータベースがありますが、それらの間には多くの結合があります。実際には、これは、すべてのシステムが使用する1つの巨大なデータベースがあることを意味します。たとえば、顧客データのテーブルが1つあります。 私が読んだことの多くは、各システムがデータベースのみを使用し、メッセージングを使用して他のすべてのシステムに更新が伝播されるように、データの非正規化を示唆しているようです。 これはSOAの境界を強化する方法の1つだと思いました-各サービスには独自のデータベースが必要ですが、それを読んでみました： /programming/4019902/soa-joining-data-across-multiple-services そして、これは行うのが間違っていることを示唆しています。 データベースを分離することは、システムを分離する良い方法のように見えますが、今は少し混乱しています。これは良いルートですか？SOAサービス、DDDバウンドコンテキスト、アプリケーションなどでデータベースを分離することをお勧めしますか？

17 soa  integration  cqrs  eai  domain-driven-design 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 英国で非常に愛されているOrdnance Surveyマップを表示するWindows Phone 7アプリケーションを作成しました（他の誰もまだこれを行っていないことに驚いています）。しかし、人々が購入するアプリの実際の支払い方法を調査し始めたとき、アプリハブの支払いとアプリを市場に出すために£65を払おうとしていました。あなたが米国の開発者でない場合は、W8BENフォームなどのフォームの送信を開始する必要がありますか？この後でも、IRSはさらに30％を取得します（MSが30％のシェアを取得した後）。また、付加価値税についても言及しているので、この後、さらに多くのお金が奪われるかもしれません。 アメリカ国外の人が実際にすべての書類を整理して支払いを受けたことがありますか？税金も取られましたか？実際に売上げの何パーセントになりますか？それだけの価値はありますか？ 私はこのアプリから多くを稼ぐことは期待していませんが、65ポンドを取り戻し、ビールを数本買うのに十分な余裕があると思いたいと思います。

17 windows-phone-7 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 Linqの機能を提供することに近いJavaのライブラリはありますか？

17 java  linq 

並行プログラミングは私にとって非常に困難です。基本的なスライドを見るだけでも、私にとっては難しいようです。それはとても抽象的なようです。 コンカレントプログラミングの概念をよく知ることの利点は何ですか？通常のシーケンシャルプログラミングで役立ちますか？私たちのプログラムがどのように機能するかを理解することに満足があることを知っていますが、他に何がありますか？

17 concurrency 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Javaの2番目のコースを受講しています。データ構造に入ります。リンクされたリストで割り当てを行い、スタックになりました。リンクリストで苦労しました。スタックは少しトラブルを引き起こしましたが、はるかに簡単でした。 これらのアルゴリズムとデータ構造で苦労することを心配する必要がありますか？本当に把握していないように感じます。

17 algorithms  data-structures 

これは私自身の議論であり、私の同僚の何人かは、私がここに来て、それについて一般的なコンセンサスがあるかどうかを確認すると思います。 基本的に、データベースコールに関する次の2つの意見があります。1。データベースコールの数を減らすために必要なすべてを取得するために、1つの大きなコールを行います。 DB呼び出し これが特に効果を発揮するのは、一般的なコードです。Employeeクラスの例を使用しますが、これはかなり簡単です。 Employeeクラスに10個の値属性（名、姓、雇用など）があり、次に2つのクラス属性があります... 1はDepartmentクラスを指し、1つのスーパーバイザーは別のEmployeeオブジェクトを指しているとします。 考え方1では、従業員データと、Department属性とSupervisor属性を設定するために必要なフィールド、または少なくともこれらのサブオブジェクトから最も頻繁に使用されるフィールドを返す1つの呼び出しを行います。 考え方＃2では、最初にEmployeeオブジェクトのみを設定し、次に実際に要求された場合にのみDepartmentおよびSupervisorオブジェクトのみを設定します。 2のスタンスは非常に単純です。要求のサイズと、それらの要求のいずれかが行われるたびにヒットする必要があるデータベースオブジェクトの数を最小限に抑えます。＃1のスタンスは、適切に実装できたとしても、コードが複数の接続を作成しなければならないという事実が、Webサーバーとデータベース間の接続を減らすのではなく、より多くの負担を引き起こすということです。 この調査の背後にある原動力は、Webサーバーとデータベースサーバー間のトラフィック量が制御不能になっていることです。

17 database  coding-style 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 多くの開発者はUIデザインが得意ではないと言われましたが（これが本当かどうかはわかりません）、少なくとも私についてはそうです。 Web開発では、UI開発の優れたスキルがなければ、優れたコード開発スキルは十分ではありません。 だから、私と私のような多くの開発者にとって、半分のこと（良い開発スキル）しか持っていないので、デザイナーにお金を払う以外の残りの半分をどのように完了するべきでしょうか？ これに最適なソリューションは、ほとんど変更を加えずにオープンソースのWebテンプレートを使用することですか、それとも他のオプションがありますか？

17 web-applications  web-design 

アプリケーションの視覚状態の25の画面のモックアップが提供されたとします。これは、完成したアプリケーションとして開発し、元の利害関係者または顧客に渡すことができると確信するのに十分であり、満足することを期待しています。当然のことながら、UIを思い付くために使用された多くの質問を関係者に繰り返し求めることになりますが、これは無駄です。 しかし、これは十分ではないことが何度もあります。アプリケーションを開発する過程で、インターフェイスを複製しているために要件が曖昧になり、最終的に顧客が最初に思ったほど満足していませんUIを作成するためにすべての情報を要求したとき。 私は他に何を求めるべきか分からず、具体的になり、要件と全体的な目標の理解を求めましたが、私は何を求めるべきかわかりません。今始めたばかりの場合、UIに至るすべての情報を再ハッシュするのに多くの時間が無駄になり、この段階では、顧客が本来持っていた多くの重要な理由が失われます。 UIモックアップに基づいて要件をロックダウンできないことを人々に理解させるにはどうすればよいでしょうか？ エンドユーザー向けのアプリケーション開発タスクを適切に実行するために、理想的には何から始めますか？

17 design  specifications 

IronSchemeは、Wikipediaで IronLispと呼ばれる失敗したプロジェクトの後継として言及されており、ClojureがJVMに対して行うように、LispをCLRおよび.NETにもたらします。この言語の経験はありますか？かなり完成しているように見えます（99％）が、セットアップするのに時間をかける価値があるかどうかを判断する方法はわかりません。安定または完全ということは、単にツールやProject Eulerスタイルの問題をいじるのではなく、実際のプロジェクトに使用することを意味します。

17 .net  lisp  scheme  clr 

OOPのバックグラウンド（Java）から来て、私は自分でScalaを学んでいます。不変オブジェクトを個別に使用することの利点はすぐにわかりますが、そのようなアプリケーション全体をどのように設計できるかを見るのは大変です。例を挙げます。 「マテリアル」とそれらのプロパティを表すオブジェクト（ゲームを設計しているので、実際にその問題を抱えている）があり、たとえば水や氷があるとします。このようなすべてのマテリアルインスタンスを所有する「マネージャー」がいます。1つの特性は、凝固点と融点、および材料が凍結または融解するものです。 [編集]すべてのマテリアルインスタンスは「シングルトン」で、Java Enumのようなものです。 「水」は0℃で「氷」に凍結し、「氷」は1℃で「水」に融解すると言います。しかし、水と氷が不変である場合、それらの1つを最初に作成する必要があり、コンストラクターパラメーターとしてまだ存在しない他のものへの参照を取得できなかったため、コンストラクターパラメーターとして相互参照を取得できません。両方のマネージャーへの参照を提供することでこれを解決することができますので、彼らは凍結/融解特性を求められるたびに必要な他の材料インスタンスを見つけるためにクエリすることができますが、マネージャー間で同じ問題が発生しますそして、それらはお互いへの参照を必要としますが、それらのうちの1つのコンストラクターでのみ提供できるため、マネージャーまたはマテリアルは不変にできません。 彼らはこの問題を回避する方法がないのですか、それとも「機能的な」プログラミング技術、またはそれを解決するための他のパタ​​ーンを使用する必要がありますか？

17 design-patterns  immutability 

私たちは誰もがアジャイルな方法でやろうと言っているプロジェクトを持っていますが、アジャイルとは何かを明確に理解しているとは思いません。 以前のプロジェクトでは、計画会議を開いてから、製品バックログを定義し、2〜3週間のスプリントで開発者に作業を割り当てました。毎朝、スクラムミーティング（毎回1時間半行われているように見えた）があり、その後、各開発者がスクラムミーティングに参加しました。スプリントが終了し、完了していない作業が次のスプリントに追加されるまで、誰もテストを作成しませんでした。 開発者はお互いに話をすることはほとんどなく、開発に関与するTDDはありませんでした。実際、ほとんどの開発者は最初に仕様を持っていて、スプリントがアレンジされた2週間または3週間だけそれを使いました。クライアント/ステークホルダーとのコミュニケーションはほとんどありませんでした。 通常、QAは数か月後に関与し、それまでに要件が欠落していることがわかりました。これにより、必要な作業量がさらに増加し​​ました。明らかに、フィードバックループはありませんでした。 だから私の質問は、どこで間違ったのか、そしてチームが同じ間違いをするのをどのように防ぐことができるのかということです。

17 agile 

プログラマブルロジックコントローラー（PLC）のラダーロジック（LL）プログラムのバージョン管理は、実質的に存在しないようです。LLは視覚言語であり、バイナリファイルに保存される傾向があるため、またはソースコード管理がプロセス制御エンジニアリングサークルで「キャッチ」されていないためか、または今夜のGoogle-Fuが弱い可能性があります。 そのようなシステムのバージョン管理のための現実的で便利なソリューションを知っていますか？ 定義： 現実的=プログラムへの変更はユーザーによって追跡され、復帰およびマージの対象となります 有用=システムは視覚的なLLデザイナーと統合され、単一のPLCメーカーのLLに限定されず、とんでもない金額がかかりませんか？ 注：SVNやMercurialなどを使用してバイナリファイルを追跡している人の話を聞いたことがありますが、diff / merge機能で読みやすい違いが表示されるとは思いません。 補遺： 最初は、Allen-Bradley PLCのみをサポートする必要がありました。現在、シーメンスとMicroLogix PLCもあります。実行可能なソリューションを探しています...

17 version-control