我实际上认为,善加方案者比蓝天-高湿度-高分辨率-受感染的品种要好。

That s because, although I m a coder, I m also a businessman and realize that programs are not for the satisfaction of programmers, they re to meet a specific business need.

在另一个问题中,我实际上曾提出过一个论点,即如何最佳地检测一个赢得的英美/华永道游戏(一个面谈问题)。

我收到的最佳解决办法是,候选人简单核对了所有8种可能性,并填写了<条码>。 有些人提供了一种普遍的解决办法,虽然可以操作,但完全没有必要,因为只有3x3个委员会才知道。

许多人认为 我的限制性太强,“双赢”解决办法是废墟,但我的意见是,它不是一位方案者撰写完美可推广的软件的工作。 该机构负责满足企业需求。

如果该企业需要允许他们自由做比必要的更多的工作,则罚款,但大多数软件和固定装置都是在时间和费用限制下交付的。 方案人员(或任何专业)在真空中工作。

作为一位方案家,我想写出无缺陷的出色软件。 我对gold-plating并不特别感兴趣,但增加“改进”软件的不必要特征的行为,尽管我们大家都在某种程度上这样做。 从这个意义上说,我对“足够”软件感到满意,如果说,如果你足够的话,就意味着我做了客户要求做的事情,同时精心设计,确保软件质量高。

当我拿着短训,写了 cr、未经测试的法典时,我是谁。 我怀着仇恨的写法,是gy的,或者在我走过头的时候,我没有把它改成更好的设计。 当我让很多技术债务陷入困境时——在我增加新的债务时,不要不断改进旧的特征——我知道,我最终会有一些东西,虽然客户可能乐于这样做,但我却胜过。

幸运的是,在我的工作场所,管理层知道保持该守则的清晰度的价值,我知道不实现完美目标的价值。 没有任何法典是完美的,但“足够”必须意味着该法典的制定良好。 我已经学到,现在仍在学习,以乐于遵守符合客户要求的准则,最佳特征就是需要加以执行。 幸运的是,我有足够的工作来完成这种放弃的特征,因为不需要这样做是一件好事。

In my experience, "good enough" always includes hacks, sloppiness, bad commenting, and spaghetti hell, thus leads to lack of scalability, bugs, lagginess, and prevents others from being able to build effectively on your work.

虽然我承认你关于商业需要和务实的意见,但“通过书”做的是for。 “现在足够”和“迅速获得某种工作权利”总是导致在确定一切事项方面,或当出现这种情况时,比第一次花在做这项工作的时候,工作时间要长得多。 该书是出于某种原因撰写的。

海事组织在“足够”和“适用”法之间有着巨大差异。 对我来说,“足够”是指满足(功能和非功能)要求。 我认为,人们可以认为,“足够”意味着短期削减或不选择守则是危险的。 如果非功能要求要求采用优化的代码,那么这是我“足够”定义的一部分。

问题的关键是如何界定“货物”。 对商人来说,“货物”软件是满足企业需要的软件。 在这种情况下,更需要保证规格得到很好的理解和适当缩减。 如果方案不像方案那样快速或高记忆效率,商人可能非常不关心。

关于您使用的商业软件的想法是否完美? 我确实不知道任何人,包括微软的朋友,谁会认为Windows的代码是“完美的”,或者与它相近的东西。 但不容否认的是,Windows是(而且总是)“足够”使数百万人能够每天使用。

这一问题早在方案拟订之前就已经解决。 我确信,你们听到了“如果它不破裂,就没有固定它”或法文原件“Le mieux est l ennemi du bien”。 或许是沃尔特,他写道“好是伟大敌人”。

ANd考虑如果雇用管理人员决定停止雇用“好”方案设计师,并坚持每个申请者在大学中拥有4.0%的平均数,那么我就永远不会放弃作为方案者的工作。

因此,就我而言,鉴于时间和预算限制,你可以做得最好。 随着更多的时间和或更多的资金,我总是能够做得更好。

“够好”是持股人所为。 通常,“够好”是那些撰写文章的不称职的人的庇护所,这给人带来了满足工作要求的印象。 我的“足够”不可能与他们的“足够”相同。

最后,我们所做的一切都必须涉及权衡。 有些人将作出错失的权衡,提供假软件,有些人将作出错误的权衡,无法交付。 谁能够作出正确的权衡,提供真正足够好的软件。

至少需要考虑两个方面的质量:

• software quality: does the software meet the desired goals/requirements? do we deliver builds which have critical bugs? is it easy for end users to operate?
• code quality: how hard is it to maintain the code? is it easy to implement new features?

如果你重新建造一个产品化软件,我认为最好假设,它从两方面来说都不够好。 如果用户不认为他们需要什么,或者产品不够稳定,他们就会看竞争。 你也希望尽快落实新的特点,以便你在市场上拥有竞争优势。

如果你重新建立习惯商业软件,而终端用户和决策者通常不是同一人,那么,特征/质量/货币交易就成为谈判进程的一部分,这种情况就令人感兴趣。 我们通常做的是,我们对这些三个方面实行“足够”的制约:我们有一套满足的要求,质量可以维持,而且通常没有足够的时间保持两者。

这一过程通常被遗忘的是第二点:代码质量或可维持性。 我们,方案制定者理解,较早或更低的戒律将采取报复行动,造成严重的 b或主食。 决策者没有。 问题是,责任和风险由你(大公司、你的司等)承担,如果出现错误,你将首先负责。

我的意见是:对于软件质量而言,客户告诉你什么,他们最了解哪些特点对他们来说至关重要,软件可以有多少份。 守则质量和可维持性:尽你所能,学会做更多的工作,并教他人做同样的事。 这是我从那里获得的。

取决于“够好”的含义。 如果你给我带来足够的好处,你可能会发现你保持和延长你的痛苦,我就能够看到一些风险。

我认为方案拟定是一个条款。 一条需要效率的艺术。 有效的法典是否与美丽的法典不符? 我怀疑这一点。 事实上,我认为,当你创造性地解决一个问题时,它可能意味着多重业绩。 我不认为,方案拟定只能是学习一个新的图书馆,以满足每个新需要,也不应有浏览和固定。 我认为,这应该是美丽的。 当然,法典并不总是艺术,有时对遇到的问题应该务实。