闲话软件工程
最近一直在进行架构方面的学习，软件工程师是比较重要的部分，正好又赶上了公司一些琐事，颇有感触，萌生了一个粗略的想法，以个人这几年的从事一线开发的经验，整理下对软件开发过程的理解，一些开发中应当注意的问题和遵循的规则，话不多说，直入正题。
1、需求与原型
一个软件项目的开发，需求是必须的，在当前的敏捷开发大行其道的形式下，在需求的基础制作出原型，应该多数团队采用的方式，毕竟原型比起繁琐的文档更加直观，更容易反应需求中不足之处。比起最初的瀑布模型、增量模型、螺旋模型等方式更加适应当前软件开发的快速迭代的模式和市场需求，但是快速开发并不代表没有需求文档，没有原型文档，我就曾经有被叫去开了十几分钟会，什么文档都没有情况下，被问这个项目多长时间能做完，醉了，个人认为，一个项目开发时间的长度，是要需求功能详细到一定程度的情况下，来评估，当然，可以提前定时间节点，但要也有详细的需求，然后在需求上分出主要功能、重要的功能、次要的功能，排期，做取舍，依次来卡时间点下完成的功能。
一个匆忙开始软件项目（更应该称之为 demo），最终走向成功的可能性也是微乎其微的，不尊重软件开发的流程和规则的，最终出来的软件也不能称之为产品。
2、代码库
代码库是软件开发中必须的工具，可以很好管理代码的版本，防止丢失，提高多人协作的工作效率，优势不多说，基本是项目必须使用的。
现在使用最多的应该是 git 了吧，当然 svn 也是很多的，github 有些庞大的开发用户，我所知道的有些企业就是拿 github 来做自己的代码仓库的，其实，创业软件公司，使用 github 时不错选择，比起自建的 gitlab，代码审查做的比较好，所有良好的软件开发习惯，git（svn）必不可少。
记得最初公司有个别组的同事，还是使用 U盘互相拷贝代码，低效易错，甚至丢失代码，问题多种多样啊，当然，他们不使用代码也有貌似很合情合理的理由，那就是这东西太麻烦了，怎么又冲突了，怎么搞啊？这东西在最初使用总是会碰到问题的，代码合并时的冲突在所难免，但不会丢失你的代码，所有不要因为麻烦而不使用他，这些问题网上一搜，解决方案很多，工具很多，没有理由拒绝一个提升工作效率和安全保障的东西啊。
3、编码及规范，学会使用工具和 IDE
程序员编码规范和代码的整洁度是水平的重要体现，这些年开发下来，基本的水平比较高的，一般的代码规范都做的很好，风格统一，结构清晰，所以对一个技术研发为主的公司来说，强调编码规范也就无比的重要了。
为什么提到了学会使用工具和 IDE 呢，因为工作中发现有很多的程序员（当然也包括初期的自己），除了 IDE 的提供基本的功能外，根本不去研究 IDE 里面的其他选项，甚至插件，比如代码模板、代码格式化等其他可以切实提供开发效率的功能，比如代码模板，可以按照规则在创建代码文件是预生成常用的代码结构，提供编码的效率。代码格式话自然比不说，有时写着写难免出现错乱，一个快捷键即可搞定。举得这两个例子都比较简单了，其实还有很多使用的地方，在闲暇时不妨好好研究下，这毕竟是你吃饭的工具啊。
4、单元测试
曾经跟公司一位测试的同事聊到了单元测试，他说，公司里也就你们组提交的代码有单元测试，其他组的没有看到过，我当时还是挺惊讶的，不过也不能解释一些问题了。单元测试是软件工程必不可少的部分，是程序员在编码的过程必须要做的，曾经一位大牛哥们，代码写的相当的整洁漂亮，单元测试代码案例完备，他提交的代码和项目，运行起来基本没出现过 BUG（不制造 BUG 的程序员是不存在），测试省时省力，服务器上线没有出现过问题。所以，编码的过程必须要编写单元测试的，有些程序员觉得自己很牛，你问他程序测过了吗，他说测过了，你去看他的代码，基本上看不到一行单元测试的代码，然后提交后总要和测试软件交流几轮甚至几十轮后才能通过，这也变项的延误了项目上线时间。
能编写良好的单员测试，是程序员上升一个台阶的标准，减少 BUG，提供程序的稳定性。
5、技术积累与流程化自动化
一个公司从最初技术的选型，积累，到重构再积累，是要经过很长的一段时间了，花费很多的心血，并不是随便的说转变就可以转变的，从人员组成，到技术培训学习，到编码规范的制定，再到自动化环境的搭建，谈何容易。一个云平台的研发建立，需要的知识和人员也要复杂多，所有，一但定好的技术选型，只要不重新洗牌，就不要轻易的改变。
我发给运维同事的对话
从公司成立到现在，一套流程的建立不易，最初小作坊式的开发方式，服务器的部署还是 scp，查看 log 远程登录到服务器，甚至出现问题直接服务器上修改更新，问题多、Bug 多、风险大、效率低，在多次失败，初步成长，建立了一套比较完整自动化流程体系，也是基于公司的研发流程，从 git 项目建立开始，到分支的确定，代码审查与合并，再到测试环境的部署，完成测试后，上线发布，自动化更新，这些流程与工具，简化了运维工作，避免错误，为什么要去打破呢？小作坊式的工作已经被证实是存在不可避免的问题的。
下面也简单的说下采用自动化方式，git 代码库是必不可少的，我们的代码会有2个基本的分支，master 和 develop，master 为线上运行的代码或即将上线的代码（线上代码也会打个标记，用于线上的 bugfix），develop 为测试环境部署的代码，每个开发人员开发会有自己的分支，但完成开发需要进行提测是，会合并到 develop 分支，通过 jekins 来自动部署到测试环境，以供测试，测试通过后，合并到 master，通过 jekins 自动化构建，并推送线上的部署系统，最终的部署，通过正式的系统一键完成，流程操作快捷简单，还不容易出错儿导致问题。
因为项目采用了微服务的架构模式，各服务运行中会有相互的依赖，所以在搭建自己的开发环境时，我自己尝试使用 TeamCity，这比起 jekins 来说要简单好多，而且可以实时跟踪变更，自动部署，再多人多服务开发的情况下，效率可以得到很大的提升。
啰嗦了那么多，也是自己作为程序员在开发路上的一点经验吧，写的比较仓促，也欢迎阅读共同讨论，望不吝赐教。
作者：lerryLife
关键字：产品经理
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
