ソフトウェア工学

システム開発ライフサイクル内で働く専門家、学者、学生向けのQ&A

4
「車輪を再発明しないでください」は人間の記憶の限界を無視しますか?
HaskellとF#で働いていることの1つは、私よりも賢い大学の誰かが、おそらく私がやっていることの抽象化をすでに見つけているということです。同様に、C#とオブジェクト指向プログラミングでは、私がやろうとしていることには関係なく、おそらく「it」用のライブラリがあります。 プログラミングの抽象化を再利用することに重点が置かれているため、1)短くて汚いものをコーディングするか、2)他の誰かのより堅牢なライブラリ/ソリューションを見つけるために同じ時間を費やし、それを使用することの間でジレンマを感じることがよくあります。 最近のように、ここのコーダーの1人がCSVファイル用の(デ)シリアライザを作成しましたが、.NET標準がまだ付属していない場合、そのようなものはおそらくオンラインで見つけるのが非常に簡単だと思わずにはいられませんでしたAPI。 私は、.NET Iで働いて数回のみ、いくつかのメソッド呼び出しまたはオブジェクトか何かがあったことを実現するために、一緒に私が知っている内容に基づいてソリューションをパッチしてきた、けれども彼を責めないで 、多くの場合、同じライブラリに、何をやっています欲しかったのですが、それについて知りませんでした。 これは単に経験不足の兆候ですか、それとも新しいものを書くことと古いものを再利用することの間には常にトレードオフの要素がありますか?私が最も嫌いなのは、すでに知っていて忘れていたソリューションに出くわしたときです。最近、ほとんどの言語にプリパッケージされている大量のコードを消化できない人がいるように感じます。

12
貧しい作家は貧しいプログラマーになりますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 私はPeter SeibelのCoders at Workを読んでいますが、書くことができないプログラマーは一般的に貧しいプログラマーになるとよく言われています-ダグラス・クロックフォード、ジョシュア・ブロック、ジョー・アームストロング、ダイクストラ(そして私は本の半分しか読んでいない)。 これについてどう思いますか?英語などの自然言語で書くことで自分を表現できないことは、良いコードを書くことの妨げですか?
16 writing 

5
マルチサーバーRDBMSまたはアプリケーションはデータベース参照整合性を処理する必要がありますか?
外部キー、制約、デフォルト値などの項目は、データベース管理システム(この場合はMS SQL 2005)またはアプリケーションによって処理される必要がありますか?両側から意見を聞いたことがありますが、どちらに行くべきかは正直わかりません。 複数のサーバー/データベースにまたがる可能性があり、リンクサーバー間で外部キーを使用できるとは思いません。それに加えて、データベース設計にはいくつかの循環参照があり、ON UPDATE CASCADEすべてを使用できません。 データベースはMS SQL 2005(おそらく2008)であり、データベースとのすべてのやり取りはアプリケーションを介して行われる必要があります。

6
例外を伴うビジネスルールの表現
私はそれが高価であることを知っていますが、(IMO)それは非常に良い習慣だと思います。たとえば、営業担当者でない場合は請求書を保存できないなどのルールについて話しているので、その場合は「あなたは許可されていません」などの例外をスローします... 別のアプローチは、ステータスなどのオブジェクトを持つことです 他のアプローチはありますか?それについてどう思いますか?

9
機能の追加をいつ停止するかをどのように知っていますか?
少し前に、非常に小さなpythonスクリプトを作成し、定期的にxmlフィードの新しいエントリをチェックし、存在する場合は新しいエントリをユーザーに警告しました。私は自分でこれを書いたので、本質的にはコンソールベースのプログラムであり、コンソールインターフェイスに慣れている人なら誰でも使用できます。 しばらくして、私はそれが他の人々にとってより有用であると判断し、それを整理し、入力をサニタイズし、バグを除去し始めました。スクリプトを書いたので、それを効率的、正確に使用する方法を知っていたので、他の人はそうではなかったかもしれないので、GUIを追加し始めました。これは単純なメニューとして始まり、その後、インターフェイスとオプションメニューの両方を備えたより完全なGUIに拡張されました。次に、保存済みのユーザー設定と、以前に検索したxmlフィード用のストレージを追加して、繰り返し検索を高速化しました。 問題が発生した場合のアプリケーションのデバッグに役立つロギングを追加し、選択したプラットフォームで使用可能な最新の安定したpythonコードベースにアプリケーションを持ち込み、ダイアログ機能を改善しました。 私は自分のコードをバグ修正してコメントしましたが、アルファテスターが利用できるようにする前にアプリを改善するためにできることはまだあると思います。私のオリジナルの20〜30行のスクリプトとはかけ離れています。私が予想していたことは、概念実証から許容可能な使用プログラムに移行するのに1〜2時間かかるだけで、10〜20倍かかりました。(私はまだ初心者で、スタッフには長い時間がかかりますが、それでも...) 素材の追加/調整/修正を停止し、赤ちゃんを屋外でクロールさせるタイミングをどのように知っていますか?

14
インタビュー中のコード質問の雇用主にとっての長所と短所は何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 Joel Testの質問#11は、「新しい候補者はインタビュー中にコードを書きますか?」です。インタビュー中に新しい候補者にコードを記述し、それに基づいて決定を下すよう求めるための賛否両論は何ですか?

5
教科書などのソースコードは翻訳すべきですか?
数週間前、私のクラスは「Real World Haskell」という本をポルトガル語に翻訳するように割り当てられました。テキストとコメントの翻訳を行ったとき、インストラクターが示唆したように、コードも翻訳すべきかどうか疑問に思い始めました。例えば: データBookInfo = Book Int文字列[文字列] 派生ショー になるだろう データInfoLivro = Livro Int文字列[文字列] 派生ショー 私はポルトガル語でソフトウェア関連の本を読んだことがないので、それが一般的な慣習であるかどうかはわかりません。最終的に、コードは言語ミックスです(おそらく、Haskellの例は、のようtype CadeiaDeCaracteres = Stringに同義語をすばやく作成できるため、良い点ではありませんが、ポイントを得ることができます)。ですから、あなたがどれほど一生懸命努力するかは問題ではありません。読者は、ある種の基本的な英語の単語について、読者の以前の経験に頼らなければなりません。 これを知っているので、コードを翻訳することに意味はありません。なぜなら、コーディングライフの初期の段階ではコードはユニバーサル言語で書かれるべきだからです。それにもかかわらず、周囲のテキスト(たとえば、コメント、および本のテキスト自体)を翻訳する必要がある場合、この問題で何が可能かつ実行可能ですか?何をすべきかのガイダンスを教えてもらえますか?
16 coding 


7
スコープを示すために空白と{}を使用する言語の長所と短所は何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 空白を使用する方が良いのか、スコープを示すために括弧のようなトークンを使用する方が良いのかについて、矛盾があるようです。一貫性のないインデント問題に対する多くのpythonのソリューションを称賛しましたが、多くの意見が異なります: トークンとして空白を含む言語は死ぬ必要があります。 同じ答えに後で投稿: 私は実際に試してみるまで、トークンとしての空白のようなものでした。おそらく、私の個人的な空白スペースのレイアウトが、python-landの誰もが使用しているものとほとんど一致するのを助けたでしょう。おそらく私は少しミニマリストなのかもしれませんが、とにかくインデントするつもりなら、なぜ{}に悩まされるのですか? 私はそれぞれの側にいくつかの明確な議論を見ることができます: 空白を使用: コードの一貫性のないインデントを減らすのに役立ちます 同じ目的を果たすために、目に見えるトークンを空白で置き換えることにより、画面をクリアします トークンを使用: コードをさまざまなレベルにカットアンドペーストするのがはるかに簡単です(インデントを修正する必要はありません) より一貫性のある。一部のテキストエディタでは、空白が異なって表示されます。 現在より人気があります。 見逃した点はありますか?どっちがいい?どちらかと長い間働いた後の知恵の言葉はありますか? PS。言語が各制御構造に同じトークンを使用しない場合、それは嫌いです。VBは、そのと本当に迷惑ですEnd Ifし、End While他のほとんどの言語は、単にすべてのために{}のを使用し、ステートメント。しかし、それは別の質問のトピックかもしれません...

9
(新しい仕事のために)私の仕事をやめる。古い仕事は私が契約に利用できることを望んでいます。実行する手順
私が退職する会社は、質問に答えたり、必要に応じてプログラムをデバッグしたりできるようにすることを求めています。私はこれに反対していません。Googleでこの種の標準的な契約を検索したところ、何も見つかりませんでした。 使用しているこの種の標準的な契約はありますか? この種の配置がスムーズに機能するようにするために、他に実行する必要がある手順はありますか?

3
選択した{DVCS}の名前付きブランチの適切な命名規則
Mercurialをオフィスにゆっくりと統合し、名前付きブランチの使用を開始したWeb開発を行っています。 しかし、ブランチに名前を付けることに関しては、良い慣習を見つけることができませんでした。 試しました: FeatureName(これが問題の原因であることがわかります) DEVInitial_FeatureName(開発者が出入りするときに混乱する可能性があります) {uniqueID(int)} _ Feature これまでuniqueID_featureNameが勝っていますが、参考のために小さなDBで維持することを考えています。 ブランチID(int)、featureName(varchar)、featureDescription(varchar)、date、whoなど... これにより、1_NewWhizBangFeature、2_NowWithMoreFoo、...のようなブランチが得られ、ログを確認せずにそのブランチが何をするかを簡単に参照できます。 より良い解決策はありますか?

4
プロジェクトマネージャーになった後、どうすれば技術的なスキルを維持できますか?
私のキャリアが進むにつれて、技術的な仕事が減り、プロジェクト管理の仕事が増えていることがわかりました。冗談を言っています 技術的な仕事に戻るたびに、物事を進めるのは少し難しいようです。あなたのキャリアを通じて技術的な専門知識を維持するために人々はどのような提案を持っていますか?

2
あなたが彼のために働き始める前に悪いクライアントを認識する方法は?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 あなたの多くが悪いクライアントに遭遇したと確信しています。また、将来このような出会いを防ぐための対策を講じたと確信しています。立ち去るように警告するクライアントの最も影響力のある特徴は何ですか?

10
プログラミングに最適なモニターは何ですか?[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 8年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 時々、私はいくつかのモニターを試しました。私の主な仕事はコーディング(仕事、phdなど)です。職場では、LG Flatron L246WHをお勧めします。しかし、自宅にはLG W2363Vがあり、コーディングの際にかなり不快に感じます。フォント、サブピクセル、またはスムーズフォントを使用するときに頭に浮かぶもの。 現在、私たちのニーズに最適な最高のモニターは何ですか?

9
日記をつけることは仕事に役立ちますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 数年前、私の最初の実際のプログラミングの仕事で、上司は私の毎日の活動の日記をつけるように勧めました。私はまだそうしていますが、もはや紙や手書きのものではありません。 あなたは日記をつけていますか?または、回復されていない時間がかかりますか?

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