随笔（2015.11）

最新推荐文章于 2021-02-10 21:51:05 发布

ysu108

最新推荐文章于 2021-02-10 21:51:05 发布

阅读量627

点赞数

分类专栏：随笔

本文链接：https://blog.csdn.net/ysu108/article/details/50165047

版权

随笔专栏收录该内容

26 篇文章 0 订阅

订阅专栏

在一些关键的函数，例如回调过来开始处理的函数，流程逻辑一定要清楚，不要掺杂太多的逻辑处理，一定要短而且要清楚表达逻辑的走向。
函数名字最好动词开始，把里面最主要的逻辑表达清楚，不要试图说明所有的动作，要抓住懂点。
想写出扩展性强、容易理解的程序，写完后代码会变多，类会变多，方法会变多，变相增加了一部分工作量，但程序流程清楚（结构化编程），变化时改动小（抽象变化）。
很多东西有共通的道理，如何让程序高效率的运行？首先要理解其所处的环境，程序是运行在哪里，运行的机制是什么（操作系统原理）。从cpu角度来讲，高效就是运算步骤尽量少（较少线程切换、锁竞争），运算工作排列的仅仅有序（不要有空闲的时候，线程中锁等待时间要短）。
除非编译器实现了新的export关键字，否则将模板成员函数设置在一个独立的实现文件中将无法运行。因为模板不是函数，它们不能单独编译。模板必须与特定的模板实例化请求一起使用。为此，最简单的方法是将所有模板信息放在一个头文件里，并在要使用这些模板的文件中包含该头文件。如果编译器实现了心得export关键字，则可以将模板方法定义放在一个独立文件中，条件是每个模板声明都是以export开始：
发现一个使用指针小技巧，如果一个对象的指针成员不停的在切换所指向的实体，那么可以在这个对象指针切换指向实体前在释放以前的资源。这也需要根据实际场景来判断。但需要注意在指针所属于的实体释放时候，不要资源泄漏。
模板的特化也可以认为是一种“多态”，处理的场景不同，当参数类型改变对应的行为也会改变。例如输出一组没有关系的结构体的时候，可以定义一个模板类”基类”，在特化的类中实现具体的功能。当然简单写可以使用重载的方式实现不同的参数有不同的行为。使用模板类好处就是可以在模板类中调用。
何时把switch case的实现使用多态类实现呢？使用多态实现的最大好处是可以隔离变化，如果使用一个工厂虽然里面也是switch case的样子创建对象，但是隔离了变化，隔离之后，在增加case的情况，更容易理解（对象），只需要修改工厂函数就可以了，其他的不用修改。
http://www.cnblogs.com/chenwenbiao/archive/2011/08/11/2134503.html 对编码介绍详细的文章
对与国际化的一种方法，需要把sql脚本，配置文件中的所有汉字词语转成葡萄牙语，首先想到的是正则表达式，比较麻烦。其次可以通过分析文件特征来，如果是sql脚本，所有的汉字都是使用”引用起来，可以把所有”引用的字符提取出来，然后转成UCS-2大顶端方式，判断字符是否在这个范围内，从而判断这个字符串是否含有汉字，如果有提取出来即可。
思考太少。下班前15分钟，可以总结计划工作。
新增协议要思考协议的功能，也就是这条协议存在的原因。从系统设计角度看，一条协议代表一个功能，这就可能会出现一条协议处理可能会多步骤的情况，如果要求事务一致性强，那么可能会处理的复杂。
JS为前端脚本，php为服务器脚本。虽然php也写在页面里面，但发送到前端的时候会进行一次编译，编译后就全是html与js了，发送给web的不会看见php任何的影子。
所以，不要再js的定义范围内使用任何php脚本，前端是看不懂的。
前端脚本有JavaScript、HTML DOM、jQuery、jQuery Mobile、AJAX、JSON等等，绝大部分为js相关。
java的枚举类在c++中也可以实现。枚举类也是一个类，用普通类也可以完全实现。那么这个东西有什么用处呢？对象有了“枚举”的特征，即：所有的枚举对象，都必须在一个地方一次性声明起来。如果是一般的类，是无法控制符合一定接口的类的产生的。
有什么好处呢？枚举多了对象的属性。可以增加一些其他的方法，例如通过名字不能描述的信息等一些其他特殊的“枚举属性”。
与普通的c++中使用关键字ENUM定义和原java中定义例如：

public interface IConstants {
        String MON = "Mon";
        String TUE = "Tue";
        String WED = "Wed";
        String THU = "Thu";
        String FRI = "Fri";
        String SAT = "Sat";
        String SUN = "Sun";
    }

主体结构与消息分发
http://www.cnblogs.com/yuanfan/archive/2012/12/31/2840779.html
游戏服务器结构探讨——结合mangos分析
http://blog.chinaunix.net/uid-26722078-id-3801402.html
mangos服务器架构
http://blog.csdn.net/kenkao/article/details/12440307
Socket通信库 C++ Sockets Library 和 C++的并行编程模板库Threading Building Blocks （tbb 和 tbbmalloc）
ZThread库是一个开源的跨平台高级面向对象的线性和sycnchronization 库，以运行POSIX 和Win32 系统中的C++程序。
ZThread库的主页：http://zthread.sourceforge.net
最新版本Zthread远吗下载地址: http://prdownloads.sourceforge.net/zthread/ZThread-2.3.2.tar.gz
ZThread文档：http://zthread.sourceforge.net/documentation.html
Session既可以表示一个用户的一次连接，又可以用来表示用户的一个消息的交互。
框架热路径处理中使用bind与智能指针。消耗资源大。
串口读超时时间，首先串口上还有一个相邻bit的超时时间，这个是系统默认配置的，这个时间是说两个bit之前相隔多少秒算超时。还有一个读超时时间，这个时间是说从系统调用起，多长时间没有读到数据返回的一个时间，但是如果等待过程中读到数据了，那么会一直持续到读不到数据为止。“读不到数据”的超时标准就是两个bit的超时时间内没有数据。
轮询未必是低效的。自己的一点想法。如果处理的请求特别多，假设每秒1w个，而且处理速度特别快。假如用条件变量，那么最坏情况会发生1w此的信号量的wait与唤醒，这个系统调用还是会有一定的消耗的，如果每10ms调用一次sleep然后处理（处理同时允许增加请求），那么虽然处理时最坏有10ms的延迟，但是系统调用次数大大减少。
有必要使用IOCP？ http://blog.codingnow.com/2006/04/iocp_kqueue_epoll.html 很久之前的一篇文章，提供一种思路，如果是分布式的服务器，逻辑服务器与连接服务器只有一个连接，对实时性要求不高，那么什么复杂的IOCP、epoll模型其实没有必要的，连接服务器可以定时（比如10Hz）把接收到的消息一次性的发送给逻辑服务器，逻辑服务器甚至可以recv阻塞式的接收消息。简化逻辑服务器网络层开发，方便记录所有的消息时序，方便调试。甚至对性能没有影响。
框架选择时，够用即可，根据需求。
http://blog.codingnow.com/2006/10/multi_process_design.html 多进程程序一些建议。其中的“有逻辑处理的进程上的数据流一定是单向的，它可以从多个数据源读取数据，但是处理后一定反馈到另外的地方，而不需要和数据源做逻辑上的交互”也可以应用到开发中的多线程中去，处理结果反馈点不一定在数据的处理点，如果真的需要反馈，那么可以反馈到数据源的地方从单一入口进入
框架的设计需要根据具体的需求 http://blog.chinaunix.net/uid-26722078-id-3801402.html
例如在发送消息的缓冲队列上，可以每个玩家分配一个缓冲区也可以分配一个全局的缓冲区，分配全局缓冲区对于广播类消息可以减少处理，每个玩家分配单独缓冲区逻辑清楚，可能需要阻塞的处理发送消息。
别人博客中的观点，有些删减，多数为吐槽，自己大都认同。
一定要code review, 一定要有良好的编码风格。一定要保持代码的整洁。
一定要print和用户相关的log。
服务代码要精简，需要大量共用组件，每个功能的开发最好不要牵扯到其他项目的开发。保持船小好调头。
要有人对需求约束负责。很多约束条件在开发初期就要定下来。千万不要说可以放无限多的内容，无字数限制，无大小限制，可以承载无限大的压力这样的话。
考核应尽量简单。另外不管怎么考核，这些考核永远是主观的。升职加薪本来就是看个人能力，而这事主管心里是清楚的。
不要简单堆砌功能。功能在精不在多。请回顾一下庞大的功能，其中80%的功能都应该被砍掉。
公司在开发者机器上的配置上不要抠门，机器速度/网速是保持开发者良好心态的关键。
公司需要尽量配置可以翻墙的网络。
公司对研发成员不要实行打卡制。
公司对员工应不时发些福利。不患寡而患不均。
http://blog.csdn.net/cctt_1/article/details/49556925
“每天专注三件事”http://blog.csdn.net/happydeer/article/details/36714427 一个比较好的习惯，可以抓住重要的事情。
锻炼才有成长 http://blog.csdn.net/happydeer/article/details/17023229 养成锻炼习惯，在忙也要有进步。工作并不等于锻炼，这里的锻炼主要倾向于“学习”。

与你所相信的恰恰相反，单纯地每天埋头于工作并不能算是真正意义上的锻炼——参加会议并不能锻炼你的人际交往能力；回复邮件并不能提高你的打字水平。你必须定期留出时间，集中锻炼，这样才能把事情做得更好。
我每天都开车去上班，但我的驾驶水平远远不如专业车手；类似的情况，天天编程可能并不足以使你成为一名专业的程序员。

此外，几种可以参考的额“锻炼方法”：

1）罗列出你所景仰的程序员。尽量包括那些与你一起工作的人，因为你会在工作中从他们身上获取一些技能。记录下他们身上的1 ~
2个闪光点，也就是你希望自己有所提高的方面。 2）花20分钟通读别人的代码。读出色的代码和读糟糕的代码都是有益的，两者都要读，轮流切换。
3）当你听到任何你一时之间也无法解决的面试问题时，赶紧回到你的座位上，把这个问题用电子邮件发给自己，以留作日后的提醒。
4）学习多种不同的编程语言，特别是那些与你现在所熟悉的语言有着不同的世界观和编程模型的。 5）
了解硬件对软件的影响。知道你的电脑执行一条指令需要多少时间，从内存中取出一个字（在有缓存或没缓存的情况下）需要多少时间，在以太网（或者因特网）上传输数据需要多少时间，从磁盘中读取连续的数据或者在磁盘上跳转到另一个位置需要多少时间，等等。
6）

高效能程序员修炼 http://blog.csdn.net/happydeer/article/details/9721989 ，
大道至简 http://blog.csdn.net/happydeer/article/details/18773097

作为程序员，我们的任务是要意识到，我们所做的每个决定都是一个折中——这就是编码的本质。要想成为程序设计大师，那就要理解这些折中的本质，并且在我们编写的任何代码中都善加处置。
在编码过程中，你可以从很多维度去评价你的代码：代码简洁度功能的完整性执行速度编码所花费的时间健壮性灵活性
记住，这些维度相互之间都是对立的。你可以花上3天时间写一个非常美观而迅捷的程序，这样你在两个维度上获得了提高，但是因为你花了3天的时间，所以在“编码所花费的时间”这个维度上就落后了很多。

那么，在什么时候这样做才是值得的呢？我们该如何做这些决定呢？其实，答案非常合乎情理，也很简单，但就是从来没有人好好遵从：从简洁开始，然后依据测试的结果按需提升其他的维度。

“代码不是什么好东西。代码会随着时间的推移慢慢腐烂。代码需要周期性的维护。代码里还藏有bug。新增功能意味着旧的代码需要被修改。你的代码越多，bug能藏身的地方就越多，迁出（check
out）或者编译的时间也就越长，新员工理解你的系统所需要的时间也就越长。如果你不得不进行代码重构，那么你需要调整的地方还有更多。

代码是工程师制造出来的。如果要写更多的代码，那就需要更多的工程师。众多工程师之间有n2的沟通成本。”

ps: 说编码的本质都是一个折中，很是赞同。为了性能代码会剑走偏锋，缺少灵活度。
上面两段话出自不同的文章，但都提倡简洁的代码。
实际中最容易出现的问题是过度的设计，写出一堆不知道为了将来什么需求设计的代码。如果怕将来需求扩展或变化可以从代码的耦合性上下手，而不是像使用模板参数，使用很多无谓的虚函数接口等。
工作中还会出现逻辑复杂，多个功能混在一起，类依赖关系混乱等情况，这也是造成代码bug隐藏的原因。
工作中还会经常看到重复造轮子的现象，而且造的轮子即难用又有问题。
还有一些过度封装的“公共模块”，最后可能既不能复用，又导致公共模块过度设计。到最后使用的时候发现，公用模块基础平台代码比真正处理业务逻辑的代码多的多。
编码目的是为了解决问题，而不是所谓的工作量多少k的代码。

另外对于简洁代码书写技巧可以参考mangos部分代码，比如：

const T* GetRegistryItem(Key key) const
{
    typename RegistryMapType::const_iterator iter = i_registeredObjects.find(key);
    return( iter == i_registeredObjects.end() ? NULL : iter->second );
}
bool HasItem(Key key) const
{
    return (i_registeredObjects.find(key) != i_registeredObjects.end());
}

上面实现的是对象注册的管理，这部分如果写成模板可以让很多代码都复用，也是简洁的一种方式。

开发管理中的问题？TODO 敏捷开发 Scrum
http://blog.csdn.net/happydeer/article/details/48932601
关于开发工作的量化 “软件度量是要花费金钱和时间的，使用起来要小心、有节制。另外，软件开发在本质上与自然科学（比如物理）是不同的；相应地，软件度量在获取它们要求的东西时会不精确得多。它们是值得怀疑的——我们不能毫无保留地相信它们。”
一个老外的观点，http://blog.csdn.net/happydeer/article/details/18728027 ，so，这个老外推荐递增式开发（有点类似敏捷开发，也是一个支持敏捷开发的理由），先完成关键的重要的功能。正如他说的软件度量是不精确的，其实需求更是不精确的，工作时候应先完成重要需求，持续集成，利于控制风险。
如果工作中大部分问题都是有类似的，那么可以进行评估而且评估开销不大，评估有利于合理的设置里程碑。
项目成功失败，非技术原因居多。“When projects fail, it’s rarely technical.” 由此想到我司，研发过程中真正的技术问题没有多少，但很多项目最后还是“失败”的。所说的失败是不挣钱或赔钱。除了市场的竞争外，无外乎两个字——“管理”。怪不得一些高管年薪动辄百万，原来管理也是非常有“技术含量”的。上面的管理说是公司中高层，中高层貌似容易拉帮结派（道听途说的），而对于基层的管理者项目经理，其实对公司的影响不大，不会因为项目经理的决定对公司有实质上的影响。但是项目经理还是很忙很重要的，需要安排开发计划，分派任务，考核，提供资源，团建（吃饭啥的）即是领导又是保姆。即能和有逻辑思维不知变通有有些内向的程序员有效沟通，又要赢得他们大多数的尊重。安排开发计划需要一定的技术功底开发经验。分派任务容易么？搞清楚上层领导想让自己干什么和自己让自己手下明白做什么，这两件事在软件开发管理中没那么容易的。考核么，大多数还是主观的，搞不好大家都不满意。对内是提供资源，对外就是争取资源了，有时候还会涉及到责任的推卸，搞不好会得罪人的。
关于会议
看下百科怎么说“会议是人们为了解决某个共同的问题或出于不同的目的聚集在一起进行讨论、交流的活动，它往往伴随着一定规模的人员流动和消费”。后面的什么伴随着消费，估计是中国特色了，暂且不提。会议的目的是未了解决问题，而不是通知或者汇报。汇报可以开会，但我觉得应该是上级对下级的汇报，让大家了解公司的方向动态。如果是向上级汇报任务开会就没有必要了。对于那些事通知的会议，不方便邮件里面说的，开个几分钟短会也是可以的。
管理神话100%利用 http://blog.csdn.net/happydeer/article/details/41511095
人脑子切换工作的代价比机器大很多，机器只消耗了cpu，内存可以完美的从内存拷贝到硬盘，而人脑会丢失相关的信息。满负荷工作下，会缺少创新力。
管理神话之二：只有专家才能做这事 http://blog.csdn.net/happydeer/article/details/41853717
不要让项目中出现不可替代的人。这里不可替代不是说一个人技术多牛无人可以替代，二是说不能只有一个人才有能力去维护的代码，这样增加项目的风险，并且不利于团队的成长。
你不会因为实施了Scrum而变敏捷
http://blog.csdn.net/happydeer/article/details/48932601
敏捷强调个能的能动性，发挥最大潜能，有点像工业4.0，不特别强调个人分工。文章中说了传统公司与敏捷公司之间一些差别，目前处于传统公司，虽然不能成为一个“敏捷”的人，但是文中说的传统公司中员工问题确实存在，比如提出问题多，但提出的解决方案少，不会主动去解决问题。“当面临挑战的时候，他们寻思的是任务不可能完成的理由。” 多数人死守自己职位，自己工作内容外都不去触碰甚至去了解。
- 规则与政策
  敏捷：因为对人的高度信任，规则和政策就没必要了，数量非常有限。只有在关键的业务领域（比如安全和合规性）才会制定一些规则。Airbnb的大部分政策都是基于“直觉判断”是否有风险。
  传统：存在很多规则和政策。但凡你想要做些改变，必须先征得中央集权部门（像架构和安全）的同意。即使是小修小补，也必须在获得批准之后才能动工。
  译者注：Airbnb是AirBed and Breakfast（“Air-b-n-b”）的缩写，意思是空中食宿。这是一家联系旅游人士和家有空房出租的房主的服务型网站，可以为用户提供各式各样的住宿信息。2015年6月，Airbnb完成15亿美元融资后，公司估值达到了255亿美元。
- 工作移交
  敏捷：团队可以自己把代码部署到生产环境，并且继续负责处理突发事件和故障。拿亚马逊公司CTO的话来说：“你做的东西，你负责让它运行起来。”尽量避免移交给别的部门。
  传统：软件会被移交给测试和运维部门。在得到他们的批准之后，会被部署到生产环境。当有突发事件时，运维团队会尝试分析并解决它们。
- 管理行为敏捷：“管理者鼓励通过合作来解决问题，而不是直接指出解决方案。管理者帮助解决那些团队依靠自身力量无法解决的障碍。”——这是Spotify关于服务型领导的敏捷宣言。
  传统：管理者口述解决方案，告诉大家应该做什么。遇到问题的时候，人们常常不会尝试自己去解决，而是把问题逐级上报给管理层。
  译者注：Spotify是全球最大的正版流媒体音乐服务平台之一，2008年10月在瑞典首都斯德哥尔摩正式上线。截止到2015年1月，Spotify已经拥有超过6000万的用户，其中1500万为付费用户。Spotify公布过一份文件，解释了它怎样做到：在快速实现规模化的同时还让企业对外界保持敏捷性。
- 管理知识
  敏捷：工程师的管理者总是掌握着技术技能和知识，因为他们自己通常也是工程师出身的。如果你在Airbnb申请一个管理职位，你首先必须是一位成功干了6个月的程序员。
  传统：管理者通常不需要掌握技术知识。也许因为他们管理的是流程吧。结果是：在他们为工程师们做一个决定或尝试解决一个问题时，会制造不必要的噪音和困扰。
- 角色
  敏捷：在多工种团队里，角色是混合的。比如说，Spotify没有雇用专职的测试人员，但他们确实有一些工程师去教会其他团队如何取得和衡量产品的质量。测试成为了一种能力，而不是一个角色。这是从质量保证（Quality Assurance）到质量援助（Quality Assistance）的改变。
  传统：人事部门设置了固定的角色，并且为每个角色定义了岗位要求和职业发展路径。如果你是一名测试员、架构师或系统管理员，你就一直做与你的角色匹配的工作。
- 心态
  敏捷：人们都有“我可以做到”的心态。InfoScout是美国旧金山的一家初创公司，在它办公室的显眼位置贴着萧伯纳的一句名言：“一个说不能干的人不应该打断别人去干。”
  传统：人们常常抱怨，总是强调问题，而不是去寻求解决方案。当面临挑战的时候，他们寻思的是任务不可能完成的理由。
  译者注：萧伯纳（George Bernard Shaw），爱尔兰剧作家，1925年因作品具有理想主义和人道主义而获诺贝尔文学奖，他是英国现代杰出的现实主义戏剧作家，是世界著名的擅长幽默与讽刺的语言大师。
- 人才
  敏捷：只雇用顶尖的人才。除了工程技术，态度、沟通等软技能也是很重要的。新员工是否能适应公司的文化，是否有足够的责任心——这是面试流程中需要重点考察的部分。这确保了敏捷的企业文化，吸引更高水平的人才加入。
  传统：如果能力强的人不能持续承担有挑战性的任务，不能从其他能力强的人那里学到东西，他们就会不乐意。很多传统公司的环境很难留住他们。这会导致恶性循环。拿乔布斯的话来说：“一流公司雇用一流的人才；二流公司雇用三流的人才。”
- 决策
  敏捷：决策常常是基于数据做出的。所有一切都用数据来衡量，通过试验不同的做法，最好的解决方案也就显而易见了。
  传统：决策常常是基于管理者的意见做出的。在谷歌，他们倡导远离危险的Hi.P.P.O（Highest Paid Person Opinions的缩写，即拿最高工资的人的意见）。
- 产品开发
  敏捷：只有当预定的业务目标达到之后，工作才算完成。在谷歌，他们称之为“发布后迭代”。尽快把你的产品送到客户手中。收集反馈，衡量效果，快速迭代以做出最好的产品。尽可能避免设定了最后期限的大项目！
  传统：产品开发是通过执行设置了固定的最后期限和范围的大项目来完成的。工作怎么开展通常是预先定义好的，但在项目启动之后，业务目标就会被遗忘，甚至都无法衡量。当产品的第一个版本正式发布之后，项目组也就解散了。