ソフトウェア工学

ここの例： Webアプリケーションの構築に興味がある場合、どの言語を知っている必要がありますか？ はい、HTMLとCSSはチューリング完全ではないことを理解しています。はい、宣言型の言語であり、命令型の言語ではないことを理解しています。しかし、なぜこれらの言語について質問するとき、人々は常にこの舌な（そして間違いなく明白な）事実で頭をかかげているのでしょうか？

158 terminology 

単独での例外処理に関する多くの有名なベストプラクティスがあります。「やるべきこと」は十分に知っていますが、大規模な環境でのベストプラクティスやパターンに関しては複雑になります。「早く投げて、遅れて捕まえる」-私は何度も聞いたことがありますが、それでも私を混乱させます。 低レベル層でNULLポインター例外がスローされる場合、なぜ早くスローしてキャッチする必要があるのですか？なぜ上位のレイヤーでキャッチする必要があるのですか？ビジネスレイヤーなど、高レベルで低レベルの例外をキャッチするのは意味がありません。各層の懸念に違反しているようです。 次の状況を想像してください。 数値を計算するサービスがあります。この数値を計算するために、サービスはリポジトリにアクセスして生データを取得し、他のサービスが計算を準備します。データ取得レイヤーで何か問題が発生した場合、なぜDataRetrievalExceptionをより高いレベルにスローする必要があるのですか？対照的に、CalculationServiceExceptionなどの意味のある例外に例外をラップすることをお勧めします。 なぜ早く投げ、なぜ遅くキャッチするのですか？

156 exception-handling 

たとえば、JSにはデフォルト値を取得するための一般的なスニペットがあります。 function f(x) { x = x || 'default_value'; } この種のスニペットは、私のチームのすべてのメンバーが簡単に理解することはできず、JSレベルは低いです。 このトリックを使用しないほうがいいですか？JS開発者によると、コードはピアでは読みにくくなりますが、次のコードより読みやすくなります。 function f(x) { if (!x) { x = 'default_value'; } } 確かに、このトリックを使用して同僚がそれを見ると、彼らは何かを学ぶことができます。しかし、多くの場合、彼らはこれを「賢くしようとしている」と見なしています。 チームメイトのレベルが私より低い場合、コードのレベルを下げる必要がありますか？

156 teamwork  communication  skills 

ケン・トンプソン・ハック（1984） Ken Thompsonは、1984年にコンパイラバイナリ（および* nixシステムのログインスクリプトのような他のコンパイル済みソフトウェア）を破壊する方法を概説しました。現代のコンパイルがこのセキュリティの欠陥に対処しているかどうか知りたいです。 簡単な説明： 2つの欠陥を含むようにコンパイラコードを書き直します。 独自のバイナリをコンパイルするとき、コンパイラはこれらの欠陥をコンパイルする必要があります 事前に選択された他のコード（ログイン関数）をコンパイルする場合、任意のバックドアをコンパイルする必要があります したがって、コンパイラは正常に動作します-ログインスクリプトなどをコンパイルするとき、セキュリティバックドアを作成でき、将来、それ自体の新しいバージョンをコンパイルするとき、以前の欠陥を保持します- そして、欠陥はコンパイラにのみ存在しますバイナリなので、検出が非常に困難です。 質問： 私はウェブ上でこれらに対する答えを見つけることができませんでした： これはジャストインタイムコンパイルとどのように関係しますか？ * nixシステムでログインを処理するプログラムのような関数は、実行時にコンパイルされますか？ これはまだ有効な脅威ですか、それとも1984年以降、これが重大な問題になるのを防ぐコンパイルのセキュリティの開発がありましたか？ これはすべての言語に影響しますか？ なぜ知りたいのですか？ 宿題をしているときにこれに出くわしましたが、面白そうに思えましたが、これが現在の問題なのか、解決された問題なのかを具体的に理解する背景がありません。 参考資料 概要 いくつかのコード

156 linux  unix  compiler  hacking 

私は長年ソフトウェア開発者として働いています。多くの開発者が製品の開発に関与するにつれて、プロジェクトがより複雑で維持できなくなるというのが私の経験でした。 開発の特定の段階でソフトウェアが「ハッカー」と「ハッカー」を獲得する傾向があるようです。特に、アーキテクチャを定義したチームメンバーが会社で働いていない場合です。 何かを変更しなければならない開発者が、アーキテクチャの全体像をつかむのに苦労しているのはイライラするものです。したがって、問題を修正したり、元のアーキテクチャに対して機能する方法で変更を加えたりする傾向があります。その結果、コードはますます複雑になり、理解しにくくなります。 何年もの間ソースコードを本当に保守しやすくする方法について何か役に立つアドバイスはありますか？

156 project-management  maintainability 

StackOverflowとこのサイトの両方で、あいまいな「Scheme vs Common Lisp」の質問が不足しているわけではないので、これにもっと焦点を当てたいと思います。質問は、両方の言語でコーディングした人向けです。 Schemeでコーディングしているときに、Common Lispコーディングエクスペリエンスで最も見逃した要素は何ですか？または、逆に、Common Lispでコーディングしているときに、Schemeでコーディングすることから何を逃しましたか？ 言語機能だけを意味するわけではありません。以下は、質問に関する限り、見逃してはならない有効なものです。 特定のライブラリ。 SLIME、DrRacketなどの開発環境の特定の機能 CコードのブロックをSchemeソースに直接書き込むGambitの機能など、特定の実装の機能。 そしてもちろん、言語機能。 私が望んでいる種類の答えの例： 「Common LispでXを実装しようとしていたので、もしSchemeの第一級の継続があれば、Yをやっただけでしたが、代わりにZをやらなければならなかったので、苦労しました。」 「Schemeプロジェクトでのビルドプロセスのスクリプト作成は、ソースツリーが成長し、Cライブラリをより多くリンクするにつれてますます苦しくなりました。次のプロジェクトでは、Common Lispに戻りました。」 「既存の大きなC ++コードベースがあり、私にとっては、Gambit SchemeコードにC ++呼び出しを直接埋め込むことができたのは、SchemeがCommon Lispに対して持っていた短所、SWIGサポートの欠如を含めて、まったく価値がありました。」 ですから、「スキームはもっとシンプルな言語です」などの一般的な感情ではなく、戦争の物語を望んでいます。

155 lisp  scheme 

私は、上司が読んでフォローできるようにしたい説明や解説を、1行ずつ（または必要に応じて、たとえば画像ごとなど）与えるように特に求められました。 彼はプログラマーではないので、彼はコードに従うことができないので、すべてを英語に翻訳したいと思っています。 これを行うように誰かに頼まれましたか？ すべてのソースコードについてコメントし、JSDocを使用して、すべての関数、変数などの完全なドキュメントを生成し、実装例と、コメント付きの完全に機能するデモを含めました。 プログラマでない人のためにコードにコメントするために私ができることは他にありますか？ これは合理的な要求ではありませんか？ 更新 最後に、私は彼が求めていたことをするのに時間の良い使い方ではなかった理由をなんとか説明することができました。彼は理にかなった男であり、私の仕事が何を含んでいるかを理解していませんでした。彼がこの投稿を見たとき、彼はそれが通常のリクエストではないことをすぐに理解したと思います。 他のプログラマーが従うのに適したドキュメント（JSDocおよびインラインコメント-技術的な問題に関する追加のメモ）と、上司が従うプログラムのメインロジックの非常に広範なフローチャート図を提供しました。 最終的に、すべての関係者は満足し、私たちは前進しました。

155 documentation 

時々「クロージャ」が言及されているのを見て、それを調べてみましたが、Wikiには理解できる説明がありません。誰かがここで私を助けることができますか？

155 language-features  closures 

私は仕事を探しており、多くの職に応募しています。ある雇用主が答えた。かなり長い電話インタビュー（おそらく1時間以上）があり、その後、開発者テストを設定しました。テストには6時間から8時間かかると推定され、その結果が承認された場合、作業に対して報酬が支払われると言われました。 それは私に一時停止を与えましたが、私は努力しました。開発者テストは、RDPを介してアクセスされるVM上で行われました。タスクは、サーバーからのデータを要求し、テーブルに画面に表示し、かなり複雑な検索フィルタースキームを備えたWebプロジェクトに検索ページを実装することでした（約15のステータスがあり、サーバーに検索を送信するときに文字列/フィールド検索に加えて、これらのステータスで検索できます）。さらに、SVGアイコンは特定のデータ値の色を変更し、一部のデータはデータベースでの構造とは異なる方法で表現されることを望んでいます。 Loooongの話を短くすると、これには6〜8時間よりもかなり長い時間がかかりました。その多くは、私が実行していた非常に貧弱なVMによるものでした（Visual Studio 2013の読み込みには10分かかり、3 GBのすばらしいソリューションを開くにはさらに15分かかりました）。 テストを完了した後、変更をソース管理にコミットする必要があると言われました...うーん、OK。指示に従いました。そして、変更をコミットした後、返信がメールで送られてきました。SVGの色は正しくありませんでした。このエッジケースにバグがあり、経験したことのないこの他の問題に時々問題がありました。などです。バグ修正を行います。私はそれらを行い、雇用主はより多くのバグ修正リクエストとともに戻ってきます。 私の仕事はすべて本番アプリケーションに移行しているようです。他の人が1つの機能をすべてコーディングしているように見えたが、他には何も触れていないように見えるコードのいくつかの異常に気付きました。 安い労働力に使われているだけですか？彼らが私に6時間1時間に約束された50ドルを支払ったとしても、私は今この事に約18時間を約束しました。もし彼らが思いつくすべてのものをバグ修正したら、少なくとも16時間は無料で働きました。 私はいくつかの開発者テストを受けましたが、実稼働向けのコードに取り組んでいた間、私はテストを受けたことは一度もありません。開発用のパイプラインにある機能を実装したテストは一度も受けたことがなく、4ラウンド、合計20時間以上かかった機能は一度も受けたことがありません。開発者テストを使用して、いくつかの機能を安価に公開している印象を受けます。 私は間違った印象を持っていますか？そして、このテストプロトコルは適切ですか？

154 interview 

私はカレーについて学んだばかりで、コンセプトを理解しているとは思いますが、それを使用することに大きな利点はありません。 些細な例として、2つの値を追加する関数を使用します（MLで記述）。カレーなしのバージョンは fun add(x, y) = x + y と呼ばれます add(3, 5) カレー版は fun add x y = x + y (* short for val add = fn x => fn y=> x + y *) と呼ばれます add 3 5 私は、関数の定義と呼び出しから括弧のセットを削除する構文糖衣のように思えます。カリー化は関数型言語の重要な機能の1つとして挙げられてきましたが、現時点ではそれに少々困惑しています。タプルをとる関数の代わりに、それぞれ単一のパラメーターを消費する関数のチェーンを作成するという概念は、単純な構文の変更に使用するのはかなり複雑に思えます。 わずかに単純な構文がカリー化の唯一の動機ですか、それとも私の非常に単純な例では明らかではない他の利点がありませんか？カレーは単なる構文糖ですか？

154 functional-programming  currying 

バックグラウンド テクノロジーインタビューで、AがBに等しく、BがCに等しく、AがCに等しい「オブジェクト」（引用符に注意）をトラバースするアルゴリズムを書くように頼まれました。 それでおしまい。それは私が与えられたすべての情報です。 私はインタビュアーに目標を尋ねましたが、どうやら目標はなく、単に「対象」を「横断」するだけでした。 他の人については知りませんが、これは馬鹿げた質問のように思えます。「値を探していますか？」ともう一度尋ねました。いや。それを「トラバース」するだけです。 なぜこの「オブジェクト」を無限にループしたいのですか？多分私のプロセッサを溶かすために？？ 答えインタビュアーによると、私は再帰関数を書かれている必要があることでした。 それでは、単に再帰関数を書くように頼まないのはなぜですか？そして、誰も終わらない再帰関数を書くでしょうか？ 私の質問： これはあなたの残りの人にとって有効な質問ですか、もしそうなら、私が何が欠けているかもしれないかについてのヒントを提供できますか？おそらく、私は現実世界の問題を解決することについてあまりにも一生懸命に考えています。私は長い間コーディングに成功してきましたが、この技術面接プロセスにより、何も知らない気分になります。

153 interview  algorithms 

私は1年前に働き始めたばかりですが、他の誰かと同じ理由でオープンソースプロジェクトに参加したいと思っています。何か役に立つものを作成し、自分のスキルをさらに高めてください。 私の問題は、私が適合するプロジェクトを見つける方法がわからないことです。 初心者向けのプロジェクトを見つけるにはどうすればよいですか？どの属性を検索する必要がありますか？プロジェクトが適切ではないかもしれないという兆候は何ですか？人々とオープンソースプロジェクトを一致させるのに役立つツールはありますか？ ここにも同様の質問がありますが、その質問は雇用に関するものであり、PHP / Drupalに限定されています。

152 learning  open-source  junior-programmer 

これは実際には技術的な質問ではありませんが、ソース管理とベストプラクティスに関する他の質問がいくつかあります。 私が働いている会社（匿名のまま）は、ネットワーク共有を使用してソースコードとリリースされたコードをホストしています。開発者または管理者は、ソースコードがリリースされているか、どのバージョンであるかなどに応じて、ソースコードを適切なフォルダーに手動で移動する責任があります。ファイル名とバージョン、および変更内容を記録する場所の周りにさまざまなスプレッドシートが点在しており、一部のチームは各ファイルの先頭に異なるバージョンの詳細も記載しています。各チーム（2〜3チーム）は、社内でこれを異なる方法で行うようです。あなたが想像できるように、それは組織化された混乱です-「正しい人々」は彼らの物がどこにあるかを知っているので組織化されていますが、それはすべて異なっていて、それはいつでも何をすべきかを覚えている人々に依存しているため混乱です。 私はしばらくの間、ある種の管理されたソース管理を推進し​​ようとしてきましたが、社内で十分なサポートを得ることができないようです。私の主な議論は次のとおりです。 私たちは現在脆弱です。いつでも誰かが私たちがしなければならない多くのリリースアクションの1つを行うのを忘れることができます。これは、バージョン全体が正しく保存されないことを意味します。必要に応じて、バージョンをつなぎ合わせるのに数時間または数日かかる場合があります バグ修正と一緒に新機能を開発しており、一部の作業がまだ完了していないため、多くの場合、どちらか一方のリリースを遅らせる必要があります。また、バグ修正だけが必要な場合でも、新しい機能を含むバージョンを使用するようにお客様に強制する必要があります。 複数の開発者が同じプロジェクトを同時に使用しているため、Visual Studioで問題が発生しています（同じファイルではありませんが、依然として問題が発生しています） 開発者は15人しかいませんが、私たちはすべて異なる方法で作業を行っています。私たち全員が従わなければならない標準的な全社的なアプローチをとる方が良いと思いませんか？ 私の質問は： このサイズのグループにソース管理がないのは正常ですか？ 私はこれまで、ソースコントロールを持っていないための唯一の漠然とした理由が与えられている-あなたが示唆している何の理由の可能性のために有効ではない 上記の情報与えられ、ソースコントロールを実装しますか？ 任意のより多くの理由があるため、私は私の兵器庫に追加できるソースコントロールは？ 私は主に私がなぜそんなに抵抗したのか感じてもらいたいので、正直に答えてください。 私は、最もバランスのとれたアプローチを取り、3つの質問すべてに答えたと思う人に答えます。 前もって感謝します

152 version-control  project-management  management  release-management 

腐敗防止レイヤーの本当の意味を理解しようとしています。私はそれがレガシーコードまたは悪いAPIを移行/回避する方法であることを知っています。私が理解していないのは、それがどのように機能し、何が望ましくない層からきれいに分離するのかということです。 私はいくつかの検索を行いましたが、簡単な例や説明が見つからないため、それを理解し、簡単な例で説明できる人を探しています。私の質問を満足させる答えは、単純なものである必要があり（必ずしも短くはありません）、実装と使用のわかりやすい例を提供する必要があります。 私のユースケースについては、この質問を参照してください。

151 design-patterns  api-design  legacy  bad-code 

現在、Cは低レベル言語と見なされていますが、70年代に低レベル言語と見なされていましたか？この用語は当時も使用されていましたか？ 多くの一般的な高レベル言語は80年代半ば以降まで存在しなかったため、低レベルの性質が長年にわたって変化したかどうか、どのように変化したかを知りたいです。

151 programming-languages  c  history