大型公司开发软件的流程是怎样的?

一首简单的歌
571次浏览
2020年01月05日 05:29
最佳经验
本文由作者推荐
知名的app开发公司
大型公司开发软件的流程是怎样的?
软件开发编程大型公司开发软件的流程是怎样的?添加评论 分享按投票排序按时间排序29 个回答546赞同反对,不会显示你的姓名vczh,专业造轮子,前排已拉黑。…健康哥哥、林艺伟77、Jenkyn Wong 等人赞同像我们经常开发那些出了bug的话客户都会过来杀了你的软件(如SQLServer)的公司,我们的开发是很严格的。在保证功能完成之后,首要的一件事就是,确保软件不会给客户带来破坏。因此除了敏捷开发以外,我们主要做了三件事情来让码农不要在开发的时候太分心搞别的。
第一件事就是你做了一个关键的设计之后,会有一个负责security review的小组来看你的文档,问你问题,根据他们的专业经验指出软件哪里可能是会被攻击的薄弱环节。举个例子,你用了XML做配置文件,如果用户偷偷给你换了一个破坏过的XML,你的程序就会挂。一旦程序进入挂了的状态的时候,是很危险的。如果你试图恢复它然后继续运行,你就得考虑大量的细节,来把你的软件从错误的状态恢复到正确的状态。中间稍有不慎就容易被攻击。所以我们都鼓励说,一旦发生了这些不可逆转的破坏,就让程序自己出dump然后自杀。当然具体到XML这个例子,我们还有xsd文件,用Windows自带的MSXML组件来实现验证一下,所以还算是个小事。JSON就没这个福利了。
第二件事情就是,我们的环境搭得特别科学。譬如说你开发SQLServer2014,那你还要给SQLServer2008打补丁。2008打补丁的时候用的SDK和开发环境可能跟2014有巨大的区别。所以我们有一个Build Team,写了几万行的perl和bat脚本,来使得我们可以做到说,我们只要从2014的branch切换到2008的branch,这些工具就自动变了,譬如说就从新的版本指向了旧的版本,库啊什么其他的乱七八糟的也是。如果你刚好用不上Visual Studio的话,只要你把代码从Source Control上搞下来,运行他帮你建立在桌面上的一个快捷方式,就可以打开一个cmd,里面的环境都配置好了,而且不会污染别的cmd。那我们就再也不怕手忙脚乱用错工具来开发导致出现更多问题了。一个人有可能要同时在不同的版本上干不同的事情,因此这是很重要的。因此我们也会把大量的二进制文件checkin进去,因此很多组尝试使用git最后都失败了(啊哈哈哈
Visual Studio组跟SQLServer做法也差不多。但是因为VS要用上一个版本来开发下一个版本(譬如说2010就是用2008写出来的),因此Source Control里面的脚本还要负责编译一个干净的、临时使用的、不在注册表里面捣乱的、热拔插的Visual Studio。你们想,如果我给2010写的代码出了翔,把2008的注册表阉割了,还是把几个文件删了,我再也打开不了2008来改2010,这种事情能被允许发生吗?不能!但是程序总是会出bug的怎么办?所以我们要有特殊的手段来解决这些问题,就是随时编译、checkin一个绿色的、但是功能丝毫不少的Visual Studio。当然这个东西只有Visual Studio组的人才有,而且长得跟正常的VS还是有显著的区别的。不过这样Source Control里面的东西就更大了,但是微软有的是硬盘,而且Perforce和TFS天生就对二进制文件支持的好,没关系,跟git什么的不一样。
第三件事情就是制度的问题了。产品狗在我们这里,责任很大,权力很小。原则上产品狗是管不了我们的,我们之所以听产品狗的话,是因为我们跟产品狗都有相同的目标——把软件做好。所以每当产品狗做了一些奇怪的决定的时候,我们可以很容易的拒绝他。他为了完成他们自己的工作指标,要么就要来说服我们,要么就只能改自己的决定了。因为产品狗和码农之间没有达成一致从而导致软件没按时完成的,产品狗具有很大的责任。我们还有专业的测试团队。测试团队的权力不小。譬如说产品狗提了一个需求,测试可以跳出来说这个功能会给测试带来无比的困难,从而拒绝产品狗的决定。因此产品狗的每一个决定,首先要保证可以被科学的实现出来。当然产品狗自己通常可能不知道什么是科学,所以我们要通过不断的打他的脸来让他明白,什么是科学。发布于 2014-09-11 117 条评论 感谢 分享 收藏 · 没有帮助 · 举报 · 作者保留权利收起49赞同反对,不会显示你的姓名顾露,程序猿一枚 : )燃冰、TerryTan、张磊 等人赞同这是一个悲伤的故事:// actually this should be a singleton, anyway I've made it global
Boss theBoss; Game* MakeAGame(Manager theProducer,
std::list<Designer>& designers,
std::list<Programmer>& programmers)
{
if (())
return NULL;
if (())
return NULL;    Game* theGame = new (nothrow) Game(tOfMoney());
if (!theGame)
return NULL;

// do the initializing work
theGame->SetPlatform(rm);
theGame->SetGameType(FindMostProfitableGameType());
foreach (Designer designer : designers)
{
theGame->AddDesignDocuments(omElsewhere);
}
theGame->bugCount = 0;

// the main loop (each iteration is a release cycle)
while (true)
{
auto thisRelease = scoped_ptr<Milestone>(new Milestone());

int intensity = (designers, programmers);        foreach (Designer designer : designers)
{
("Ctrl", "C");
("Ctrl", "V");
}

foreach (Programer programmer : programmers)
{
(thisRelease, intensity);
}

theGame->bugCount += thisRelease->bugCount;
if (theGame->IsPlayableWithoutCrash())
{
ast("Let's ship it!!!");
break;
}        rDelay();       
}

return theGame;
}
如果上边的故事太长的话,这是一个化简版:-----------v 1.04 修复 @蛋丁 同学提到的内存泄漏
v 1.03 @程睿 同学说参数太多,嗯嗯,俺虚心接受,想了想,把 theBoss 改成全局的了。
v 1.02 把传值的 std::list 改成std::list&,本来想传常引用的,不过想想还是算了。这个捏其实也是照顾广大还没用上 C++11 的同学的习惯,C++11 通常是 std::move 进来就可以了。
v 1.01 修复了 @阿峰 同学报的 bug,Hack() 传入 thisRelease 应该就好了吧 :)编辑于 2014-09-13 13 条评论 感谢 分享 收藏 · 没有帮助 · 举报 · 作者保留权利21赞同反对,不会显示你的姓名知乎用户,博雅人吴是非、知乎用户、TerryTan 等人赞同我所在的成都分部有200多号人,类似的分部全国各地有十几处。应该算是比较大的公司了。
大致流程如下:
1、采样、收集汇总数据,确认产品类型。
2、立项评估(demo演示,PPT/VISO/思维导图/Axure都行)。
3、立项书撰写与审核(包括团队成员的确定、工期预估、经费等等)。
4、详细设计文档(分程序类和美术类,项目开发,策划先行)
5、开发过程(不细说)
6、真机测试(细化、反复修正改良,小的半月,大的3~6个月)
7、上传审核(自家渠道可以不用)
8、上线试运营期(1~2周,没什么问题的话这个项目才能算完结)编辑于 2014-09-12 3 条评论 感谢 分享 收藏 · 没有帮助 · 举报 · 作者保留权利18赞同反对,不会显示你的姓名知乎用户,程序猿一枚AH Plankton、Jun WANG、墨涵 等人赞同谢邀,我当前部门的开发流程其实并不够规范高效。
一般企业级软件定制开发有的毛病一样不少。。。
一般首先是销售去卖软件,签合同。
然后需求调研去调研需求。
需求调研完形成需求文档,传递给开发人员,再由系统架构师分析并分解需求为各个足够小并相对独立的功能点,分派给各个开发。
开发去写代码,写完转测试。
测试开始测试的时候,开发相互review代码。
修改各种问题,写各种文档。
发布。流程大概就是这样,至于喜闻乐见的需求变更和产品之间相互不配合什么的,等我下班在补。。。继续加班—————————————华丽丽的分割线———————————————
下班回来补上,由此可见业软狗的苦逼。
牢骚结束。首先,业内流行的软件开发模式无外乎两大类,一类叫CMMI,一类叫敏捷。
其次,这两类开发模式无所谓优劣,只有适不适合项目和团队当前的需要。从无一竿子打死,说XX一定比XX好这样的事存在。
再次,从本人目前经历过的若干项目来看很少有极为纯粹的CMMI或者敏捷的实践,多数都是因地制宜的以一种模式为主,并且加入了另外一种模式的几个关键动作形成了所谓的流程。
CMMI和敏捷的共同点就是核心思想是一致的,就是持续改进,随着团队技能水平的提高和沟通效率的提升,逐步的优化流程,这才是管理者应该做的事,而不是天天盯着报表和文档上的数字,仿佛进度条到头了,项目就可以大功告成了一样。