iOS老司机聊聊实际项目开发中的<<人月神话>>

本文正在参加「金石计划 . 瓜分6万现金大奖」

前言

• 有这么一本书, 计算机学院的大学老师可能推荐过、职场上的前辈可能安利过、豆瓣计算机项目管理类书籍排行榜上可能霸榜过.
• 这本书就是互联网软件相关行业从业人员必读的经典书<<人月神话>>.

• 文章纯手打, 抛砖引玉, 如有错误还请评论区指正, 先行谢过了:)

  六千五百万年前, 恐龙这样的巨兽还横行于地球上, 现在出土的很多恐龙化石的成因是因为这些远古巨兽陷入了焦油坑, 拼死挣扎却越陷越深. 作为一线开发人员, 不论你愿意不愿意, 我们负责的项目, 都面临着类似于困住巨兽的"焦油坑". 与很多同事一起开发的项目, 随着项目复杂度的提升, 慢慢地变得很难扩展更新, 当在原有基础上新增功能的投入产出比过低时, 就不得不推倒重来. 这种"焦油坑"不单只出现在软件开发行业, 其他行业的复杂项目中也有可能发生.

  软件项目中的"焦油坑"产生的原因有很多, 其中的一个原因就是程序员的"乐观主义". 我们辛辛苦苦写了一段功能代码, 在编译运行快捷键触发之前, 已经在我们的脑海中过了好几遍, 内心肯定乐观的想着, 跑起来肯定没问题, 但是往往事与愿违, 各种报错产生了. 这是很多一线开发的日常, 罗永浩星巴克表情包.jpg.

  软件项目中的乐观主义不止体现在代码开发中, 项目估时的单位(人/月 或 人/日)本身就是乐观主义的体现. 如果项目出现延期, 一些PM可能就会想着以"人/日"为衡量标准, 多去增加人手, 在DeadLine之前发布. 这种做法可行吗? 可行, 但是有坑! 这种发版往往是各种妥协的产物, 增加人手加班加点, 总得有个产出吧. 问题的关键是, 软件开发这种针对复杂度本身的高级抽象, 往往写代码只占了工作的1/3, 更多的是项目功能梳理、团队沟通、解决不断新产生的问题. 这就造成了新增人手可能会带来新的沟通问题, 培训熟悉项目也需要很长的时间. 慢慢地这种大型项目就如同远古巨兽那样, 陷入了项目上的"焦油坑".

  生活中我们都渴望民主, 做抉择时并不希望被强权控制. 但是这种民主不适用的地方有很多, 比如做手术时, 你是想有一个主刀医生把控全局还是希望一群医生相互讨论? 我想我应该会选择一个主刀医生的"贵族专制". 能成为主刀医生本身就代表着经过了无数的手术试炼, 是可靠的. 同样在软件项目中, 作者认为也需要一个类似于主刀医生这样的"贵族专制", 那就是软件行业中的"架构师". 架构师需要一直跟着项目才能对项目的架构有个具体深入的理解, 架构师应该对一些关键问题做技术把控及拍板决策, 这样就能让项目拥有"概念完整性". 在项目的生命周期中, 文档应该跟着项目一起成长, 每次版本更新都应该对应着文档更新. 好记性不如烂笔头, 有了一个好的文档体系, 才能让项目开发人员够做到心中有数. 以后面对需求变更, 也能根据文档更加从容, 避免把过去做过的功能重复做浪费宝贵的人力资源.

  "沟通"在各种复杂项目中的作用, 可能比行动落地本身更加重要. 沟通能力并不只是一个"软技能", 同时也是技术能力的一个体现, 因为只有真正能理解一些技术底层, 我们才能把一件复杂的事用"简单"的方式"说出来". 这也就是所谓的"说到点子上", 抓重点. 在多人合作时, 沟通的作用就显得更为重要, 你不但要自己明白, 还要能跟团队伙伴们解释清楚. 人都不是机器, 在团队沟通的过程中, 我们还需要考虑到当时的环境上下文场景, 顺势而为方能事半功倍. 沟通的过程中, 我们可以利用各种工具, 比如说功能"流程图", 但是流程图的作用在作者看来也不能被一味地神化, 流程图也不是解决项目管理问题中的特效"银弹". 流程图只是方便沟通, 并且不能太复杂, 最好一页纸画清楚.

  除了功能流程图我们还有很多的备选"银弹", 比如高级语言、OOP(Object Oriented Programming)、POP和高性能的机器, 只是解决了软件项目中的次要矛盾. MOP市场驱动开发往往才是我们面临的实际问题, 我们开发的项目是给用户使用的. BOP(Boss Oriented Programming)面向老板开发也不能长久. 有没有完美解决软件项目中的"银弹"? 作者的观点是悲观的, 没有普适的完美解决方案. 只有适合各个项目的接地气解决方案, 这颗"铜制子弹", 需要我们实时的跟进, 定期的补充, 不断地优化~

发文不易, 喜欢点赞的人更有好运气👍 :), 定期更新+关注不迷路~

ps：欢迎加入笔者18年建立的研究iOS审核及前沿技术的三千人扣群：662339934，坑位有限，备注“掘金网友”可被群管通过~

本文正在参加「金石计划 . 瓜分6万现金大奖」