>你的一句玩笑话、我却当了真,疼到现在。
曾经看过一个案子一款较为成功的软件在开发推出市场后反响不错但原产品负责人离职后问题就显现出来更新的版本总是延期而且越来越慢在追问下CTO却是这样回答的产品的代码太复杂结构不好耦合太紧架构设计完全错误用户界面和核心逻辑代码混杂在一起每当修复一个bug或者作出一些修改时其他部分就像被病毒感染那样受到影响
也就是说每次更新都会引起新的问题bug此起彼伏新版本成为人们心头的鸡肋不更新用户抱怨更新吧可能永远失去用户这一切都因为开发时混乱的代码造成的一个好的软件不但是能够投入市场获得认可更难能可贵的是软件应该有持续性可以进步可以运维而非迅速占领市场后就后继无力问题百出
像这种真正投入到工作才了解到的需要注意的事项很多培训学校并不会告诉你但是负责任的学校具有项目技术开发经验的专业教师却能把这些经验融入到培训课程当中让你培训出来时便知道软件开发中的难点需要注意的点妥妥一个工作刚上岗就很快适应了遇到的各种难题
好了那到底软件开发当中程序员还会遇到哪些难题让我们稍微说一下
许多培训中的学员开始尝试写代码往往会遇到一个问题如果代码出现问题需要重写吗这么说吧培训中练习的代码并不复杂重写并没有什么关系而对于自己写的代码知道逻辑修改起来也不难但在实际工作中遇上大项目重写代码可是一件需要慎重的事情
重写得出来的结果真的如你所愿吗当你选择抛弃一个软件的知识和已经收集到的错误和修复时同样的错误很可能也会出现在你的新代码当中甚至你会犯下旧版本中的大部分错误并带来一些新的错误
我知道很多程序员看别人写的代码很痛苦心里总有一个念头让你不要看快扔掉但重写代码比起你重新整理那一堆混乱的代码还要痛苦bug层出不穷你就像面对着一只自己制造出来的怪兽看到它要毁坏村庄却又无可奈何时间方面更值得考量当你用上一年时间重写代码时你确定你的软件还会再次受欢迎吗所以没有完善的重写计划不要轻易重写代码
理工科的人通常心比较大做事不很仔细但做开发人员却需要心细譬如开发合同的订立无论是合理不合理的你想新增或者去掉某些功能等等不可以随意按照自己的意愿去行事必须按照合同办事确实需要改变时协商更改条约再拟定新合同或者增加补充合同
为什么这么严谨合同需要对未来几个月或者几年做出明确的说明范围内容责任费用阶段付费付费形式等等都需要一清二楚白纸黑字的才好开展工作合同不明确这是成为将来合作不愉快的导火线
有些程序员遇到技术难题一头热相信自己总能克服但是时间不等人更加可行的方法是疑难外包记得有人在做项目中遇到了wcf配置相关的问题多方尝试都无法搞定甚至在解决问题过程中有遇到新问题最终不得不请求外援结果是外援专家两个小时就搞定了最后支付了五百元的辛苦钱皆大欢喜
我们相信问题早晚是可以得到解决的但如果有一定数量的用户时间就必须分秒必争否则失去了信誉后怎么更新怎么完备的功能都无济于事了
程序员在开项目会议时通常会讨论到一个问题那就是让你发表想法如何看待某个软件组件应不应该购买面对这样的问题你不需要慌张这就需要计算时间成本例如开发人员的工资加上公司运营费用房租水电测试成本等等需要多长时间来开发如果购置了这个软件组件时间成本会降到多少如此衡量利害得失就自然出来了
往往购买了新组件的项目团队因为把更多心思用在细处和实处出来的产品可能会更优质一些
其实作为软件开发的程序员还需知道更多实际工作中的门路懂得如何权衡利弊才能在职场上站稳脚跟所以如果选择具有开发项目背景的培训机构老师或多或少会把这些要点带进去一并告知如此一来对于学习软件开发的初学者来说甚好