Talk is cheap, show the code.png

还记得老大当初跟我聊他关于这个项目的想法时，我听了之后觉得很简单。我还说：“这个很简单，可能找几个实习生两三个月就能够做出来”。但结果是，我们团队六七个人，从4月忙活到现在，才算勉勉强强做出来一个可用的系统，真的只能够说勉勉强强可以使用。有时候，有一个好的想法很简单，但是如何真正将好的想法转换成完善的计划，良好的执行和最终良好的结果，却是一个相对来说比较复杂的过程，而且充满着一定的不确定性。知易行难。

从今年4月入职到现在，可以说以一个程序员的身份工作了将近一年时间了。以前的工作虽然也写代码，但是相对于程序来说，还是差别很大的。首先，在性能上，研究员的代码只要没错能够产出正确的结果，基本就行了，但是如果要将代码嵌入到系统中，就需要考虑到代码的性能和效率；而且研究员的代码，基本自己用就可以了，没那么多规范，不需要接口说明，不需要文档，自己看得懂就行，而作为程序员的代码，必须考虑到团队的协作性，因此写规范的代码注释，写相关文档也是一件重要的事情。研究员写的代码，能够解决问题就行，程序员的代码，很多时候需要从整个系统的架构和性能考虑，需要从其他同事对接的角度去考虑。

但是，说是一个程序员也不完全是一个程序员，因为除了单纯写码的活，还需要参加其他开发流程。

产品开发流程

一个产品常见的流水线式开发流程。

产品开发流程.png

当然产品并不是完全按照这个流程走的，比如如果在测试阶段产生了问题，那么将会重新流转到原型，UI，后端或者前端等产生问题的部分。

需求

image.png

在需求端，我做得工作比较少。因为很多需求其实很多时候是由老板提出来，我们做得不过是将老板的具体想法和需求落实到场景，以及在该场景下比较合理的交互原型和不同板块之间的逻辑结构。

老板提出来的需求基本是基于竞品而提出来的，基本的口号是“人无我有，人有我优”。站在老板的角度和去外面拉投资的角度，老板这样做其实是合理的。但是这样也存在一个很严重的问题，有时候是为了功能而去做功能，导致我们目前的产品目前太过于臃肿，有时候自己也不清楚，某个功能是否是客户真正需要的。过于臃肿的系统，其实也是影响用户体验的。可能下一步的工作计划应该重点在需求端，从客户需求的角度出发去整理或者说优化系统的功能。

其实，对于用户需求的把握很分析是很重要的，从开发流程就能够看出来，后续很多工作都是基于用户的需求来开发和开展的，如果对于用户需求把握方向出现了错误，后续整个工作可能说是空中楼阁。而且，对于用户需求的把握，也决定了产品最终的客户群体，产品的盈利模式，以及最终团队和公司的生存问题。

原型

原型.png

原型主要是考虑整个系统的功能框架的逻辑组织，还有就是如何运用具体的交互去解决用户实际的需求。原型是在需求上更加具体的一层，类似于整个大厦的设计稿。在原型设计上，遇到的最大的最大问题是，主要用户群体不确定，或者主要的用户需求不确定。因为很多时候，某些设计或者交互没有绝对的正确或者错误，只是说站在某个角度是否合理的过程。为了能够考虑到不同用户的需求和可能出现的场景，需要将原型设计到尽可能兼顾更多用户的需求，但是这样也有一个缺陷就是，太复杂的交互或者逻辑，务必会影响到用户的体验。比如某种交互考虑到了B用户的使用场景，但是会使得A用户的使用场景复杂化。这个中间的平衡其实是比较难把握的。

UI

逻辑能够把你从A带到B，但是想象力可以把你带去任何地方.png

UI部分的工作，我基本不参与，主要由专门的UI同事负责。不过在于UI的交流的沟通得过程中，我对于设计，或者更加深一层的艺术，产生了浓厚的兴趣。代码或者说编程，是逻辑性非常强的工作，你工作久了，这种思维已经深入到你的日常生活中，或者说已经深入你的骨髓，成为你生活中形影不离的一部分。比如，你一开始做计划的时候，就会考虑，if xxxxx, then xxxxx, else xxxxx。然后考虑，计划可能会存在哪些极端或者异常情况，然后对于这些异常情况如何做出处理，认真考虑某些细节，希望各种情况都在已经考虑的范围之内。并不是这种思维方式有错，只不过这种逻辑性的思维到束缚你的想象力，为什么不可以去尝试一下其他方法呢。设计或者其他方式，却是一种无拘无束的表达和跳跃式的表达，只要你的想象力足够丰富，你总可以将你的情感，你的想法，你内心真实的感受，通过某种，具体或者抽象的方式，表达出来。

后端

program.png

我主要的工作集中在这个部分。主要的工作内容有三个部分，相关数据的爬取，采集，清洗和整理，底层数据库设计和某些业务场景的实现。后端的工作，20%时间是在处理正常的情况，80% 的时间是在处理异常。因为，之前本身写代码经验不够，而且某些特殊情况没有经历过，尤其是爬虫，各种奇葩的异常需要处理，需要花费大量的时间，其实很多时候，技术并不是最难的，最难得是一些细节的处理。
后端开发，和原型设计也有矛盾和冲突的地方。作为原型设计，站在用户体验的角度去思考，可能专注的是最主要的用户群体。然而在后端设计时候，需要考虑到整体的性能，今后程序的可扩展性，可修改性，有些部分和结构需要尽可能解耦合，还需要尽可能考虑到某些用户输入或者请求的极端情况。有时候，在设计原型的时候，会不由自主的切换成后端开发的角色，开始考虑这部分需求或者功能在后台如何实现，然后发现这个一下子完不成，或者感觉难度很大，那我可能说，这个功能太难了，算了还是换一个吧，或者说，换一种简单的功能吧。其实，有时候自己的内心是很矛盾的，这样其实对于做产品是不利的。

前端

前端.png

前端我涉及的很少，主要是UI和专门的前端同事沟通。我和前端沟通得多的是接口参数的传递问题，从业务上某些交互的逻辑和合理性问题。如果，我想成为一名真正的全栈式开发工程师的话，前端是我一个不能够绕过去的坎，但是前端也是个坑，各种细节，大量繁琐而细节的工作，让我有点望而生畏。

前后端的区别.png

测试

Debug.png

其实测试并不难，也不是很烦。最烦的是测试产生的一堆Bug需要你去修改。
因为之前做研究员写代码，不会注意去考虑很多异常情况，一般都是等到错误产生了才去修改。但是作为程序员，可能需要考虑更多的代码可能存在的错误情况，并且做相关的异常处理。有时候是一些业务上的或者逻辑上的一些极端情况没有考虑情况，导致会有一些异常。
其实，Debug也不是最难受的，最难受的是你一边做着新的需求，还一边被催着去Debug，相当于你要不停地中断去做某些事情，这样效率非常低下，而且人也会感觉到很疲倦。

上线

系统登录界面.png

虽然目前系统系统功能还有待完善，系统性能还有待提升，但是当系统真正上线的时候，还是非常有成就感的，就像是几个月的劳动和付出吐出了芳华，精疲力尽翻过乱石坡之后见到的云海。

小结

在这将近一年的程序员工作中，有时候很辛苦，还记得一个月连续加班，还记得旅游上飞机之前都是解决了几个Bug才上的，还记得一边背着电脑一边背着旅游，每天晚上到了第一件事就是打开笔记本，开始解决Bug，更新数据库。还记得系统要求上线前一个月，非常忙，而且压力很大，真的很大，压力达到有时候胸闷，甚至感觉自己可能都得了心肌炎了。以前，看到一些调侃程序员的段子，只是觉得很搞笑，现在看到同样的段子，虽然也会笑，但是明显是带有一种深有体会的苦涩。“码海无涯，回头是岸”

不过，整个流程走下来，我还是接触到很多东西，当然在这个做得过程中也学到了很多东西，还记得刚刚加入团队的时候，不知道原型，不知道Axure，不知道SVN，不了解前端......

但是，虽然很多环节都有参与，看似非常全能，什么都能够做，但是也存在一个非常严重的问题，无法专注。时间和精力比较分散，无法集中在某个方面将事情做好。正如我前面所说的，在原型设计的时候，就开始考虑后端的实现，如果后端实现比较麻烦，就会考虑去修改原型或者交互。

展望，2018

华哥曾说，徒步最大的困难出是出发。现在竟然都已经出发了，就不要想着下撤了，那就逢山过山，逢水过水，风雨无阻，一路向前吧。

Keep Going.png

后记

这篇blog是29号晚上，开始写的。但是到现在才完成。这段时间工作以来，可能另外一个最大的感受是，有些事情，真正当你自己去做的时候，才会有真正的感受。

Talk is cheap get your hands dirty.png