标签：
在集群通信行业两家公司开发PC应用六年了,但在对开发的理解的道路上感觉还是挺孤独的,于是想写点东西发泄下郁闷,没想到只想了一两小时就写了几十条提纲.好话说在前面,文中的提到的现象可能不全面,甚至是误会的,文中的观点更是需要审视的看待.
产品越复杂（越多硬件）越能卖出好价钱
产品便携易用，越能解决客户问题，越给客户创造价值，才越值钱。产品成本和产品价值没有直接关系，iphone的成本如果只有1元钱，就没人花45千买了？
性能问题需要测试数据来证明
在讨论某个功能的整体设计时，做嵌入式开发的常常随意的说句“影响性能”，就放弃部分对他们实现起来可能(通常是经过秒级的思考时间)复杂点的接口，导致应用层无法设计出易用的操作流程。另一方面，真正出现性能问题的时刻反而在客户现场，因为此前的n个里程碑n*m个版本都没系统的认真的对性能问题明确指标, 做过测试。
产品卖的多,无反馈,不代表产品设计好/质量好
由于客户行业的特殊性，供应商(就是我所处公司)存在垄断或半垄断性，公司有时较难接触到最终的直接客户。产品卖出去后，整体/单功能使用率到底如何，使用过程中的问题有哪些，这些都需要主动积极调查获取，持续完善，现实情况可能是没有主动行为，部分客户在忍无可忍的情况下才会反馈。在充分公平竞争的市场中，深入客户调研，口碑营销有多重要，看看小米就知道了。
融入客户工作,为客户创造价值
研发成本很大一部分和需求不清晰或变更相关。客观原因上，这个行业很多时候是上级部门推动项目，而不是真正应用的底层部门主动提出具体问题和需求，有时候需要针对技术提前预研可能的应用；主观原因上，需求调研不是和个别领导讨论个几次就能完成的，需求调研具有很强的技术性，需要专业的知识，通常需要不断的学习实践领悟，公司常犯的错误是将单纯擅长销售或是技术的人去做调研，只调研客户中的个别领导，导致需求调研的信息太少、片面，加上调研人员没有专业的知识，不能透视客户信息的本质，引导客户讲清业务全貌，更不能在看清需求本质的基础上，设计好的方案解决客户问题。解决办法就是融入客户工作，举个例子，要给交警开发，就要深入了解交警日常的巡逻、处理事故、梳理交通等等场景，了解整个流程，包括与调度台的信息交互，考虑各个角色（普通人、事故相关人、外勤普通交警、外勤交警领导、调度员、办公室交警领导）的立场利益，只有了解了，才能思考如何通过产品提高他们的工作效率，完成他们之前无法完成的工作，需求调研需要的沟通能力、观察能力、创造能力非常高，产品设计过程中与其他人包括自身领导和客户都可能有冲突，有时候还要固执的坚持自己的原则到最后一刻。另一个办法就是尽早提交可用的版本，观察用户使用情况，听取反馈，透视本质，持续迭代产品。
面向抽象接口设计,而不是从实现细节定接口
照理说做通信这行，要涉及那么多协议，面向接口设计的意识应该要比其他行业好些，实际上这么多年观察下来似乎没那回事，从领导到底层都是。面向抽象设计接口的意识和能力对开发来说非常重要，因为依据好的接口实现的代码易读、易维护、易扩展，能大大提高研发效率。
复杂的分析设计,请三思而后行
一个重要的功能的需求分析，一个复杂功能的多设备模块间的设计，领导可能一次会议就定下了，会前可能都没有独立思考过，结果就是匆匆定下的需求交互不友好、不全面，接口不停变，被污染，流程不完善。按问题多多的需求和设计去详细设计和编码，只能是返工频频，既浪费也伤士气。按照人的思考规律，人一时想不全问题的方方面面是正常的，但可以通过三思来修正和优化，我还真没看到能拍板复杂功能需求和设计的领导，有很强的这种意识。
从知识到方案到好的方案, 从知识到管理到好的管理
两个公司都或多或少由通信学院的老师担当重要的岗位，有转业的有现役的，作为老师他们通信的基本知识都该不错，到从基本知识到能用的设计方案再到好的方案有着遥远的距离，就好比很多家公司都能做公网手机，但做的好的没几家，做的优秀的就更少。从学校的基础知识到具备优秀的管理技能，这中间的距离就更大了。最怕的就是懂点皮毛，然后还自以为是。
领导请关注识人用人与各重要环节的原则, 别做不擅长的事
三国演义中刘备真不会打仗，但能三分天下，后期为关羽报仇，冲动的亲自带了次兵，落得惨死，还让国家元气大伤。原则具有较强的抽象性，原则包括哪些，需要自己领悟，通过深入的讨论可以大大加快，然后慢慢形成一种直觉。
用户模式/工程模式/开发者模式
我个人是比较鄙视在给客户使用的界面软件中包含大量的目标用户根本无法懂也不需要懂的术语，觉得这就是违反界面设计原则的事，觉得这就是不尊重目标客户，好比老板看到自己花钱雇的员工上班时间不务正业，一天到晚玩游戏。客户中普通用户，客户中的管理员用户，客户中的领导用户，测试人员用户，工程人员用户，开发者用户，这些是典型的用户类型，理论上每类用户都可能有独立的界面视图，好比读红楼梦的每个人心里都有一个林黛玉。安卓手机中有个开发者选项就是这个概念的产物，默认通过一个隐藏的操作来开启，里面能开启usb调试模式，还有些工具能开启手机的工程模式，在那里面能配置音量最大值之类的。PC应用软件当然也可以类似的做。
重视工具开发与重用
能提高工作质量和效率的任何手段都该重视，例如通过升级电脑配置加快电脑启动速度，编译速度，运行速度，降低故障率，买电脑时也尽量买同型号主板的，因为那样备份一台电脑就能在其他电脑快速恢复，现在的状态是可能要花大半天时间重装一台电脑的系统和软件，效率好低啊，我是老板的话要骂娘了。好像扯远了，这里想说的是通用日志记录工具、打包输出工具、分析工具，通用但能加载自定义解码库的抓包工具，通用但能加载自定义命令集的telnet工具。研发成本中最大的应该是人力，通过工具就能持续节约开发时间，时间就是金钱，对公司而言，这是非常有利可图的，对个人而言，提高效率是能力的体现。可惜公司对工具特别是通用工具的开发，重视程度还很不够，个人也常常缺乏对工具持续的完善或排斥学习新事物。
话单和录音本该在一起,依据客户职责划分应用边界而不是依据系统底层设计的独立性
网管有独立的服务器和客户端，话单放在网管，录音有独立的服务器和客户端，这从开发者角度是多么的顺其自然，但从客户角度日常的应用场景可能会多出了许多不必要的操作。在客户端，话单和录音肯定应该在一起，在服务器端，话单和录音可分可不分。
统一平台,依据客户职责配置权限的应用中心
海底捞还是榆舍
公司搞活动时，为什么不能稍微民主一点，一笔小小的活动经费非要迁就领导喜好，再三迁就领导时间。其实让大家畅所欲言的或是尽情享受的才是重要的。
网元间的接口的测试与诊断,测试/工程人员该做, 请能让他们做
据了解华为就是这么做的，我们公司就不行，开发没有意识到问题的重要性，其实技术上对开发而言不难。如果做到了，可以大大提高定位和诊断故障的效率。
应用开发不是陪衬,当成主角时公司就强大了
现实是很多领导觉得界面不重要，没技术含量，我只能说无知。为什么那么多人买iPhone，除了买了装逼的，主要是硬件外观好手感好，系统操作流畅简单，应用丰富，在进一步总结，这些因素都是外在的。
买软件送主机,解决兼容性与提高维护效率,同时提升品牌形象
有时会涉及到访问部分硬件功能,没有直接的通用的API可用,这是会遇到兼容性问题,例如有的声卡行,有的声卡不行.兼容性问题可能无法预计,最好的解决方案就是开发时适配少数的设备,然后买软件送设备(例如声卡,甚至主机).其实是不是送只是一个说法而已.如果你想方设法去兼容所有硬件,那可能是不归路或是布满地雷的路.
仅靠统一文档模板无法提升设计质量,提升设计质量重神不重形
小时候写作文,老师说要有时间地点人物,连作文纸都是模板,但写出的作文有0分的,60分的,100分的. "神"是指原则/核心概念一类的.如何衡量设计文档的质量,举个例子,依据文档去解决bug,越快解决的文档质量越高.
货比货,另一种重构
还是有机会接触到别的机构或公司的硬件/软件/协议,通过比较和深入分析是能够借鉴很多东西的,但现实是没开过一次专题会议讨论,有"事不关己,高高挂起"的嫌疑,也有观察力分析力欠缺的嫌疑.
定义接口,应用开发者该更有话语权
上层决定下层,下层提供可行性约束,接口必须抽象.只有这样,系统才能更好的适应变更,系统组件才能更好的重用.现实的情况是反的,很悲剧很无知.
BS/CS不需要分清楚
一般来讲,BS更易于部署和跨平台,CS客户端效果更好.这个行业中,用户数量和使用场所都不多,类型相似,BS的优点不太重要.用BS做一个功能导航兼CS客户端的下载服务器是一个不错的结合.
从明确测试用例到自动化测试,现代化编程必经之路
软件开发中的所有步骤，所有任务都该都能明确完成标准，测试用例就是标准的主要形式，有了严谨的测试用例才能衡量大大小小的任务的质量，才能准确把握产品的质量，这需要严谨的工作态度。公司要做到这一点还有很长的路要走。自动化测试是高效测试的必由之路，特别是回归测试，如果不通过自动化测试，成本会很高，理论上每改动一处代码都可能产生BUG，都需要回归测试。
想要稳定的产品,不能轻易重启
功能测试成功过一次就算通过，再出现问题就推脱责任，或是重启一下再试，如果试成功了就结束了，也不会去仔细研究之前的问题的原因。这是现实中常出现的。结果就是产品中存在很多隐患，这种隐患越到后期排查难度越大，成本越高。解决问题的首要条件是严谨务实的态度，然后是导出异常状态、记录日志、调试诊断问题等等的技术问题。
告警与状态本来就是两回事
告警与状态模块在很多系统中都是非常重要的，包括每天使用的公网手机，系统层面状态包括wifi、xg信号强度、电量等等，系统层面的告警通过下拉出通知列表呈现。我发现我们现在的产品中连告警和状态的概念都分不清，怎么能设计出优秀的应用。从一点可以看出集群通信行业整体的产品设计能力都不强，不专业，但就因为不强，挖掘空间很大。
谨慎使用"透传"
可用的方案可以设计出很多，大部分人就止于可用而已，但优秀的方案却可带来高重用、易维护、易适应变化。‘透传’就是常见的‘’可用‘’的设计方法之一，例如对各类号码的编解码，嵌入式开发人员常常为了省事将编解码责任透传到应用层，这肯定是不符合设计原则的，但目前没遇到一个嵌入式开发人员能正视这个问题。这个很能体现公司的产品实现的设计水平。
在小团队中,尽量统一开发平台,提高技术复用性和人员可替换性
网管是用java做的,
公司没几个会java的, 会.net倒是有四五个, 很长时间就是一个人在写java代码,半年前做网管的离职,我和其他一两个做.net的同事临时接手网管,半年来工作时就没几天好心情,换做3年前的我,估计已经换工作了.主要原因是代码很烂/协议设计一般烂/应用设计很烂. 客观上对一个公司而言,就一个员工用java开发网管这么重要的软件, 非常不靠谱, 难道就没意识到”如果这个员工离职了, 能很快找到人继续把网管做下去吗”? 这种不靠谱一直持续了好像两三年吧. 其实这个问题一开始就可以避免, 那就是统一开发平台, 要么全用java开发PC软件, 要么全用.NET开发PC软件. 似乎刚开始领导并不知道.NET能开发网站. 像”JAVA更适合开发网站,
.NET更适合用来开发桌面软件, JAVA性能更好框架更成熟,
LINUX比WINDOWS性能更好”之类的流行的成见, 对一个小的开发团队/中小的项目来说没意义. 在小团队中,只有尽量统一开发平台,人员的可替换性/技术的复用性才能很好的得到保障, 使用自己擅长的技术解决问题才能达到高效.
搭建演示系统,应该分分钟搞定, 3G/4G请随身带, 以便远程调试
经常听到测试人员抱怨, 出差去部署演示系统时是多么的郁闷和辛苦, 最大的问题是里程碑/版本控制不力, 出差带出去的应该是正式提交并相对严格测试过的版本, 有着严谨的测试用例, 现实是不把开发版本和提交到测试的阶段性正式版本彻底分开, 导致测试面对的是海量的开发调试版本, 测试人员哪能按照严谨的测试用例去认真测试. PC端程序尽量在出差前制作虚拟机版本, 到现场后分分钟就能部署好. 如果系统设计的便捷, 网管支持离线配置,交换基站能方便的远程升级, 手机支持空中编程, 搭建演示系统分分钟解决不该是梦. 有些时候工程或测试人员反馈一个问题, 通过电话沟通, 效率可能非常低, 如果能让开发人员进行类似远程桌面一般的调试, 效率可能高很多, 这仅仅需要一块3G/4G网卡.
拓展训练不如当面互相平等的骂
想通过拓展训练或是普通的聚聚餐来增强团队凝聚力和战斗力，只能是隔靴搔痒。首先尊重、合作（权责契约），我觉得是人与人关系的基本原则，处理团队内部关系自然也是适用，能基本做到这点，大家就可以平等的坐下来谈；然后，要想提高团队凝聚力，就是要能让个体通过依赖团队成长和收获，举个例子，别人指出你的设计缺陷、思维缺陷、性格缺陷，并帮你改正，或是你能通过项目经历主动学习领悟到技术、管理上的道理。我觉得一种好的团队氛围就是，讨论问题时应该畅所欲言，想骂就骂，骂能让人影响深刻，能把矛盾暴露，能逼人换位思考，能推动问题解决，骂完后该妥协的还是得妥协，服从整体利益出发。
个人知识库/团队知识库/公司知识库不该是虚无缥缈的
知彼知己,百战不殆. 如何知己? 建立知识库. 个人的知识库可以涉及价值观/职业技能, 团队知识库可以涉及开发技术知识库/组件库/项目管理技术/参考项目. 没有明确的知识库, 在面对选择时容易迷失, 浑浑噩噩.
里程碑/版本计划与奖惩条件应该很醒目
要控制项目就是要控制里程碑/版本, 必须严谨务实的围绕测试用例; 要提高整体的工作效率就是要调动团队中各成员的积极性, 要调动人的积极性, 就要围绕奖惩. “分田到户, 农民有地就有好日子”, 党就凭这个调动了无数的农民的积极性, 才有了新中国. 项目如期完成奖50000,
提前2周奖80000, 延迟2周奖20000,延迟1月扣罚20000, 类似的制度在细化后可以尝试尝试, 核心在于每个人都要有压力和动力, 奖罚分明, 团队作战.
项目开发超时，没见领导出来担责，只会让别人加班
经常遇到项目开发超时, 一超再超, 但从来没见过大大小小的领导出来主动承担责任, 项目超时或者烂尾, 主要责任当然应该领导承担, 因为领导把握着更多的选择权, 选择成员/选择项目迭代计划/选择技术框架/选择设计方案/选择如何控制风险/选择是否重构何时重构, 在团队成员面前主动的承担错误, 总结教训, 看起来没有面子, 但可能利于加强团队的凝聚力, 能打造出有真正战斗力的团队. 现实中,
面临项目即将必须交付, 领导通常会严厉的要求成员加班, 并把责任都推到成员身上, 最过分的是让人连续几个星期每天加班, 周六周日不休息, 这种做法一来是严重的不尊重人, 二来是蛮干, 工作效率根本得不到保证, 反而埋下人心涣散的大患.对我来说,连续加班一周是极限, 前2天效率能得到保证, 后面几天效率就会逐渐下降. 软件开发的各个步骤都或多或少带有创造性, 需要清醒的头脑, 清醒的头脑需要省心协调来保障.
被动重构与主动重构，被动领悟与主动领悟
重构是个人和团队提升能力的非常重要的手段, 领悟是个人提升能力的途径, 聪明的人会主动积极的重构, 麻木的人害怕重构, 得过且过.
无设计文档/乱七八糟的文档都是维护的灾难
标签：
原文地址：http://www.cnblogs.com/wangk/p/5730970.html
