入职稀里糊涂已经一个多月了，是该写点东西回顾下了。
过年从家里回帝都之后就一直催HR坚叔争取让我早点入职，搞得我们组老大詹总一听说有实习生想入职就知道是我……于是在3月6号终于可以正式成为有道的实习生，没想到入职那天闹钟不太好使or我把闹钟稀里糊涂关掉继续睡导致下午一两点钟才去公司……
有道一直以来算比较熟悉（原因不少，但似乎归结到根源都是因为黄大仙），入职一个多月额外给我的感觉就是有道算是一个大公司里的小公司。大公司意味着业务大用户多（尤其是我们组做的词典），技术水平比较高、牛人多，能学到靠谱的东西；小公司是说人不多，相对来说没有大公司的各种蛋疼问题（尤其是相对于微软百度啊啥的），人员也没什么冗余，经常一个人同时搞不少东西，更适合刚毕业的人来提高姿势水平。同时，又因为有道是上市公司的子公司，所以财务压力着实不低，没法像那些没上市的小公司那样有的是钱可以烧。这年头码农价位又炒得这么高，于是招人更少。
入职以来主要也就相当于做了两件事，一个是词典网络释义结果的优化，一个是某后台数据编辑系统的开发。前者主要是类似hadoop的东西，之前略懂mapreduce还参加个很水的hadoop比赛没想到还真用上了，起码免去入门时间（虽然入门也挺容易的……），先试了某个方案发现并不能提高质量，然后又修了一个bug，把新版数据跑出来因为测试的服务器各种坑爹原因导致服务不稳定没法准确测新数据的质量以至于拖了好几个礼拜才最终上线，然后上线的服务器好像又有点问题导致昨晚只上线了一部分今晚才能全部上线……第二个活是纯码农的java web开发，具体技术细节不知道是否可以随便说，反正我写的只是个内部编辑系统不需要考虑高并发或者安全性之类的问题所以毫无压力的当成一个类似大作业的东西写，大概一个礼拜也就写完了，然后不断的改bug或者改进细节或者遇到突然改需求之类的然后就来回的改……之前有个类似功能的系统，但感觉代码写的实在太乱看着蛋疼于是本来可以从那个改我干脆从头自己写了，只是沿用了之前那个系统的package结构、项目目录结构，连spring的版本我都给改了然后用@开头的那个注解写显得更整洁也更直观方便。反正就是个标准的码农活。
不得不说对于大一些的web项目的开发，java+eclipse还是挺方便，性能也算几乎是用于web开发的语言里最高的（或者说java作为一个虚拟机语言性能已经被优化的非常牛逼了），但本身设计的一些缺陷也导致很多地方很不方便。属于写着不太爽只能靠因为用的人多所以有各种成熟的库、框架、工具还有性能优化来弥补这种不爽。虽然java各种库很多很成熟，但似乎好像java也没有什么好的模板框架，起码我们现在用的跟Django自带的那个模板系统比似乎就弱一些，用起来也没Django顺手——如果我不是没用明白的话。最起码我特别需要模板继承，然后现在用的好像没有。
另外，之前那个编辑系统用了frame，我是个非常厌恶frame的人……frame实在太蛋疼了，尤其是直接那么用地址栏永远不变，也不方便前进后退。感觉很多人都喜欢用frame，包括hustoj那个开源系统的admin后台也是frame……这次写直接用table排版，不过据说业界最靠谱做法似乎是div+css神马的好像载入速度比table快还是什么原因的，然后各种类型分类过滤显示之类的完全是裸的js DOM api而不是惯用的传个参数只返回某类型的list啥的，以前那点js基础还真用上不少，由搞了个不刷新页面在线传个图片啥的……反正怎么看怎么像大作业……
总体来说日子过的虽然清贫（每个月月末发上个月的工资&&offer后的实习生工资比以前少了不少T T），但还算充实，不能说学到了什么牛逼的东西，但起码终于能跟有经验的人真刀真枪做东西而不是自己一个人写个“只是能用”的东西出来，我觉得这是在公司学东西和自己学东西最重要的区别。当然很多人总强调可以看开源项目什么的来自学，这固然有用甚至必须这样做，但很多优秀的代码真的不开源或者有些东西没有什么开源项目……前者举例就是google的很多东西只贡献论文不贡献代码，后者举例就是不来有道当然不知道一个词典的查询流程、系统架构是怎么设计和实现的。而且开源项目除非是特定企业完全自己贡献出来的，那种社区开发的很多时候过分强调了普适性和扩展性之类的不见得就比企业内部搞的好用。最重要的是，亲自写代码和阅读代码，实在是两个不同的概念，而一般人也没法真正参与那些开源项目的开发。
据说是入职并且转正之后可以申请配个笔记本，但我现在已经开始纠结要不要自带macbook上班，唯一的问题是我的是pro而且是15寸的挤地铁实在不爽还很沉，但大屏写代码也比11/13寸的爽多了。带本的好处不少，比如离开工位也有电脑可以随时做一些事情，然后我的台式机是linux（不过贵公司大多数人似乎都还是windows写代码）一些东西比如泡泡用着很不爽而泡泡居然有MAC版……但是否好到值得我每天来回背着是个纠结的问题……
另外最近那个后台系统基本写完了，开始进入“补testcase”的状态。之前从没写过单元测试，但看了下这东西，实在是怀疑这玩意存在的必要性……从我这几天接触单元测试的入门级角度讲，大概有这些理由：
一，对于很多项目（比如一个网站的web项目或者一个本地程序的项目）来说，单独测一个函数能不能用真不如直接在测试服务器或者编译成程序实地测试——何况服务器上的测试或者实际使用的测试本来就是必须的。或者说，不足够大的项目单元测试感觉没意义，要是个非常庞大的软件或者操作系统啥的，当然也没法只靠“使用”去完美的测试了。
二，testcase的数量有时候有覆盖率的要求但质量如何其实根本没法控制，能不能测出什么bug来真是未知（测出直接使用的时候发现不了或很难发现的bug就更难了，这道理就跟出ACM题的同时也出靠谱数据一样）。
三，起码从我个人的心理状态的角度，使用的时候更容易去发现问题或者找一些极端例子，单纯给一个实现了某个逻辑的模块（函数）找极端例子反而更难。另外也很难搞清楚一个模块的输入是否真的会有极端的例子因为本身这个输入很可能就不是之前模块运行完能得到的结果。
四，testcase本身也是一个需要写代码的过程，测试一个功能能不能用和写代码实现对一个功能的访问哪个快也是显而易见的……举例说明就是在输入框搜索一个词看有没有结果和写一个代码构造一个HTTPrequest含有query参数并访问对应url哪个容易的问题——而且参考第一条，因为一定会有实际测试所以写单元测试测这个意义真不大。而且后续测试一定会批量测试这样的查询看结果对不对还有准确率失败率什么的，甚至当年在微软看到STC的测试都是完全自动化的，直接让与dev人员甚至dev团队独立的SDET去写程序模拟鼠标和键盘的事件去测试网站是否可用，牛逼多了也有意义多了。
五，有一些额外的问题，比如某些系统功能只能在集群机器上用不能在自己本地电脑上用于是本地写testcase也只是一些模拟，我觉得两者就不是一回事了，实在没意思……
六，似乎单元测试的一个好处是能实现批量测试的自动化，一个ant test命令就把所有单元测试挨个跑一次，但第四条末尾已经说了，微软那种才叫真正的自动化测试，所以这个意义实在不大……
总之，我觉得testcase真没啥用……
不知不觉写多了，本来还想顺便介绍下贵司买的&&我们几个人组装的3D打印机，明天再说好了。
发表回复