タグ付けされた質問 「maintenance」

これが一般的な質問ではないことを願っています。経験豊富なアドバイスを本当に活用できました。 私は、過去10〜20年にわたって広大なコードベースを一緒に使用してきたかなり小さな科学者の店で、唯一の「SWエンジニア」として新たに採用されました。（実質的に廃止された言語で書かれました：G2 -Pascal with graphicsを考えてください）。プログラム自体は、複雑な化学処理プラントの物理モデルです。それを書いたチームは信じられないほど深いドメイン知識を持っていますが、プログラミングの基礎に関する正式なトレーニングはほとんど、またはまったくありません。彼らは最近、存在しない構成管理の結果についていくつかの難しい教訓を学びました。また、コード自体に文書化されていない「スラッジ」が大量に蓄積されているため、メンテナンス作業が大幅に妨げられています。私はあなたに状況の「政治」をspareしまない（常にある 政治！）、しかし言うことで十分ですが、先の道に必要なものについて意見のコンセンサスはありません。 彼らは、現代のソフトウェア開発の原則のいくつかをチームに提示し始めるように私に頼みました。彼らは、コーディング規約、ライフサイクル管理、高レベルの設計パターン、およびソース管理に関する業界標準の実践と戦略のいくつかを紹介してほしいと思っています。率直に言って、それはかなり困難な作業であり、どこから始めればよいのかわかりません。 最初は、The Pragmatic Programmer、またはFowler's Refactoring（ "Code Smells"など）の中心概念のいくつかでそれらを指導したいと思っています。また、多くのアジャイル手法を紹介したいと思っています。しかし、最終的には、効果的にするために、5〜7の基本的な基礎に磨きをかける必要があると思います。言い換えれば、彼らが現実的に実装を開始できる最も重要な原則または慣行は何であり、それは彼らに最も「大金」を与えるでしょう。 それが私の質問です：スパゲッティをまっすぐにするのに役立つ（そして将来的にそれを防ぐために）最も効果的な戦略のリストに何を含めますか？

470 project-management  agile  development-process  maintenance  sdlc 

私は最近、中規模企業のWeb開発者としてのキャリアを始めました。開始するとすぐに、既存のアプリケーションを拡張するタスクを取得しました（不適切なコーディング、長年にわたって複数のプログラマーによって開発され、同じタスクを異なる方法で処理し、構造はゼロです）。 そのため、要求された機能を使用してこのアプリケーションを正常に拡張した後、アプリケーションを完全に保守するタスクをくれました。これはもちろん問題ではありませんでした。しかし、その後、既存のコードを改善することは許されず、バグが報告された場合にのみバグ修正に集中することができないと聞いた。 その時から、上記と同じようにさらに3つのプロジェクトがあり、それを今も維持する必要があります。そして、アプリケーションをゼロから作成することを許可された4つのプロジェクトがあり、それらも維持する必要があります。 現時点では、私が維持しなければならない各アプリケーションのユーザー（読み取りマネージャー）の毎日のメールから少しばかり夢中になり始めています。彼らは、私がこれらのメールを直接処理すると同時に、他の2つの新しいプロジェクトに取り組んでくれることを期待しています（そして、その後にさらに5つのプロジェクトが並んでいます）。残念なことに、自分でコーディングしたものに関するバグレポートをまだ受け取っていません。そのため、たまに180度のさまざまな変更要求を受け取りました。 とにかく、これは正常ですか？私の意見では、私は開発者のチーム全体と同等の仕事をしています。 最初は物事が違うと思っていたとき、私はばかでしたか？ この投稿は大暴れになったと思いますが、これはすべての開発者にとって同じではないことを教えてください。 PS私の給料は、スーパーのレジ係の給料より低くないとしても、ほぼ同じです。

368 maintenance 

未知のコードベースを探索および学習するために、どのツールとテクニックを使用しますか？ 私はのようなツールを考えていますgrep、ctagsコードメトリクスが好き、ユニットテスト、機能テスト、クラス図ジェネレータは、グラフを呼び出すsloccountように、と。私はあなたの経験、あなたが使用または書いたヘルパー、そしてあなたが働いたコードベースのサイズに興味があります。 コードベースに精通することは時間の経過とともに発生するプロセスであり、「コードを要約できる」から「リファクタリングしてサイズの30％に縮小できる」まで、なじみがあることを意味します。しかし、どのように始めるのでしょうか？

145 source-code  maintenance 

私は優れたプログラマーです。私はいつもプログラムが大好きです。そして、私はプログラミングについて多くのことを学び、私をより良いプログラマーにしたいと思っています。私は1年間プログラミングを学び、現在はほぼ2年間プログラマーとして働いています。要するに、私はほぼ3年のプログラミング経験があります。 私たちのチームは5人のプログラマで構成されており、うち4人は新しく、1人は3年以上の経験があります。私たちはもう1年近くプログラムに取り組んでおり、コードをレビューする人は誰もいませんでした。コードのレビューは一度も行ったことがなく、まったく新しいので、きれいなコードがどのようなものかはわかりません。プログラマーは自分で学ぶと思う？ 徹底的なテストなしで、プログラムにプログラムを展開しました。現在はタイトであり、コードを変更する前にまず承認とコードレビューが必要です。初めて、誰かが私のコードをレビューし、彼はそれが混乱だと言います。 私はとても悲しくて傷つきます。プログラミングが大好きで、そのようなことを言わせると本当に痛いです。私は本当に自分自身を改善したいです。しかし、私は映画のような天才プログラマーではないようです。もっと良くする方法についてアドバイスをいただけますか？コードを批判する何かを経験したことがありますか？それらのイベントで何をしますか。

86 teamwork  code-reviews  maintenance 

私は大規模な非技術的なユーザーベースを持つプロジェクトのメンテナーです。約4年間メンテナンスを続けており、要求に応じて新しい機能を追加しています。 今すぐ他のプロジェクトに移り、このアプリケーションの開発を停止したいと思います。ユーザーの非技術的な性質のため、過去にはコードの貢献はほとんどありませんでした。私の代わりにプロジェクトを引き継ぐ他の誰かを見つけることができるとは思わない。 バグ、問題、機能のリクエスト-これらはまだ寄せられています。私はまだメールを受け取っていますが、それらを無視すべきかどうか、アプリケーションで作業していないこと、または返信すべきかどうかはわかりません。特定の場合にのみメールを送信します。 このプロジェクトを「放棄」するための最良の方法は何ですか？それでもユーザーはアプリケーションを使用できますか？ 更新（2016年7月）-計画どおりに進みませんでした。私はREADMEで発表し、すぐに、より本質的な貢献を受け取り始めました。バグ修正、機能、ドキュメント、問題アクティビティを含むプルリクエスト。それ以来、プロジェクトは「活力を取り戻した」と感じており、新しいプロジェクトと一緒に喜んでそれを維持しています。協力者もいます。推測では、それはプロジェクトの私の見解に影響を与えていた種類の貢献だったかもしれません。

75 open-source  project  maintenance 

バージョン管理システムにより、コードのいたるところに「変更ログ」を貼る必要がなくなるという印象を受けました。私は頻繁に変更ログの継続的な使用を見てきました。これには、ファイルへの変更のためにブロックされた大きなセクションを含むストアドプロシージャの開始時の大きな長いブロックが含まれます。 // 2011-06-14 (John Smith) Change XYZ to ABC to fix Bug #999 そして： // 2009-95-12 (Bob Jones) Extracted this code to Class Foo // <commented-out code here> 私に説明されたように、この理由は、VCSログをふるいにかけるのに時間がかかりすぎて、誰が何をなぜ変更したかを見つけようとしている間、コードファイル自体に関連する上部または近くにそれを持っているからです誰が何をいつ変更したかを簡単に確認できます。私はその点を見ていますが、冗長であり、「VCSを適切に使用する方法が本当にわからないので、そのようなことは一切気にしません。 どう思いますか？コメントとログの両方を使用していますか？ただのログ？John Smithが1週間前にXYZをチェックするようにメソッドを変更したコードブロックの上に表示されると、Diffツールでログを検索してコードファイルを比較する代わりに、コーディングが簡単になりますか？ 編集：SVNを使用しますが、基本的にはリポジトリとしてのみ。ブランチ、マージ、ログ+ストレージ以外はありません。

75 version-control  coding-standards  maintenance 

比較的大きなプログラム（C＃で900k SLOCなど）があり、すべてが十分にコメント/文書化され、適切に組織化され、適切に機能しているとします。コードベース全体は、もはや会社にいない単一の上級開発者によって作成されました。すべてのコードはそのままテスト可能であり、IoCが全体で使用されます（ユニットテストを作成しなかった奇妙な理由を除く）。今、あなたの会社はコードを分岐させ、変更がコア機能を壊すときを検出するために単体テストを追加したいと考えています。 テストの追加は良いアイデアですか？ もしそうなら、どのようにしてこのようなものから始めるのでしょうか？ 編集 わかりました、それで私は反対の結論に対して良い議論をする答えを期待していませんでした。とにかく問題は私の手に負えないかもしれません。私も「重複した質問」を読みましたが、一般的なコンセンサスは「テストを書くのは良い」ということです...ええ、しかしこの特定のケースではあまり役に立ちません。 レガシーシステムのテストを書くことをここで考えているのは私だけではないと思います。どれだけの時間を費やし、新しいテストが問題をキャッチする回数（および、そうでない回数）のメトリックを保持します。私は戻って来て、私の結果でこれから1年かそこらを更新します。 結論 そのため、正統性に似た既存のコードに単体テストを追加することは基本的に不可能です。コードが動作すると、テストを赤信号/緑信号にすることは明らかにできません。通常、テストする必要がある動作が明確ではなく、どこから始めればよいか、完了したら明確ではありません。本当にこの質問をすることでさえ、そもそもテストを書くことの主要なポイントを見逃しています。ほとんどの場合、意図した機能を解読してユニットテストを遡及的に追加するよりも、TDDを使用してコードを書き直す方が実際に簡単であることがわかりました。問題を修正したり、新しい機能を追加したりするのは別の話であり、ユニットテストを追加するときだと思います（以下で指摘するように）。最終的には、ほとんどのコードが書き直され、多くの場合、予想よりも早くなります。

68 unit-testing  tdd  maintenance 

私は10年以上ソフトウェア開発に携わっていますが、「新しい」ものを作成することはめったにありません。「新しい」という用語は曖昧な用語であることを理解していますが、明確な新しい大規模プロジェクトから既存のプロジェクトの新しい大規模な機能に至るまで、その定義を定義します完了するには2週間以上かかります）。大まかなガイドラインは、書面による仕様が必要な場合は新しいものかもしれません。ほとんどのプログラマは私が話していることを知っていると思います-あなたはゾーンにいて、大量のコードを速いペースで書いています。 とにかく、自分がやったことを振り返ってみると、「新しい」仕事に費やされている時間は10％未満だと見積もっています。「この既存のシステムをこの新しい環境で動作するように適応させる」など、確かに多くの計画が必要ですが、実際のコーディングと「新しいもの」は、コード全体の多くの場所で小さな変更を行うことになります。同様に、小さな機能のリクエストについては-何をすべきかを知っていれば、これらは1時間以内に完了することがよくありますが、そうでない場合は、コードを読んで何をすべきかを考え出すだけです読むことではなく、行うことでより良くなります）。 一般的に、私はほとんど何も実際に作成していないように感じます。ほとんどの場所でこれが当てはまると思います-新しい製品がかなり早く出て、その時点で誰もが興奮してコードを速いペースで叩き出しますが、一度ライブになるとメンテナンスモードに移行しますその後の変更のいくつかは、「新規かつ創造的」と見なされます。 私が間違っている？私はほとんどのプログラミングの仕事を正確に説明していますか、それともほとんどのプログラマーは新しいものを頻繁に作成していると感じていますか？

63 programming-practices  maintenance 

私はソフトウェア業界での仕事、独学、就職する前にオープンソースに参加した経験はあまりありません。お金のために働いている今、私はまた、いくつかの不快なものに対処する必要がありますが、これは当然のことです。 最近、私は明らかに仕事でコーディングすることを学んでいたプログラマーによって書かれた大規模なSharePointプロジェクトにロギングを追加するように割り当てられました。2年間の共同作業の後、クライアントは当社に切り替えましたが、損害は発生しました。そして今、どういうわけかこのコードを保守する必要があります。 コードはありませんでしたことをあまりにも読みにくいです。問題にもかかわらず、各プロジェクトにはコピーペーストされたメソッド、巨大なifネスト、Systems Hungarian、無秩序な接続を含む1つのクラスがあります。 しかし、ロギングを追加するような簡単な作業を行っていたにもかかわらず、私は完全に非生産的でした。基本的に、ステップごとにコードを調べて、トレース呼び出しを追加するだけです。ただし、コードの愚かさは非常に迷惑なので、開始から10分以内に疲れてしまいます。最初は、usingコンストラクトを追加し、を逆にしてネストを減らしif、変数の名前を読み取り可能な名前に変更しましたが、プロジェクトは大きく、最終的にはgaveめました。これは私がやるべきタスクではないことはわかっていますが、少なくとも混乱を減らすことで、続けることができるように何らかの心理的な報酬を得ることができました。トリックが機能しなくなり、仕事の60％がまだ残っています。 仕事の後に頭痛がし始め、今までの満足感が得られなくなりました。通常は、10時間ストレートでコーディングしても新鮮に感じることができます。 これは単なる大騒ぎではありません。実際に質問があります。 生産性を維持し、風車と戦わない方法はありますか？ 代わりに思考の、タスクに集中するために心理的なトリックのいくつかの種類があり、「どのように愚かであることは？」私は以前、プログラマが別の巧妙なトリックを見るたびに？ロギングを追加する際の問題は、実際にコードが何をするのかを理解しなければならないことであり、そうすることは不快な形で脳を傷つけます。

63 code-quality  productivity  maintenance 

コーディングの経験はほとんどありません。作業を始めた後は、ほとんどの場合、他の人のコードに取り組み、既存の機能に新しい機能を追加するか、既存の機能を変更します。実際のコードを書いた人は、私の会社ではもう機能しません。私は彼のコードを理解し、自分の仕事をするのに苦労しています。コードを変更しようとするたびに、何らかの形で作業機能を台無しにしています。他の人のコードを操作する際に注意すべきことは何ですか？

60 architecture  coding-style  coding-standards  coding  maintenance 

私は、大企業内でライフサイクルの中間点にあるアプリケーションの小さな開発者チームを管理しています。残念ながら、これは通常、プログラミングタスクが「その他の技術的作業」に30/70分割されていることを意味します。この作業には以下が含まれます。 DBA / Unix / Network / Loadbalancerチームとのさまざまなタスクでの作業 異なる地域でのハードウェアまたはインフラストラクチャの注文と配置の管理 まだCIに移行されていないテストの実行 分析 サポート/調査 開発者はすべて、これらのより日常的なタスクを行うよりもコーディングを好むと言うのは当然です。そのため、楽しいプログラミングジョブをチーム間で均等に配布するようにします。 ほとんどのチームは、独自のコンパイラ/ゲームエンジン/高頻度取引システムなどを作成するためのエリートプログラミングスキルを持たないかもしれませんが、「物事を成し遂げる」ことができ、他のチームと協力する優れたコミュニケーターであるため、採用されました、そしてここで複雑な官僚機構をいくぶんナビゲートします。彼らは優れた開発者ですが、優れた総合的な技術スタッフでもあります。 ただし、チームの1人のメンバーはおそらく平均以上のコーディングスキルを持っていますが、平均以下のコミュニケーションスキルを持っています。従来、以前の開発マネージャーは、上記のより日常的なタスクではなく、プログラミングタスクを提供する傾向がありました。ただし、大企業のIT部門で一般的に必要とされるバランスのとれたスキルセットを開発する適性を示している他のチームにとって、これが公平だとは思いません。 この状況ではどうすればよいですか？彼にもっとプログラミングの仕事を与え続けると、それがより速く行われることを知っています（そして逆に、彼は他の仕事をより遅く完了すると期待しています）。しかし、それは私の原則に反しており、単にあなたが好きではないタスクに悪いことによって、あなた自身のために「快適なニッチ」を切り開くことができるという考えを促進します。 clarifyみが原因でこの問題に対処しようとしていないこと、または言及したように「肩に欠けている」ことを明確にしたいと思います。バランスの取れたチームを維持する方法についてのアドバイスを探しています。チームは幸せでやる気があります。この質問に対するさまざまな答えを観察することにより、これを達成する方法について多くの異なる意見があるようです。

52 teamwork  management  communication  maintenance  team-leader 

過去3年間の私の仕事の大部分は、再販売する前にパッチの適用や時折の改良が必要なレガシーシステムの維持に主に取り組んできました。 多数のプロジェクトを抱え、開発者が限られている企業では、専任のメンテナンスプログラマが果たすべき重要な役割を理解しています。 しかし、私が現在のキャリアの進歩を判断し、仲間を見ると、請負業者と企業開発者の両方; 私が触れた領域の面でかなりの幅を獲得したので、私ははるかに遅れているように感じますが、深さはあまりありません。ブログを始め、自分の小さなgit-hubプロジェクトに取り組み、仕事の後に定期的に個人的なコーディングを行う時間があるように私の人生を再スケジュールすることで、これに対処し始めました。 メンテナンス作業から逃れるために他の会社に面接したのは、特定のことに焦点を当てた3年の経験を持つ人に必要な深い知識レベルがないので、スキルレベルがかなり後輩であると自分自身を表さなければならないだろうと思う機能開発のパスは。ですから、私の現在の仕事の経験の半分は、長期的には無駄になります。 しかし、これは私の個人的なジレンマにあまりにも集中していると感じたら謝罪する私の主な質問につながります： 専用のメンテナンスプログラミングの役割は、初期のキャリアにとって不利になりますか？他のプログラマは、このような役割を避ける権利がありますか？この作業を行うと、後輩としてやり直す準備ができていない限り、同様のタスクを実行できなくなりますか？

52 maintenance  skills  legacy 

私たちが勉強したいものを選択し、私たちのキャリアと人生をどうするかを選択するとき、私たちは皆、それがどのようになるかについていくつかの期待を持っています。ほぼ10年間業界に携わってきた今、私は（コンピューターサイエンスを勉強していた頃の）プログラミングワーキングライフがどのようなものになるのか、実際にどうなるのかについて少し考えてきました。あります。 私の2つの最大のショック（または、期待を裏切る）は、ソフトウェアに関わるメンテナンス作業の量が非常に多いことと、プロフェッショナリズムの全体的な欠如です。 メンテナンス：uniでは、ソフトウェア作業の大半は既存のシステムのメンテナンスであると言われました。だから私は抽象的にこれを期待することを知っていた。しかし、これがどれほど圧倒的であるかを正確に想像することはできませんでした。おそらくそれは私が精神的にmentalめたものであり、私はもっと多くのクールな新しいものをゼロから構築することを望んでいました。しかし、実際には、ほとんどのジョブは、圧倒的にメンテナンス、バグ修正、およびサポート指向です。 プロフェッショナリズムの欠如：大学では、商用ソフトウェアの仕事は非常にプロセス指向であり、厳密に設計されているという印象が常にありました。ISOプロセスのイメージ、一連の技術文書、すべての機能とバグが厳密に文書化され、一般的にプロフェッショナルな環境がありました。ほとんどのソフトウェア企業が、学期規模の大規模なプロジェクトに取り組んでいる学生チームと同じように運営されていることに気づいたのは、大きな衝撃でした。そして、私は小さなアジャイルハックショップと中規模の企業の両方で働いてきました。私はそれが常にあからさまな「非専門的」だとは言いませんが、ソフトウェア産業は（全体として）私が期待していた強力なエンジニアリングの規律とはかけ離れているように感じます。 他の誰かがこれに似た経験をしましたか？私たちの職業がどのようになるかについてのあなたの期待が現実と異なっていた方法は何ですか？

50 maintenance  development-methodologies 

プロジェクトの既存のモジュールを拡張する必要があります。私はそれが行われた方法が好きではありません（コピー/貼り付けられたコードのような、アンチパターンがたくさんあります）。多くの理由で完全なリファクタリングを実行したくありません。 したほうがいい： 次のメンテナーとの混乱を避け、コードベースとの一貫性を保つために、間違っていると感じたとしても、既存の規則を使用して新しいメソッドを作成しますか？ または コードに別のパターンを導入している場合でも、私が気分が良いものを使用してみてください？ 最初の回答後に編集された精度： 既存のコードは混乱ではありません。簡単に理解できます。しかし、良いデザインで回避できる多くの定型コードを導入しています（その結果、コードを追跡するのが難しくなるかもしれません）。私の現在のケースでは、古き良きJDBC（インボードのスプリングテンプレート）DAOモジュールですが、すでにこのジレンマに遭遇しており、他の開発者フィードバックを探しています。 時間がないので、リファクタリングしたくありません。そして、時間が経っても、完全に機能するモジュール全体にリファクタリングが必要であることを正当化するのは困難です。リファクタリングのコストは、そのメリットよりも重いでしょう。覚えておいてください：コードは乱雑でも複雑でもありません。そこにいくつかのメソッドを抽出して、ここで抽象クラスを紹介することはできません。それは設計上の欠陥です（極端な「愚かなシンプルを保つ」の結果だと思います） したがって、質問はそのように尋ねることもできます： 開発者として、あなたは簡単な愚かな退屈なコードを維持することを好みますか、またはあなたの場所で愚かな退屈なコードを行うヘルパーを持っていますか？ 最後の可能性の欠点は、いくつかのことを学ばなければならず、完全なリファクタリングが完了するまで、簡単な愚かな退屈なコードを維持しなければならないことです）

45 refactoring  coding  maintenance  anti-patterns 

私は小さな開発者チームを管理しています。コードをクリーンアップするために、1〜2日を費やすことにします。 コードベースをクリーンアップするために、2か月ごとに1週間などの定期的な時間をスケジュールすることをお勧めしますか？

42 project-management  programming-practices  refactoring  maintenance