新手晋级主程之路

   在一个团队中,有的程序员一点就通。也有的程序员需要项目经理一点一点往前推才能继续。
对于一点就通的程序员通常已经成长为每个项目中的主程。另外的程序员我们权且叫新手。
鉴于国内目前的环境,基本上多数开发需求都是文档不全,产品经理拿到需求,随便写下几个要点。扔给项目经理,项目经理一看,捋起袖子找来程序员就开干了。
这时如果这个功能交给主程开发,这种程序员你只要跟他讲你需要什么样的东西,最后的结果会是怎么样,他仍然能够完成任务,达到最后的效果。
新手程序员拿到需求一看,完全没有碰到过,一下子傻了,完全不知道从何下手。这个时候就等着了,等着项目经理来仔细讲解。这是个什么样的功能,之前在什么地方用到过相同的逻辑,还在什么系统中用到过相同的技术。讲完之后,这个程序员忽然恍然大悟,哦,原来是这样的。可是最后出来的结果呢还是达不到产品经理的需求。
都是同样一个需求,怎么会差别有这么大呢。为什么主程凭着寥寥几笔的需求就能做出产品经理想要的东西,新手虽然项目经理已经给他讲的很详细,可是还达不要求。
为了让更多的新手成为主程,我们观察了一批效率高的主程和新手的工作方式。试图找出他们的不同。
同样的任务分给两个人。
主程开始了,主程一开始也并不知道这个需求要怎么做。他开始在网上搜相关的知识,了解需求上面写的到底是些什么,记录下来、写下了自己的见解。
同时我们发现这个时候主程并不急于写代码。而是接着找到产品经理或者项目经理,通过自己的思考和他们进行再次的去沟通。基本上比较完整的确定接下来所需要做的功能。主程开始干了。碰到了不清楚的地方再次百度和找产品经理沟通。经过多次沟通,反复调整。虽然产品经理只有寥寥几笔的需求,最后主程还是实现了。
新手拿到需求,打开编辑器。立马开始要编码了。再拿需求一看,额,这个要怎么做,没有做过啊。怎么办?
整个人都呆了,完全不知道如何下手了。只有找到项目经理,然后项目经理开始讲解,这是个什么样的功能,之前在什么地方用到过相同的逻辑,还在什么系统中用到过相同的技术。程序员一听好像恍然大悟,立马又开始去写程序了。做了一部分,哦。又不行了。这个时候项目经理又帮忙了…一次、两次、三次。周而复始。最后也做出来了。可是主程已经做了另外的两三个功能了。新手才刚刚完成。而且最后程序员崩溃了,项目经理也崩溃了。
我们发现同样是程序员,主程其实没有比其他人聪明多少。人嘛,都是一个肩膀扛一个脑袋。看过两种程序员的工作方式,其实我们就完全可以看出为什么有的人是主程,有的人是新手了。
我们发现主程总是自己去挖掘需求中没有被发现的点,同时自己去找到解决的方法。亦步亦趋,最后完成产品经理所需要的功能。
新手总是开始写代码,不知道怎么做了就找项目经理。不清楚了也找项目经理。项目经理让他怎么做,他就怎么做。让他怎么写代码,他就怎么写代码。项目经理就是他坚强的后盾。后面我们发现这个好像是项目经理借他的手实现一样,但是代码还写的乱七八糟。
我们发现这种程序员其实只不过是项目经理的一个傀儡而已,完全没有自己的思想,完全就是替项目经理敲敲代码而已。
从这个试验中我们发现主程做事情总是很主动,新手总是依赖着项目经理。完全等着项目经理来推动,甚至推都推不动。细细想来,可能这就是主程和新手的差别了。
人,总是会有依赖性。有的人天生依赖性强,有的人天生依赖性弱。我们试图找到一种方法,让天生依赖性强的程序员也能很好成为主程。
我们发现依赖性强的程序员不是能力不够,可能只是做事情的主动性不够或者方法不对。
思考良久,我们发现很难从程序员身上去改变。我们试着从项目经理身上开始着手。
孔子讲,育人应该因材施教。
同样,我们认为项目经理带领团队的时候也需要因材施教,只有如此,才能够培养更多的主程,培养更多的使用顺手的人。
我们开始让项目经理换一种方式和新手沟通。
每次新手来问问题的时候,先让新手自己讲出自己的想法和自己的解决方案。
新手开始有点不习惯,可是几次之后我们发现新手的问题越来越少了,做的功能开始接近产品经理的需求了。
四五次之后。我们发现新手几乎不问该怎么实现了,好像突然之间换了个人。开始自己一个人思考,一个人去完成。
这个时候,新手已经在通往了主程的路上了。
我们成功了,我们又多给项目经理培养了一个主程替补。
       经过多次试验,我们终于找到了一条更好的培养主程的方法。
与其一直推着程序员去走路,不如推着程序员学习怎么走路,然后程序员自己上路。项目经理每次只需要引导程序员去思考,而不是去教导程序员如何实现。授人以鱼不如授人以渔,何乐而不为。
同样新手,自己学会主动思考,摒弃自己的依赖性,离主程就不远了。

怎样成为一个好的技术领导者

如果不能从帮助团队获得满足感,那么就不要成为一名领导者
技术领导者要忙于会议、计划、打断、团队沟通、文档等工作,永远无法达到一个人单独工作时所能达到的那种个体生产力。
技术领导者的工作不再是让自己成为最好的编码人员,而是要尽可能地让其他人成为最好的编码人员。工作分配也要以一种有利于团队和个人成长的方式进行。要负责为团队成员清楚障碍,让他们的工作进入正轨。
技术领导者的满足感来自新人的培养和成长。
将自己视为其他开发人员的导师
即使已经知道了答案,有时候也需要让团队自行决策。许多时候,正确的答案并不唯一。技术领导者的工作不是选择正确的答案,而是确保团队不选择错误的答案。允许团队作为一个整体自行决策有利于保持高涨的士气,让每名成员都更有自豪感和主人翁精神。
在有关技术问题上,团队信任并依赖你的建议/观点。作为技术领导者要了解团队所开发的应用,了解该应用所涉及的领域,了解功能背后的技术,并编写详细的技术文档。
有时候,技术领导者同时也是首席工程师。这时,他所能为团队做的最有价值的事情是在开始和结束时为团队成员提供帮助。
有时候,技术领导者还是架构师。当解释系统或代码的行为时,他需要能够快速改变高度。当同开发人员调试问题时,他要能够深入技术细节;而当向 CEO 解释计划或成本估算时,他要能够在一个更高的层次上谈论系统。
随时准备好回答团队成员的问题
但当你有问题要问他们时要首先询问他们是否方便。这很难做到,因为作为一名技术领导者,你有许多工作要做。但是,为了可以有更多的时间回答他人的问题及为其他人提供支持,可以将复杂的任务委派给团队中更有经验的成员。
很多时候,团队成员的问题本可以在空闲或闲聊的时候提出。为此,引入可异步使用的生产力工具是一种更好的方式,比如,对于一些不太紧急的问题,可以借助 Trello 卡片或 GitHub 问题跟踪器提出。不过,不管采用什么样的沟通机制,关键是要获得其他团队成员的支持,让他们在工作无法进行或完成的时候,可以很舒服地打断你。
为了了解团队成员,技术领导者要定期主动同团队成员进行一对一的沟通。每名开发人员都是不同的,通过沟通可以了解到这种不同。
减少具体的编码工作,但仍然要编码
即使不做很多具体的编码工作,也仍然需要监控和接受所有的 pull request,并利用这个过程,帮助初级开发者修改代码。这是必须的,如果不编码,那么开发人员会质疑你的判断,不容易接受你的建议。
但是,作为技术领导者,你的首要任务是确保团队成员的生产力,而不是自己的生产力。你要为整个团队的输出负责,如果那意味着零编码,那么就不要编码了。同时,这也意味着,即使代价是停下自己的工作,也要帮助处于困境中的团队成员。
要谦逊
要相信,你的团队所具备的能力和理解力都要超过你。
要承认,关于某个主题或组件,有人懂得比你多。成为一名优秀的领导者,并不需要事事都懂得比别人多。
如果团队成员都将你视为权威,那么他们会害怕自己做决策。在这种情况下,你就成了障碍。
要诚实
当你知道答案的时候,就说出来,即使那意味着某些人要重做大量的工作。如果你不知道答案,也要说出来,不能不懂装懂。你获得了当前的职位,就说明你有资格,你永远不需要向其他人证明你的能力。
除了上述这些讨论比较多的观点外,还有一些其它的观点,比如,把令人愉快的任务分给别人,把令人讨厌的任务留给自己;公开表扬,私底下批评;让每个团队成员都清楚地知道你对他们的期望;及时反馈和表扬;与非技术管理人员建立稳固的关系等等。还有一些行为是技术领导者应该避免的,比如,不要抱怨代码库有多糟糕;不要说“我们要重写 XYZ”,技术债务要逐步解决;不要轻易提议使用可选的平台和框架。不过,需要注意的是,不同的组织有不同的企业文化,对技术和技术领导者有不同的看法和预期,技术领导者要以此为出发点考虑问题。

一些研发管理定律

最近看到的几条定律,在工作当中了解一下或许有用。
1. 帕金森定律(Parkinson’s Law)亦称“官场病”或“组织麻痹病”:工作会自动地膨胀,占满一个人所有可用的时间,如果时间充裕,他就会放慢工作节奏或是增添其他项目以便用掉所有的时间。 The demand upon a resource tends to expand to match the supply of the resource.
The amount of time that one has to perform a task is the amount of time it will take to complete the task.
2. 康威定律(Conway’s law):最终产生的产品设计等同于组织内和组织间的沟通结构。
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
(人力组织的结构要变更总是设计到各种既得利益者,不一定都能往最合理的方向演化。)
3. 布鲁克斯定律(Brooks’ law):往落后的项目中投入更多人往往使进度更加落后;来自《人月神话》。(PS:新增加人有学习曲线和沟通成本的增加)
According to Brooks, there is an incremental person who, when added to a project, makes it take more, not less time. Brooks adds that “nine women can’t make a baby in one month”.
4. 手表定律(Segal’s law):手表定理是指一个人有一只表时,可以知道现在是几点钟,当他同时拥有两只表时,却无法确定。
“A man with a watch knows what time it is. A man with two watches is never sure.”
It refers to the potential pitfalls of having too much potentially conflicting information when making a decision.
5. 木桶定律又称短板理论,木桶短板管理理论:一只木桶能装多少水,完全取决于它最短的那块木板。从一个软件系统或者是一个产品、公司都很可能适合木桶理论;不过,也有反木桶理论。
6. 墨菲定律(Murphy’s law):凡事可能出错的事必定出错。事情往往会向你所想到的不好的方向发展,只要有这个可能性。
Anything that can go wrong, will go wrong.
不要存有侥幸心理~~~

《人月神话》书摘,看这一篇就够了

什么叫“人月神话”?
人是程序员,月是时间,,如果1人干10个月如果等同10人干1个月,那就成神话。
  1
焦油坑
过去几十年的大型系统开发就犹如一个焦油坑,很多大型动物在其中剧烈挣扎,他们中大多数开发出了可运行的系统–不过,其中只有非常少数的项目满足了目标、时间进度和预算的要求。
各种团队,大型的和小型的,庞杂的和精干的,一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难,每个都能被解决,但是当它们相互纠缠和累积在一起的时候,团队的行动就会变得越来越慢且很难看清问题的本质。
  2
人月神话
缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来影响还大。
我们围绕成本核算的估计技术,混淆了工作量和项目进展。人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。
向软件项目中增派人手从三个方面增加了项目必要的总体工作量:
任务重新分配本身和所造成的工作中断;
培训新人员;
额外的相互沟通。
关于进度安排,我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
Brook法则:向进度落后的项目中增加人手,只会使进度更加落后。
特别需要指出的是,不为系统测试安排足够的时间简直就是一场灾难。
在现实情况中,一旦开发团队观察到进度的偏差,总是倾向于对任务进行削减。当项目延期所导致的后续成本非常高时,这常常是唯一可行的方法。
  3
外科手术队伍
小型、精干队伍是最好的–尽可能的少。
需要协作沟通的人员的数量影响着开发成本,因为成本的主要组成部分是相互的沟通和交流,以及更正沟通不当所引起的不良结果(系统调试)。
Mills建议大型项目的每一个部分由一个团队解决,但是该队伍以类似外科手术的方式组建,而并非一拥而上。
一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法–既能获得由少数头脑产生的产品完整性,又能得到多位协助人员的总体生产率,还彻底地减少了沟通的工作量。
  4
贵族专制、民主政治和系统设计
为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统,哪怕它们其实包含着许多很好的设计。
同工作的水平分割相比,垂直划分从根本上大大减少了劳动量,结果是使交流彻底地简化,概念完整性得到大幅提高。
  5
画蛇添足
一种普遍倾向是过分地设计第二个系统,向系统添加很多修饰功能和想法,它们曾在第一个系统中被小心谨慎地推迟了。
实际情况中,尽早交流和持续沟通能使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。
面对估算过高的难题,结构师有两个选择:削减设计或者建议成本更低的实现方法–挑战估算的结果
  6
贯彻执行
即使是大型的设计团队,设计结果也必须由一个或两个人来完成,以确保这些决定是一致的。
允许体系结构师对实现人员的询问做出电话应答解释是非常重要的,并且必须进行日志记录和整理发布。
对于存有疑问的实现人员,应鼓励他们打电话询问相应的结构师,而不是一边自行猜测一边工作,这是一项很基本的措施。
  7
为什么巴比伦塔会失败?
巴比伦塔项目的失败是因为缺乏交流,以及交流的结果–组织。
 “因为左手不知道右手在做什么,从而进度灾难、功能的不合理和系统缺陷纷纷出现。
随着工作的进行,许多小组慢慢地修改自己程序的功能、规模和速度,他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定,而因此给其他部分引发了BUG。
解决方案:
团队应该以尽可能多的方式进行相互之间的交流:非正式、常规项目会议,会上进行简要的技术陈述、共享的正式项目工作手册。举行常规项目会议,会议中,团队一个接一个地进行简要的技术陈述。这种方式非常有用,能澄清成百上千的细小误解。
制定项目工作手册,并实时记录变更:首先,必须在页面上标记发生改变的文本,例如,使用页边上的竖线标记每行变化的文字。第二,分发的变更页附带独立的总结性文字,对变更的重要性以及批注进行记录。
  8
胸有成竹
编码大约只占了问题的六分之一左右,编码估计或者比率的错误可能会导致不合理的荒谬结果。
对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释,并可能存在错误的情况.
使用适当的高级语言,编程的生产率可以提高5倍。
  9
削足适履
在大型的团队中,各个小组倾向于不断地局部优化,以满足自己的目标,而较少考虑队用户的整体影响。这种方向性的问题是大型项目的主要危险。
为了满足目标,每个人都在局部优化自己的程序,很少会有人停下来,考虑一下对客户的整体影响。
培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。
 10
提纲挈领
如果要制造一台机器,哪些是关键的文档呢?
目标:定义待满足的目标和需要,定义迫切需要的资源、约束和优先级。
首先,书面记录决策是必要的。只有记录下来,分歧才会明朗,矛盾才会突出。项目经理常常会不断发现,许多理应被普遍认同的策略,完全不为团队的一些成员所知。每个文档本身就可以作为检查列表或者数据库。
项目经理的基本职责是使每个人都向着相同的方向前进。项目经理的主要日常工作是沟通,而不是做出决定;文档使各项计划和决策在整个团队范围内得到交流。
通过周期性的回顾,他能清楚项目所处的状态,以及哪些需要重点进行更改和调整。
 11
未雨绸缪
变更的客观需要
对于大多数项目,第一个开发的系统并不合用。它可能太慢、太大,而且难以使用,或者三者兼而有之。
用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
软件产品易于掌握的特性和不可见性,导致了它的构建人员(特别容易)面临着永恒的需求变更。
目标上(和开发策略上)的一些正常变化无可避免,事先为它们做准备总比假设它们不会出现要好得多。
为变更计划组织结构
当系统发生变化时,管理结构也需要进行调整。只要管理人员和技术人才的天赋允许,老板必须对他们的能力培养给予极大的关注,使管理人员和技术人才具有互换性。
为什么缺陷不能更彻底地被修复?
首先,看上去很轻微的错误,似乎仅仅是局部操作上的失败,实际上却是系统级别的问题,通常这不是很明显。
设计实现的人员越少、接口越少,产生的错误也就越少。
所有修改都倾向于破坏系统的架构,增加了系统的混乱程度。用在修复原有设计上瑕疵的工作量越来越少,而早期维护活动本身的漏洞所引起修复工作越来越多。
随着时间的推移,系统变得越来越无序,修复工作迟早会失去根基 ,尽管理论上系统一直可用,但实际上,整个系统已经面目全非,无法再成为下一步进展的基础。
机器在变化,配置在变化,用户的需求在变化,所以现实系统不可能永远可用。崭新的、对于原有系统的重新设计是完全必要的。
 12
干将莫邪
每个编程人员也保留着编辑器、排序、内存信息转储、磁盘实用程序等工具。 这种方法对软件项目来说是愚蠢的。首先,项目的关键问题是沟通,个性化的工具妨碍–而不是促进沟通。
交互式编程
MIT的Multics项目的成果之一,是它对软件编程系统开发的贡献。在那些系统编程所关注的方面,Multics(以及后续系统,IBM的TSS)和其他交互式计算机系统在概念上有很大的不同:多个级别上数据和程序的共享和保护,可延伸的库管理,以及协助终端用户共同开发的设施。我确信在某些应用上,批处理系统决不会被交互式系统所取代。
 13
整体部分
许许多多的失败完全源于那些产品未精确定义的地方。
“细致的功能定义、详细的规格说明、规范化的功能描述说明以及这些方法的实施,大大减少了系统中必须查找的bug数量。 注: 需求文档越详细,bug越少
在编写任何代码之前,规格说明必须提交给测试小组,以详细地检查说明的完整性和明确性 注: 需求文档给测试过一遍
他将程序开发划分成体系结构设计、设计实现和物理编码实现,每个步骤可以使用自顶向下的方法很好地实现。
好的自顶向下设计从几个方面避免了bug。
首先,清晰的结构和表达方式更容易对需求和模块功能进行精确的描述。
其次,模块分割和模块独立性避免了系统级的bug。
另外,细节的隐藏使结构上的缺陷更加容易识别。
最后,设计在每个精化步骤的层次上是可以测试的,所以测试可以尽早开始,并且每个步骤的重点可以放在合适的级别上。
一些糟糕的系统往往就是试图挽救一个基础很差的设计,而对它添加了很多表面装饰般的补丁。自顶向下的方法减少了这样的企图。
 14
祸起萧墙
当人们听到某个项目的进度发生了灾难性偏离时,可能会认为项目一定是遭受了一系列重大灾难。然而,通常灾祸来自白蚁的肆虐,而不是龙卷风的侵袭。
里程碑
里程碑的选择只有一个原则,那就是,里程碑必须是具体的、特定的、可度量的事件,能够进行清晰定义。
例如:”结构师和实现人员签字认可的规格说明”,”100%源代码编制完成,纸带打孔完成并输入到磁盘库”,”测试通过了所有的测试用例”。
如果里程碑很模糊,老板就常常会得到一份与实际情况不符的报告。
慢性进度偏离是士气杀手。[Microsoft的Jim McCarthy说:”如果你错过了一个最终期限(deadline),确保制订下一条deadline
如果在某项活动开始之前就着手估计,并且每两周进行一次仔细的修订,根据实际情况动态调整时间。当里程碑没有正确反映损失的时间,并对人们形成误导,以致事态无法挽回的时候,它会彻底碾碎小组的士气。
保持进度透明可见
一线经理的利益和老板的利益是内在冲突的。一线经理担心如果汇报了问题,老板会采取行动,这些行动会取代经理的作用,降低自己的威信,搞乱了其他计划。所以,只要项目经理认为自己可以独立解决问题,他就不会告诉老板。
有两种掀开毯子把污垢展现在老板面前的方法,它们必须都被采用。
一种是减少角色冲突和鼓励状态共享
减少角色的冲突。老板必须规范自己,不对项目经理可以解决的问题做出反应。当项目经理了解到老板收到项目报告之后不会惊慌,或者不会越俎代庖时,他就逐渐会提交真实的评估结果。
另一种是猛地拉开地毯。
猛地拉开地毯。不论协作与否,拥有能了解状态真相的评审机制是必要的。PERT图以及频繁的里程碑是这种评审的基础。大型项目中,可能需要每周对某些部分进行评审,大约一个月左右进行整体评审。
没有银弹软件工程中的根本和次要问题
没有任何技术或管理上的进展,能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。因为软件有无法规避的特性:复杂度、一致性、可变性、不可见性。
产品复杂度:
由于复杂度,团队成员之间的沟通非常困难,导致了产品瑕疵、成本超支和进度延迟;
由于复杂度,列举和理解所有可能的状态十分困难,影响了产品的可靠性;
由于函数的复杂度,函数调用变得困难,导致程序难以使用;
由于结构性复杂度,程序难以在不产生副作用的情况下用新函数扩充;由于结构性复杂度,造成很多安全机制状态上的不可见性。
复杂度不仅仅导致技术上的困难,还引发了很多管理上的问题。它使全面理解问题变得困难,从而妨碍了概念上的完整性;它使所有离散出口难以寻找和控制;它引起了大量学习和理解上的负担,使开发慢慢演变成了一场灾难。
软件可变性:
软件实体经常会遭受到持续的变更压力
现实工作中,经常发生两种情况。
当人们发现软件很有用时,会在原有应用范围的边界,或者在超越边界的情况下使用软件。功能扩展的压力主要来自那些喜欢基本功能,又对软件提出了很多新用法的用户们。
其次,软件一定是在某种计算机硬件平台上开发,成功软件的生命期通常比当初的计算机硬件平台要长。即使不是更换计算机,则有可能是换新型号的磁盘、显示器或者打印机。软件必须与各种新生事物保持一致。
软件不可见性
软件是不可见的和无法可视化的。 其中的秘密就是逐步发育成长,而不是一次性搭建。
软件开发是一件棘手的事情,并不会有魔术般的解决方案,现在是从业者研究和分析革命性进展的时刻,而不是等待或希望它的出现。
现在有可能可以在软件生产率上取得逐步的进展,而不是等待不可能到来的大突破。

为什么本地开发时使用CURL请求本地URL会卡死

^_^是在WIN下开发。配置是nignxphp mysql
默认时启动phpcgi是
D:\php \php-cgi.exe-b 127.0.0.1:9000 -c D:\phpfind\phpa\php.ini
先看NGINX配置
location ~ \.php(.*)$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
include fastcgi_params;
}
NGINX中,看PHP文件块fastcig-pass的设置值(127.0.0.1:9000)。设置都是以keepalive方式请求,接收到PHP文件时,交于后端过程PHPCGI解析处理(127.0.0.1:9000),等待响应。而在本地文件以CURL请求本地环境中PHP文件时,之前的PHP还在等待CURL后的结果,这时9000端口已经被占用。导致CURL一直在处于等待状态。不设置timeout超时,程序就会卡死。结果都是false
解决方案:
新开启一个phpcgi进程设置不同端口:
例D:\php\php-cgi.exe -b 127.0.0.1:9001 -c D:\phpfind\phpa\php.ini
在需要被CURL的端口或域名设置中设置。
location ~ \.php(.*)$ {
fastcgi_pass 127.0.0.1:9001;
fastcgi_index index.php;
fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
include fastcgi_params;
}
这样就可以请求了。但是不能请求同一个域下的文件。
这样可以在nginx中使用php-cgi负载均衡:
upstream backend{
server 127.0.0.1:9000;
server 127.0.0.1:9001;
}
location ~ \.php(.*)$ {
fastcgi_pass backend;
fastcgi_index index.php;
fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
include fastcgi_params;
}