堆糖实习总结

       时间过得真快,2015.06.03入职,到本周结束,也就是2016.04.01,我在堆糖的实习期也就结束了。十个月的实习期学到很多,趁这个机会好好梳理一下。
堆糖LOGO


关于技术

       实习的岗位是Java后台开发,那重点当然是先聊下技术上的成长。

相关技术栈

  • 操作系统
    • Linux
  • 编程语言
    • Java
    • Python
  • 开源框架&技术
    • springmvc/django
    • mybatis/ibatis
    • mysql/mongo/memcache/redis/solr
    • mvn/Jetty/nginx/docker
  • 辅助开发工具
    • IDEA/Vim
    • Git/GitLab/Bitbucket
    • curl/Postman
    • mitproxy/Charles
    • item/tmux
    • Tower/Confluence/JIRA
    • ShadowSocks
    • Google Code Style

日常工作内容

  • 参与分析日常迭代需求,进行详细设计,编码实现并通过单元测试,集成测试然后发布上线。持续按期交付。
  • 线上系统的bugfix。
  • 老旧系统的下线迁移和重构工作,从Python平台迁移到Java平台。
  • 定期与同事交叉进行CodeReview。

参与项目

  • Saturn

    该项目是传统MVC架构中的Service层,直接与DB交互,通过RPC协议对外层Web App提供服务,为堆糖主站提供了坚实稳定的地基。

    我在此项目中参与最早期的详细设计和开发工作,提供了最基础的用户信息CURD服务模块。使用memcache和redis提供缓存策略,使用批量查询替换所有循环逐个查询操作,降低时耗,提升系统系能。自己在这个项目中培养了良好的编码风格和阅读官方文档,英文文档等习惯。

    觉得自己做的不错的地方在于:大多数情况下会有较高的执行力。

    发现自己不足的地方在于:碰到难度相对较高的问题容易钻牛角尖钻进去,而导致项目延时交付。认真反思后采取的改进措施是在工作场景中,应对任务的优先级和交付时间有更好的把控。而在平时的学习中,继续保持钻牛角尖的态度,不轻易放过问题。

  • Japa下线

    Japa是堆糖早期的主力Web App.承担了堆糖绝大多数的HTTP请求。由Python语言编写,采用Jython框架。因代码质量较差,以及公司技术栈向Java转型的原因,需要下线。由另一个代码质量更优秀,技术社区更庞大的系统Vienna来顶替。Vienna由Java语言编写,采用SpringMVC框架。

    我是此项目的众多参与者之一,工作形式主要是阅读原有的python代码,理解业务逻辑,用java语言对业务逻辑进行重构。要求可用性比迁移之前要提高,而且API压力测试平均响应时间要在500ms以下。项目中最大的收获就是养成了重构有“坏味道”的代码的习惯,归功于Martin Flower所著的《重构–改善既有代码的设计》一书。

    觉得自己做的不错的地方在于:在项目中积极主动的沟通,习惯写出技术方案向更有经验的前辈请求指点。

    有待进一步提升的:技术方案的深度需要花更多时间和精力去探索。

感想

授人以鱼不如授人以渔。

       上面提到的一些技能点,我认为大多可以算做’鱼’。现在我更看重的以及有意识的去培养的能力是:分析问题的关键需求–>获取足够的备选方案–>比较方案的优劣并选择匹配度最高的方案–>高效的执行。我认为这是可以钓到很多大鱼的‘渔’。当然这套‘渔’上可以下功夫的地方也有很多,比如如何获取足够的备选方案,如何高效的执行。都是说着容易做起来难的事。

技术之外

       对自己未来的期许,不仅仅止步于一名架构师,更希望自己能主导一个有创意,能给人眼前一亮,并为人们生活带来实质性改善的产品。所以我平时也会关注一些技术之外的东西。

产品需求文档

       创业初期,经常出现的场景是老板想到什么就让程序员做什么。做到一半觉得不好于是改成另一种方式,再做再改,甚至有时候还会改回到最初的版本。程序员被折磨的苦不堪言。

       不过毕竟是初期,这样的事还是可以容忍的。但是当业务逐渐趋于稳定的时候,规范的开发流程还是很有必要的。一篇好的产品需求文档显得尤为重要。

       我觉得一篇好的产品需求文档应具备但不限于以下几点:

  1. 便于阅读的排版格式和通顺的语句表述
  2. 辅助理解的原型图
  3. 尽可能写明需求的产生原因

       第1点跟第2点的目的其实是相同的,因为开发是根据这篇文档来进行产出,测试根据这篇文档来进行验收,所以降低开发和测试人员对于需求的理解的心智负担是直接提升团队效率的措施。而且叙述有条不紊,逻辑清晰易懂的文档是产品经理经过认真思考的产物,若形式太过简陋,其实是可以辨别一个产品经理的专业水平的。

       提出第3点是出于希望让开发和测试更有参与感的考虑。我觉得开发人员沦为一个写代码的工具是对团队极其不利的事情。有需求过来了,不去想来龙去脉,只管coding的工作方式与我对自己的期许是相违背的。如果产品经理能在文档中适当的描述一下需求产生的原因或是支持这个需求的调研数据等等,我觉得开发人员会对需求有更多的认同感和更深层次的理解,在实现上也会有更多的考虑。

持续反馈

       平时的项目中,通常的流程是产品提出需求,技术进行详细分析并设计方案,开发,提测,bugfix,测试通过然后上线。之后除了发现线上有bug,开发这边几乎得不到什么反馈信息。商业线那边可能还好一点,可以观察每天的销量等信息。社区线这边我觉得问题比较突出。比如堆糖6.0对首页进行了大改版,以前的Blog瀑布流换成了卡片形式的长图文,话题,Album等,风格的改变很大。上线一段时间后也没有任何关于流量变化和用户反应的反馈信息通知到大家,可能是产品自己消化掉了,或者是管理层没有将这些信息继续向下传递。但是我认为这些数据一个开发应该能够看到,能够有参与感和自己的反思。再比如每年年初的年度计划或者半年计划,某项指标业务方希望能在半年时间内达到500%的增长量。技术作为参与者却不能比较轻松的得到一个可以定期持续观察的数据反馈,可能只有等到半年时间到了之后,才可以看到这个数据。这不是一个“持续集成”(Continuous Integration)的过程,开发过程中如果没有CI,代码质量和系统的可用性很难保证。任务管理的过程中没有类似CI的环节,我觉得也会对任务的成功完成有很大影响。

感想

       互联网从业人员中,如果技术人员能抽出一部分时间去关注产品逻辑,关注市场竞争,那他们相比于设计,测试,产品等在团队中的视野应该是最开阔的,话语权和决策权也应该最重。这样才能更好的做到“技术驱动”。而如何关注产品逻辑市场竞争等,除了需要程序员的自我驱动,团队是不是也应该提供一些便利。


总结

       技术之路还很长,还有很多需要潜心研究。同时技术也只是我从业的出发点,是手段而不是目的地。
       看很多书,见很多人,去很多地方,做很多事情,而后成大器。