私はフリーランスのキャリアの中で、プロジェクト管理、予約/予約、電子メール管理などをサポートする中小企業向けのWebアプリケーションをいくつか開発してきました。
私はこの作業が好きですが、最終的には私のアプリケーションがメンテナンスの監視が非常に高くなるポイントに到達することがわかりました。6か月前に書いたコードを振り返ると、修正や機能の追加を行う前に、最初にどのようにコーディングしたかを再学習する必要があることがわかりました。私はフレームワークを使用して練習しようとしています（以前はZend Frameworkを使用しており、次のプロジェクトでDjangoを検討しています）
簡単に保守できるようにコードを壊さずにクリーンに保つことができるアプリケーションを計画するために、どのような手法または戦略を使用していますか？誰かが推薦できる本や記事を持っているなら、それも大いにありがたいです。
そのトピックに関する優れた記事は確かにありますが、どれも実際の経験に代わるものではありません.
保守性は、非常に小規模なプロジェクトを除いて、すぐに計画できるものではありません。これは、プロジェクト全体で処理する必要があるものです。実際、大量のクラスとインフラストラクチャ コードを事前に作成すると、単純なスパゲッティ コードよりもさらに理解しにくいコードが生成される可能性があります。
したがって、既存のプロジェクトを継続的にリファクタリングしてクリーンアップすることをお勧めします。変更するのが面倒だった部分を見て、理解しやすく、調整しやすい、より単純なソリューションを目指してください。コードがあまりにも悪い場合は、最初から書き直すことを検討してください。
いくつかの記事を読んだり、新しいフレームワークを使用したからといって、新しいプロジェクトを開始して、それらが成功することを期待しないでください。代わりに、既存のプロジェクトの失敗を特定し、特定の問題を修正してください。コードを変更する必要があるときはいつでも、将来の同様の変更をサポートするためにコードを再構築する方法を自問してください。今後も同様の変更が行われるため、これはとにかく行う必要があることです。
これらのリファクタリングを行うことで、質問したり記事を読んだりできるさまざまな特定の質問に出くわすでしょう。そうすれば、一般的な質問をしたり、メンテナンスやフレームワークに関する一般的な記事を読んだりするだけでなく、より多くのことを学ぶことができます。
今日からコードのクリーンアップを始めてください。将来のプロジェクトに延期しないでください。
(ドキュメンテーションについても同じことが言えます。誰もが最初のドキュメンテーションは非常に悪いものでした。数か月後には、冗長になりすぎて、重要でないものでいっぱいになることが判明しました。そのため、実際に抱えていた問題の解決策でドキュメンテーションを補足してください。次の可能性が高いからです。あなたは同じような問題に直面するでしょう. これらの経験は、「良い書き方」スタイルガイドよりもあなたの文章スタイルを改善します.)
I'd honestly recommend looking at Martin Fowlers Patterns of Enterprise Application Architecture. It discusses a lot of ways to make your application more organized and maintainable. In addition, I would recommend using unit testing to give you better comprehension of your code. Kent Beck's book on Test Driven Development is a great resource for learning how to address change to your code through unit tests.
保守性を向上させるには、次のことができます。
あなたが唯一の開発者である場合は、コーディング スタイルを採用し、それに固執してください。これにより、後で自分のコードをナビゲートする際に、実行できた可能性があることと、絶対に実行しないであろうことについて自信が持てます。どこを探すべきか、何を探すべきか、何を探すべきでないかを確信することで、多くの時間を節約できます。
ドキュメントを最新の状態にするために、常に時間をかけてください。開発計画にタスクを含めます。その時間を変更または新機能の一部として計画に含めます。
ドキュメントのバランスを保ちます: 概要図、意味のあるコメント。最良のコメントは、コード自体から読み取ることができないことを示しています。ビジネス上の理由や、コードの特定のチャンクの背後にある「理由」のように。
コード構造、フォルダー名、名前空間、オブジェクト、変数、およびルーチン名を最新の状態に保ち、実際の動作を反映させるための努力を計画に含めます。これにより、保守性が大幅に向上します。スペードは常に「スペード」と呼びます。コードの大きなチャンクを避け、選択した言語内で利用可能な方法で構造化し、チャンクに意味のある名前を付けます。
低結合で高コヒーレンス。契約による設計、依存性注入、アスペクト、設計パターンなど、これらを達成するためのテクニックを最新の状態に保つようにしてください。
タスク管理の観点からは、より多くの時間を見積もり、非継続的な作業に対してより高い料金を請求する必要があります。管理と分析のオーバーヘッドが大きくなるため、より大きな継続的なプロジェクトや継続的なメンテナンスとは対照的に、時間の経過とともに広がる小さな非継続的な変更を行うには余分な時間が必要であることを顧客に知らせることを躊躇しないでください (影響を含む各変更を管理および分析する必要があります)。既存のシステムでは別途）。お客様が得られるメリットの 1 つは、システムの平均寿命が長くなることです。もう 1 つは、必要に応じて他の人に助けを求める選択肢を保持する正確な文書です。どちらもお客様の投資を保護し、強力なセールス ポイントです。
まだ行っていない場合は、ソース管理を使用します
顧客のために行ったすべてのことと、重要なコミュニケーション (単純なコンピューターまたは紙ベースの CMS) の詳細なログを保持します。各課題の前に記憶をリフレッシュしてください。
未解決の問題、アイデア、顧客ごとの提案のログを保持します。課題を始める前に、もう一度記憶をリフレッシュしてください。
実装後のサポートをどのように実施するかを事前に計画し、お客様と話し合います。システムの保守を容易にします。パラメータ化、監視ツール、ビルド内の健全性チェックを計画します。初期契約の一部として、実装後のサポートをお客様に販売します。
実装後のサポートを提供するためだけに誰かが必要な場合でも、採用して拡大します。
推奨読書:
設計パターンに関するものはすべて、推奨される読書のリストに含まれています。
The most important advice I can give having helped grow an old web application into an extremely high available, high demand web application is to encapsulate everything. - in particular
Here is an excellent article on how eBay tackles these problems http://www.infoq.com/articles/ebay-scalability-best-practices
フレームワーク/MVC システムを使用します。コードが整理され、一元化されているほど優れています。
Memcache を使用してみてください。PHP には組み込みの拡張機能があり、セットアップに約 10 分、アプリケーションに追加するのにさらに 20 分かかります。すべてのアプリケーションについて、必要なものは何でもキャッシュできます。すべてのデータベース レコードをその中にキャッシュします。それはさまよいます。
まだ使用していない場合は、Subversion などのソース管理システムを使用することをお勧めします。
おそらくSharePointの使用を検討する必要があります。これは、あなたが言及したすべてを実行するようにすでに設計されている環境であり、おそらくあなたが考えていなかった他の多くの機能を備えています (ただし、将来必要になるかもしれません:-) )
以下、公式サイトからの情報です。
使用できる SharePoint 環境には、Windows SharePoint Services (WSS) または Microsoft Office Sharepoint Server (MOSS) の 2 つがあります。WSS は無料で、Windows Server 2003 に同梱されています。一方、MOSS は無料ではありませんが、より多くの機能を備えており、企業のニーズのほぼすべてをカバーしています。