Python编程-用Python开发企业级软件的规则/建议？

Question

我是一个有点高级的C++/Java开发人员，最近对Python很感兴趣，我非常喜欢它的动态类型和高效的编码风格。目前，我将它用于解决编程谜语和脚本等小的编程需求，但我很好奇是否有人在企业质量的项目中成功地使用了Python？(最好使用现代编程概念，如OOP和某种类型的设计模式)

如果是这样的话，请您解释为什么(特别是)选择Python，并给我们一些您从这个项目中学到的课程？(可以将Python在项目中的使用与Java或等等进行比较)

Answer 1

我正在使用Python开发一个复杂的保险承保应用程序。

我们的应用软件本质上重新包装了我们的精算模型，使公司可以订阅它。这项业务是基于我们的精算师和他们的深思。我们没有包装一个相对固定的聪明算法。我们通过网络服务将我们的精算大脑出租给客户。

精算师必须自由地进行变革，因为他们对导致索赔的各种因素有了更深入的了解。

- Static languages (Java, C++, C#) lead to early lock-in to a data model.
- Python allows us to have a very flexible data model.  They're free to add, change or delete factors or information sources without a lot of development cost and complexity.  Duck typing allows us to introduce new pieces without a lot rework.

​

1. 我们的软件是一个服务(而不是包)，所以我们有一个没完没了的集成问题。

- Static languages need complex mapping components.  Often some kind of configurable, XML-driven mapping from customer messages to our ever-changing internal structures.
- Python allows us to have the mappings as a simple Python class definition that we simply tweak, test and put into production.  There are no limitations on this module -- it's first-class Python code.

​

1. 我们必须做广泛的，长期运行的概念证明.这涉及到许多具有不同数据提要和自定义功能的“什么-如果”场景。

- Static languages require a lot of careful planning and thinking to create yet another demo, yet another mapping from yet another customer-supplied file to the current version of our actuarial models.
- Python requires much less planning.  Duck typing (and Django) let us knock out a demo without very much pain.  The data mappings are simple python class definitions; our actuarial models are in a fairly constant state of flux.

​

1. 我们的业务模式需要经过一定的谈判。我们与信息提供商签订了相当复杂的合同；这些合同的变化不像精算模型那样频繁，但这里的变化需要customization.

- Static languages bind in assumptions about the contracts, and require fairly complex designs (or workarounds) to handle the brain-farts of the business folks negotiating the deals.
- In Python, we use an extensive test suite and do a lot of refactoring as the various contract terms and conditions trickle down to us.  

每周我们都会遇到这样的问题：“我们能处理X这样的条款吗？”我们的标准答案是“绝对”。然后是一个小时的重构，以确保我们能够处理它，如果交易是以这种形式达成的。

1. 我们主要是一个RESTful web服务。Django做了很多这件事。我们不得不编写一些扩展，因为我们的安全模型比Django提供的模型更严格。

- Static languages don't have to ship source.  Don't like the security model?  Pay the vendor $$$.
- Dynamic languages must ship as source.  In our case, we spend time reading the source of Django carefully to make sure that our security model fits cleanly with the rest of Django.  We don't _need_ HIPAA compliance, but we're building it in anyway.  

​

1. 我们使用信息提供商提供的web服务。urllib2很好地为我们做到了这一点。我们可以快速建立一个接口。

- With a static language, you have API's, you write, you run, and you hope it worked.  The development cycle is Edit, Compile, Build, Run, Crash, Look at Logs; and this is just to spike the interface and be sure we have the protocol, credentials and configuration right.
- We exercise the interface in interactive Python.  Since we're executing it interactively, we can examine the responses immediately. The development cycle is reduced to Run, Edit.  We can spike a web services API in an afternoon.

​

Answer 2

我一直在世界上最大的银行之一使用Python作为分布式计算框架。之所以选择它，是因为：

开发和部署新的functionalities;

• It必须非常快，必须易于与C和C++集成；代码的某些部分是由专门从事数学建模而不是软件开发的人编写的。