ソフトウェア工学

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

9
ライブラリフォルダーよりもパッケージマネージャーを好むのはなぜですか?
静的ライブラリフォルダーとパッケージマネージャーの長所と短所を考えると、ライブラリフォルダーの方が良いアプローチだと思います。 ライブラリフォルダーで表示される長所: パッケージを管理するための外部ツールは必要ありません。 構築にインターネット接続は必要ありません。 ビルドの高速化(パッケージチェックなし)。 よりシンプルな環境(必要な知識が少ない)。 パッケージマネージャーで見られる長所: 複雑な依存関係ツリーを支援します(依存関係とそのすべての依存関係をダウンロードして管理できます)。 利用可能な新しいバージョンがあるかどうかを確認するのに役立ちます。 業界は、今日構築されているほぼすべてについて、パッケージマネージャーパスに従うことを決定したようです。だから、私は何が欠けていますか?

10
ダウンキャストの適切な使用とは何ですか?
ダウンキャストとは、基本クラス(またはインターフェイス)からサブクラスまたはリーフクラスにキャストすることです。 ダウンキャストの例は、System.Object他のタイプにキャストする場合です。 ダウンキャストは人気がありませんが、コードの匂いかもしれません。例えば、オブジェクト指向の教義は、ダウンキャストの代わりに仮想メソッドまたは抽象メソッドを定義して呼び出すことを好むことです。 ダウンキャストの適切で適切なユースケースは、もしあれば、何ですか?つまり、ダウンキャストするコードを書くことが適切なのはどのような状況ですか? 答えが「なし」である場合、ダウンキャストが言語でサポートされているのはなぜですか?

7
多くのプロジェクトが「git merge」よりも「git rebase」を好むのはなぜですか?
DVCSを使用する利点の1つは、edit-commit-mergeワークフローです(多くの場合、CVCSによって施行されるedit-merge-commitを超える)。マージに関係なく、固有の各変更をリポジトリに記録できるようにすることで、DAGがプロジェクトの真の血統を正確に反映するようになります。 なぜこれほど多くのWebサイトが「マージコミットを回避する」ことについて話しているのですか?事前コミットまたはマージ後のリベースをマージすると、リグレッションの分離、過去の変更の取り消しなどが難しくなりませんか? 明確化のポイント: DVCSのデフォルトの動作があるコミットをマージ作成します。なぜそんなに多くの場所が、これらのマージコミットを隠す線形の開発履歴を見たいという願望について語っているのでしょうか?

7
サービス層を作成することはどれほど重要ですか?
3層(DAL、BL、UI)でアプリの構築を開始しました[主にCRM、いくつかの販売レポート、在庫を処理します]。 同僚から、サービスレイヤーパターンに移行する必要があり、開発者が経験からサービスパターンにアクセスするようになったと言われました。彼は、将来そのようにアプリケーションを維持する方がはるかに簡単になるだろうと言いました。 個人的に、私はそれが物事をより複雑にしているだけだと感じており、それを正当化するような利益はあまり見られませんでした。 このアプリには、デスクトップアプリケーションの機能の一部(ただしごくわずか)を使用する小さな部分UIが追加されているため、コードを(あまり多くは)複製していません。いくつかのコードの重複のために、私はそれをサービス指向に変換しませんが、一般的にそれは非常に優れたアーキテクチャであるため、とにかくそれを使用するべきだと言いました。 私はそれでグーグルしようとしましたが、私はまだ混乱しており、何をすべきかを決めることができません。

10
なぜCはPascalに勝ったのですか?[閉まっている]
私の理解では、1980年代、そしておそらく1990年代にも、PascalとCは実稼働言語としてほとんど真っ向勝負でした。 パスカルの究極の終miseは、ボーランドのデルファイの怠慢によるものですか?または、運が悪かったり、Pascalに本質的に問題があるなど(復活の希望はありますか?) 好き嫌いではなく、歴史的な事実や観察できるバックアップに興味があります。

7
関数が意図した動作を実行する前にnullチェックを実行する必要がある場合、これは悪い設計ですか?
だから、これが良いコード設計なのか悪いコード設計なのかはわからないので、私は尋ねた方が良いと思った。 クラスを含むデータ処理を行うメソッドを頻繁に作成し、メソッドで多くのチェックを行って、null参照やその他のエラーを事前に取得しないようにします。 非常に基本的な例: // fields and properties private Entity _someEntity; public Entity SomeEntity => _someEntity; public void AssignEntity(Entity entity){ _someEntity = entity; } public void SetName(string name) { if (_someEntity == null) return; //check to avoid null ref _someEntity.Name = name; label.SetText(_someEntity.Name); } そのため、毎回nullをチェックするimを見ることができます。しかし、メソッドはこのチェックを行うべきではありませんか? たとえば、外部コードが事前にデータをクレンジングして、メソッドが以下のように検証する必要がないようにする必要があります。 if(entity != null) // this …
67 c#  design  validation 

16
TDDが役に立たなかったときに、コードの論理的な間違いを避ける方法は?
私は最近、イベントがどれくらい古いかを人間に優しい方法で示す小さなコードを書いていました。たとえば、イベントが「3週間前」または「1か月前」または「昨日」に発生したことを示すことができます。 要件は比較的明確であり、これはテスト駆動開発に最適なケースでした。テストを1つずつ作成し、各テストに合格するコードを実装しましたが、すべてが完全に機能するように見えました。本番でバグが現れるまで。 関連するコードは次のとおりです。 now = datetime.datetime.utcnow() today = now.date() if event_date.date() == today: return "Today" yesterday = today - datetime.timedelta(1) if event_date.date() == yesterday: return "Yesterday" delta = (now - event_date).days if delta < 7: return _number_to_text(delta) + " days ago" if delta < 30: weeks = math.floor(delta / 7) …

10
URLルートをファイルシステムから分離するために、現代のWebアプリケーションフレームワークはどのように、そしてなぜ進化したのですか?
約10年前と比較して、URLパスをファイルシステムから切り離すルーティングのスタイルを使用するフレームワークへの移行に注目しています。これは通常、フロントコントローラーパターンの助けを借りて達成されます。 つまり、以前は、URLパスはファイルシステムに直接マップされていたため、ディスク上の正確なファイルとフォルダーを反映していましたが、最近では、実際のURLパスは構成によって特定のクラスに向けられるようにプログラムされているため、ファイルを反映しなくなりましたシステムフォルダとファイル構造。 質問 どのようにして、なぜこれが当たり前になったのですか?かつて一般的なファイルへの直接アプローチが事実上放棄された時点まで「より良い」と判断した理由は何ですか。 その他の回答 ここには、ルートの概念といくつかの利点と欠点に少し似た答えがあります:PHPフレームワークでは、なぜ「ルート」概念が使用されるのですか? しかし、これは、この新しいルーティングスタイルパターンを使用して現在の新しいプロジェクトがほとんど行われており、ファイルへの直接書き込みが古くなったり放棄されたりする、歴史的な変化の側面、またはこの変化が徐々に起こった方法や理由については扱っていません。 また、言及されたこれらの利点と欠点のほとんどは、そのような世界的な変化を正当化するほど重要ではないようです。この変更を推進している唯一のメリットは、おそらくファイル/フォルダーシステムをエンドユーザーから隠すことと?param=value&param2=value、URLが少しきれいに見えるようにすることの欠如です。しかし、それらが変更の唯一の理由でしたか?そして、はいの場合、なぜそのような理由があったのですか? 例: 私はPHPフレームワークに最も精通しており、多くの人気のある現代のフレームワークはこの分離されたルーティングアプローチを使用しています。それを機能させるには、Apacheまたは同様のWebサーバーでURL書き換えを設定します。通常、Webアプリケーション機能は、ファイルへの直接URLパスを介してトリガーされなくなります。 Zend Expressive https://docs.zendframework.com/zend-expressive/features/router/aura/ https://docs.zendframework.com/zend-expressive/features/router/fast-route/ https://docs.zendframework。 com / zend-expressive / features / router / zf2 / Zend Framework https://docs.zendframework.com/zend-mvc/routing/ ララヴェル https://laravel.com/docs/5.5/routing CakePHP https://book.cakephp.org/3.0/en/development/routing.html

9
プログラム最適化の90/10ルールの意味は何ですか?
ウィキペディアによると、プログラム最適化の90/10ルールは、「プログラムの実行時間の90%がコードの10%の実行に費やされる」と述べています(ここの2番目の段落を参照)。 私はこれを本当に理解していません。これはどういう意味ですか?実行時間の90%をコードの10%だけを実行するために使用するにはどうすればよいですか?では、コードの他の90%はどうでしょうか?わずか10%の時間でどのように実行できますか?

10
「if」および「while」と一緒に使用する場合、言語が式の周りに括弧を必要とするのはなぜですか?
C、Java、およびC ++のような言語はすべてで使用した場合、式全体の周りに括弧を必要としif、whileまたはswitch。 if (true) { // Do something } とは対照的に if true { // Do something } 括弧が冗長であるため、これは私には奇妙に思えます。この例でtrueは、は単独の式です。括弧は、私が知っている方法でその意味を変えません。なぜこの奇妙な構文が存在し、なぜそんなに一般的ですか?気付いていないのに利点はありますか?

8
プログラムの有効期間中にメモリを使用する必要がある場合、プログラムの終了直前にメモリを解放する必要は本当にありますか?
多くの本やチュートリアルで、メモリ管理の実践が強調されていることを聞き、使用後にメモリを解放しないと、不可解で恐ろしいことが起こると感じました。 私は他のシステムについて話すことはできません(私にとっては同様のプラクティスを採用していると仮定するのは合理的です)が、少なくともWindowsでは、カーネルは基本的にほとんどのリソース(奇数を除いて)をクリーンアップすることを保証されていますプログラム終了後のプログラム。これには、ヒープメモリなどが含まれます。 ユーザーが利用できるようにするためにファイルを使い終わった後にファイルを閉じたい理由や、帯域幅を節約するためにサーバーに接続されたソケットを切断したい理由を理解していますが、プログラムが使用するすべてのメモリをマイクロ管理する必要があります。 今、私はこの質問はあなたが必要とどのくらいのメモリに基づいており、あなたの記憶を処理する方法以来、幅広いであることに同意し、あなたがそれを必要とするとき、私はこれまで、この質問の範囲を狭めるます:私はの作品を使用する必要がある場合プログラムの存続期間中のメモリ、プログラム終了直前にメモリを解放する必要は本当にありますか? 編集:重複として示唆された質問は、オペレーティングシステムのUnixファミリーに固有のものでした。その一番の答えは、Linux固有のツール(Valgrindなど)でさえも特定しました。この質問は、ほとんどの「通常の」非組み込みオペレーティングシステムと、プログラムの寿命を通じて必要とされるメモリを解放するのが良い習慣であるか、またはそうでない理由を網羅することを意図しています。

7
プログラムを開発中からリリースにどのように移行しますか?
ある時点で、プログラムが開発中です。機能は常に追加、削除、または変更されています。すべてのバージョンはプロトタイプにすぎません。ですから、その時点で非常にきれいなコードを書くことに時間を無駄にしないのは、何かがいつまで続くかわからないからです。もちろん、コードの品質を特定の標準に保つよう努めていますが、時間は常に問題です。 次に、プログラムが終了し、意思決定者が「それでいい」と言うところまで来ます。私はこの時点で動作するプロトタイプを持っていますが、内部のコードは開発フェーズの前後で少し面倒です。テスト/最終デバッグを開始することが期待されていますが、メンテナンスなどを容易にする適切なアーキテクチャを提供するために、なんらかの方法でクリーンアップおよび/または書き直すべきであると言っています。 ひとたびテストされ承認されたら、その時点で書き直すことは意味がありません。定期的に「完成した」プロトタイプを使用してそこに立ち、テスト中にバグが発生します。これは、開発プロセス全体の結果であるスマートでないコーディングの結果であることがわかります。私はテストの最中であり、バグ修正は書き直しになるでしょう...それは混乱です! より良い/教科書的な方法があります、私は確信しています。しかし、私はすべてが教科書ではない実際の職場環境で働かなければなりません。 それでは、どのように作業中のプロトタイプを安定したコードベースを備えたリリースバージョンに移行するのですか?たぶん、開発が完了したと考えるべきではなく、実際にクリーンアップフェーズと見なすべきです...わかりません。ここで助けが必要です。 編集 いくつかのことを明確にしたいと思います。 私はコードをクリーンで読みやすいコードの前後ではなく、100%実行しています。しかし、私はまた、物事を成し遂げなければならず、コードの美しさをすべてきれいで輝くように夢見ることはできません。妥協点を見つけなければなりません。 多くの場合、新しい機能は実際に試してみて、このようなものを実装する意味があるかどうかを確認したいものです。(特にモバイルアプリでは、実際のデバイスで実際のルックアンドフィールを取得するため)最初の「見てみよう」の繰り返しで(imho)があまり多くの作業を正当化しないのは小さなものです。ただし、このtech.debtを支払うときに疑問が生じることがありますか?それがこの質問のすべてです。 機能の半分が1日後に削除されることがわかっている場合(今までの会社での十分な経験)、私の問題にアプローチする最善の方法は、それでもすべてをきれいに書くために余分な時間を費やすことであると信じることは本当に難しいと思いますそのほとんどはまもなく削除されます。物事が固まったら一度大きなクリーンアップをすれば時間を節約できると感じているので、私の質問です。


10
重大ではないタイプミスを解決するためだけにコミットする価値はありますか?
コードで重要でないタイプミス(たとえば、print(error)ステートメントの誤ったアポストロフィ)に遭遇した場合、そのエラーを解決するためにコミットする価値がありますか、それともそのままにしておくべきですか? 具体的には、これらの重要ではないタイプミスを解決する価値に対して、コミットログのガムアップを比較検討することに興味があります。私はそれらを解決することに傾いています。私はつまらないですか?

9
どの時点で自分が言語を「学んだ」と言えるでしょうか?
プログラミングの数年で、RubyからC ++までのすべてをいじりました。私は基本的な構文(Ruby)を学ぶことから、言語の能力を伸ばすいくつかの主要な(私にとって)プロジェクトを完了するまで、すべてを行いました。この多様性(および言語の真の学習が決して止まらないという事実)を考えると、いつ言語を知っている(または学習した)と言えますか?

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