1.软件工作的总论

1.1.代码进化的几个过程

越重要的代码，要求越高。有些代码，能运行即可。有些反复修改和阅读的代码，则最好满足如下四个要求。注意，较高的级别包含低于其级别的要求。

初级：运行。这个是基本要求。即代码的逻辑符合要求。

中级:易读。代码易于阅读理解，在第一个要求的基础上，完善注释、命名、布局等。

高级:性能。代码运行速度快。对于某些对性能要求高的场景，这个很重要。

超高级:精炼。用尽可能少的代码实现想同的功能，包括编程语言的实现形式、算法的选择。

在最初实现，达到初级即可。在以后的维护和迭代中，逐步识别代码的运行维护次数。对于运行次数多的代码，必须达到高级，以保持系统的性能。对于维护次数多的代码，必须满足中级的要求。对于运行和维护次数多高的代码，必须满足超高级的要求。不要一开始将时间浪费在雕琢代码上。如果不分代码的重要性，都按最高级别要求，将大量的时间浪费在雕琢代码上，那就是追求不必要的完美导致效率低下。

1 跑通。

2 结构(按照具体原则和按照需求调整)

3 细节(按照具体原则和按照需求调整)

4 性能

1.2.设计阶段和调试阶段工作分配问题

为什么我们总是在一些低级错误上忙忙碌碌？如何才能避免呢？个人认为主要是一个时间和精力分配的问题。做好一件事情，精力是应该分配在调试阶段，还是设计阶段。这是一个最优化的问题，应该是分配在那个阶段耗费的时间和精力少，就分配在那个阶段。这个需要仔细的权衡，形成一个习惯。肯定的是，不要把时间都分配在调试阶段，因为调试问题，不仅仅涉及到自己，还好涉及别人。而且问题的调试非常的耗费时间和精力。

关于设计与调试的问题。在最近的工作中，发现许多同事调试系统花了好长时间，不禁要思考这个问题。一个重要的问题是如何安排设计和调试的工作问题，也是软件开发计划的一个重要的问题。具体坚持如下。调试是一个没有预期的工作，这导致其无法为其制定计划，同时也给自己的内心造成了很大的压力。所以应该尽量把工作放在设计阶段。坚持如下原则。

1、总体的框架和逻辑应该在设计阶段完成。因为一旦出错，需要修改的代码和逻辑涉及的面太广，调试时需要付出巨大的精力。

2、太细的细节没有必要分配太多的精力。安排精力太多的话，必然耗费大量的精力，得不偿失。

3、做好局部测试(比如单元测试)，让问题在局部解决。因为全局定位问题，非常的耗费时间。

1.3.代码复杂度和性能的权衡问题

代码复杂度和性能的权衡问题。最近遇到一个问题，就是以前的关于网络、打包、发送的代码太复杂了，几乎没有人看懂，是以前的一个人用一个类似网络节点(Node)的代码改写成的，实在是没有必要，因为没有必要太复杂。再者，是跑在多用户系统中，没有必要采用多线程。因为已经导致多个人在这上面耗费大量的精力，包括多个项目经理，浪费了公司大量的人力。从这个事情，可以得出如下结论。

ü  在做决策时，应该从全局思考问题，而非局部。比如以上系统的多线程，如果是但用户，可以加快速度；但如果是多用户，则未必。

ü  在速度和代码可读性上，应该是代码可读性优先。一般而言，如果只有10%或以下的速度收益，则没有必要采用复杂的代码结构。20%以上的速度收益，有必要采用复杂的代码结构。10%~15%为灰色地带。

ü  一般流程为，先将代码整理的可读，然后优化。

1.4.软件开发第一目标:跑通

软件第一目标的思考。软件设计的第一目标永远是跑通，基于如下几点理由。1、只有跑通才能说明其可行性。2、只有跑通下面的工作才具有可验证性，才能以小步快跑的方式完成工作。3、跑通，说明已经将脑力劳动转换为体力劳动。

2.软件设计

2.1.软件设计的整体流程

l  架构设计:根据功能需求，性能需求、和其他需求，划分模块、选择合适的技术、确定各个模块的通信方式。

l  设计模式:选择各个模块的实现模式。

l  架构分析。确定程序的实现结构。

l  模块划分

2.2.软件思考流程

最近学习了思维导图，想到了一个软件思考流程：思维导图→流程图→调用图→架构图。

第一步:思维导图，发散思维，寻找合适的突破点。

第二步:流程图(uml),总结逻辑流程。

第三步:调用图(uml),总结代码模块实现流程。

第四步:架构图(uml),总结整个系统的结构。

2.3.思考问题的正常流程

在日常分析问题时，如何才能将问题思考透彻？应该遵循从简单到复杂，从复杂到简单的顺序。因为只有这样，才能将问题思考透彻。开始的简单，是一种不求理解的简单。最后的简单是将问题简化的简单，是一种可靠的简单。

即从简单到简单的思考流程，得出的结论是经不起推敲的，可能是错误的。

2.4.形象化思维→深刻理解→拓展你的思维

比如用ppt、uml、思维导图，可以将思考流程直观的表达出来。加深对问题的理解，尽而拓展了思维。

最近看了一本<<实用线性代数(图解版)>>的书，突然感到直观理解的重要性。主要基于如下原因。

l  直观理解是真正的理解。非直观理解是死记硬背的理解。

l  直观理解是理论和实践的桥梁。如果不直观理解，理论和实践是不可能相通的。

3.其他

3.1.库的选择顺序

关于库的使用次序，今天看了许多库，比如boost、googletest、ffmpeg。对于共有的模块，如何确定其使用次序。我想应该是c++标准库(STL)->C标准库->Boost库->权威代码代码库(比如OpenCV，ffmpeg等)->系统本身提供的库(与系统相关的库)->非权威的开源库。之所以将系统提供的库排在后面，因为其和系统相关，不具有跨平台的属性。上面的次序只是一个一般次序，具体还是需要具体情况具体分析。除了这个库，还有汇编指令，但这个不能跨平台。

尽可能使用成熟的开源库源码，最好不要使用私人或个人的库。

1、开源库集中了整个社会的智慧。它经过了整个社会人的使用、反馈和完善。

2、有一个团队一直在维护他，让其与时俱进。

3.2.公司研发的深刻反省

l  从简单到复杂。

l  合理评估。

l  先质量后速度。这是做事的一个很重要的原则，因为没有质量的速度是毫无意义的。

3.3.IT技术含量高的工作

算法研究和优化、系统分析和调试、工作计划和跟踪。

3.4.技术工作的三种核心能力

技术工作的三种能力:策划跟踪的能力、解决问题的能力、设计开发能力。有如下想法。

1、策划设计能力的关键是某些关键点的工作走向或整体设计的优化问题。关于关键点的工作走向问题，首先要注重平时的积累，一旦项目失败或有挫折，一定要总结其经验，形成自己的具体的原则。其次是请教专家。

2、软件设计能力，形成良好的软件设计习惯和设立严格的测试基准，尽可能多的把问题聚集在尽可能早的阶段。

标签：精力,总论,代码,理解,问题,软件工程,流程,调试
来源： https://blog.csdn.net/great_sea/article/details/118250140