本文正在参与「金石方案 . 分割6万现金大奖」
前语
-
有这么一本书, 计算机学院的大学老师或许推荐过、职场上的长辈或许安利过、豆瓣计算机项目办理类书籍排行榜上或许霸榜过.
-
这本书就是互联网软件相关职业从业人员必读的经典书<<人月神话>>.
-
文章纯手打, 抛砖引玉, 如有过错还请评论区指正, 先行谢过了:)
六千五百万年前, 恐龙这样的巨兽还横行于地球上, 现在出土的许多恐龙化石的成因是因为这些远古巨兽陷入了焦油坑, 拼死挣扎却越陷越深. 作为一线开发人员, 不管你乐意不乐意, 咱们负责的项目, 都面对着类似于困住巨兽的”焦油坑”. 与许多同事一起开发的项目, 随着项目杂乱度的提高, 慢慢地变得很难扩展更新, 当在原有基础上新增功用的投入产出比过低时, 就不得不推倒重来. 这种”焦油坑”不单只出现在软件开发职业, 其他职业的杂乱项目中也有或许发生.
软件项目中的”焦油坑”发生的原因有许多, 其间的一个原因就是程序员的”乐观主义”. 咱们辛辛苦苦写了一段功用代码, 在编译运转快捷键触发之前, 已经在咱们的脑海中过了好几遍, 心里必定乐观的想着, 跑起来必定没问题, 但是往往事与愿违, 各种报错发生了. 这是许多一线开发的日常, 罗永浩星巴克表情包.jpg.
软件项目中的乐观主义不止表现在代码开发中, 项目估时的单位(人/月 或 人/日)自身就是乐观主义的表现. 假如项目出现延期, 一些PM或许就会想着以”人/日”为衡量标准, 多去添加人手, 在DeadLine之前发布. 这种做法可行吗? 可行, 但是有坑! 这种发版往往是各种退让的产品, 添加人手加班加点, 总得有个产出吧. 问题的关键是, 软件开发这种针对杂乱度自身的高级笼统, 往往写代码只占了作业的1/3, 更多的是项目功用梳理、团队交流、处理不断新发生的问题. 这就造成了新增人手或许会带来新的交流问题, 培训了解项目也需求很长的时刻. 慢慢地这种大型项目就好像远古巨兽那样, 陷入了项目上的”焦油坑”.
生活中咱们都渴望民主, 做选择时并不希望被强权控制. 但是这种民主不适用的当地有许多, 比方做手术时, 你是想有一个主刀医师把控大局还是希望一群医师相互讨论? 我想我应该会选择一个主刀医师的”贵族独裁”. 能成为主刀医师自身就代表着经过了无数的手术试炼, 是牢靠的. 同样在软件项目中, 作者认为也需求一个类似于主刀医师这样的”贵族独裁”, 那就是软件职业中的”架构师”. 架构师需求一直跟着项目才能对项目的架构有个详细深入的理解, 架构师应该对一些关键问题做技术把控及拍板决策, 这样就能让项目具有”概念完整性”. 在项目的生命周期中, 文档应该跟着项目一起成长, 每次版别更新都应该对应着文档更新. 好记忆不如烂笔头, 有了一个好的文档体系, 才能让项目开发人员够做到心中有数. 今后面对需求变更, 也能根据文档愈加沉着, 防止把过去做过的功用重复做浪费名贵的人力资源.
“交流”在各种杂乱项目中的效果, 或许比举动落地自身愈加重要. 交流能力并不仅仅一个”软技术”, 一起也是技术能力的一个表现, 因为只有真实能理解一些技术底层, 咱们才能把一件杂乱的事用”简单”的方式”说出来”. 这也就是所谓的”提到点子上”, 抓要点. 在多人协作时, 交流的效果就显得更为重要, 你不但要自己明白, 还要能跟团队伙伴们解释清楚. 人都不是机器, 在团队交流的过程中, 咱们还需求考虑到其时的环境上下文场景, 顺势而为方能事半功倍. 交流的过程中, 咱们能够运用各种东西, 比方说功用”流程图”, 但是流程图的效果在作者看来也不能被一味地神化, 流程图也不是处理项目办理问题中的特效”银弹”. 流程图仅仅方便交流, 并且不能太杂乱, 最好一页纸画清楚.
除了功用流程图咱们还有许多的备选”银弹”, 比方高级语言、OOP(Object Oriented Programming)、POP和高性能的机器, 仅仅处理了软件项目中的次要矛盾. MOP市场驱动开发往往才是咱们面对的实际问题, 咱们开发的项目是给用户运用的. BOP(Boss Oriented Programming)面向老板开发也不能持久. 有没有完美处理软件项目中的”银弹”? 作者的观点是失望的, 没有普适的完美处理方案. 只有适合各个项目的接地气处理方案, 这颗”铜制子弹”, 需求咱们实时的跟进, 定时的弥补, 不断地优化~
发文不易, 喜爱点赞的人更有好运气 :), 定时更新+关注不走失~
ps：欢迎加入笔者18年建立的研究iOS审核及前沿技术的三千人扣群：662339934，坑位有限，备注“网友”可被群管通过~
本文正在参与「金石方案 . 分割6万现金大奖」
