如果你接受这个观点,那么下面两点也很显然:
软件复杂性有很多不同的管理层次和办法,好的做法可以是这样的:“任何软件项目的 优先都是客户满意度,这是客户期望的函数
换言之,软件复杂性取决于你控制客户期望的水平如何
我只补充一句:
telastyn:
结果就是他他做出来的版本坚如磐石,但是也导致他完成项目的时间比菜鸟还要长
“好、快、省只能3选2”以前你懂得少所以牺牲了“好”,现在你懂得多了却牺牲了“快”
应考虑敏捷方法论而不是瀑布流先交付然后迭代交付此举有助于降低风险和成本
我的建议是用番茄工作法专注于小的时间间隔(番茄),然后为未来的工作/研究分配这些时间段,并且在执行的过程中不断根据事情的优先级进行调整”
简而程序员开发网言之,他的问题已经从“怎么做”变成了“怎么做 /最安全”
[本文编译自:programmers.stackexchange.com]
似乎你加入黑暗面:管理的时候到了
关键是像管理商业债务一样管理好你的技术债务借的钱不够的话就拿不到 的投资回报但是负债太高的话利息会把你压垮
客户期望永远都可以改变且通过协商完成
下面就是精选出来的解决方案:
哪怕你是开发者也无妨:忽略权限和命名冲突的情况下建个临时文件只需5分钟的时间净收益:团队其他成员可以开始依赖此文件的代码编写工作这是不是一个完美的解决方案?当然不是99%呢?95%?90%?这些可能性是存在的
saul:
客户期望必须明示
编程的一个关键是管理并控制好复杂性,这是我的 优深圳黑马程序员先级之一忽略了复杂性管理,要么缺陷频发,要么软件的eta(预计到达时间)急剧增加
sevenseacat:
mouviciel:
zilk说,他自己精通算法、热爱数学,享受复杂项目,专注度也没有问题也许经验是有问题(尽管已经39岁了),所有会害怕犯错,因此导致项目费时所以他在stackexchange上邀请同行帮助他解决这个问题
zilk1988年14岁时就开始编程,此后尝试过几种职业,最终还是在1997年决定成为职业程序员(又称码农),现在已经39岁,对此选择依然无怨无悔
同样是造飞机,f16能飞,航模也能飞,但那能一样吗?
你完成项目并不慢以前你认为自己的菜鸟项目做完了但实际上并没有完你应该把质量卖给客户“公司可以做得更快成本更低,但项目真的完php程序员工作总结成了吗?或者说你愿意花几年的时间找bug吗?”此外,你还应该知道并接受那句老话:“完美是好的敌人”
但是后来他发现一个问题,自己的经验越丰富,完成项目或任务的时间反而越长因为他见过了太多可能会出问题的情况而对选择踌躇比方说,假设他刚想到要写一段写入文件的代码时,电光火石之间他就已经开始担心起下面的一系列的问题:权限、锁定、并发、源自操作、迂回/框架,不同的文件系统、目录中的文件数、可预测的临时文件名、prng(伪随机数生成器)的随机性质量够不够、操作过程中断电怎么办、api怎么写才好理解、文档应该怎么写等等
黑暗面的一切都与现值有关它要考虑的是如何用最小的投入实现 的产出(成本效益分析)商业上的一切事情黑马程序员培训费用都要归结到成本、成功几率、失败几率、潜在回报等问题做好这方面的数学然后采取相应行动
本来我打算把所有建议都摘录出来的,但是考虑到上述的精彩见解足以解决zilk的困惑,并且为了践行这些建议,本文就此打住,感兴趣者可参见完整讨论
你举了一个很好的例子,“直接写”还是“无数的其他考虑”考虑一下,如果有人详尽写下了此二者的需求,双方的功能描述还是一样的吗?
还要问你一个问题:你对技术债务(注:快速解决但会增长后续维护成本的做法)感觉如何?有人认为不应该有技术债务我不同意跟商业一样,技术债务让你可以借到“金钱”和“时间”以便晚点交付某样东西2年做出一个完美解决方案,或者用4个月时间快刀斩乱麻作出客户可以使用并且购买的美国php程序员工资东西,哪一个更好?判断当然要因情况而定,但是大多数情况下如果你要让客户等两年的话,客户可能早就跟竞争对手签约了
dxm:
satish:
本文来源:36氪
我不是要建议你放弃编程变身经理但从你的描述来看你的经验仅限于技术层面写文件这么简单的事情你居然能想到10个方面的问题,稚嫩一点的开发者 是想不出来的这不是什么坏事,但是……
你还可以看看麦当劳理论
似乎你的经验的确不足:)教训:遵守需求即可,不要想其他这样才不会实现不需要的功能