咨询

中小微公司，尤其是初创型公司，一定要记住: “move fast"! 在国内，由BAT"巨头垄断"的大环境下，我们中小微公司要想在夹缝中生存和发展起来， 一定要快，在快中寻找机遇，在快中寻找突破，或许，一不留神，你就成了。 所以，今天聊聊，在快速发展中，中小微企业该如何技术选型呢？有没有更好的选择？ 因为业务领域不同，在技术选型上肯定大有不同，但是，选择的思路和原则肯定是一致的。 这里，我们列举了我们开发电商系统是如何技术选型的，仅供参考： 1、开发语言 PHP、JS 为什么我们选择PHP： 1）web开发的成熟语言 2）简单，灵活 3）随写，随测，随调，随时上线，开发效率高 4）PHP不是性能差，是你没用好 2、前后端分离 1）前后端协同开发，效率高 2）Resultful API，标准化API接口 3）便于以后服务化或技术迁移，比如迁移Java或go 3、开发工具 sublime、netbeans/phpstorm、vim、Git、postman、API契约测试Pact 开发工具尽量趋于个人习惯，但是好的工具应该纳入公司首选和推荐中。 4、数据存储 MySQL、redis 1）MySQL没有你想想中的那么慢，你真的用好它了吗 2）缓存，缓存。良好的缓存机制，可以让你的系统飞一样的快 5、开发框架及工程工具 JQuery、Vue.js、bootstrap、laravel、composer、webpack 框架要轻，要成熟，要实用 6、开发环境和运维 Vagrant、virtubox、Linux、Jenkins、Docker、ansible、Nagios、Fluentd 1）用vagrant构建一致的应用环境（开发、测试、预发、生产），不要把时间浪费在怀疑环境的问题上。 2）CI/CD（可选），如果有能力还是要建立CI/CD，让开发只关注代码开发，让自动化一切可以自动化的。 3）Docker (可选)，docker的轻量和效率是有目共睹的，但是，如果用不好，会给团队增加复制度和不必要的麻烦。 4) 阿里云平台，使用方便，相对还是可靠的。 5）轻量稳定的监控系统Nagios、日志采集分析工具fluentd 7、敏捷开发 1）快速迭代、协同作战、高效沟通 2）做好阶段性回顾总结，让团队持续推进， 3）从每日站会、需求管理、看板、代码审查、需求验证、持续集成、持续反馈中，寻找团队节奏，持续演进。 8、协同工具 钉钉、Tower 1）选择钉钉，初衷是想将工作(钉钉)和生活(微信)分开。 2）Tower，你需要一个简单好用的项目协同工具，这里还包括trello、Worktile、teambition 总之，我们在做技术选型时，遵循以下原则： 1、简单、轻量、高效 2、能用开源的，绝不自己造轮子 3、能用钱解决的，不要耗费人力时间 4、自动化一切可以自动化的（只要错误在可控范围内） 中小微公司，和大型公司不一样，我们是在技术、人力、成本的平衡中去做选择，可能不是最好，但一定要是最适合发展的，快速争取时间和赢得市场，你说呢？ 如果你有更好的选择和建议，欢迎拍砖和探讨。

软件开发的现状• 软件的复杂度持续不断地提升 • 业务需求复杂度 • 部署运营规模复杂度 • 维护支持复杂度• 软件开发迭代周期和频率越来越快 • 开发、测试周期 • 交付周期 • 解决问题的周期• 软件的运行和质量要求的越来越高 • 扩展性 • 稳定性、可用性 • 用户体验客观事实 优秀的程序员创造的价值是平庸程序员的10000倍 只有亲身体验过痛苦，才会有想要改进的动力 程序就是用来自动化一切机械劳动 主动工作的生产力远远大于被动工作的生产力非工程师文化1、流程文化 = 官僚主义+办公室政治2、咨询师文化 = 假大空文化3、产品经理文化 = 模仿抄袭文化4、老板文化 = 独裁文化（要么牛，要么混蛋）5、营销文化 = 腐败 + 弄虚作假工程师文化 = 创新、自主、效率、价值创始人懂得工程师文化；知识（技术）密集型价值观和目标一致；资源平等，信息透明；雇佣最好的人，个体能力强，每个人都是Leader；（不要舍不得那点工资）自组织，自协作，自管理，自进化；简化功能，抽象软件；残酷无情的推动自动化；残酷无情的降低维护工作量；允许20%的自由时间；维护一个相互尊重，不断反思和相互主动学习的环境。什么样的领导，什么样的文化。什么样的创始人，什么样的公司。什么样的组织架构，什么样的产品形态。大公司是否能持续发展，主要看管理层（选人和用人）小公司是否能发展壮大，主要看boss（格局和能力）

• 1.idea思考完,是否开始行动了 光思考，光计划，如何行动才是关键 • 2.idea为自己思考 只有为自己思考的idea才有意义 为别人设计的idea没有意义，比如马云用我的idea可以赚100万等。 • 3.为一个大市场做产品 原因 传统互联网 百万级别才能活下来 太过度细分市场的冠军没有意义 能收费的模式 马上能回血的模型 要具体问题具体分析 • 4.不要依赖单一资源 人 渠道 巨头 政策 供应商 公司公开资源 伴随公司政策调整 ex.阿里 交易数据 腾讯 好友关系 • 5.不要高度投机 不够长期 ex.越狱 刷榜 • 6.系统出发考虑创业 适合这个国家 适合我 有很多idea 根据象限 选一个 • 7.公司行业定位 没有动到大公司的核心利益 和大公司中层可以硬碰硬竞争 • 8.对竞品分析 能达到做客服的水平 了解完整发展流程 创始人的水平 用发展的眼光看竞品 • 9.不要过度创新 产品 市场 二选一 旧产品 新市场 新产品 旧市场 • 10. 想象的需求要最小成本验证 换成第三人称视角讲述idea 寻求反馈 有真金白银的支持权重很大 • 11.流量从哪里来？ 获客成本极高 对方有你不知道的流量来源 • 12. idea落地纸上 有商业计划书 或 deck 能口头用对方能理解的语言解释清楚 能理解包括 用英语 和 不用专业术语 • 13.追求真正的价值 价值衡量的标准可以是你自己设计 不能凭感觉，要结合客观数据衡量 你自己的标准 股东 合伙人 员工要认可

作为技术负责人，如何才能有效的减少技术债务？ 技术债务，到底应该怎么还？ 几乎所有的技术团队，都会经历或多或少的技术债务。技术债务虽然是实现快速收益的一种捷径，但是为了修复那些为了快速收益而不得不为之的技术问题，企业往往需要花费大量的金钱、人力等。那么如何有效地避免技术债务，使得开发人员能把更多的精力投入在有效的工作，从而产生额外价值、提高企业的产品竞争力呢？ 技术债务的产生有着很多原因，但其中更多的是由于要在短时间内匆忙完成原本耗时较长的工作，导致部分业务逻辑没有完整的设计等，使得产品在短时间内有效，但是长远来看，却是一颗不稳定的炸弹，一旦触发，对产品、对企业都有可能造成无法挽回的损失。总而言之，技术债务会带来很多麻烦，有些甚至是“致命”的。 什么是技术债务？ 技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是编程及软件工程中的一个比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复由于之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。——摘自 维基百科 很多人将技术债务类比于金融债务，但是和金融债务不同的是，技术债务可能不会承担利息。例如当需要快速验证产品的某个特点的时候，带有一定技术债务的产品可能是个好的选择；当验证之后，无需该特点的时候，即可以直接移除等，此时可能不会承担债务利息。但是大多数时候，此类情况较少，就算仅仅是为了验证产品，也不建议使用技术债务的方式去实施。类似这样的技术债务可称为有意的技术债务，另一种更加危险的技术债务称为无意的技术债务，无意的技术债务就像是前文说到的隐藏在代码中的炸弹。 无论是那种技术债务，在未来的产品迭代过程中，都需要开发人员去界定债务边界，不能任由技术债务滋生，否则在迭代过程中，面临的困难会越来越多，甚至需要被迫承担更多的技术债务。基本上，你承担的债务越多，项目的进度就越慢，项目的后续阶段就会更加困难。 但是需要清楚的是，技术债务是无法消除的，你必须随时做好承担技术债务的准备。因为在有的项目场景中，一些解决方案可以针对性解决某些具体问题，但是该方案可能不是全局有效或最佳的，于是在系统的其他方面就形成了一个不可避免而必须承担的技术债务问题。一个好的工程师团队，应该是能够最小化技术债务影响，并对技术债务进行合理管理的团队。 上文提到，技术债务分为有意的技术债务和无意的技术债务，两种形式的技术债务形成的原因和带来的结果是不同的。在某些情况下，有意的技术债务相比无意的技术债务更好，有意的技术债务会让团队意识到问题，从而有意的去进行优化改进等；而无意的技术债务可能在项目中潜伏很长一段时间，可能导致严重的问题，然而，无意的技术债务在项目中是无法避免的，只能通过在工程师团队中强化编码规范、业务理解等来对技术债务进行管理或者减弱其出现的可能。 另外还可以将技术债务分类为鲁莽型技术债务和谨慎型技术债务。一些谨慎型的技术债务在项目进程中是可取的，但是不论是哪种技术债务，都需要每个人勇于承担。理想的情况下，承担的债务应当是那些有意的和谨慎的技术债务，而那些无意的和鲁莽的技术债务应当不惜一切代价去避免。 为什么要关心技术债务？ 技术债务如何影响开发 在开发阶段，开发人员不可避免会遇到技术债务，应当直面技术债务，并积极处理技术债务问题。虽然处理技术债务可能会使得开发周期变长，但从长远来看，开发人员及时处理技术债务是有益的，一方面处理技术债务是一个技术经验积累的过程，另一方面及时的处理可以在之后的迭代中减少技术债务产生的可能等。每一个开发人员都应当有意的或者尽力地避免那些无意的和鲁莽的技术债务。 技术债务如何影响客户 虽然乍看起来，技术债务和客户并无联系，客户也不太关心产品的代码质量等，客户只需要在成本没有增加的情况下，产品能够按时交付使用。然而，一个背负无意或者鲁莽的技术债务的产品在开发过程中，往往需要花费更多的时间、精力和资源，导致成本增加而收益却减少的情况等。 技术债务如何影响用户 即使是间接的，用户也会受到技术债务的影响。他们可能不关心软件开发所需的工作量或资金，但他们确实关心它的可靠运行，以及快速添加的新功能，这两者都可能受到大量技术债务的影响。用户越快乐，客户越快乐，开发者越快乐。 技术债务最佳实践 解决技术债务的最大问题是，它无法真正被量化。这使得开发团队很难跟踪技术债务并让管理层向客户展示为什么要投入更多的资源和时间。 但是这里有一些事情是你可以做的： 保持最新状态 不言而喻，工具、框架和库应该始终保持最新状态。并不是每个人都能意识到这一点，所以这里再强调一下也无妨。 文档 记录需要修复或更新的所有内容，这是确保实际修复和更新的最重要步骤。 如果存在技术债务，最好了解它并确保团队或未来的开发人员也了解。文档减少了定位和修复问题所需的工作量，如果债务记录良好，甚至能在业务层面上可见，将有助于获得客户承认并提供额外资源。 代码审查 另一个强大的工具是在sprint期间定期审查代码。代码审查可以捕捉到可能导致问题的隐患，并找到解决方案。代码审查确实需要一些时间，但在整个项目的背景下肯定是值得的。 但是，代码审查也有其缺点。开发人员往往太忙，无法深入挖掘他人的代码，因此他们只会发现明显的错误，而吹毛求疵可能会导致团队内部紧张。因此，它可以成为减少技术债务的有力工具，但应该谨慎应用。 自动化测试 自动化测试是一种非常强大的工具，但是经常被忽视。自动化测试被忽略后，可能会无法察觉出代码中的隐藏问题，往往导致产品发布后需要投入不成比例的人力和时间来应对，使得成本变高甚至不可控。在开发阶段，有必要实施测试驱动开发，编写完善的测试用例，以清除代码中的许多不易察觉的问题等。 敏捷架构 敏捷架构具有很多优点，在构建软件的过程中对更改更加开放，这基本会发生在任何项目上。但是，它确实要求代码具有灵活性和可维护性，因此敏捷方法自然会使开发人员保持良好的代码，这有助于防止技术债务的大量积累。 有效地复盘 如果出现问题，应该勇于面对，当问题解决后，需要进行有效地复盘。但是要注意的是，复盘是为了提高工作效率，而不是为了找人背锅。复盘的重点应放在了解问题及产生问题的原因上，以便团队可以采取必要措施防止同样的问题再次发生。 管理技术债务的最佳做法 即使你做了以上所有事情，并尽可能避免技术债务的堆积，仍然会有一些债务需要去处理。这是无法避免的，因此应该执行最佳实践和流程以防止技术债务失控。 高利息（高代价）技术债务优先 并非所有技术债务都是平等的，因此应该优先考虑在特定时间内要解决的问题以及先不解决的问题。存在于经常使用和更改的部分代码中的“垃圾”，就比在几乎没有使用或更改过的部分代码中的“垃圾”要严重得多。 高息债务往往是那些在项目中起重要作用的核心部分，通常围绕它进行了很多工作并以此为基础。如果此部分的技术债务没有解决，就会妨碍所有的工作，并可能迫使其他部分的代码背上更多的技术债务。因此，如果有可能，首先应优先考虑这些问题，并在后续使一切变得更加顺畅。 童子军规则 “要始终保持营地比你发现它的时候更清洁”也是适用于软件开发的：“提交的代码要比检出的更好”。鼓励团队成员，以积极减少技术债务 ; 例如，当他们发现了为了功能增加或错误修复的代码时，激励他们重构这部分代码。 当然，它不能没有边界，否则它可能会无止境的消耗时间。但是，如果你在每个sprint中留出一定比例的时间，专门用于修复开发人员发现的任何技术债务，那么它可以在很大程度上保持产品尽可能无债务。 在履行有价值的客户工作时偿还债务 在项目的整个sprint阶段修复技术债务不是一个好主意。一方面，客户往往不喜欢延期，对他们来说，看起来你似乎花了他们的时间和金钱来解决你的错误。另一方面，它也表明你已经因技术债务所累而做了大量工作，所以你可能已经为了债务付出了超出必要的代价。 最好限制在每个sprint中偿还技术债务所花费的时间，并用它来解决高优先级或突然遇到的问题。让客户满意，并使技术债务处于可控水平。 忽略 同样重要的是，要注意并不是所有技术债务都应该偿还。当产品接近其使用寿命时，如果它是短期使用或者只是一次性原型时，技术债务不是主要问题。这些实例很少见，但是当它们出现时你可以节省一些时间和精力。 结论 技术债务是伴随着项目出现而且无法避免，但是如何保持其在可控范围之内，是我们应该思考的问题。技术债务的避免和消除都需要优秀的开发人员，人始终是软件开发中最重要的因素。作为一名普通的码农，不断地提升自己是非常必要的。 本文主要译自： TECHNICAL DEBT: EVERYTHING YOU NEED TO KNOW, AND HOW TO MANAGE IT （https://codingsans.com/blog/technical-debt） ​ 其他参考资料： 技术负债（https://zh.wikipedia.org/wiki/%E6%8A%80%E6%9C%AF%E8%B4%9F%E5%80%BA） 技术债治理的四条原则（https://insights.thoughtworks.cn/managing-technical-debt/） 解析技术债务（https://www.infoq.cn/article/2009/10/dissecting-technical-debt ​