至简李云-51CTO博客

至简李云

295W+
人气
184
文章
0
关注
164
粉丝

博客之星
专家博主

关注私信

原创 184
翻译 0
转载 0
评论 1610
点赞 816

全部

原创
软件产品的可使用性设计 - 塑造概念
0

最近所做的一个项目与命令行配置有关，简单地说我们的产品能采用输入命令的方式对其功能进行配置，这一点与Cisco路由器的配置很相似。在产品的开发过程中，美国的同事提出一种设计思路，即所有的配置命令之间都不应当存在依赖关系。提出这种设计思路的同事，其初衷在于让用户能更加容易地对产品进行配置。但是，这种设计思

李云发布于：2010-08-12

阅读 962

评论 3

收藏 0
原创
无能的很可能正是我们自己荐
6

现实工作中，存在不少情形让我们觉得身处混乱使得工作应付不过来。最为常见的现象有：工作量太大、人力资源不足、沟通不畅等等。对于混乱状态的出现也存在不同的解释，比如： 1) 我的领导无能。有这种思想的人会认为：因为我的领导无能，造成向他人做了不应当做的承诺，最后导致过多的工作量。 2) 公司没有钱。有这种思想的人则认为

李云发布于：2010-07-27

阅读 8622

评论 22

收藏 1
原创
[错误处理原则] 明确职责
0

错误处理很重要的另一个原则是，明确模块的职责。明确职责的目的在于分清所出现的错误将由哪一个模块去处理（比如，很多情形下需要写错误日志），从而避免同一个错误却被多个模块处理，进而产生大量的冗余。现在假设需要设计一个专用于TCP套接字（socket）通信的框架（后面简称框架），这个框架的目的是向上层应用程序提供对套接字的封

李云发布于：2010-06-29

阅读 1008

评论 0

收藏 0
原创
软件设计中的“自上而下”和“自下而上” 荐
0

在切入主题之前先要了解“上”与“下”的含意是什么，这需要从图1中找答案。图中，应用层在最上面，其下依次是框架、平台、库和操作系统层，因此“上”是指靠近应用层，而“下”则是指靠近操作系统层。图1 对于一个被设计的软件模块，存在两个视角。一个是从上

李云发布于：2010-06-26

阅读 6631

评论 3

收藏 0
原创
出色技术团队的关键要素荐
0

对于出色技术团队的关键要素可以从下图中找到。下面让我来对其进行解读。这幅图首先映入眼帘的是，它是一个三角形，而其顶点则是求精。求精离不开下面三个要素的支持，即分享、责任和合作。求精应是技术团队所追求的最高目标，只有拥有求精的精神，团队的技能才能得到逐步的提高，也只有求精的精神，团队的长远工作和生活质量才会更好。要做到求精离不开学习，否则求精只能是口号；要做到精一定会出现困难，而

李云发布于：2010-06-18

阅读 2397

评论 9

收藏 0
原创
[设计原则] 防止他人犯错荐
0

在进行软件设计时，并不能一味地站在设计者的角度去思考，而是同时需要站在模块使用者的角度去思考。设计者通常容易对自己所设计模块的使用者进行一定的使用假设，且假设使用者是完全沿着自己的设计思路去使用模块的，这种假设在现实生活中通常表现得很是脆弱，问题的发生往往就是出现在模块的使用者打破了设计者原有的假设。很有可能模块的使用者正是模块的设计者本人，在这种情形下，设

李云发布于：2010-06-16

阅读 1486

评论 2

收藏 0
原创
技术管理的核心内容 - 提高团队技能荐
3

最近与同事聊天，从软件质量保证的方法论谈论到了技术管理。技术管理的内涵到底是什么？在此通过这篇文章做一个小小的总结和适当的外延。技术管理给人的感觉更多是工作量评估、项目计划、项目进度跟踪等，但这只是技术管理工作的一部分。大体上，可以将技术管理分为两个纬度，如图1所示。图1 纬度之一就是项目管理，其中包括项目计划、风险管理、预算管理等。对于基层技术管理者，更多涉及

李云发布于：2010-06-13

阅读 8616

评论 4

收藏 0
原创
走出软件质量困境的指导性思想荐
0

对于软件行业的从业人员，不论是管理者还是工程师，对于软件设计的重要性都应当有允分的认识，只有这样才有可能在团队中构建真正有意义的愿景。是的，具备出色软件设计能力的工程师少之又少，但这并不表明它不重要。相反，这种人的工作效能很有可能是普通工程师的百倍。除了认识软件设计的重要性，整个团队还应当至力于打造适合的质量保证方法论

李云发布于：2010-06-10

阅读 1405

评论 1

收藏 0
原创
建立软件质量保证方法论的核心手段 — 要素有形化和无缝整合荐
0

在软件质量保证的关键要素中，大体上可以将其分为有形的和无形的两大类。是否有形，是指能否通过一定具体的方法来保证。比如，设计能力和编程好习惯一开始就不是一种有形的要素，而工具、文档却是有形的。诚然，无形的东西也有可以通过一定的方法将其有形化。如果将好的设计思想（设计原则）和编程习惯通过文档将其固化，并在项目组中广泛学习和实践，就有可能将无形的变为更具有形性。强调有形和无形的目的在于指出其可操作性，一

李云发布于：2010-06-07

阅读 1544

评论 4

收藏 0
原创
软件质量保证需要系统性的方法论荐
0

软件质量保证是一个非常复杂的系统工程，高质量的软件获得不可能通过只做好软件开发活动中的某一个或某几个环节而获得，当然更不可能在没有任何方法的情形下“意外地”获得高质量，除非软件的规模非常小，且所有的开发工作是由一、二个人完成的。方法论 = 流程 + 工具经验告诉我们，对于复杂的问题应当通过分而治之的方式去解决，这同样适用于质

李云发布于：2010-06-02

阅读 2476

评论 2

收藏 0
原创
保证软件质量的关键要素荐
0

软件在没有发布之前的开发过程主要分为需求分析、设计、编码和验证四个阶段，最终的软件质量与这四个阶段的各自质量之间的关系如果用C语言来表达的话应当是：最终的软件质量 = 需求分析质量 && 设计质量 && 编码质量 && 验证质量即，最终的质量来自于各阶段质量之“与”，只要其中一个环节质量是差，则产品的整体质量都

李云发布于：2010-05-28

阅读 5588

评论 1

收藏 0
原创
理解软件开发的特点 - 软件质量保证的第一步荐
1

与软件开发过程中产品从无到有的创造所带来的兴奋与有趣相比，软件质量保证更多地让人觉得沉闷和枯燥。相比之下，软件开发过程中的需求分析、设计和编码是一个相对容易做的事，因为在这些过程中如果出现差错，工程师都觉得有劲可使以进行弥补，这些过程中的错误更多地表现为“明枪”。软件质量保证则不然，往往很容易出现有劲使不出，乃至怎么也做不好，其更多地表现为“暗箭”。之所以会

李云发布于：2010-05-27

阅读 3715

评论 4

收藏 0
原创
[设计原则] 以人为本
0

在《什么是软件设计》一文中指出，软件设计应当是一个创造模型的过程。那软件世界中的模型其原型源于何处呢？来源于现实世界！这与“以人为本”设计原则又有什么关系呢？设计出来的软件除了达到其所应满足的需求外，其很重要的另一个功能是它能向他人传达设计者的设计意图，毕竟一个设计不可能永远地由一个人去维护。在绝大多数的情形下需要多人

李云发布于：2010-04-09

阅读 1245

评论 2

收藏 0
原创
【编程好习惯】永远将头文件作为定义和引用的桥梁
1

在现实项目中，有时为了省事在引用一个变量或函数时，会直接采用extern关键定在.c文件中进行声明。图1中reference.c的第3行是对一个变量采用extern关键字进行声明，图2中reference.c的第1行则是对一个函数采用extern关键字进行声明。define.c00001: char g_name [] = {’Y’, ’u’, ’n’, ’\0’};reference.c0000

李云发布于：2010-04-06

阅读 1647

评论 1

收藏 0
原创
[设计原则] 保护自己荐
0

软件开发中的保护自己不是指个人行为上的自我保护，而是指防犯别的模块的错误却最终表现在我所设计的模块上。当某一模块出现错误时，毫无疑问大多情形下模块的作者将会被“招见”。出现软件错误是正常的，但最为郁闷的是最后发现错误是别的模块误用而引起的。偶而这种情形的发生是可以理解的，但是如果这种事情是家常便饭，则需要考虑通过设计来“保护自己”。提出“保护自己

李云发布于：2010-04-01

阅读 1655

评论 7

收藏 0
原创
如何提高设计能力？荐
1

要提高设计能力首先需要对软件设计有着精神上的追求，即在软件开发的过程中追求设计的完美性。梦想之所以有可能成为现实，是因为我们会去“想”并为之努力，软件设计能力的获得也不例外。设计能力的获得并不会因为不去追求而“不小心”获得且水平很高。具备软件设计追求的人，会在设计的第一时间积极思考以试图找到更优实现，也会随着产品的演变而反思是否存在更好的设计，或者在必要的时

李云发布于：2010-03-10

阅读 6063

评论 16

收藏 0
原创
[设计原则] 为模块设计统计信息荐
0

设计的过程可以存在依靠感觉去把握，但是最终软件产品哪个地方存在不足，或者在用户那运行的状态如何，乃至一种错误的出现其根源是什么等等，就不能完全依靠感觉去行事了。对于这些问题的分析是需要思考，但最终哪一种思考是正确的或更具可能性却需要让数据来说话，为模块设计统计信息的目的就在于此。现实世界的复杂也反映在了软件的设计上，软

李云发布于：2010-03-08

阅读 1516

评论 1

收藏 0
原创
【编程好习惯】让模块的对外头文件保持简洁
0

从“精确包含头文件”（参见《精确包含头文件》）这一编程好习惯中可以得到另外一个好习惯，那就是就是尽可能保证模块的对外头文件简浩。通常的编程习惯是将所有的数据结构都放在头文件中，且这个头文件也包含模块接口函数的原型声明，图1就是一个例子。请注意其中的62~69行所定义的bucket_t结构，这一结构是模块的内部数据结构，也就是说从模块的外部

李云发布于：2010-03-04

阅读 1580

评论 2

收藏 0
原创
阻碍改善设计的常见观念荐
0

既然软件设计如此重要，那么忽视它就是一种战略短视行为。软件工程师最重要的工作内容理应是进行真正的、创造性的软件设计，而不是只忙于简单地修补漏洞。漏洞是得补，但得补得有艺术、有深度，而不是头痛冶头、脚痛冶脚地补。那种没有深度的修补方式注定是在为将来埋下更大的定时炸弹，也可以预见未来的软件维护工作将愈加的困难。 &nb

李云发布于：2010-02-25

阅读 1737

评论 5

收藏 0
原创
[设计原则] 为模块设计初始化和终止化函数荐
0

在软件行业，模块化编程早已深入人心，通过模块的划分能有效地减小软件系统的复杂度，模块化其实就是将系统“分而治之”的方法。在嵌入式系统中，每一个模块存在初始化函数相对比较的普遍，但是并不是每一个模块都存在一个终止化函数，相反，有可能整个系统根本就没有终止化函数。之所以出现这种现象，这与嵌入式系统的特点有关。与桌面系统上的软件不同的是，由于整个嵌入式设备就只有一个

李云发布于：2010-02-24

阅读 2373

评论 8

收藏 0
原创
【编程好习惯】只暴露必要的变量和函数
0

在设计一个软件模块时，应当做到尽可能少地暴露只在模块内部使用的变量和函数，这可以通过使用static关键字做到。当一个内部变量或函数并没有被声明成static的话，那意味着所设计的模块存在“洞”。通过这些“洞”其它的模块可以窥视到模块的内部实现，或通过这些“洞”影响模块的内部行为，而后者更加的可怕。理论上，一个模块不应当暴露任何一个内部变量，除非因为不可避免的某种因素，否则都应当通过提供函数接口的

李云发布于：2010-02-21

阅读 1312

评论 2

收藏 0
原创
[设计原则] 重视自己的设计感觉荐
0

人天生就是审美家，软件工程师在设计和编写程序时这种天性会自然的发挥作用，但其作用很有可能被忽视。笔者在做软件设计时，会不时出现让自己也觉得别扭的情形，在这种情形下笔者知道是审美的天性在发出告警，“Hey，man！这样的设计好象不是很好哦！”。一旦出现“审美告警”，笔者通常都是停下手中的工作，去与同事聊聊天、或是倒杯水喝什么的。当然，虽然在做别的事，但脑中还是会

李云发布于：2010-02-10

阅读 1317

评论 5

收藏 0
原创
【编程好习惯】精确包含头文件荐
1

请注意这里用的是“精确”而不是“正确”，之所以不说正确，那是因为如果头文件没有被正确地包含的话，编译器是不会生成最终的目标代码的。那用精确一词想表达除正确之外的什么意思呢？包含两层意思。第一层意思是，只包含必需的头文件。图1是一个简单的示例程序，先让我们假设这个文件只有foo()一个函数的实现，在foo()函数中也只有简单的一行打印语句。我们知道printf()函数的原型声明来源于标准库的stdi

李云发布于：2010-02-08

阅读 8726

评论 9

收藏 0
原创
[设计原则] 好命名胜于任何注释荐
0

设计软件除了从思想上要把握其结构，在实现上也得费番心思，比如变量与函数的命名就位列其中，毕竟程序是设计思想的物质外壳，再好的思想必须通过最后的程序代码去体现。命名的重要性如同写文章时的用词和语句的组织，一篇好的文章除了注意用词，还得将文章组织得“行云流水”，为程序命名也如此。现在通过一个例子来说明命名的重要性，假设要为双向链表（Double-Linked List，简称dll）设计一个函数，这个函

李云发布于：2010-02-05

阅读 2431

评论 5

收藏 0
原创
【编程好习惯】青睐小粒度锁荐
0

在多任务环境中，不可避免的需要用到锁以防止竞争问题，锁可以用mutex或直接开关中断等方式来实现。当对关键代码或数据进行访问之前需要上锁，然后在使用完了以后则需要解锁。作为一个好习惯，应当使上锁的粒度及可能的小。对于图1的代码，timer_init()函数在对_handler数据结构进行初始化之前，在123行先进行上锁操作，在完成了数据结构的初始化之后，则在145行进行解锁操作。这段代码在功能上没

李云发布于：2010-02-03

阅读 1767

评论 1

收藏 0
原创
[设计原则] 通过机制解决问题荐
0

设计并不只是存在于全新项目的开始阶段，而可能存在于软件生命周期的任何一个时间点。软件是注定要出错的，这是因为人的大脑在思考时存在局限性，或许也是源于“内存不足”。当一个问题出现了以后，在寻求解决方案时大致存在两类解决方案。第一种就是“头痛治头，脚痛治脚”，即只针对这单个问题去设计解决方法。第二种方案则是采用设计

李云发布于：2010-01-31

阅读 1797

评论 2

收藏 0
原创
让我们拥有“改变”的心态和勇气荐
0

或许每一种工作只要时间做长了的话，就会变得不那么带劲，那怕是“很具创造性的”软件行业也不例外，工作一旦无趣那就意味着难以从工作中获得快乐和成就感，这将带来诸多负面影响。或许每天早上一想到上班就是一阵紧张；或许失去自己曾经在工作中坚持的原则从而变得对工作不负责任；也或许想到“另谋高就”；等等。然而，改变有助于让工作变得更加有趣。拿软件测试为例吧，如果每天只是机械地进行人工操作，那自然时间长了就无聊了

李云发布于：2010-01-29

阅读 1757

评论 4

收藏 0
原创
【编程好习惯】借助隐式初始化简化程序逻辑荐
1

在图1中示例了三个API的原型，分别是mprotector_init()、mprotector_fini()和mprotector_section_add()。假设mprotector_section_add()将会被多个任务调用以用于初始化各任务相关的一些数据，但是在mprotector_section_add()被调用之前，必需保证mprotector_init()已经被执行过了且只能执行一次

李云发布于：2010-01-27

阅读 2293

评论 3

收藏 0
原创
定时器管理
5

通过本文你将了解 1）定时器的具体实现是怎样的。 2）什么是中断回调定时器。 3）什么是任务回调定时器。 4）实现中断回调定时器的回调函数时应当注意什么。 ...请打开附件阅读全文。

李云发布于：2010-01-26

阅读 2553

评论 17

收藏 0
原创
[软件错误处理原则] 局部问题缩小，全局问题放大荐
0

当一个错误出现以后，如果发现它是一个局部错误那应当采用缩小处理的原则；反之，如果是一个全局错误，那应当采用放大处理的原则。什么是局部和全局错误呢？局部错误就是错误的发生只影响系统的一部分，其它同类功能还能使用；反之，全局错误的出现将导致整个系统不能正常工作。这需要通过更为具体一点的例子来探讨，在此我们拿一个WiMAX系统的

李云发布于：2010-01-25

阅读 1834

评论 1

收藏 0

首页
上一页
1
2
3
4
5
6
7
下一页
末页
共184条记录

李云

分享到朋友圈

这个家伙比较懒，还没有个人介绍

关注技术：C/C++ 嵌入式开发
入住博客：2009-06-20 11.6年

七日热门: ITIL 4：服务目录管理; golang 发送post请求其body中json对象使用变量作为value; 【编测编学】接口测试面试题必背（上）; 100道Java并发和多线程基础面试题大集合（含解答），这波面试稳了~; IDA调试修改内存数据

最新文章: 中国软件开发工程师之痛; 聊一聊工程师思维; 『细节』是什么; 打造高质效的技术团队 —— 酝酿篇; 打造高质效的技术团队 —— 混乱篇

最新评论: 『细节』是什么

春江一条鱼：“另一类则他认为没有必要，你得花大量的时间做说服工作，即便全团队（除他）都已认定的事他仍能固执己见，交互过程低效而无趣”，这种情况还好，只是一两个人。如果是整个团队大部分人都是认为没必要，都是阿猫阿狗随意而为，认为我有我自己的习惯，这才可怕，不仅与类人交互过程低效而无趣，整个工作也是无趣，然而你换了工作，发现周遭环境差不多，尤其二三线。至于“低效”不太好说，反正最后项目是能跑起来的，解决问题速度也是很快速的，本来大部分业务类东西就没多大技术成分。由衷希望和高素质人结伴为伍共事，退而只能独善其身。; 打造高质效的技术团队 —— 酝酿篇

callme_friend：李云大牛你好：|@| 好久没跟你联系了，自从《专业嵌入式软件开发》这本书后，一直在等你的下本大作，可惜等的花都谢了，你又去了淘宝啊~~~~|@| 现在工作两年了，我一直在从事嵌入式linux开发工作，在一个研究所里，管理较分散，所以我硬件、软件、内核驱动、应用软件都有做。最吸引我的有两方面：（1）linux内核；（2）软件的架构设计能力。|@| 在linux内核方面，不知不觉中，本人突然开窍了，以前看着头大的内核代码，现在慢慢能顺畅看下去，甚是欣喜；但对于一个具体项目开发，如何做好合适的“需求分析“和”架构设计“，我一直不得要领。对于软件架构设计能力提升方面，想听听李云大牛的建议。或者有好的相关培训机构推荐吗？; 打造高质效的技术团队 —— 混乱篇

ebuffalo：没想到大牛一开始也只是做做“界面编程”，只是一个基层的码农。; 【人在职场】能力与价值

duhaiying：楼主老师讲的很精彩，大家的评论也精彩。; 打造敏捷的自组织团队

lxl459735：见解很赞！学习了。

最近来访