软件工程

我几乎可以找到有关递归的每篇文章，其中包括阶乘或斐波那契数的示例，它们是： 数学 在现实生活中无用 是否有一些有趣的非数学代码示例来教授递归？ 我在考虑分而治之算法，但它们通常涉及复杂的数据结构。

47 recursion 

标题说明了一切，但以下是我想知道的一些解释：让我们假设一个程序员在多种主流语言中拥有大约5年的经验。还假设程序员从初级开发人员到高级软件工程师到团队负责人都曾担任过不同的职务。他怎么会知道现在该是停止为他人工作并开始自己的生意的时候了。除课程财务要求外，技术技能和要求的重要性。 问题的第二部分是，如果他决定担任自己的公司角色，他应该如何开始？ 好的，这里有更多信息：我是单身，除了我自己的手机账单和大学费用外没有其他费用。另外，由于我们拥有共同的家庭制度，因此我没有房租（这在我的文化和社区中不仅很普遍，而且很明显）。 我注意到大多数人都以为我想建立一个新产品或网站。我很欣赏您对此的想法，但您能否也从另一个方面来阐述一下？如果我想建立一个新的小型软件商店（或我们这里所说的软件公司）怎么办？

47 business  entrepreneurship 

我已经成为某个特定项目的首席开发人员，但是我很难专注于全局并确保项目的所有部分都被覆盖。 在管理这个项目时我应该记住什么？我如何确保一切都按照应有的方式处理？

47 project-management  team-leader 

一位知识渊博的朋友最近浏览了我帮助启动的网站，并评论了诸如“非常酷的网站，对源代码中的内联脚本感到羞耻”之类的内容。 我绝对可以删除发生内联脚本的位置；我隐约意识到这是“一件坏事”。我的问题是：内联脚本的真正问题是什么？是否存在重大的性能问题，还是仅是良好风格的问题？当还有其他事情需要处理时，我可以证明对上级的内联脚本方面立即采取行动是合理的吗？如果您打开一个网站并看了一眼源代码，什么因素会导致您说“嗯，在这里从事专业工作”，什么原因会使您从显然业余的工作中退缩？ 好的，在写作中那个问题变成了多个问题。但是基本上，内联脚本-有什么关系？

47 javascript  performance  html  coding-style 

我刚开始教一个朋友编程（我们正在使用Python），当我们开始讨论变量的创建和赋值运算符时，她问为什么将右边的值分配给左边的名称，反之亦然。 我以前并没有考虑太多，因为它对我来说似乎很自然，但是她说从左到右对她来说似乎更自然，因为那是我们大多数人阅读自然语言的方式。 我考虑了一下，并得出结论，它使代码更易于阅读，因为分配给它们的名称（程序员将需要重用）很容易看到，并与左侧对齐。 aligned = 2 on = 'foo' + 'bar' + 'foobar' the = 5.0 / 2 left = 2 + 5 相对于： 2 = aligned 'foo' + 'bar' + 'foobar' = on 5.0 / 2 = the 2 + 5 = right # What were the names again...? …

47 language-design  history 

我正在开发一种我还没有完全准备好的产品，但是我有一些用户非常感兴趣，现在他们将其用作“ alpha”测试仪。我现在想免费为他们提供产品作为“ alpha”测试人员，但我希望以后再授权该软件。 这可能吗？谁能指出我任何链接/书/文章/等？ 谢谢。 编辑： 由于缺乏明确性和对问题的回答，我认为我应该添加此声明。 我还没有决定要关闭还是开源这个项目。想要立即使用它的用户群让我有些惊讶，我担心我的选择是什么，因为现在能够以开放源代码的形式提供给他们，后来又改为封闭源代码，或者反之亦然。 感谢所有回答和评论的人。我非常感谢您的见解。

47 licensing 

两种主要的软件开发方法是瀑布式和敏捷式。在讨论这两者时，通常会着重于将它们区分开的特定实践（结对编程，TDD等与功能规范，大型前期设计等）。 但是真正的差异要深得多，因为这些实践来自一种哲学。 Waterfall说： 更改成本很高，因此应将其最小化。 敏捷说： 改变是不可避免的，所以要使改变便宜。 我的问题是，不管您如何看待TDD或功能规格，瀑布式开发方法真的可行吗？ 真的有人认为对于希望交付有价值的软件的人来说，最小化软件更改是一个可行的选择吗？还是真正的问题是，哪种方式在我们的情况下最能应对不可避免的变化？

47 agile  development-methodologies  waterfall 

我的团队使用Team Foundation Server进行源代码控制，今天我在签入之前修复了一些错误和冒烟测试应用程序，但是我忘了注释一些代码。（此代码使UI有点奇怪。） 我想在签入代码之前先知道有什么好的做法-我不想再犯这种错误。

47 version-control  team-foundation-server  configuration-management 

如今风靡一时。“每个人”都推荐它。这本身使我感到怀疑。 在进行测试优先（测试驱动）开发时发现了哪些缺点？我正在寻找经验丰富的从业人员的个人经验-我可以在互联网上的其他地方阅读一百个想想的人的假想。 我之所以问并不是因为我不想讨厌TDD，而是因为改善软件开发过程是我的工作，而且我们越了解人们遇到的问题，就越有机会改进该过程。

47 development-process  tdd 

也许这只是我的个人经历，但是我与不同的群体和类型的人联系在一起，在我看来，我遇到的程序员中有很大比例的人“不好”，或者试图给出更好的定义： 居高临下 纳尔基 他们谈论人的方式是负面的 如果您注意到了同一件事，那么为什么会有任何理论呢？关于如何礼貌地或不礼貌地提出建议，让这些程序员之一知道他们的行为，并建议如果他们想被视为专业人士，他们可以纠正它。 也许我只是遇到了一个不好的样本，每个人都可以列举出不好的种子。

47 teamwork 

标志变量是邪恶的吗？以下类型的变量是否极不道德，是否邪恶地使用它们？ “布尔值或整数变量，您可以在某些位置分配值，然后向下选择以下值，然后进行其他操作，例如，使用newItem = true下面的某些行if (newItem ) then” 我记得做过几个项目，在这些项目中我完全忽略了使用标志，最终得到了更好的体系结构/代码。但是，这在我从事的其他项目中是一种常见的做法，当代码增长并添加标志时，恕我直言，意大利面条也随之增长。 您是否会说在任何情况下都使用标志是一种好习惯甚至是必要的做法？或者您是否同意在代码中使用标志是...红色标志，应避免/重构。我，我只是通过执行实时检查状态的函数/方法来解决问题。

47 code-quality  code-smell  maintainability 

我正在一个C ++项目中工作，其中有很多数学函数，这些函数最初是作为类的一部分编写的。但是，由于我一直在编写更多代码，所以我意识到我到处都需要这些数学函数。 放置它们的最佳位置在哪里？假设我有这个： class A{ public: int math_function1(int); ... } 当我写另一个类时，我不能（或者说我不知道​​如何）math_function1在那个其他类中使用它。另外，我已经意识到其中一些功能与A类并没有真正的联系。它们似乎只是开始，但现在我可以看到它们仅仅是数学功能。 在这种情况下有什么好的做法？现在，我一直在将它们复制粘贴到新类中，我敢肯定这是最糟糕的做法。

47 c++  functions  class 

用static多种语言在成员上使用关键字表示您不应创建该类的实例才能访问该成员。但是，我认为没有理由进行整个课堂学习static。我为什么以及何时上课static？ 上课能给我带来什么好处static？我的意思是，在声明静态类之后，仍然应该将他/她希望不带实例化即可访问的所有成员也声明为静态。 例如，这意味着Math可以将类声明为普通（非静态），而不会影响开发人员的编码方式。换句话说，将类设为静态或普通对开发人员而言是透明的。

47 c#  class  static-keyword 

我一直在阅读《 Smalltalk的早期历史》，并且提到了“分配”，这使我质疑其含义： 尽管OOP来自许多动机，但其中两个是核心。大型方案是为包含细节隐藏的复杂系统找到一种更好的模块方案，而小型方案是找到一种更灵活的分配方案，然后尝试将其彻底消除。 （从1960-66年开始-早期的OOP和六十年代的其他形成性思想，第一部分） 我从Simula得到的是，您现在可以用目标替换绑定和分配。您希望任何程序员做的最后一件事就是内部状态混乱，即使以图形方式呈现也是如此。相反，应该将对象呈现为更适合用作动态组件的更高级别行为的站点。（...）不幸的是，当今所谓的“面向对象程序设计”中的大部分只是带有奇特构造的旧式程序设计。许多程序现在都通过“昂贵的附加程序”来完成“分配样式”操作。 （摘自“面向对象”样式，第IV节） 我将目的解释为对象是外观，而目的是在对象上设置实例变量（即“赋值”）的任何方法（或“消息”）都违反了目的，我是否正确？第四节中的以下两个陈述似乎支持了这种解释： 一起使用的四种技术-持久状态，多态性，实例化和作为目标的方法-占据了很大的力量。这些都不要求使用“面向对象的语言”-ALGOL 68几乎可以转变为这种样式-OOPL只是将设计师的思想集中在一个特定的富有成果的方向上。但是，正确执行封装不仅是对状态抽象的承诺，而且是从编程中消除面向状态的隐喻的承诺。 ...和： 分配语句（甚至是抽象的语句）表达了非常低级的目标，需要更多的目标才能完成任务。通常，我们不希望程序员弄乱状态，无论是否模拟。 可以这样说，鼓励不透明，不可变的实例吗？还是不鼓励直接改变状态？举例来说，如果我有一个BankAccount类，它的确定有GetBalance，Deposit和Withdraw实例方法/消息; 只需确保没有SetBalance实例方法/消息？

47 object-oriented  immutability  smalltalk  functional-programming 

模型视图视图模型是由Microsoft开发的，目标是支持事件驱动编程的UI开发平台，特别是使用XAML和.NET语言的.NET平台上的Windows Presentation Foundation（WPF）和Silverlight。此后的几年中，许多Javascript框架（例如Angular，Knockout和ExtJS）都采用了这种模式。 像大多数软件模式一样，MVVM具有适当的用途和滥用。在什么条件下使用MVVM是合适的？什么时候不明智？

47 wpf  mvvm  silverlight  angularjs  xaml