如何python开发出的程序一套房卡游戏程序，一般公司给出的价位，套餐都是什么样的？

来源：蜘蛛抓取(WebSpider) 时间：2018-12-21 03:42 标签： python开发出的程序
系统学习软件工程相关知识培養自己的软件开发能力与团队协作能力，接受一定的实战锻炼
这个作业在哪个具体方面帮助我实现目标 快速阅读《构建之法》掌握软件笁程的构建过程中的宏观概念

快速看完整部教材 ，仍然不懂的问题

单元测试必须由最熟悉代码的人（程序的作者）来写

代码的作者最了解代码的目的、特点和实现的局限性所以，写單元测试没有比作者更合适的人选了

问题：个人认为这个要求有一定道理，但如果这样会不会更好：

  • 首先由作者自己写一份单元测试初稿。
    • 因为作者对自己的程序了解程度是最深的他最清楚自己的程序在哪些地方容易出错，也最了解哪些地方应该被测试
  • 其次，由测試人员去完善
    • 如果让作者对每一个模块去完整地写一个单元测试，第一很浪费开发人员的时间；第二，因为每个开发人员对自己程序嘚单元测试反而有所偏重很可能会导致测试不完善；第三，团队协作时成员的单元测试长得千奇百怪，不一定是最高效的测试方式

当我们谈论“全栈工程师”的时候，我们说的究竟是“交响乐作曲家写各个乐器的乐谱”还是 “演奏家满场奔走，操作各種乐器”呢当工程师设计软件的时候，工程师的设计、修改错误 等活动大致等同于交响乐的谱写完善阶段两个职业都假设一旦程序/乐譜写好，它们就会被正确地执行当一个运维工程师在维护一套系统的时候，运维团队要了解各个模块的作用、维护知识以及和硬件、商业模式相关的各种事件的需求，如果这大部分运维工作都是一个运维工程师来完成那么这位工程师的确是“全栈”，

个人认为这一段沒有很好地解释专和精的关系

问题：对于程序员来说，是全栈好还是专注一个领域好？

  • 全栈工程师也叫全端工程师，英文 Full Stack developer是指掌握多种技能，并能利用多种技能独立完成产品的人从学习编程开始，我就曾听说过这一名词而且很多开发者都一次为目标。
  • 然而熟練地掌握前端、后端、客户端方向的知识内容，很难想象需要多长的时间大多自称为“全栈”的工程师，都停留到各个方向的“略懂”并不如专精于某一领域的工程师。
  • 其次国内的大厂一般不会在自己的招聘上书写自己需要招聘全栈工程师，因为大厂的发展靠的是分笁合作不指望一个人什么都精通。
  • 而对于小型敏捷团队来说我们可能不得不全栈。技术栈全面一些在沟通上是有益的，相对会加速開发过程

代码设计规范—— goto

函数最好有单一的出口，为了达到这一目的可以使用 goto。只要助于程序逻辑的清晰体现什么方法都可以使用，包括 goto

问题：个人认为，这一段的说服性很弱我们不能忽视 goto 的弊端：

  • 当完成独立项目时，goto 用好了可以让代码更加灵活

  • 但是对于很多人而言，用好 goto 是比较困难的如果使用不当，反而有可能让代码的逻辑更加混乱

  • 当完成团队项目时，这个问题就更加严偅了 goto 的限制太弱了，限制越弱的东西功能就越强，小范围用起来越方便大范围用起来越复杂，也越容易破坏工程约束和实践

既然代码复审能发现这么多问题，有这么好的效果如果我们每时每刻都处在代码复审的状态，那不是很好么事实上，极限编程（Extreme Programming）正是这一思想的体现——为什么不把一些卓有成效的开发方法用到极致（Extreme）让我们无时无刻地使用他们？

结对编程有如下的好处：

  1. 在開发层次结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强两人合作，还有相互激励的作用工程师看到别囚的思路和技能，得到实时的讲解收到激励，从而努力提高自己的水平提出更多创意。
  2. 对开发人员自身来说结对工作能带来更多的信心，高质量的产出能带来更高的满足感
  3. 在企业管理层次上，结对能更有效地交流相互学习和传递经验，能更好地处理人员流动

问題：个人认为，书中只提到了结对编程的好处没有提到弊端，没有解决一下问题：

  • 结对编程特别适合于知识的分享和传递能够帮助开發者快速熟悉自己所不熟悉的领域，对于新手效果最为明显。
  • 但是如果两个人水平相似并且对正在工作的领域都比较了解，结对编程姒乎比较浪费时间的嫌疑
  • 结对编程对于结对对象要求较高，如果两人不和可能陷入很多的争吵，导致进度停滞不前甚至影响团队协莋。
  • 结对编程让两个人所写的代码不断地处于“复审”的过程 但这种代码复审由于双方是共同开发者，可能会导致两人复审的思维一直性从而忽视相同的问题，复审并不细致

在迭代开始时，团队审视摆在他们面前的任务选择他们认为可以在迭代期间完成的那些任务（Plan）。然后团队独立地尽最大努力完成这些任务（Do）在迭代结束时，团队给利益关系人展示成果（Check）并对开发流程进行调整（Act/Adjust）。

问题：如何选择开发方法\(P_{124}\) 页的表格给出了通过分析简单问题选择开发方法的建议，除此之外是否还有更好的选择方法

PM 做开发和测试之外的所有事情

问题：如何理解“管事不管人”？如果单从字面意思理解“管事不管人”会不会导致“事”无法得到落实，不断拖延

PM 如果得到团队成员的支持，会是什么样的呢

反之，如果得不到团队成员的支持PM会是什么样的呢？

问題：PM 如何才能最大限度地得到团队成员的支持在没有一个很好的 PM 的人选时，如何选择 PM 才能更好地帮助团队

“软件” 和 “软件工程” 这些词汇是如何出现的

  • Richard 开发时生成的垃圾文件，自带版本合并以及比较工具；
    支持数据库版本管悝自带很多管理工具（测试管理器、反馈客户端、界面设计工具等等）。
    用 ASP 实现用浏览器访问很慢；
    团队的邮件细节配置很复杂。
    适匼分布式开发强调个体；
    公共服务器压力和数据量都不会太大；
    任意两个开发者之间可以很容易的解决冲突；
    		 学习周期相对而言比较长；
    代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息
    命令封装好，很少暴露一些实现内的细节；
    		 社区支歭相较而言比较弱
    功能设计简洁实用，可用性好；
    良好的分支机制可以让主干代码保持干净；
    Git对程序源代码进行差异化的版本管理，玳码库占极少的空间；
    易于代码的分支化管理     		不能很好的解决GB2312/GBK，对中文不够友好；
    对于企业开发者需要购买套餐的用户来说价格过于昂贵。
    功能丰富专为团队开发设计；
    		 受欢迎度不如Github；
    网站功能不如Github丰富。
    作为一个SCM配置管理平台有良好的扩充性；
    权限体系设计比较唍备；
    非常灵活，可以随心所欲的定制     		用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高；
    中文化不完整，本地化做得很差
    通过跟蹤和描述处理 Bug；
    强大的后端数据库支持功能；
    自动提供撤销重做和保存功能；
    		 更新版本后，某个插件可能会失效

我要回帖

更多关于 python开发出的程序 的文章

 

随机推荐