【荐读】三读上古遗迹之《人月神话》

打印 上一主题 下一主题

主题 759|帖子 759|积分 2277



        ##昨夜西风凋碧树。独上高楼,望尽天际路。
        第一次读还是门生的时候,那时候读的很艰难,根本明白不了形貌的情况,那时候还是200年,很多多少人对于这本被很多多少人奉为圣经的书,没有什么详细的感受,仅仅是感叹软件工程领域真是一个令人费解的、匪夷所思的、充满困惑的世界!!!也确定了本身对于这个世界的向往,那个时候接触的第一门编程语言是HTML。(very interesting)
        ##衣带渐宽终不悔,为伊消得人憔悴。
        第二次读的时候已经在读研快结束的时候,那时候接触了导师带的项目,也学习了软件工程,编写了大量的代码,完成了一些工程项目标实践,回头再看这本书的时候,对于一些理念仍然是云里雾里,但是深刻明白了一些项目管理上的事情,作为乙方参与实行的项目确实接触到了一些非量化数据转成量化数据,用来核算月结工资,那个时候还没有详细的折算概念,但是读这本书的时候确实贴合甲方的很多多少事情,一些事情明白起来也就没那么困难,但是困惑的事情依然不少,从这本书出书(1975年)到2015年,这四十年的时间,原书中提到的“高级语言、面向对象、可复用的构件”已经成为默认的毕竟。他们那个时候期许的事情,成了我们这种后来者的出发点。接触的项目也是省科、市科、重点单位互助的类型,接触不到所谓“高端局”。也就是作育了读这本书的时候,很难明白很多多少人对于工程领域内:“没有银弹,没有银弹,没有银弹!!!”,这句话的明白是摸不到头脑的那种……
       ##众里寻他千百度,蓦地回顾,那人却在,灯火阑珊处。
        近来一次读是2022年的春节假期,这一次没有认真的通篇去读,但是很多多少概念很多多少内容也由于随着年岁、知识、阅历、经历的增长,有了很深刻的共鸣。就像之前很多多少人不明白的问题、不明白的答案是一个原理,没有经历过书上形貌的再深刻,再栩栩如生,再发人深省,依然是隔岸观火,雾里看花般的不通透。转过观念过来,作为软件开发工程师,深度参与一个项目,明白需求,估算工时,开发任务,上线运维,解决bug。很多多少人在认真的评估、认真的理论、认真的记录、认真的复盘,认真的总结。唯一错过的是认真的去明白软件工程,谷歌的技术代言人Jeff Dean证明了:“七天能做完的工作,平常的小型的开发团队大概必要几个月的时间来完成!”,这其中的差距为什么会这么大的原因就在这里。像极了我在灵敏认知内里谈到的,一定是见仁见智!
想发一些牢骚:(哈哈哈哈哈!!!)

        期间在发展
        现在,盘算机领域颠末几十年的飞速发展,软硬件都比作者所处的年代有了极大提拔。尤其是硬件资源实现了跨数量级的提拔,更是诞生了云盘算,边缘盘算等。包括AI的发展也让很多很多的场景不再是单一必要考虑资源的问题,原书中提到的“高级语言、面向对象、可复用的构件”也已经成为默认的毕竟。但是不管技术怎么发展,技术仍然是第一生产力,包括近来爆火的ChatGPT也是,以是:
        “在新的期间我们依然面临着新的问题,新的纠结,新的无可怎样!”
        时间未能改变的   
        到现在更快的硬件、更快的网络、更多的盘算、更大的存储资源、更优秀的重用库、更美满的框架、更方便的语言、更先进的头脑、更新颖的管理模式等等一切较之前无法想象的海量资源,以至于我们能够感觉软件工程领域的种种问题可以迎刃而解,最次也是新的问题来困扰我们了。然而毕竟上:


  • 我们依然无法正确评估工作量
  • 我们依旧难以进行公道的进度安排
  • 项目落后时,只能被动的延伸工作时间大概增加人力。
  • 大量的bug反复出现
  • 开发的软件不能让用户满意,甚至用户仅仅使用软件极少的功能。
  • 大量的软件项目以失败告终。
        这些作者其时形貌出来的问题,到了现在仍然无法解决,大量存在,是几十年没有什么发展吗?还是软件工程的根本问题没有有用解决呢?
        “不消妄自菲薄,这些软件项目标问题是普遍存在的,不要对本身的本领产生猜疑”
        “众多前辈已经总结了大量软件项目标问题和解决方案,而且经历了时间的考验。我们应该刚强的学习掌握,同时在实际工作中运用、改善,从而形成行业规则,告竣行业共识。如许才能推动软件行业不停发展。”
         唯一不变的就是变化
        软件领域的名言:“唯一不变的就是变化本身”,潜台词就是“其他都会发生变化”。变化意味着不可预料、不可提前预备、预备好的大概徒劳、不可控。 比方:


  • 用户不会在初期提供明白的需求,用户的实际必要和用户的感觉会随着程序的构建、测试和使用而变化;
  • 软件开发和运行过程中的环境不一定一致甚至运行环境本身也在变化;
  • 计划职员在软件开发完成之后才能意识到计划上的缺陷,从而试图在下一个版本中补充;
  • 团队成员由于各种因素(私人的大概公司的)发生变化,甚至于核心成员发生变化大概直接导致软件推翻重来; 
        “软件的变化是不可避免的,以是软件行业也由“控制变化”转变为“拥抱变化”,既然变化是不可避免的,那么就以最快的速度去相应变化。这不是就会灵敏吗?哈哈哈”
        时间在迟钝流失
        《人月神话》中提到:“一天一天的进度落后比庞大灾难更难以识别,不易防范,更加难以补充”。而在实际的项目过程中,更多的时间是浪费的,某天关键人物请假了,延误一天;某天服务器资源申请没到位,延长个两三天;某天公司网络出问题了,停格半天;忽然的某种会议,全员参与,浪费半天等等,也许你会说加加班就赶返来了,但真的能赶返来吗?这种还只是加班能挽回的吗?
        “慢性的进度偏离绝对是士气杀手”
        直到有一天,项目到了时间,才发现“时间都去哪儿”?甩锅的时候到了!!!
        预测
        在软件工程领域,大家在靠近50多年前就提出了高屋建瓴的头脑,我们应该看的更远一些。以是在一样平常的工作中我们要严格要求本身,提高本身的追求,将眼光放久远,有些小小的提倡,与看到此处的屏幕前的共勉:
        总则:小处着手,大处着眼。   
        第一:不要重复出现已知得的缺陷。
        第二:持续不停的学习相关的知识和履历。
        第三:思考和使用公道的解决方案。
        第四:正确认识新的问题和现象。
        第五:努力积累形成属于我们期间特色的头脑和履历。
        终身学习!!!吾辈当自强!!!

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

大连密封材料

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表