关于软件开发的一些常识和思考

标签: 软件开发 常识 思考 | 发表时间:2013-05-18 11:14 | 作者:
出处:http://kb.cnblogs.com/

   有最好的编程语言吗

  作者的观点:程序员在最初学习BASIC、Fortran、 Pascal、C、C++等语言时会感觉一个比一个好,不免有喜新厌旧之举。而如今的Visual Basic、Delphi、Visual C++、Java等语言各有所长,真的难分优劣。能很好地解决问题的编程语言就是好语言。开发人员应该根据实际情况,选择业界推荐的并且是自己擅长的编程语言来开发软件,才能保证有较好的质量与效率。

  编程是一件自由与快乐的事情,不要发誓忠于某某语言而自寻烦恼。

   编程是一门艺术吗

  作者的观点:水平高到一定程度后,干啥事都能感受到“艺术”,编程也不例外。但在技术行业,人们通常认为“艺术”是随心所欲、不可把握的东西。如果程序员都把编程当成“艺术”来看待,准会把公司老板吓昏过去。

  大部分人开发软件是为了满足客户的需求,而不是为了自己享受。本书(《高质量程序设计指南——C++/C语言》)提倡规范化编程。规范化能够提高质量与效率,最具实用价值,尽管它在一定程度上压抑了“艺术”。编程艺术是人们对高水平程序创作的一种感受,但只可意会,不可言传,不能成为软件公司的一个指导方针。

   编程时应该多使用技巧吗

  作者的观点:就软件开发而言,技巧的优点在于能另辟蹊径地解决一些问题,缺点是技巧并不为人熟知。若在程序中使用太多的技巧,可能会留下错误隐患,别人也难以理解。一个局部的优点对整个系统而言是微小的,而一个错误则可能对整个系统是致命的。我建议用自然的方式编程,不要滥用技巧。我们有时的确不知道自己的得意之举究竟是锦上添花,还是画蛇添足。就像蒸出一笼馒头,在上面插一朵鲜花,本想弄点诗情画意,却让人误以为那是一堆热气腾腾的牛粪。

  小时候读的《狼三则》故事启示我们,失败的技巧被讽刺为“伎俩”。当我们编程时无法判断用的是技巧还是伎俩的情况下,那就少用。《卖油翁》的故事又告诉我们“熟能生巧”,表明技巧是自然而然产生的,不是卖弄出来的。

   换更快的计算机还是换更快的算法

  如果软件运行较慢,是换一台更快的计算机,还是设计一种更快的算法?

  作者的观点:如果开发软件的目的是为了学习或是研究,那么应该设计一种更快的算法。如果该软件已经用于商业,则需谨慎考虑。若换一台更快的计算机能解决问题,则是最快的解决方案。改进算法虽然可以从根本上提高软件的运行速度,但可能引入错误并延误进度。

  技术狂毫无疑问会选择后者,因为他们觉得放弃任何可以优化的机会就等于犯罪。类似的争议还有:是买现成的程序,还是彻底由自己开发?技术人员和商业人士常常会有不同的决策。

   错误是否应该分等级

  微软的一些开发小组将错误分成以下4个等级(Cusumano, P354~P355)。

    一级严重:错误导致软件崩溃。

    二级严重:错误导致一个特性不能运行并且没有替代方案。

    三级严重:错误导致一个特性不能运行但有替代方案。

    四级严重:错误是表面化的或是微小的。

  作者的观点:将错误分等级的好处是便于统计分析,仅此而已。但上述分类带有较重的技术倾向,并不是普遍适用的。假设某个财务软件有两个错误:错误A使该软件死掉,错误B导致工资计算错误。按上述分类,错误A属一级严重,错误B属二级严重。但事实上B要比A严重。工资算多了或者算少了,将会使老板或员工遭受经济损失。而错误A只是使操作员感到厌烦,并没有造成经济损失。再例如航空软件操作手册写错了,按上述分类则属四级严重,但这种错误可能导致机毁人亡,难道还算微小吗?

  开发人员应该意识到:所有的错误都是严重的,不存在微不足道的错误。只有这样才能少犯错误。

   一些错误的观念

   错误观念之一:我们拥有一套讲述如何开发软件的书籍,书中充满了标准与示例,可以帮助我们解决软件开发中遇到的任何问题。

   作者的观点:好的参考书无疑能指导我们的工作。充分利用书籍中的方法、技术和技巧,可以有效地解决软件开发中大量常见的问题。但实践者并不能因此依赖于书籍,这有如下两个原因。

  (1)在现实中,由于工作条件千差万别,即使是相当成熟的软件工程规范,也常常无法套用。

  (2)软件技术日新月异,没有哪一种标准能长盛不衰。祖传秘方在某些领域很吃香,而在软件领域可能意味着落后。

   错误观念之二:我们拥有充足的资源和经费,可以买最好的设备,一定能做出优秀的软件产品。

  作者的观点:大公司经常有这样的心态。良好的开发环境只是产出成果的必要条件,而不是充分条件。如果拥有好环境的是一群庸人或者是一群勾心斗角的聪明人,难保他们不干出南辕北辙的事情。

   错误观念之三:如果进度落后于计划,可以增加更多的程序员来解决问题。

   作者的观点:软件开发不同于传统的农业生产,人多不见得力量大。如果给落后于计划的项目增添新手,可能会更加延误项目,原因如下。

  (1)新手会产生很多新的错误,给项目添麻烦。

  (2)老手向新手解释工作及交流思想都要花费时间,使实际开发时间更少。

  所以精确地制定项目计划很重要,不在乎计划中的进度看起来有多么快,计划要恰如其分。

   错误观念之四:只要干活小心点,就能提高软件的质量。

  作者的观点:软件开发是一种智力创作活动,世上最小心翼翼、最踏实的程序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面(称为质量属性),一定要先搞清楚怎样才能提高质量,才可以在进行需求开发、系统设计、编程、测试时将高质量内建其中。

  软件质量属性之间并非完全独立的,而是互相交织、互相影响的。因此,程序设计中要同时兼顾几个质量属性,使程序达到整体最优。要把质量属性牢记在心,这样才能在程序设计时一次性地编写出高质量的、错误较少的代码来,同时也可以减轻查错和调试的负担。

  经典的软件工程书籍厚得像砖头,或让人望而却步,或让人看了心事重重。请宽恕作者的幼稚,本章试图用聊天、说理的方式来解释软件工程的道理。软件工程的观念、方法和规范都是朴实无华的,平凡之人皆可领会,但只有实实在在地用起来才有价值。我们不可以把软件工程方法看成是诸葛亮的锦囊妙计—在出了问题之后才打开看看,而应该事先预料将要出现的问题,控制每个实践环节,防患于未然。

  研究软件工程永远做不到像理论家那样潇洒:定理证明了,就完事儿。

相关 [软件开发 常识 思考] 推荐:

关于软件开发的一些常识和思考

- - 博客园_知识库
  作者的观点:程序员在最初学习BASIC、Fortran、 Pascal、C、C++等语言时会感觉一个比一个好,不免有喜新厌旧之举. 而如今的Visual Basic、Delphi、Visual C++、Java等语言各有所长,真的难分优劣. 能很好地解决问题的编程语言就是好语言. 开发人员应该根据实际情况,选择业界推荐的并且是自己擅长的编程语言来开发软件,才能保证有较好的质量与效率.

软件开发的核心

- - 博客园_知识库
  「我们一直这样做开发,时间做久了,便忘了当初的本意.   有关软件系统开发,我们谈些什么.   我们谈过程,编码规范、开发流程、同行评审、结对编程、持续集成,从瀑布到敏捷再到极限编程.   我们谈架构,企业级、J2EE、容器化、SOA(面向服务架构)、Microservices(微服务化).   我们谈规模,大容量、高并发、大数据.

[来自iPc.me] 批判中医 – 运用常识正常思考!至于你信不信,反正我不信!

- ji - iPc.me
批判中医,我不是第一人,也不会是最后一个人. 批判中医不是什么有趣的事情,可它却是必须做的事情——总有一些人(比如我)基于这样那样的原因,最终觉得中医必须批判. 批判中医的理由只需要一个:中医常常害人……. [ 请大家更新订阅地址 http://feed.ipc.me ]. iPc.me 猜你可能还会喜欢:20多个值得你一生反复回味与体会的小故事.

软件开发的“三重门”

- - 酷壳 - CoolShell.cn
自从上次写了“ 程序员技术练级攻略” 以来,就觉得似乎还有很多东西没有谈到,但当时没有继续思考了. 而春节前有人问我,是做底层技术,还是做业务. 这问题让我思考了很多,不由自主地回顾了一 下我这十多年的软件开发经历,并顺着整理分类了一下自己解决过的若干问题,还发散想了很多,经过了一个春节假期的发酵,产生了下面这篇文章.

软件开发的人文关怀

- - 博客园_知识库
  几年前,我从温伯格的《技术领导之路》中学到一点:技术人员往往更喜欢和机器打交道,因为他们“认为”自己更适合和机器打交道;但是,优秀的技术人员必须(也必然)具备好的沟通能力. 所以,温伯格鼓励各位技术人员多加练习和其他人打交道的能力. 温伯格的这个观点我是非常赞成的,好的技术人员一定需要“勇敢”面对他人,不能被“自实现的预言”局限在机器的世界里.

软件吞噬软件开发

- - PingWest中文网
软件蚕食世界,自互联网特别是移动互联网连接线上线下服务后,已成为不可逆的趋势. 每一项实用的服务可以由小团队来完成. 以WhatsApp为例,这款被高调收购的IM应用,拥有4.5亿月活跃用户,70%的日活跃率,至今还保持每天新增用户1000万的速度. 但这些服务居然由32名工程师支撑下来了,所以有了业界八卦“每位员工价值20亿”的说法.

软件开发中的两种态度

- - 外刊IT评论网
一种态度认为,应该对程序员在软件开发中的行为进行约束( DirectingAttitude). 持这种态度的人认为大部分的程序员水平都不高(谣传说有50%的人低于平均水平),所以应该对他们所做的事情进行管教约束. 要防止他们做一些可能会给他们正在开发的系统带来危害的事情. 通常,这种态度体现在一些系统设计和工具中时,你会发现它们会试图阻止程序员去做某些事情,限制程序员的一些做法,以此避免他们陷入过于复杂的境况.

软件开发的人文关怀

- - 极客公园-GeekPark
我是极客公园黑板报认证值日生. [核心提示]软件可以没有活力,而软件开发却不能没有活力;程序可以像机器一样,程序员却不能像机器一样. 要改变这种状态,就应当增添更多的人文关怀,把开发人员当成活生生的人,而不是视为程序或者工具. 编辑注记:本文来自余晟的博客 乱象,印记. 作者从自己的经验出发,提出了一些给软件开发人员提供人文关怀的可行措施.

软件开发模型综述

- - CSDN博客推荐文章
                     软件开发模型概述. 最早出现的软件开发模型是1970年W·Royce提出的瀑布模型. 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架. 软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段.

防火长城内的软件开发

- - Solidot
对于软件开发者来说,防火长城不只是屏蔽网站过滤流量这么简单——它是痛苦之源,尤其是如果你想开发针对中国市场之外的软件或想利用广泛使用的服务和软件库的话. 上海聊天机器人创业公司Rikai Labs的创始人DC Collier认为,中国的软件开发者写代码的时候一只手是绑在背后的. 防火长城的屏蔽范围日益扩大,这意味着越来越多的服务被永久性或不定期的屏蔽.