前段时间（额，至少是六个月前）接手了一个应用。看了一圈代码心里满是郁闷。应用要处理的事情很简单，但是代码一点儿也不简单。给人的感觉就是为了要使用java8的一个特性而生生将程序扭曲成了一个奇怪的东西。当时就有心吐槽一番，不过拖延症发作才等到了今天。这也是一件好事情，因为在这段时间里多少经过了一些思考和反思——满是负面情绪吐槽只是一时痛快了，思考和反思却是对以后有益的事情。
回到问题上来。可以将一个开发者设计开发应用的心态分成两种：魔术师和建筑师。魔术师是想法最多的那一批人，他们会搬出各种令人眼花缭乱的技术，随口说出各种专业术语，拿出的方案有各种理论的支持。建筑师则相对保守，他们通常是从曾经使用的方案上衍生出方案，没有新意却有经验的支撑。需要在这两者间选择的时候该怎么办呢？可以从三个方面考虑：目标、一致性还有简洁性。
在设计和开发的时候，至少要思量两个目标：怎样完成任务需求以及这个任务对自己有哪些提升？这两个目标一个是对职业的负责、一个是对自己的负责。对职业负责，就是尽量将一切做好，做到问心无愧。对自己负责就是在工作中学习更多的东西、掌握更多的技术、开拓自己的人脉。最好的做法当然是将这两个目标拧到一个方向上。最不好的做法就是一心偷懒敷衍任务。还有一种做法是将任务做成一块试验田，试验田的意思就是更重视过程而不计收成。魔术师最容易犯这个毛病，虽然有时候不是有意的，但是经常会走到为技术而开发的路子上。
在团队开发中需要考虑到一致性。这里的一致性指的是在使用的技术、方案以致编码风格上做到统一。这样做有如下好处：降低风险，减少学习成本和沟通成本。如果不是有明确的需要，就不要打破这种一致性。建筑师很容易加入到一致的队伍中。魔术师则可能会对这种一致性产生反感。
要避免和魔术师的冲突只需要用事实说话。这里有一种思路：列出应用中需要商榷的部分，逐一进行验证，应该保留的就保留，可以简化的就简化、可以删除的就删除。这样最后剩下来的部分就是最该留下来的部分。最后保留的部分也成了一致性的构成。
这里说的魔术师和建筑师的衡量是从技术追求和业务需求两个方向进行的衡量。可能是因为之前想要吐槽的缘故，所以前面多少显得对技术追求型做法有些不认同。不过作为开发就得凭技术说话，对新技术的学习永远也不该停止。但是否要以及怎样将一项技术引入到工作中，就得全面考虑了。
就这样。
发表评论