methodology - 自分で開発する

Question

私の会社では、各開発者が自分で作業するプロジェクトを与えられているため、チームワークはほとんどありません。私はこのようなソフトウェアを、優れた開発方法論の規律なしで 1 年間構築してきました。結果は問題ありませんでしたが、次のプロジェクトでは、より本格的な開発アプローチを変更して使用したいと考えています。

自分でソフトウェアを開発するためのベストプラクティスは何だと思いますか? ソフトウェア開発でよくある落とし穴を避けるために、どのような方法論を使用できますか? どのソフトウェア開発モデル (冗談ですが、ウォーターフォール、エクストリーム、アジャイルなど) が自分に最も適していますか?

より良い開発者になる方法を学べるリソースやチュートリアルを教えていただければ幸いです :)

ありがとう。

score 11 · Accepted Answer

自分でソフトウェアを開発するのは非常に困難です。別の人間がアイデアを跳ね返してくれると、物事がはるかに簡単になり、満足度が高まります。しかし、ここにキッカーがあります-他の人はあなたがしていることにそれほど同調する必要はありません. 物事を誰かに説明するだけで、自分が何をしているかについての洞察が得られることがよくあります。

私は以前、「テディと話す」ことを推奨する誰かと仕事をしていました。つまり、お気に入りのぬいぐるみ (ビンキー氏) を選び、あなたが取り組んでいる新しい RESTful API の詳細をビンキー氏に説明してください。目がくらむようなインスピレーションのフラッシュがあなたを襲うので、頭を叩きます-「ああ、そこに別のリソースが必要であることはわかっていました、ありがとうBinkster!」.

気をつけてください、その同僚の正気はわかりません...

より合理的なアプローチとして、別の開発者と緩やかな提携を結び、プロジェクトをお互いに跳ね返して、その後孤立して作業に戻ったとしても、できませんか?

score 8 · Accepted Answer

コードを文書化しないという罠に陥らないでください。これは、簡単に忘れられてしまうアドバイスの 1 つだと思います。なぜなら、can を自分で書いたので、それが何をするのかを知っておくべきだからですよね?... 間違っています! 過去のプロジェクトの 1 つを取り上げて、ドキュメントをまったく使用せずに物事がどのように機能したかを理解するだけです。それは、他の誰かの (悪い) コードを読むようなものです。

私は常に、Java の javadoc やコード内の .NET に相当するものなど、標準のドキュメントスタイルを使用することをお勧めしますが、実際には、どのような種類のドキュメントでも、まったくないよりはましです...

score 5 · Accepted Answer

私は何年も自分で仕事をしてきました。最初は機械エンジニアのグループの一員として。今、自分のプロジェクトに取り組んでいます。上記の回答に同意します。

あなたが取り組んでいることについて誰か（誰にでも）と話してください。妻の目はすぐに曇ってしまいますが、明確な質問をしようとします。通常、質問は意味をなしませんが、私は彼女が私の上司であるふりをして、とにかく答えます. 私はそのようにしてあらゆる種類の解決策を見つけます。

開発方法論は、ほとんどが 1 人のチームにとってやり過ぎです。ただし、いくつかのアジャイルプラクティスを採用しました。まず、半日以内の短い時間単位ですべてを見積もります。次に、作業を 3 週間または 4 週間の小さな「スプリント」に分割します。私は見積もりとスケジューリングのすべてに FogBugz を使用しています (1 ～ 2 人のグループ用の無料のホストバージョンがあります)。

コードのドキュメント化、ソース管理、および単体テストの基本事項を忘れないでください。私はそれぞれ Doxygen、Subversion/TortoiseSVN、NUnit を使用しています。

score 3 · Accepted Answer

バージョン管理を使用し、常にコードのコンパイルを最小限に留めて、常にチェックインします。私は長年、比較的孤立した大規模な組織で働いていました。より一般的にアジャイル開発プラクティスと呼ばれるものを自然に適用しました。どんなに大まかでも動くものを手に入れ、リファクタリングを繰り返します。

安定した状態を維持することは非常に役立ちます。つまり、誰かとやり取りできるとき、アイデアや抽象的な概念の集まりではなく、何かを示すことができるということです。

「Pragmatic Programmer」は素晴らしい読み物だと思います。

score 2 · Accepted Answer

ジョエルテストをチェックしてください。独立した開発者としてこれらのプラクティスを実装することは、やりがいのある挑戦でした。

score 2 · Accepted Answer

ほとんどの方法論の大部分は、実際にチームとしてどのように連携できるかを定義しています。アジャイル/エクストリームプログラミングなどの大部分は、コミュニケーション、チーム環境の設定などに関するものです。一人で作業する場合、簡単な作業もあれば (ペアプログラミングなど) 難しい作業もあります。

いくつかの方法論を読んで、必要だと思われるプラクティスを選んでください。1 人のチームであれば、非常に柔軟に対応できます。したがって、大規模なチームを連携させることを目的とした方法論に従うためだけに、それをあきらめないようにしてください。したがって、本当に必要なプラクティスのみを選択してください。TDD のような薄いものと反復作業は、容易に達成できる成果です。自分がしていることを評価し続け、改善し続けてください。

score 1 · Accepted Answer

SCM を使用するだけでなく、Issue Tracker を使用することをお勧めします。やらなければならないことを追加するのに少し時間がかかるかもしれませんが、リビジョン管理からの変更ログよりも追跡しやすい形式で、進捗状況の具体的な記録を提供します。

また、リストから項目を削除すると、暖かいファジーが得られます。TODOリストの拡張だと思います。

score 1 · Accepted Answer

XP などのような「本格的な」開発手法のほとんどは、チームメンバー間のコミュニケーションのチャネリングと合理化に重点を置いていると思います。

「1人」のチームで開発する場合、毎日のスクラムミーティングなどを自分で行うメリットはありません;-) したがって、「バージョン管理を使用する」などのいくつかのベストプラクティスに固執するだけで十分なはずです。など。本「Pragmatic Programmer」と「Ship it!」チームで作業する場合でも、単独で作業する場合でも、順守する価値のあるいくつかのプラクティスの概要がわかるかもしれません。少なくとも私のためにそれをしました。

明確にするために、コーディングを開始する前に、プロジェクトの何らかの構造または計画が必要になりますが、単純な To Do リストと計画されたソフトウェア設計の生のスケッチのようなもので十分です。

score 1 · Accepted Answer

私がローン開発者として働いていたとき、私は XP を使用しており、Joel が物事を成し遂げるのと相まって、あなたが単調な記事にすぎないときに、私を率直で狭い範囲にとどめています。

「ベストプラクティス」を適用することで ROI が向上することを証明できれば、それをチームに統合できる学習演習として扱いました。これは優れた開発者に与えられますが、まだ証明する必要があります。少なくとも私の経験では。

その後、私は、私が働いていた会社の方針によりよく適合する、カスタマイズされたアジャイルプロセスを使用しました。

score 1 · Accepted Answer

練習が最適ではないと感じ、同じように感じている人がいる場合は、少し協力してみませんか? あなたの会社が特に奇妙で、開発者がお互いから学ぶことを許さないのであれば、別の雇用を真剣に検討すべきだと思います。おそらく、そのような環境では最高の状態にはなれないでしょう。

あなたが間違った質問をしていることを示唆したので、C2 Wikiにソロ開発者のアジリティの良い出発点があります。

score 1 · Accepted Answer

@reefnet_alex

おっしゃる通り、たとえそれが自分自身であろうとぬいぐるみであろうと、明確に表現するプロセスは物事を考える上で素晴らしいものです。個人的には、何かを解決しようとするとき、ファイルにブログのようなモノログを入力します。これには、必要なときに参照できるという追加のボーナスがあります。

他の戦略に関する限り、TODO リストを維持するのが最善の方法だと思います。1 つのことに行き詰まったら、todo リストの別のことに移ります。

score 1 · Accepted Answer

@カイル

昔の人は、ファイルラウスのメモを通して自分自身に説明しますね。恐ろしいことに、先日、古いコードのいくつかの上部に次のコメントがありました。

/*
    bloody hell - where to start...
*/

score 1 · Accepted Answer

あなたがプロジェクト/問題に取り組んでいる唯一の人であるとき、コミュニケーションは良好でなければならないので、そのために形式は実際には必要ありません. ただし、他の投稿で述べたように、バージョン管理などの優れたプラクティスは引き続き適用されます。誰かからアイデアを跳ね返すことは、私にとっても重要であることが証明されています.

一人で作業する場合、コミュニケーションは問題ありませんが、場合によってはポストイットを使用して個人的なスクラムボードを作成すると役立つことがわかりました。私はつい最近、チーム指向の会社から、それとはかけ離れた会社に引っ越しましたが、それは難しい移行です。

解決に至る方法についてのもう 1 つの考えです。Conceptual Blockbustingという本には、問題をより適切に解決する方法についての優れた観察結果が含まれています。

score 1 · Accepted Answer

あなたはコード部分を管理しているように見えますが、あなたが唯一の開発者であるという理由だけで、ユーザー、管理者、ネットワーク管理者などとどのように連携しているかを管理する必要があります.私は私たちの会社で唯一のプログラマーですが、常に特定のプロジェクトで他のユーザーとやり取りします。彼らはおそらく、ドキュメンテーション、要件の収集、テストとデバッグに関心があります。

score 0 · Accepted Answer

0

パーソナルソフトウェアプロセス

于 2008-09-17T19:36:12.853 に答える

score 0 · Accepted Answer

ヒントをありがとうございました:

共通の基準を使用して、コードをできる限り文書化するようにしています。私は、いつか私のコードを保守しなければならない可哀想な人のことを考えようとします (その人が私かもしれません!)。
ソース管理を使用しています。これは私にとってなくてはならないものであり、それなしでは仕事をすることができません。
単体テスト (これは 3 番目の柱ではありませんか?)... うーん... 私は単体テストをまったく行いません :(。これは、将来のプロジェクトのために変更したいことの 1 つです。
デザインをするときは、自分の考えをすべてメモするようにしています (テディベアと話しているようなものですよね?)。
TODOリストもあります。これらすべてのタスクをより適切に監視するためのアプリケーション (または Web アプリケーション) があるのではないかと思います。

いくつかの最新の方法論を見て、いくつかのテクニックを私自身の方法論に組み込んでみます。これは本当に面白そうです。

現在、自分のマシンにCruise Controlをインストールすることも考えていますが、本当に価値がありますか?

methodology - 自分で開発する

16 に答える 16

Related

Reference