作为一个有一定持续周期的项目，开发一般都是按一定的计划，逐渐开发的。
开发的计划肯定是根据实际的用途和紧迫性来定的，但我建议，开发计划要有条理。
要分清主次，确定做到什么程度。一个一个开发，不要多面开花，狗熊掰玉米。不要一个目标没完成就开发其他的，然后都留下bug，互相叠加，玩bug叠叠乐，引爆大烟花。
做开发不要拍脑袋，拍脑袋开发的结果大家都享受过，知道是一个怎么样酸爽的节奏。
具体来说，个人建议。
除开紧急修复(mud的突然更新）
机器人建议还是分为一个一个子计划。
每个计划有 研判阶段，开发阶段，试用阶段，稳定性测试阶段。
在确保当前计划足够稳定后，再开始新的一轮开发。
千万不要老计划的bug还没修完，就开始新的计划！
千万不要老计划的bug还没修完，就开始新的计划！
千万不要老计划的bug还没修完，就开始新的计划！
重要的话说三遍。
喜新厌旧，老计划不收口就开新计划，在我的经验里是开发大忌。
很容易导致整个项目失控，你自己修复不了，别人也没办法接手。
做计划时也要有可行的目标，不要好大喜功，贪多食不烂。
合理的划分目标，把一个大目标分为几个阶段，分别能在合适的时间内收口，才是比较符合逻辑的开发方式。
别说写代码了，就算追女生也不带随意乱夸口的不是……
9.对代码要保持敬畏（内含马屁）
开头说过，一个代码项目，足够复杂的话，甚至能类似一个生命体。
说难听点，就是屎山跳舞，而且这个屎山吧，可能时沉在海里的屎山一角，掏出来比航母还大。
所以，对于项目，建议要保持一定的敬畏。
ina有句名言“All老师你会么？”
All老师会吗？
看看news,看看论坛，All老师当然会。
你不服?那看看all老师cut你的时候剑利不利?
在这里我必须要称赞All老师一下，All老师的“不会”，才是真正的会，是对代码敬畏。
会，只是说能看懂代码，看懂逻辑。
不会，针对的是业务。不确定业务逻辑，不确定业务这样写的背景，不确定是否会有上下游关系。
会改代码易，会调业务难。
正经的有经验的程序员，遇到线上/实际的代码出现问题，也不会大大咧咧的说这个我会，直接去改。
而是在保留现场，同时避免问题造成更大的破坏的前提下。
逐步分析问题，了解业务逻辑，和实际主持的 人沟通，确保在最小范围内做改动，波及面最小，从根本上解决了问题。
不然迟早演变成“删库跑路”的问题。
所以，我觉得，在写代码时，大家应该忘记下意识的“这有啥难”的自以为是。
先对自己说一句
“这个，我不会”
今晚，我们都是All老师。
本帖最后由 jarlyyn 于 2024-4-24 04:54 PM 编辑
10.对代码要有基本的责任感和感情。
写代码，一般来说，有两种人。
1.混饭吃
2.找乐子
对于混饭吃的代码，只要对得起工资就行，了不起老板要求你80分，你做到85分，那你就是个大善人。
对于为了乐趣写代码的，比如大部分写mud机器人的，却是另外一回事情。
写代码是一件很有趣时。github上有无数程序员，为了这个乐趣，写了无数开源代码和项目，让我们的世界变得更没好。
但同样的，写这样的代码，也有一份责任在里面。
当然，绝大部分开源协议，本质上都是免责协议，代表作者不对代码可能造成的影响负责。
但是，真的所有作者都没责任心么？
有一些没有，但大部分有。
因为对代码没有责任心，不光光是对代码不负责任，更是对自己的乐趣和爱好的一种否定。
的确，代码很难保证没有bug.
但你真的吸取教训，去尽量避免bug的发生了么？
自己是骗不了自己的。
你自己写的代码你都不上心了，你还写他干嘛呢？
对于我自己，非工作的代码的质量和要求也远比工作代码的高的多。
而且，就像我一开始说的，代码和项目是有生命的。
很多时候，代码的开发过程，等于是看着一个孩子的出生和成长。
人非草木，多少都有点感情的。
不能说，不收钱写代码，必须要多负责任，多少感情。
只是，我想问一句。
如果你对自己的代码都没责任感，都没感情，
你花费美好的青春，宝贵的生命去写他，为啥呢？
为了将来自己隔应自己么？
当然，写了，写不好，没关系，尽力就行。
我一直觉得，人可以被别人看不起，但最怕的是，被自己看不起。
吹完收工，又是摸鱼的一天过去了。 马斯洛的五层需求，工作给你的只是三层以下的基本需求，自发去做的免费劳动可是第五层的自我实现呢。 protectqiqi 发表于 2024-4-24 05:26 PM
马斯洛的五层需求，工作给你的只是三层以下的基本需求，自发去做的免费劳动可是第五层的自我实现呢。 ...
差不多吧。
很多开源软件都是自我满足和得到认同为出发点发起的。
页:
1
[2]