問題タブ [methodology]

サードパーティのツールなしでDIを実行することは可能ですか？DIフレームワークを発見する前に、抽象クラスとインターフェースを使用してそれを行っている人々について読んだことがあります。IDはその非常に基本的な形式でどのように行われますか？

私は数年前から開発を行っていますが、私のチームの年配のプログラマーの何人かが、開発哲学を一切持たずに設計と実装を進めていることに不満を感じていました。柔軟性と検証の欠如に。私は同僚にこのイライラを募らせたところ、彼らは「それでは、何百もの開発哲学のうちどれを使用することをお勧めしますか?」と答えました。

チームで作業するよりも、自分で作業するときに開発哲学を使用する方がはるかに簡単であるため、これは答えるのが難しい質問でした. 私はコードが正しく動作しているという最高の安心感を与えてくれるように思えるので、テスト駆動開発には少し偏っていますが、TDD には限界があり、主にすべてのテストを書くために必要なオーバーヘッドと、私たちのテスト フレームワークにギャップがないこと (チームで作業する場合、これを実現するのは困難です)。私の友人は、Agile Unified Process (AUP) を支持し、それ以外の使用を拒否しています。

私の質問は

• チームで開発する際にうまく機能することがわかった開発哲学はどれですか?また、それらはどのように製品を予定どおりに予算内で提供するのに役立ちましたか?

• どのような問題に遭遇し、どのようにそれらを克服しましたか?

• それらはまったく必要だと思いますか？

「UP開発方法論」を求める求人広告を見たところです。

それは何ですか？

それとも、HT 部門がジョブ スペックを間違えたのでしょうか。

私は PHP 開発者として働いていますが、上司に気が狂いそうになっています。彼はときどき私に電話をかけ、前のタスクが完了していなくてもタスクを与えてくれます。クライアントと会うことを禁じ、仕様が不完全であることを口頭または電話で伝え、最初の展開からアプリケーションが機能することを期待しています。この男の熱意を抑える方法を提案できる団体はありますか?

私は非常に小さな会社で孤独な開発者として働いています。私の仕事はかなり混沌としていて、もっと整理する方法を探しています。

問題の 1 つは、私のプロジェクトには実質的に管理者がいないことです。何をしているのか、何か問題があるのか​​と聞かれることはめったにありません。ある時点で、毎週のステータス ミーティングについての話がありましたが、それは少し前のことです。そういうのが欲しければ、自分で手配しないといけないようです.. タスクや明確なスケジュールが定義されていないため、次に何をすべきか少し迷ってしまうことがあります。

本や記事から、役立つかもしれない多くのことを見つけました。優れたコーディング標準 (私の意見では多少古くなっている大まかなスタイル ガイドしか存在しない)、コード インスペクション、TDD、ユニット テスト、バグ データベースなどがありますが、小規模な会社ではリソースも時間もないようです必須ではないもの。私が組み込みドメインで働いているという事実は、物事をより複雑にするだけのようです。

手抜きをして急遽ハックする風習もあると思います。これは、未完成で専門的でない製品やバグが後日出現するのを待っていることにつながります. それらを維持するのも面倒だと思います。だから、私は挑戦的なコードベースを継承しようとしており、多くの新しいことを学ぶ必要がある新しい開発を行い、同時にそのためのプロセスを構築しようとしていると思います. 最終的にはやりがいがあるかもしれませんが、経験があまりないので、うまくいくかどうかはわかりません.

このような小さなショップでは、環境はプログラミングに最適とは言えません。カスタマー サポート、電話応対、小包への署名、ハードウェアのテスト、組み立て、その他の雑多なタスクが表示されるなど、他の多くのことが時々行われる必要があります。したがって、リソースについてのアイデアが得られます。すべてが悪いわけではありません (顧客の問題を解決することで啓発されることもあります)。改善できると信じていますが、私が本当に懸念しているのは他の点です。

このような場所で開発プロセスを行うことは可能ですか?

ある種の管理を行うことは役に立ちますか？どんな？

少ないリソースで高品質の製品を作ることは可能ですか?

何十年も成功を収めてきた会社が変わる必要があることを自分自身や他の人に納得させるにはどうすればよいでしょうか? 何が不可欠でしょうか？

似たようなお店で働いている人もいるのではないでしょうか？

ソフトウェア エンジニアとして、私はアプリケーション レイヤーでビジネス ロジックを記述することに強い偏見を持っていますが、通常は CRUD (Create Retrieve Update and Delete) 操作以外はほとんどデータベースに依存していません。一方、大量のビジネス ロジックがストアド プロシージャで記述されているアプリケーション (通常は古いアプリケーション) に出くわしたことがあります。そのため、データベース レイヤーでビジネス ロジックを記述することを好む人がいます。

ストアド プロシージャでビジネス ロジックを書いたり書いたりすることを楽しんでいる人のために、この方法を使用する理由は何ですか?

1989 年 2 月 2 日付けのページ (ページ 1) があり、以前の上司から提示された、プログラミングに関する Niman の 13 の最小限の十分な戒めの概要が説明されています。(彼はそれらが時代遅れであることを認識していたため、これは現代の一連のガイドラインというよりも考古学の作品になっています。) それらを見たことがない場合は、次のとおりです。

1. 何を意図しているかを説明するために、コードに適切なコメントを付けなければなりません。人間は記憶術だけでは考えません。
2. 数値定数を意味のあるシンボル名と同一視しなければなりません。はっきりと話し、異教徒のアイコンを避けてください。
3. モジュール内のすべての入力と出力を記述する必要があります。あなたのモジュールを保守しなければならないかもしれないあなたのソフトウェアの兄弟姉妹に親切にしてください。
4. あなたはあなたの改訂を適切に説明しなければなりません。あなたの仲間が心を読む人であることを期待するのは罪です. とにかく読心は罪です。
5. アセンブリ コードの疑似コードの説明を提供する必要があります。確かに、アセンブリは COBOL ではありません。
6. モジュールごとに 1 つの入口点と 1 つの出口点しか持たない必要があります。多くの入り口と出口を持っている人は、自分の体が同じように発達することを期待するでしょう.
7. コードを開発する前に、コードを設計する必要があります。本当に、本当に。
8. あなたは仲間と一緒にあなたのコードのレビューを行うべきです。彼らはオブジェクトコードを継承するからです。
9. 設計を文書化し、コードを保守するすべての人が文書を利用できるようにする必要があります。確かに、それを拒む者はオペレーティングシステムのデバッグを永遠に地獄で行うことになるだろう。
10. 彼らのコードに対する有意義な批判を受け入れることができなければなりません。もし自分のルールを恥じるなら、プロのボウラーになるべきだ。
11. コードをライブラリ管理に配置する前に、コードを徹底的に (sic) テストする必要があります。聖書から除外された部分の 1 つは、ディーゼル エンジン コントローラーの一部である大規模な 8096 アセンブリ言語プログラムをデバッグすることによって、ヨブが神によってテストされた箇所です。リリース前に全体がテストされていません。さらに悪いことに、ジョブは Intel ツールを使用しなければなりませんでした。
12. 可能な限り、グローバル データ構造の使用を避ける必要があります。タワーには Babel という名前を付ける必要がありますが、プログラムには名前を付けないでください。
13. アセンブリ プログラマが、最適にコンパイルされた 20 世紀後半のコードの効率に匹敵しない場合は、高級言語を使用する必要があります。アセンブリは常に (速度とサイズの点で) 優れたコンパイラが生成できるものよりも効率的であると考える偽りの神々に注意してください。アセンブリ言語を実際に活用するには、コーディングだけでなく設計にも優れている必要があります。

私はインターネットを精査しましたが、これらの戒めやニマンの戒めの出所について何も明らかにしていません。これについて、また彼が言わなければならなかったかもしれない他のビットについてもっと調べようとして、私を殺していました. 私が持っている他の唯一の手がかりは、左下にイニシャル「DEN」があることです.NはNimanのNだと思いますが、テキストを特定するものは他にありません. そう、

A. ニマンとは誰ですか? (プログラマー? 教師? コンサルタント? 会社のランダムな男?)

B. このページは何でしたか? (古いプログラミングガイド? 会社のマニュアル? 昔の BBS? )

C. 残りはどこですか? (もっとありますか?他に何がありますか?これは独立したものでしたか?)

コメントに応えて、私の上司はその後亡くなりましたが、それ以前は、彼は長い間、白ひげを生やしてビジネスに携わっていました. 紙の色から、日付 (1989 年) が印刷されたおおよその日付であることがかなり確信で​​きます。

誰がバグを修正するべきだと思いますか? プログラマーですよね？わかりましたが、本当に、誰が... 説明させてください。

私は多くのスクラム プロジェクトのスクラム マスターです。スクラムは、「可能な場合はリソースをリング フェンスする」と言っていますが、私はこの意見に心から同意します。

通常、各スプリントの特定の %age を統合して、前のスプリントからのバグ修正を行います - すべて順調です。

各スプリントの後、クライアントにデモと再調査を行い、開発コードを UAT 環境にプロモートします (クライアントは通常、プロジェクトの一部を公開することを望んでいませんが、それはクライアント次第です。動作するテスト可能なコードを確実にデプロイすることで、取引の側にいます）。

すべてのスプリントが完了すると、クライアントが完成したソフトウェアを徹底的にテストして最後のバグを見つける UAT フェーズがあります。理想的には、これらはすでに検出されているはずですが、現実的には、UAT 中にのみ発見されたものもあります。

この UAT フェーズでは、すべての開発者が 100% プロジェクトに必要とされるわけではないため、開発者を他のプロジェクトに再割り当てしたいと考えています。ただし、スクラムは「可能な場合はリソースを囲う」と言っています。

私の問題は、あるプロジェクトの UAT フェーズに開発者を割り当て、別の場所で別のスクラム プロジェクトを開始していることです。理想的ではありませんが、現時点では商業的な現実です。

次のいずれかを実行できます。

1) それを受け入れ、開発者に独自のコードを修正してもらい、開発者の時間 (たとえば 20%) を前のプロジェクトの UAT に割り当てます。

2) 引き継ぎが適切に行われていることを確認し、バグ修正コードに 100% 専任の開発者を 1 人または 2 人配置します。

私は 1) が好きですが、リソースを確保するのは非常に面倒です。

2) 恐ろしいことに、開発者は自分のコードの品質に責任を負わないと思います。開発者が自分のコードの所有権を確実に取得できるようにするためには、多くのことを言う必要があると思います。また、自分のバグを修正するよう依頼することは、品質を確保するための良い方法です。バグを修正するのが好きな人はいないので、開発者は通常、いずれにせよ発生した問題を修正する必要があることを知って、前もってより良い仕事をしようとします。ただし、2) の方が計画とリソースが簡単です。ただし、2) 他の人のコードのバグを修正するのは時間とリソースの面でコストがかかるため、時間がかかります。複雑な修正である場合は、いずれにしても元の開発者の助けが必要になる可能性があり、コード ベースのそのセクションに精通していない人が修正するには、確かに時間がかかります。

人々はどう思いますか？

BBDはこのスレッドで参照されています（Karl Seguinの回答）。BDDとは何ですか？

かんばんを管理するためのどのツールをお勧めしますか？