1,118 次浏览

2014 年度总结

时光荏苒,如果从大三时候在北京开始实习算起,这已经是我作为一个程序员的第四个年头了。重读加入现在公司以来的年终总结,感受自己的变化还是挺大的。在这里晒晒自己的心路历程,欢迎吐槽。

这是入职第二个年头的总结(2014)。

 

2014 年度总结

201515

站在2014的年尾,回望这一年所经历过的一切,可以说,还是对得起毕业后的第一年的。这一年是我真正进入工作状态的第一年,这一年我学到了很多,无论是开发技术上、业务逻辑上,还是对工作、对自己的理解和认识上。在此,我对2014年所经历过的一些事情和感触做下总结,为的是重拾那些已经遗忘了的经历与过错,并更多的期待2015这个新的开始,这份总结写给别人,更是写给自己。

1 回望2013年的那些期许

 重读2013年的年终总结,曾经期许2014年能够完成以下的这些目标:

  • 继续学习.NET基础技术,针对NET的结构和思想进行一些深入的了解

由于这一年所有的工作都是在MVC项目下进行开发,所以也算是学习了一点东西,同时也在近期开始尝试编写一个叫“AA”的MVC辅助结构,但是目前仅限于半个原型,还有很多很多ASP.NET MVC的知识需要学习、整理,也有更多的需要重新为实际应用而优化的基础结构,希冀今后能够完成一个稍稍完整的原型版本。

  • 进一步完善国际化小工具,实现词条批量上传等功能,使其实用化

针对国际化小工具,今年进行了几次的重写和翻新,并添加了一些小功能,年初的时候还尝试过说服大家把国际化的任务移交给Design来完成,甚至还弄了个I18n Tools for Designer,从而把设计图的制作和国际化的过程统一。可是,站在今天回顾,当时的想法还是很有局限性的,Design在不同的项目中扮演的角色也不同,而且Design部门平时的工作量很大 ,也许针对AA的项目有些可行性,但是针对其它项目,页面的具体设计随着开发的过程随时都有可能发生变动,而且针对不同的项目将相同的任务分配到不同的部门,这本身也是一种效率损耗,所以这一想法也就不切合实际了。由于最近JJJ REST API的一些变化,2015年初,将会与新人ZZ一同重新整理JJJ词条上传部分的代码实现,并整合已有的GG词条工具,争取年初给大家带来一个新的实用版本。

  • 继续学习JavaScript,了解和熟悉公司的前端控件类库(PP等)

上半年,针对JavaScript的学习时间还是较长的,同时也学习了一些Bootstrap的内容,虽然没有完整的学完,但是JavaScript还是今后一段时间内的主要学习目标。

  • 学习Microsoft Dynamics CRM的相关概念和开发技术

这怎么成了一个年度目标了呢?还记得 [CC-99] 那个Task,需要AA在用户注册的时候向咱们公司的CRM里插入一条记录,当时还不了解CRM里的那些概念,Lead、Contract什么的,于是在当时这个略显恐怖的概念理解任务就成了个年度目标。

  • 了解Windows Azure的相关技术并掌握DD产品的详细使用

当然,如今的Azure已经改名叫Microsoft Azure了,今年上半年由于需要协助AA项目进行部署,所以学习了下Azure的使用,之后又利用些时间学习了下私有云的部署。针对Azure,更多需要注意的是在Azure下运行的项目需要考虑很多与On-premise部署不同的场景问题,也必须考虑Load Balance情况下重要逻辑节点的处置机制,比如Session、各类Buffer、各种静态对象的同步等。

针对DD,由于GG项目的需要,现在对于CC的使用已经比较熟练了,不过对于DD的实质功能,我一次还都没有用过,完全不了解。

  • 学习和初步了解MM代码

还没有等到开始这项工作,我就去学习GG的代码了,目前甚至对于MM的作用的了解也是完全基于想象的。

  • Hadoop技术做相关的了解

目前还没有机会去进行实际的实践工作。

曾经的大概念,如今有的也变成了面前的小概念。2014年的那些目标还是实现了一些的,这可以归结为设定这些目标的时候,我才来公司不久,没有太多的认知,不知道未来可能会面对的是什么,所以所有的目标很小,也很容易。也有些目标没有被完成,这可以归结为自身时而发作的惰性或者归结为外界不可抗拒之因素。总之,希望新的一年会把那些新的期冀完成并做好。

2 回顾2014 —— AA Team

2014年的前一半,主要在AA Team从事一些基本功能的开发工作,这主要集中在前端和一些辅助技术上。AA项目是13年9月启动开发的,因此AA属于一个全新的项目,这半年也正是AA茁壮成长、同时也使我有机会接触并大量学习全新内容的阶段。除了项目内容,这期间还参加了C和D Band的提升考试、并为部门带来了一些简单的培训。下面我按照时间顺序,针对每个月份完成的主要主题工作进行下回顾和总结。

  • 1月:Dynamics CRM 相关功能开发,参加C Band考核,部门培训 WinForm 与线程池简述

针对 [CC-99] 这个Task,算是我来到公司所接触的第一个稍有难度的开发任务了。首先Dynamics CRM是微软开发的客户资源管理系统,它类似于SharePoint,有一套独立的API接口和概念定义,所以为了实现相关功能,需要先学习具体的概念。于是,一个本地版本的Dynamics CRM被安装到了电脑上,然后接踵而至的是各式各样的配置问题、权限问题,花费了几天的时间,一切就绪,然后突然明白了公司使用的是Office 365 Online版本的CRM。于是,由于信息获取的不充分,很多时间被浪费掉。

当部署问题解决后,却又发现实际代码的开发是如此的不顺,其它项目已有的Dynamics调用代码不知所云,充满地区、时区、货币类型定义的“幻数”,为了完成功能,只能靠猜想。比如,打开CRM 的HTML代码,查看货币下拉菜单input域的value值来对应具体的枚举结果。经过类似一系列的折磨后,终于完成了功能,提交代码,等待测试和之后的部署。

可是,到了部署的时候,突然发现功能不可用。在请教了长春CRM相关开发的同事之后,了解到代码中有一处涉及到本地文件的读写,而项目在Azure平台上没有相关的权限,这与本地平台有很大区别,也直接导致了功能不可用,又因为前期的测试都是基于本地搭建的环境,而非Azure环境,因此,问题也没有被及早的发现。

通过这件事,我深刻了解到沟通和提前准备的重要性,这也是我最缺乏的。针对Dynamics CRM的相关开发,早已有技术熟练的长春开发前辈,如果提早请教他们,实现的过程也不会过分的曲折。而另一点就是提早进行完整测试的重要性,有时,实际部署环境和开发环境存在着巨大差异 ,应该早做完整的测试,提早的暴露问题。

针对C Band考核,我要在此感谢HH哥和WW给予的机会和信任,非常非常感谢HH哥和WW能够让我在入职初始就获得C Band的提升机会。通过这次考试,我发现了自身很多的不足,同时获得了机会去追赶和弥补。

这段时间,还第一次在MM部门内部,为大家带来了一次基础培训,主要讲解WinForm与线程池的一些概念,大家对于知识的深究、认真的态度与热情是如此的宝贵,这些真挚的态度确确实实的影响到我。我觉得,这些不仅体现了环境可以塑造、影响一个人,也让我在今天明白,当你拥有值得珍惜的东西时,不要以背向之。

  • 2月:Office 365相关功能开发

针对此问题的开发几乎全部集中在DLL和运行时依赖的探索上,由于我们要做Office 365用户的管理,而非SharePoint Online的管理,所以存在Office 365用户没启用SPO的情形,这时获取用户信息的代码就不能使用SPO的API了,这也涉及到了具体的调用方式、项目包的大小等一系列的问题。

我感觉面对功能,我们可能已经有一种解决方案,但是如果这个解决方案是禁不住推敲的、不能广泛、稳定地为人所用时,那就证明这不是理想的实现方式。我觉得,AA的一个优点就是,它允许开发者们有一个自由的空间,通过这个空间去完善代码,剪掉那些已有的、看上去还好但是实际已经烂掉的代码。这让AA能够健康生长,也正如前人所说,软件是长出来的。

  • 3月:国际化小工具

国际化小工具的起源,在去年的年终总结里已经介绍过了。这是一个为了简化Developer对于项目词条的维护和提交流程,而编写的基于WinForm的小工具。今年曾多次对这个小工具进行了重写和更新,增加了一些小的功能,这其中就包含向JJJ提交词条。

与当时处理Dynamics CRM问题类似,为了大量测试JJJ REST API,我搭建了个JJJ环境,结果部署之后才发现,JJJ本身没有国际化词条这个Issue类型,那些是我们公司自定义开发的,所以又一次浪费时间在部署环境上。通过联系长春的同事,了解到我们有一个JJJ测试环境。这告诫我,别再同一个坑里掉三、四次。

由于目前词条提交的接口有些变化,工具处于不可用的状态,我会在新的一年里,利用一些时间与新人一起对工具的相关接口进行重新维护,并尽快提供一个稳定版本。

  • 4月:学习Azure的相关知识,部门培训异常和状态管理

AA是部署在Microsoft Azure之上的云端项目,所以学习如何管理、部署Azure项目是必备的知识。

同时,这期间获得了为部门讲解异常处理机制的机会,这次培训的核心分为两部分,一个是具体机制,一个是应用场景。针对异常处理,后者属于一个重点的内容。当然,这一点是我在讲解的过程中才突然意识到的。首先,在培训的准备过程中,自己并没有非常完整的意识到异常处理机制并非千篇一律的,在不同的应用层次上,其使用的方式也有所不同。另一方面,由于没有过多的开发经验,所以使用场景的总结也相对的匮乏。除了针对这次培训不足的反省以外,作为培训的讲解人,如果没有具体的开发经验,是很难将技术在不同场景下的应用讲解给大家的,所以我也觉得,针对部门内部的培训可以更多的集中在经验的交流与分享上,讲解者可能更应该扮演组织者和讨论点提供者的角色。

  • 5月:Report 与 Map Board

我觉得,正是从这段时间开始,面对AA,我觉得她更像是自己的孩子。年初的时候,由于AA开发时间比较轻松,我产生了将用户Audit数据以坐标方式统计在地图上并进行扩展的想法。由于我的毕业设计就是一个基于地图的应用,所以这项工作并不复杂。在完成编写之后,它作为一个原型被悄悄地包含在了AA的产品之中。5月,HH哥与PM协商,在新的AA XX Dashboard上将这个原型以Map Board Report的形式成为产品的一部分。我非常开心,也非常享受完成这个工作的过程。不过,当平静下来并回想它,在这件事上,我也明白了一些道理。

首先,有了想法如果有条件,就要去努力实现,谁也不知道哪一天,理想就会进化为现实。

其次,兴趣是最大的驱动力,它能让你完全的投入工作,并且一定会做到最好,因为这一刻,你是在做自己热爱的东西。可这也是危险的,因为在现实的工作中,并不是每项任务都是自己所喜欢的,对于我,更是如此,兴趣驱动也许反而会在一些时候带来懈怠,所以有时候更该去尝试克服这类问题。

第三,必须在理想与现实之间寻找平衡。Map Board这项工作本来是可以不在当时的那次迭代中完成的,但是为了尽快看到效果,我还是尝试在那次迭代中完成这个工作。这直接导致了开发时间比较紧迫,这也是让HH哥当时有些生气的原因。开发进度是需要谨慎控制的,任意随性的添加功能,不仅减少了其它既定功能的伸缩时间,让其它功能失去了可以更加完善的机会,这也会导致其他开发者、测试者、甚至PM的工作量的突然增加。为了头脑一热而丢掉已有功能稳定性的行为,是不负责任的,也许该等一等,再去实现它会更好。不过还好的是,最坏的事情并没有在这次发生,Map Board和其他Report现在还是很稳定的。

  • 6月:AD FS与AA前端页面Redesign

当AD FS这一问题摆在面前时,对AD域相关概念的理解成为首要任务,由于相关资料对于AD FS的介绍要么太专业,要么太笼统,而具体实现方式又有多种。所以,大多数的时间都花在了理解概念和选择实现方式上,而最终的代码与配置仅有几行。

Dynamics  CRM也好,AD FS也好,一个在《代码大全》中读到过的理念被呈现:程序开发的过程就是对于新事物的认知过程。

回头看去,这些功能的实现可能只有几行,或者只是几个类,而大部分的时间是在学习第三方的规范定义、或者了解和选择API或实现机理。当这些我们从未触及过的东西摆在面前时,如何去有效的完成认知的过程就是我们需要思考的了。在没有前辈指导或缺乏参考的情况下死磕并强硬的推进是一种方式,而在有很多前辈经验的情况下,放下“不好意思”直接去请求已有的实现,则是更明智的选择。解决问题是我们的目的,问题解决了,才能有更多的时间去完善它、优化它,这些是我最大的感触。

当然,饭饱思淫欲,在这段时间,由于自己对现有AA 登录界面的设计不满,并且有些业余的时间,所以提出了一些意见和建议去质疑了下Art Design Team的设计,同时还做了个新的登录页。虽说这样做确实得罪人家,不过也还是觉得这样至少在某些方面是对得起项目了吧。当然,可以确定的是,这样的事情也许只有在这段时间、这类项目里才能发生吧。我真心的认为AA是一个开放的、正向积极的、不断拮抗促进的团队。总之,这是值得回忆的时光,也希望AA以后越来越好。

  • 7月:参加D Band考核,Mail重构

再次感谢HH哥和WW,给予我一次参加Band考核的机会, 这次考核的题目正是之前关于AD FS的一些内容,因为之前对于相关的概念有一些认识,所以就有一些时间可以去编写一份比较完善的文档,并且制作一个基于MongoDB的、支持多AD FS验证的模型(当然,也包含了那个我重新设计的登陆页)。感谢GG哥、HH哥、WW,还有BB哥和YY姐,提供这样一个宝贵的空间能让我能去做些喜欢的东西。

针对AD FS和相关的问题,我还有太多需要理解和学习的地方了,感谢LL部长让我认识到了这点,LL哥有太多GG、SharePoint上的经验和处理问题及CI的方法,真心的期待今后更多的向LL哥学习的机会。

这段时间,还针对AA的全部Mail模板进行了重构,主要是整理了下邮件的发送方法、基于Razor Engine提取了邮件的Layout并统一了邮件模板的编写方式,去掉了冗余代码。不过处理过程中,也出现了一些值得今后注意的问题,比如由于邮件缓存的错误而引发的不发送邮件的问题,或由于字符串时区格式不正确所引发的异常页面的问题,再如项目间引用及依赖关系的问题。

今天的积累在未来可能就是救命的稻草或能为自己来一次锦上添花。总之,这半年,在实际开发的场景下,我学到了很多,不过这些也有局限,比如在AA项目,我们只有3个全职开发,1个QA,1个PM,我们有如此多的空间能去创造、去在培养一个项目的同时培养自己。可是,非乌托邦的现实与之有很大的不同,7月末,我来到GG Team,这绝对是一段新的里程。

3 回顾2014 —— GG Team

14年的后一半,7月末,我加入了GG Team,在这5个月的时间里,我接触到了太多太多之前不曾接触过的东西。学习到了很多。同时,也看到了在很多思维思想、实践方式上,所存在的与先前冲突的地方。不过我觉得正是在这些冲突中,我看到了不曾见过的对比、也做了点思考。这段时间里,我也有幸作为一名讲师,为公司的新人讲解了一些内容。总之,这段时间比较累,但有助成长。

来到GG Team,直到今天,我的心里一直萦绕着一个词,自觉无知。与JJ哥和TT一样,我们都是来自MM Team,但和他们俩的区别是,除了新人培训外,我从未深入接触过SharePoint和DD。这两个软件只是在上次重做系统前从未被我使用过也不曾被卸载的两个存在而已。所以,来到这里之后,想要安装上GG都是一个挑战,因为我根本不知道要去哪里给GG注册Farm。

所以,先要感谢下已经离职的SS,谢谢他写了个文档,让我对GG能有个最最基础的认识,让我不至于连GG都安装不上。

而之所以说到今天仍然自觉无知,是因为我确实有太多需要学习的东西了。从SharePoint的API和相关领域知识到WF和WCF、甚至GG本身的一些逻辑功能,这些基本上存在着知识领域的缺失,一旦涉及到此类问题,巨大的阻碍就出现了。所以,新的一年里,努力学习和理解现有GG所使用的技术和GG本身的深层逻辑,是一个主要的目标。下面针对这段时间我在GG Team的学习经历,做一个简要的回顾。

  • 8月:来到GG Team参与5.1 迭代两个小功能的开发

功能1:DT MM

当刚刚得到这个任务时,我所估算的开发时间是一周,可能是之前开发习惯的惯性,我觉得这只是在几个页面中添加个小控件,后台做个保存或比对下数据而已。而当我真正看见代码之后,我才明白自己是多么无知和肤浅。随DT MM而来的是接连1个多月的开发过程,以及随其产生的20多个Bug。回想这个任务的开发过程,我学到很多。

首先,一定要在了解了具体代码的影响范围和代码实现的预想方案后,再给予开发时间的评估。在普通的迭代开发上这一点可能并不十分明显,但是面对POC,这就异常重要了,预估的时间会直接影响到具体开发的进度,直接面向客户就不容得我们随意了。

其次,导致DT MM如此不堪的原因可以归结为以下几点,(1)由于自己刚刚加入团队,完全没有掌握具体的逻辑结构,尤其是MM的实现结构,导致在具体开发过程中,主观的认为一个模块中的实现是如此,其它模块亦是如此。这直接导致了前期MM的数据结构设计不能正常适应后边的模块(如Change MM,尤其在前端结构中)。同时,我万万没想到MM在具体的实现中拥有多套代码。这一类问题直接导致了MM成为一个巨大的泥沼,而作为一名菜鸟,我所编写的代码不仅实现过程缓慢、功能不健壮,并且我所添加的代码也让MM变得更加混乱。我真心的感觉愧疚,我也非常感激在年底我开发POC期间,帮助我修改那些我所制造出的Bug的同事,非常感谢大家的帮助。(2)面对需求,没有具体明确。由于DT MM包含两种子类型,DO与 DT,而JJJ中没有提供R页面的具体设计,我就主观的参照CS的页面设计,允许用户在R期间修改具体的DT MM的子类型,这导致我花费了很多的精力和时间去完成这个没有必要的功能。所以,我今后一定要注意,如果有任何疑问必须马上询问别人,而不是自己去做猜测和推想。(3)遇到问题缺乏记录,由于MM代码实现分散、重复,命名等没有规矩、随意杂乱,所以如果想找到具体实现的位置,是比较费劲的。而且一旦找到,如果没有记录,下次再去寻找,就要再次浪费时间。有几次,由于不知道正确查找MM代码实现的方法,导致寻找代码实现一次花费了5个小时的时间!这让我身心俱疲,并完全丧失信心。这些问题,是我今后需要注意的。同时,这一切也如烙铁般深深的印刻在我的心上,我永远记住了,代码是写给人看的,而不是写给机器看的,一定要对自己的代码负责,一定要为编写好的代码投入所有努力。

目前,MM由我进行维护,虽然做的很不到位,对逻辑也没有百分百的掌握,但在新的一年里,我一定会对MM的优化重构工作付出努力,无论如何也会使其得到一些有益的改善。

功能2:TVR

这段时间,还完成了一个新的通用正则表达式验证模块,由于这是一个全新的模块,功能需求清晰,除了在探索Grid控件的使用上花费了些时间,其它的开发过程都十分顺利,也没有产生后续的严重Bug 。

  • 9月:协助HH哥带新人ZZ

这段时间主要协助HH哥为上海开发新人ZZ讲解一些基础的问题,并将自己的一些开发经验与其分享。ZZ非常热爱开发,求知且高效,是公司难得的人才。那段时间他也帮了我很多忙,替我分担了不少的问题,真心希望他在新的一年取得更多的进步,取得更好的成绩。

  • 10月:开始了解客户问题,并处理UU相关CI,开始AA的编写

在这段时间,我第一次接触到客户问题的处理。由于之前都是在做Online项目的开发,完全不了解需要发包和WebEx的客户问题的处理流程。所以这段时间对具体流程进行了下学习和实践,同时也明显感到,客户问题的处理与普通迭代开发有很大的不同。直接面向客户时,问题处理的效率、效果会直接影响客户对产品的信心,针对项目的熟悉程度也会直接影响CI处理的效果,这些需要更多的经验和责任心。我会在今后注意之前不够周到、完善的地方,尽力提高自己CI的处理能力。

同时,也利用了些时间开始编写一个叫做AA的MVC辅助结构。AA的主要目的是将页面中的Section抽象为一个在View、Model和前端JS层次的AA对象,并在前端和后端交互过程中提供一些维护及辅助功能。虽然后来由于CI、POC等问题,没有时间完整的完成所有设想,但其作为一个原型,将会在今后一段时间内被继续编写和完善。

  • 11月:开始带新人ZZ,开始前端开发规范和案例的编写

11月中旬,我开始负责带新人ZZ。这段时间里,ZZ的表现还不错,由于新人的入职培训还没有结束,所以目前还没有开始具体的项目工作。基于目前的考虑,在公共培训后的一段时间里,主要希望ZZ可以从事三个方面的学习和工作,(1)维护并进一步更新国际化工具,以此希望ZZ可以进一步掌握C#的基础知识,并针对JJJ等工具有更加深入的理解。(2)进一步学习HTML、CSS及JavaScript,对前端技术有所了解的前提下,基于简单的ASP.NET MVC开发一个工具站点,该站点可以XXXXXXXXXXXXXXXXXXXXXX。(3)充分使用GG产品,在不接触代码的情况下,尽量掌握产品的逻辑、概念,尽量熟练的操作产品,为之后熟悉产品代码打下良好基础,同时,也可以协助我完成更多的工作。

对于AA的编写和前端案例整理的工作,也在某些方面暴露了我自身的一些问题。由于我在迭代期间开发和处理一些和迭代功能无关的东西,这使得我在迭代期间的工作时间被压缩,一些Bug的修改进度被延后,也让我不得不在一些情境下通过加班来解决问题。这确实在一些方面反映了我个人能力及责任心的缺失,也体现了我自己无法做到100%投入日常工作的特点,这是值得我今后小心谨慎的,当然,这也是不可能避免的。

  • 12月:为新人培训III课程,开发UU POC

非常感谢公司能在12月初给我一次向新人讲解III培训课程的机会,这段时光可以说是我在这段时间里最愉快的一段经历了。通过这次培训,我认识了很多非常有活力且充满斗志的新人,这也让我得到了一次休息心灵的机会,我非常羡慕他们,也希望他们能通过我们的培训在今后更快的成长。这两天看了一下当时培训的视频,还是挺有意思的,也希望今后能有更多的机会为公司的新人带来更多有益的帮助。

这段时间,还在LL哥的指导下完成UU的POC任务,这项任务主要包含两个不太复杂的NFR和一系列的CI及Merge工作,在此过程中,也有一些问题需要自己反省。

首先,还是要更多的注意预估NFR时间的重要性。在POC的开发过程中,有一个针对MS Report的基于PP MM的记录权限筛选的NFR。而MS Report并不像其它Report一样具有显示MM的功能。而是否在界面上显示MM直接关系到了MS Report模块是否需要全部重写的问题。由于历史原因,MS Report与其它Report的实现完全不同,这个小小的问题直接关系到了具体开发时间和发包日期的确定。好在后来我们针对此问题确定了需求,并延长了3天开发时间,但实际上,重写模块的时间还是相当紧凑的。而在重写的过程中,为了使MS Report与其它Report的实现保持一致,其编写的过程也导致了更多低维护性代码的产生,附录中的那个大长SQL就是其中之一。

其次,如果我们发现问题可能会发生,那么它就一定会发生。在处理 [DD-11111] 最小权限问题之后,我曾怀疑这是否会影响GG升级,但是由于知识浅薄,不了解GG Patch升级的具体实现过程,因而没有提出疑问。而在客户设置完最小权限之后,QA及用户就出现了不能安装GG Patch升级包的问题,这是非常值得我自己反省的,以后此类问题,一定要多多注意。

最后,在一些存在设计问题的结构之上短时间内为客户编写POC,这不仅会进一步降低代码的可维护性,也会引发更多的后续CI。同时,在将POC功能Merge到Trunk代码中时,能否做到先Review POC实现再Merge代码,这更是一个需要我们注意的问题。一味的拷贝代码,或者不断的向已有代码中添加更多的补丁代码,只能使项目的维护越来越困难。

回望这半年,很多工作只完成了一半,由于时间和能力所限,很多东西没能按照计划完成。知识与精力的匮乏导致我无法对自己的工作表现满意。虽然这半年过的比较累,但取得的效果较差,而如今也只能期冀新的一年,能更多的吸取教训、清理更多的阻碍,然后将那些没能完成的任务继续推动向前。

面对每一位GG Team的普通开发者,我更需要向他们学习,这不光是技术或业务逻辑上,更多的是开发态度上。每一位GG Team的普通开发者在工作时长、所付的努力上绝对远远高于我以前所在的团队。这可能是某些内在的原因所导致,但抛开那些不说,只是从工作的意志和态度上,我对每一位普通的开发者感到由衷敬佩,GG的每一位普通的开发者都是英雄。

4 对新一年的期冀

对2015我充满期待。个人觉得,GG 目前确实存在着一些问题,有些问题可能是我个人无力改变的,而有些问题可能是我力所能及的。作为团队的一员,努力去让GG 变得更好,是我自己现在最大的目标。希望在新的一年里,我可以完成以下的这些最基本的计划,并取得一些切实的效果,为GG Team做出自己的贡献,也努力为我们的Team增加更多有益的东西。总之,如果不能在新的一年里通过自己全身心的努力为项目带来些有益的改变,那辞职的勇气,我还是应该有的。

  • 完成国际化工具,使其成为一个广泛使用的实用工具。
  • 进一步熟悉MM逻辑,完成MM代码重构工作。
  • 进一步熟悉GG,更加有效的完成CI和POC的工作。
  • 深入学习.NET MVC框架,完成AA原型的编写。
  • 继续学习Bootstrap,整理出一份较为完整的前端编写规范,并继续提高自己对前端技术的掌握。

在新的一年里,希望通过自己的努力,学习更多、分享更多,并用所学为大家带来更多有益的贡献。无悔于自己,也无愧于他人。

以上就是我对2014年度工作的总结,诚祈大家平安和顺、快乐幸福,谢谢!

5 附录

以下这段我不忍删除,就当是自我拉扯吧。

在UU POC的编写过程中,极大的锻炼了自身编写“基于StringBuilder的单行‘动态’大长T-SQL”的能力,在快速完成软件构造的情况下,保证不改变任何原有代码层次结构并在放弃安全性和扩展性的情况下最大化开发速度,这是极其简便有效的。以下就是我编写的T-SQL,此SQL语句的成功执行,标志着我在超大型SQL语句领域的巨大突破。

select Count(*) FROM (
        select 's' as ItemType,
        sites.properties.value('(Property/Title/@Value)[1]', 'nvarchar(max)') as Title,
        sites.FullUrl as FullUrl,
        siteD.Department as Department,
        ISNULL(siteOwner.LoginName, sites.SiteOwner) as SiteOwner,
        ISNULL(siteSecondaryAdmin.LoginName, sites.SecondaryAdmin) as SecondaryAdmin,
        sitePrimarySiteContact.LoginName as PrimarySiteContact,
        siteSecondarySiteContact.LoginName as SecondarySiteContact,
        CAST(sites.Properties AS VARCHAR(MAX)) as Properties,
        sites.IsDeleted as Status,
        requests.Details as requestDetails,
        siteD.PolicyName as PolicyName
        , [Mda4dab94_9d17_4895_999d_e2199111d353]  as M0, [M1467a923_0695_458c_8d41_73e33c274ac6]  as M1, [Me5f7330b_1f67_4099_b0fb_754b9cb002d1]  as M2, [Mccd3a21f_1d32_4366_ac0a_60a924acade2]  as M3, [M121e8285_3821_445a_85c6_c9a4aa1ca7bb]  as M4, [Mc743348f_3892_4268_94df_771c3e489149]  as M5, [Ma7aca43b_7738_4fc8_b914_84149ea88d1e]  as M6, [M14f532d4_0615_4131_bcfa_b4d95e90e3a8]  as M7, null as M8
        FROM Sites as sites WITH (NoLock)
        LEFT JOIN Requests as requests WITH (NoLock) ON sites.RequestId = requests.Id
        LEFT JOIN Users as siteOwner WITH (NoLock) ON sites.SiteOwner = siteOwner.LoginName
        LEFT JOIN Users as siteSecondaryAdmin WITH (NoLock) ON sites.SecondaryAdmin = siteSecondaryAdmin.LoginName
        LEFT JOIN Users as sitePrimarySiteContact WITH (NoLock) ON sites.PrimarySiteContact = sitePrimarySiteContact.LoginName
        LEFT JOIN Users as siteSecondarySiteContact WITH (NoLock) ON sites.SecondarySiteContact = siteSecondarySiteContact.LoginName
        LEFT JOIN(
            SELECT sites.id as Id,
                    department =
                CASE
                    WHEN requests.Department IS NULL
                        THEN
                            sites.properties.value('(Property/Department/@Value)[1]', 'nvarchar(max)')
                    ELSE
                        requests.Department
                END,
                    policyName = policies.Name,
                    siteTitle = sites.properties.value('(Property/Title/@Value)[1]','nvarchar(max)')
            FROM sites WITH (NoLock)
            LEFT JOIN requests WITH (NoLock) on sites.RequestId = requests.Id
            LEFT JOIN policies WITH (NoLock) on sites.policyid = policies.id)
        as siteD on siteD.Id = sites.Id
        where PrimarySiteContact = 'A\iii' or SecondarySiteContact = 'A\iii'
        or SiteOwner = 'A\iii' or SecondaryAdmin = 'A\iii'
         OR 'M1467a923_0695_458c_8d41_73e33c274ac6' like 'A\iii'
 
        union all
 
        select 'w',
        webs.Title,
        webs.FullUrl,
        webD.Department,
        ISNULL(siteOwner.LoginName, webs.Properties.value('(Property/PrimarySCAdmin/@Value)[1]', 'nvarchar(max)')) as PrimarySCAdmin,
        ISNULL(siteSecondaryAdmin.LoginName, webs.Properties.value('(Property/SecondarySCAdmin/@Value)[1]', 'nvarchar(max)')) as SecondarySCAdmin,
        webPrimarySiteContact.LoginName,
        webSecondarySiteContact.LoginName,
        CAST(webs.Properties AS VARCHAR(MAX)),
        webs.IsDeleted,
        webs.Details,
        null
        , null, [M1467a923_0695_458c_8d41_73e33c274ac6] , null, null, [M121e8285_3821_445a_85c6_c9a4aa1ca7bb] , [Mc743348f_3892_4268_94df_771c3e489149] , null, null, [Md899b7ae_50ef_4d99_ac9a_9863368ddbf4] 
        FROM Webs AS webs WITH (NoLock)
        LEFT JOIN Users siteOwner WITH (NoLock) ON webs.Properties.value('(Property/PrimarySCAdmin/@Value)[1]', 'nvarchar(max)') = siteOwner.LoginName
        LEFT JOIN Users siteSecondaryAdmin WITH (NoLock) ON webs.properties.value('(Property/SecondarySCAdmin/@Value)[1]', 'nvarchar(max)') = siteSecondaryAdmin.LoginName
        LEFT JOIN Users webPrimarySiteContact WITH (NoLock) ON webs.PrimaryContact = webPrimarySiteContact.LoginName
        LEFT JOIN Users webSecondarySiteContact WITH (NoLock) ON webs.SecondaryContact = webSecondarySiteContact.LoginName
        LEFT JOIN Requests AS requests WITH (NoLock) ON webs.RequestId = requests.Id
        LEFT JOIN (
            SELECT webs.Id AS Id,
                    department =
                CASE
                    WHEN requests.Department IS NULL
                        THEN
                            webs.properties.value('(Property/Department/@Value)[1]', 'nvarchar(max)')
                    ELSE
                        requests.Department
                END
            FROM webs WITH (NoLock)
            LEFT JOIN requests WITH (NoLock) ON webs.RequestId = requests.Id)
        AS webD ON webD.Id = webs.Id
        where PrimaryContact = 'A\iii' or SecondaryContact = 'A\iii'
    ) as outside  
 Where  (  (  Department = @ColName1 Or Department = @ColName2  )  ) 

About nista

THERE IS NO FATE BUT WHAT WE MAKE.

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注