Home

如何充分利用您的時間進行個人和專業發展

在當今快節奏的世界中，時間是寶貴的商品。使用時間的方式不僅影響專業進步，也對個人成長至關重要。以下是一些有效利用您的時間進行個人和專業發展的方式：

1. 技能增強

利用這段時間學習新技能或加強現有技能。可能涉及到參加在線課程，參加研討會，或獲得與您領域相關的認證。 在數字時代裡擁有豐富的资源，應充分利用。

2. 建立人脈

透過參加行業活動，社群聚會，或會議進行人脈活動。與其他專業人士建立關係可能帶來新的機會，讓你掌握行業趨勢。

3. 個人項目

投資時間於個人項目或嗜好，這可能補充您的專業技能。這不僅可以讓您探索新的興趣，也有助於建立多面向的個人作品組合。

4. 研究與閱讀

保持了解您所在領域最新的趨勢和進步。定期閱讀書籍，行業期刊，或在線文章。這種習慣可以為您的工作帶來新的觀點和創新的想法。

5. 指導和協作

考慮指導初級同事或進行內部專案的協作。這不僅可以建立領導技巧，還可以讓您與團隊保持聯繫。

6. 身體和精神健康

專注於維護健康的工作與生活平衡。定期運動，冥想，和追求嗜好對精神和身體健康至關重要。

7. 內部貢獻

參與內部公司活動，如培訓計劃，招聘工作，或組織公司活動。這顯示出您對組織的主動性和承諾。

8. 為即將到來的項目做好準備

如果您知道接下來的專案，早點開始準備。研究客戶，行業或相關技術，以保持領先。

9. 組織參與

參與組織的各種方面。參與多元化和包容性的活動，或對公司通訊做出貢獻，這都可以是充實的體驗。

10. 設置目標

花時間反思您的職業生涯，設定實際的目標。思考未來幾年您想要達到的地方，並規劃可行的步驟以實現這些目標。

結論

實質上，充分利用時間的關鍵在於平衡專業發展與個人成長。通過增強技能，擴大人脈，投入個人專案，並專注於健康和組織參與，您可以創建一個全面的日常程序，這不僅可以推進您的職業生涯，也可以豐富您的個人生活。請記住，每一刻都很重要，所以將其用於個人和專業地成長和進化。

Developing a Career Path in Architecture - Navigating the Complexities and Embracing Continuous Learning

Embarking on a career as an architect in the technological realm is a journey that demands continuous effort and learning. The landscape of technology shifts rapidly. A former Clipper expert would found his extensive knowledge in the field becoming obsolete.

The Necessity of Continuous Learning and Resourcefulness

An architect’s journey doesn’t end with acquiring a title; it’s a path marked by constant learning. Keeping abreast of both technological and business advancements is crucial. However, resources fluctuate, making it essential to actively seek the latest tools, newsfeeds, and groups. This proactive approach to resource gathering is vital in staying current and relevant in the field.

The 20-Minute Rule: Balancing Career and Personal Life

One effective method to manage this balance is the "20-Minute Rule." This technique involves dedicating a minimum of 20 minutes each day to your career development, whether it's exploring new concepts or delving deeper into familiar ones. This practice, although seemingly brief, can significantly enhance an architect's technical breadth and overall career growth.

However, implementing this rule can be challenging amidst the demands of work, family, and personal interests. It's often proposed to utilize these 20 minutes during lunch breaks or post-work hours, but these time slots frequently become occupied with other priorities. Therefore, it's recommended to apply this rule first thing in the morning, post-coffee and pre-email check, to ensure it becomes a consistent part of your daily routine.

Developing a Personal Technology Radar

The perils of ignoring technological advancements and the dangers of living in a technology bubble. This realization underscores the importance of having a personal technology radar, a concept derived from ThoughtWorks.

The ThoughtWorks Technology Radar: A Guide for Personal Adaptation

The ThoughtWorks Technology Radar, developed by the Technology Advisory Board, offers a structured approach for evaluating technologies. This biannual radar consists of four quadrants covering tools, languages and frameworks, techniques, and platforms, and it categorizes technologies into four rings: Hold, Assess, Trial, and Adopt.

For personal use, adapting these quadrants and rings can provide guidance on what to focus on, research further, actively experiment with, or fully embrace. This approach helps in balancing the allure of new, exciting technologies with practical career considerations.

Utilizing Open Source Visualization Tools and Social Media

In 2016, ThoughtWorks released a tool to assist in creating personal radar visualizations. Additionally, social media platforms like Twitter can be invaluable in staying informed about emerging technologies and industry trends.

Conclusion: Practice Makes Perfect

The path to becoming a great architect lies in constant practice. Architecture, much like any skill, improves with regular exercise and application. Remember, there are no definitive answers in architecture—only trade-offs. The key is continuous learning and practice. So, take the plunge and start building your architecture skills today!

Developing a Career Path in Architecture - Navigating the Complexities and Embracing Continuous Learning

Hello, everyone! Welcome back to Continuous Improvement, the podcast where we explore how to refine our skills and enhance our careers in technology. I’m your host, Victor Leung, and today we’re talking about the life of a software architect—not just the role itself but how to continually grow and adapt in this rapidly evolving field.

Being an architect in technology is more than just reaching a title. It’s about engaging in an ongoing journey of learning and adaptation. The landscape of technology shifts constantly; what was relevant yesterday might become obsolete tomorrow. Remember the Clipper programming language? Exactly my point.

Let's dive into something I call The 20-Minute Rule. This is a method where you dedicate at least 20 minutes each day to advancing your knowledge—whether that’s exploring a new technology or deepening your understanding of a current project. This might sound brief, but these focused minutes can profoundly influence your career growth over time.

However, it's not without challenges. Our lives are packed with responsibilities, so it’s essential to carve out this time intentionally. I recommend setting this period first thing in the morning—after your coffee and before you dive into emails. It’s about making a small window of time a non-negotiable part of your day.

Another powerful tool in your arsenal should be a Personal Technology Radar. This idea, inspired by ThoughtWorks, helps you keep track of the latest in tools, languages, frameworks, and platforms. Their Technology Radar is a fantastic resource that categorizes tech into what you should Hold, Assess, Trial, and Adopt. Adapting this to your personal learning can guide you in what to focus on and experiment with next.

And don’t underestimate the power of social media and open source tools for keeping up with tech trends. In 2016, ThoughtWorks released a tool for creating your own radar visualizations, and platforms like Twitter are invaluable for real-time updates from tech leaders and communities.

To wrap up, becoming a great architect is like any other skill—it improves with practice. There’s no perfect blueprint in architecture; it’s all about making informed trade-offs and learning from each project. Continuous learning is your best tool in navigating this complex, ever-changing environment.

Thank you for tuning in to Continuous Improvement. I hope today’s episode inspires you to integrate daily learning into your routine and actively shape your technology radar. I’m Victor Leung, and I look forward to joining you next time as we continue to build our skills and improve together. Until then, keep learning, keep growing, and keep pushing the boundaries of what you can achieve.

在建築領域的職業生涯發展中 - 應對複雜性並擁抱持續學習

作為技術領域中的建築師開始職業生涯是一條需要不斷努力和學習的旅程。科技的風景瞬息萬變。一名曾經的Clipper專家可能會發現他在這個領域的大量知識已經過時了。

持續學習與足智多謀的必要性

一個建築師的旅程並不是在獲得職位後就結束；這是一條由不斷學習標記的道路。保持對技術和商業進步的了解至關重要。然而，資源會波動，使得主動尋找最新的工具、新聞源和團體變得至關重要。這種對資源收集的主動態度對於保持與時俱進和在領域中保持相關性至關重要。

20分鐘法則：平衡職業生涯和個人生活

平衡這兩者的一種有效方法是"20分鐘法則"。這種技巧涉及到每天至少花20分鐘在你的職業發展上，無論是探索新概念還是深入瞭解熟悉的概念。這種做法，儘管看似簡短，卻可以大大提升建築師的技術廣度和整體職業發展。

然而，在工作、家庭和個人興趣的需求中實施這種規則可能會充滿挑戰。人們常常建議在午餐時間或下班後的時間利用這20分鐘，但這些時間經常被其他優先事項佔據。因此，建議早上起來，喝咖啡和查看郵件之後，第一件事就是實施這個規則，以確保它成為你每天日常生活的一部分。

發展個人科技雷達

忽視科技進步的危險和生活在科技泡沫中的危險。這一認識凸顯了擁有一個個人科技雷達的重要性，這是一個源自ThoughtWorks的概念。

ThoughtWorks科技雷達：個人適應的指南

由技術諮詢委員會開發的ThoughtWorks科技雷達，為評估技術提供了結構化的方法。這個每半年出一次的雷達包括工具、語言和框架、技術和平台的四個象限，並將技術分為四個環：保留、評估、試驗和採用。

對於個人使用，這些象限和環的調整可以提供在什麼上面集中，進一步研究，積極實驗，或完全擁抱的指導。這種方法有助於平衡新的、令人興奮的技術的吸引力和實際的職業考慮。

利用開放源碼的視覺化工具和社交媒體

在2016年，ThoughtWorks發布了一個幫助創建個人雷達可視化的工具。此外，像Twitter這樣的社交媒體平台可以在了解新興技術和行業趨勢方面提供無可估量的價值。

結論：熟能生巧

成為一個優秀的建築師的道路在於不斷的實踐。建築，就像任何一種技能一樣，隨著定期的練習和應用而提高。請記住，建築中沒有定性的答案——只有權衡。關鍵是持續的學習和實踐。所以，采取行動，開始今天就構建你的建築技能！

The Art of Negotiation and Leadership in Software Architecture

Harnessing Negotiation and Leadership as a Software Architect

In the complex world of software architecture, possessing strong negotiation and leadership skills is crucial. These are not innate traits but are cultivated through years of learning and real-world experiences. This blog post delves into these vital skills, offering foundational techniques for aspiring architects to embark on their journey towards mastery.

Understanding Negotiation and Facilitation in Architecture

A software architect's role involves navigating the political landscape of an enterprise, a task that requires keen negotiation skills. Every decision is subject to challenge, be it from developers, fellow architects, or stakeholders. Effective negotiation helps in balancing varied viewpoints and arriving at decisions that align with the organization's goals.

Real-World Negotiation: Balancing Cost and Availability

Take, for instance, the decision to use database clustering and federation for enhancing system availability. While technically sound, it's a costly choice. Here, the architect's negotiation skills come into play, striking a balance between availability and cost with business stakeholders.

Negotiating with Business Stakeholders

Scenario 1: Balancing Technical Realities and Stakeholder Expectations

Consider a scenario where a lead architect must negotiate with a senior vice president insisting on unrealistic system availability. The challenge lies in respectfully aligning the sponsor's expectations with technical feasibility, without coming off as condescending or dismissive.

Key Techniques in Stakeholder Negotiation

1. Leverage Grammar and Buzzwords: Understand underlying concerns behind phrases like “zero downtime”. It reveals stakeholders' priorities.
2. Gather Information: Before negotiating, research to understand the implications of terms like “five nines” of availability.
3. State Things in Terms of Cost and Time: Use this as a last resort, presenting the financial and temporal implications of decisions.

Negotiating with Other Architects

In disagreements, like the choice between asynchronous messaging and REST, the key lies in demonstration over argumentation. Showcasing the effectiveness of a solution in the specific environment often resolves conflicts more efficiently than theoretical debates.

Collaborating with Developers

A successful architect collaborates with the development team, justifying decisions rather than dictating them. This approach fosters mutual respect and a collaborative spirit, essential for effective team dynamics.

The Software Architect as a Leader

Leadership in software architecture is about 50% people skills. It's not just about technical prowess but also about guiding teams with clarity, communication, and collaborative spirit.

The 4 C’s of Architecture

1. Communication: Clear and concise communication is fundamental.
2. Collaboration: Work alongside teams and stakeholders for joint solution crafting.
3. Clarity and Conciseness: Avoid accidental complexity; simplicity is key.

Being Pragmatic and Visionary

Balancing pragmatic solutions with visionary thinking is vital. It's about making realistic decisions while considering future implications and technological advancements.

Leading by Example

Good architects lead not by title, but by example. They earn respect through their actions, demonstrating their commitment and expertise in real-world scenarios.

Integrating with Development Teams

An effective architect integrates with their team, balancing meeting obligations with hands-on team interaction. This involvement is crucial for mentoring, guiding, and resolving issues as they arise.

Conclusion: The Path to Effective Software Architecture Leadership

As Theodore Roosevelt aptly put it, the key to success is knowing how to get along with people. For software architects, this translates to a blend of negotiation prowess, leadership skills, and the ability to foster collaborative environments. These are the cornerstones of not just surviving but thriving in the complex landscape of software architecture.

The Art of Negotiation and Leadership in Software Architecture

Hello and welcome to another episode of Continuous Improvement. I’m Victor Leung, your guide on this journey to mastering the art and science of software architecture. Today, we're diving deep into the realms of negotiation and leadership—two crucial skills for any software architect. Whether you’re just starting out or looking to hone your existing skills, this episode is packed with insights to help you navigate the complex landscape of modern software development.

As software architects, we often find ourselves at the intersection of technology and business, where every decision can impact multiple stakeholders. Effective negotiation isn't just about getting what you want; it’s about finding a balance that aligns with the organization's goals and satisfies the varied interests of all parties involved.

Let’s consider a real-world scenario. Imagine you’re deciding whether to implement database clustering and federation to boost system availability. Technically, it’s a sound choice, but it comes with high costs. Here, your negotiation skills are crucial to balance the technical benefits against the financial constraints, crafting a solution that stakeholders can agree on.

When negotiating with senior stakeholders, like a vice president demanding unrealistic system availability, the key is to align their expectations with what’s technically feasible. Use their language, understand the concerns behind terms like “zero downtime,” and prepare to discuss the implications of these requirements.

And it’s not just about talking to business executives. Negotiating with fellow architects or developers often requires a different approach. For example, when there’s a disagreement over using asynchronous messaging versus REST, demonstrating the benefits of your preferred solution can be more effective than just theoretical debate.

Now, transitioning from negotiation to leadership, remember that being a leader in the architecture space is about 50% people skills. It’s about guiding your teams not just with authority but with empathy, clarity, and a collaborative spirit.

Embrace the 4 C’s of effective architectural leadership: Communication, Collaboration, Clarity, and Conciseness. Speak clearly, work closely with your teams and stakeholders, simplify complex ideas, and always aim to remove unnecessary complexities.

A visionary yet pragmatic approach is essential. Strive to make decisions that are realistic and consider the long-term implications of your architectural choices. Lead by example—show your commitment and expertise, and integrate closely with your team to mentor, guide, and resolve issues collaboratively.

As Theodore Roosevelt said, “The key to success is knowing how to get along with people.” For software architects, this means mastering negotiation to harmonize technical and business needs, and leading in a way that inspires and uplifts your team.

Thank you for tuning in to Continuous Improvement. I hope today’s episode empowers you to step up as a leader in your field and navigate the complexities of software architecture with confidence and finesse. I’m Victor Leung, and I look forward to exploring more topics with you that help us all grow and improve. Until next time, keep negotiating, keep leading, and keep improving.

在軟體架構中的談判和領導藝術

利用談判和領導作為一名軟體架構師

在複雜的軟體架構世界中，擁有堅強的談判和領導技能是至關重要的。這些並非天生的特質，而是經過多年的學習和真實世界經驗所培養出來的。本博客文章深入探討這些重要技能，為有志於成為架構師的人提供基礎的技術，使他們開始掌握這些技能的旅程。

理解在架構中的談判和協調

軟體架構師的角色涉及導航企業的政治景觀，這需要敏銳的談判技巧。每一個決定都可能受到挑戰，無論是來自開發人員，其他架構師，或持分者。有效的談判有助於平衡各種觀點，並做出符合組織目標的決定。

真實世界的談判：平衡成本和可用性

例如，決定使用資料庫集群和聯邦來增強系統可用性的決定。雖然在技術上聽起來完全可行，但這是一個成本高昂的選擇。這裡，架構師的談判技巧就派上用場了，他們需要跟商業持分者達成平衡可用性和成本的協議。

與商業持分者談判

情境1：平衡技術現實與持分者期望

考慮一個場景，其中一名主架構師必須與一位堅持對系統可用性有不切實際期望的高級副總裁進行談判。挑戰在於尊重地將贊助商的期望與技術可行性對齊，而不顯得高傲或無禮。

在持分者談判中的關鍵技術

1. 利用語法和流行詞：理解像是“零停機時間”這種語句背後的潛在關注點。這顯示了持分者的優先事項。
2. 收集信息：在進行談判之前，蒐集研究結論以理解像是“五個九”這種包含在可用性條款中的概念的影響。
3. 以成本和時間來說明事情：將這個方法作為最後的手段，提出決策的財務和時間影響。

與其他架構師的談判

在意見分歧中，如在異步訊息與REST之間的選擇，關鍵在於以示範優於爭論。在具體環境中展示解決方案的效果通常比理論辯論能更有效地解决衝突。

與開發人員合作

一個成功的架構師要與開發團隊合作，解釋決定，而不是強加決定。這種方法培養了相互尊重和合作的精神，對於有效的團隊動態至關重要。

軟體架構師作為一個領導者

軟體架構的領導約占人際專業技能的50%。這不僅僅是關於技術實力，也是關於以清晰，溝通和合作的精神引導團隊。

架構的4C法則

1. 溝通：清晰和簡潔的溝通是基本的。
2. 合作：與團隊和持分者一起工作，共同提出解決方案。
3. 清晰和簡潔：避免意外的複雜性；簡單是關鍵。

務實和有遠見

平衡務實的解決方案與有遠見的思考是非常重要的。這關乎在考慮未來的影響和技術進步的同時，做出現實的決定。

以身作則

好的架構師不是靠頭銜領導，而是以身作則。他們透過自己的行為贏得尊重，並在實際情境中展示自己的承諾和專業知識。

與開發團隊整合

一個有效的架構師會與他的團隊整合在一起，平衡滿足會議義務與實際團隊互動之間的關係。這種參與對於指導，指導和解決問題至關重要。

結論：成為有效軟體架構領導者的道路

正如西奧多·羅斯福所說，成功的關鍵在於知道如何與人相處。對於軟體架構師來說，這意味著談判實力，領導技能，以及培養合作環境的能力的結合。這些是在軟體架構的複雜景觀中不僅生存，而且蓬勃發展的基石。

Mastering Cloud-Native Applications - A Comprehensive Guide to the 12 Factor App Manifesto

The 12 Factor App manifesto is a methodology for building software-as-a-service (SaaS) apps that are scalable, maintainable, and deployable on modern cloud platforms. Developed by engineers at Heroku, it's a set of best practices designed to enable applications to be built with portability and resiliency when deployed to the web.

Introduction to the 12 Factor App

In the early days of web development, applications were often built in a monolithic style, tightly coupled to their execution environment. This approach led to numerous issues, especially when apps needed to scale or move to different environments. The 12 Factor App methodology was created to address these challenges, emphasizing a declarative format for setup automation, clean contract with the operating system, and minimizing divergence between development and production.

The Twelve Factors

1. Codebase: One codebase tracked in version control, many deploys. This principle advocates for a single codebase for each service which can be deployed in any environment.

2. Dependencies: Explicitly declare and isolate dependencies. Applications should explicitly declare all dependencies, not relying on the implicit existence of system-wide packages.

3. Config: Store configuration in the environment. This factor pushes for the separation of config from code, as configurations vary substantially across deploys while code does not.

4. Backing Services: Treat backing services as attached resources. This means that a deploy of the app should be able to swap out a local MySQL database for a third-party service without changing the app’s code.

5. Build, Release, Run: Strictly separate build and run stages. This factor emphasizes the need for strictly separating the build stage (where the code is converted into an executable bundle), the release stage (where the executable is combined with the config), and the run stage (where the app is actually run).

6. Processes: Execute the app as one or more stateless processes. This principle states that the app should be executed in the stateless fashion, and any data that needs to persist should be stored in a stateful backing service, like a database.

7. Port Binding: Export services via port binding. Apps should be completely self-contained and should not rely on runtime injection of a webserver into the execution environment to create a web-facing service.

8. Concurrency: Scale out via the process model. This factor implies that apps should be able to scale horizontally by adding more concurrent processes.

9. Disposability: Maximize robustness with fast startup and graceful shutdown. This principle advocates for short startup times and graceful shutdowns to maximize robustness.

10. Dev/Prod Parity: Keep development, staging, and production as similar as possible. This factor aims to reduce the gaps between development and production to ensure continuous deployment for maximum agility.

11. Logs: Treat logs as event streams. Applications should not concern themselves with routing or storage of their output stream. Instead, each running process writes its event stream, unbuffered, to stdout.

12. Admin Processes: Run admin/management tasks as one-off processes. This principle states that management tasks should be run in an environment identical to the regular long-running processes of the app.

Conclusion

The 12 Factor App methodology provides a framework for building software that demonstrates key characteristics necessary for modern cloud platforms. It addresses issues of scalability, reliability, and portability, making it easier for development teams to build and manage applications effectively. As the world of web development evolves, the principles of the 12 Factor App continue to be a vital reference for building robust, scalable cloud-native applications.

Mastering Cloud-Native Applications - A Comprehensive Guide to the 12 Factor App Manifesto

Welcome to Continuous Improvement, the podcast where we explore cutting-edge methodologies and best practices that enhance how we build software. I’m your host, Victor Leung, and in today’s episode, we’re unpacking a crucial methodology for anyone working in the realm of Software-as-a-Service or SaaS—The 12 Factor App. Developed by the engineers at Heroku, this set of guidelines has transformed how applications are built and deployed on modern cloud platforms.

To start, let's talk about why the 12 Factor App methodology was created. In the early days, web applications were often built as monoliths—large, single units that were tightly coupled with their environments. This created a myriad of problems, especially when these applications needed to scale or be moved to different environments.

The 12 Factor App methodology was designed to overcome these challenges. It emphasizes a declarative format for automation setup, a clean contract with the operating system, and a drive to minimize the gap between development and production. These practices ensure that applications are portable, scalable, and maintainable. Let’s break down these factors.

Factor 1: Codebase. There should be exactly one codebase for a service, with the codebase being used for many deployments. This means having a single repository that can be deployed anywhere, from the developer's local environment to the final production servers.

Factor 2: Dependencies. Your application should explicitly declare and isolate dependencies. This avoids the pitfalls of implicit dependencies that can lead to conflicts between differing environments.

Factor 3: Config. Configuration settings should be stored in the environment rather than in the code. This separation of config from code helps keep the application environment agnostic, making it easy to adjust settings without changing the codebase.

Factor 4: Backing Services. Treat all backing services as attached resources which can be attached or detached to deployments without significant changes to the code.

Factor 5: Build, Release, Run. Strictly separate the build and run stages. By doing this, applications are more stable and predictable since no changes are allowed that might affect the running application during the release phase.

Factor 6: Processes. Execute the app as one or more stateless processes. This is crucial for scalability and distribution since no user session or context is stored locally.

Factor 7: Port Binding. The application should be self-contained and not rely on runtime injection of a web server.

Factor 8: Concurrency. Scale out via the process model. Essentially, this involves starting more copies of the application to handle more load.

Factor 9: Disposability. Maximize robustness with fast startup and graceful shutdown. This improves the application’s reliability in the face of hardware/software failures.

Factor 10: Dev/Prod Parity. Keep development, staging, and production as similar as possible to avoid bugs that arise from environmental differences.

Factor 11: Logs. Treat logs as event streams. This allows for more scalable and manageable logging.

Factor 12: Admin Processes. Run administrative/management tasks as one-off processes. This ensures that these tasks are performed without affecting the running application’s environment.

The 12 Factor App is more than just a methodology; it’s a philosophy for software development and deployment. It’s about building software that is robust, manageable, and above all, adaptable to the changes and scales as needed without a complete overhaul.

Thanks for joining me on Continuous Improvement. Whether you’re building your next big SaaS or scaling an existing one, keeping these 12 factors in mind can be the difference between success and failure. I'm Victor Leung, and I’ll be back soon with more insights and strategies to help you refine your craft and improve your projects. Until next time, keep coding, keep improving, and stay cloud-savvy.

掌握雲原生應用程式 - 12因子應用程式宣言的全面指南

12因子應用程式宣言是一種構建軟件即服務（SaaS）應用程式的方法，這些應用程式具有可擴展性，可維護性，並且可在現代雲平台上部署。這套方法是由Heroku的工程師開發的，旨在使應用程式具有部署到web時的可攜性和彈性。

介紹12因子應用程式

在網頁開發的早期，應用程式經常以單體風格構建，與其執行環境緊密結合。這種方式導致了許多問題，尤其是當應用程式需要擴展或遷移到不同環境時。12因子應用程式的方法論就是為了解決這些挑戰，強調以聲明的方式進行設置自動化，與操作系統保持良好的合同，並使開發與生產之間的差異最小化。

十二因子

1. 程式碼庫：一個在版本控制中追蹤的程式碼庫，許多部署。這條原則主張每個服務都應有一個程式碼庫，該程式碼庫可以在任何環境中部署。

2. 依賴性：明確宣告並隔離依賴性。應用程式應明確宣告所有依賴性，不依賴於系統範疇內包的隱含存在。

3. 配置：在環境中儲存配置。這個因子推動將配置與程式碼分離，因為配置在部署間變化很大，而程式碼則不是。

4. 支援服務：將支援服務視為附加資源。這意味著應用程式的部署應能夠換出本地 MySQL 資料庫為第三方服務，而不用修改應用程式的程式碼。

5. 建立，發佈，運行：嚴格分離建立和運行階段。這個因子強調需要嚴格分離建立階段（將程式碼轉換成可執行包的階段），發佈階段（將可執行文件與配置結合的階段）和運行階段（實際運行應用程式的階段）。

6. 進程：作為一個或多個無狀態進程來執行應用程式。這個原則認為，應用程式應該以無狀態的方式執行，並且任何需要保留的資料都應該儲存在有狀態的支援服務，如資料庫。

7. 端口綁定：通過端口綁定導出服務。應用程式應完全自包含，不應依賴於服務器在運行環境中的注入來創建面向web的服務。

8. 併發：通過進程模型進行擴展。該因子意味著應用程式應能通過增加更多並發進程來實現水平擴展。

9. 廢棄：通過快速啟動和優雅關閉來最大化魯棒性。這個原則主張縮短啟動時間並優雅地關機，以最大程度地提高魯棒性。

10. 開發/生產同態：保持開發，暫存和生產盡可能相似。這個因子的目標是減少開發與生產之間的差距，確保連續部署以達到最大的敏捷性。

11. 日誌：將日誌視為事件流。應用程式不應對其輸出流的路由或儲存感到憂慮。相反，每個正在運行的進程都將其事件流無緩存地寫入stdout。

12. 管理流程：作為一次性流程運行管理/管理任務。這個原則認為，應該在與應用程式的常規長期運行進程相同的環境中運行管理任務。

結論

12因子應用程式的方法提供了一個構建軟體的框架，該軟體顯示了現代雲平台所必需的關鍵特性。它解決了可擴展性，可靠性和可攜性的問題，使開發團隊更容易有效地構建和管理應用程式。隨著網頁開發的世界不斷演進，12因子應用程式的原則繼續是構建強大、可擴展的雲原生應用程式的重要參考。