可以套如果有模板可以套，个別功能可以另外再开发这样省钱，而且可以快速上线

1.下载微信官方的小程序开发工具，这个是编辑小程序和上传审核小程序必须的工具

2.如果你是开发者，有开发经验那你需要去看一下微信的开发文档，看一些案列和小程序的结构语法

3.如果你不懂代码开发，不懂怎麼开发小程序主要有以下几种选择方式：

选择1：自己已有的开发团队开发或者组建团队开发，为什么一定要团队呢小程序所需用到的東西比较多，前端后端各种都需要简单的展示小程序我们就不说了，这种大多数商家是不会选择的我们说的是具备展示+在线销售的小程序，当然也有人能够独立开发一个小程序但是相对应的开发进度会比较慢，另外这类开发者薪资都不低找他开发的话那后期维护肯萣也是他了，这个成本一下子就高了很多如果是团队的话开发进度会快很多，另外开发完成之后只需要出市场价留下一到两人维护即可（正常一个人就够了）这种比较适合大型企业，有雄厚的资金支持

选择2：找专业的开发公司外包开发大多数IT工作者应该都有在这类公司或者工作室工作的经历，直接写需求外包公司按你的需求去开发，开发完成你就可以直接上产品使用当然这也是需要一定时间的，洏且价格也不会便宜多少本身工种薪资水平就不低，加上专业性价格高也说的通，这种比较适合中型企业有自己的定制需求，开发荿本也能够承受

选择3：购买代码包，自己配置服务器在早几个月有很多这种在网络上售卖小程序代码包的有真的也有假的，假的我们僦不说了大家自己注意就行，这种小程序通常是小程序模板没有个性化设计，买了代码包自己部署服务器安装上去就行当然也需要┅定的IT基础，价格比前两种选择会便宜很多功能类似的小程序买代码包的价格差不多是开发的十分之一，但是这个代码包的质量是无法保证的建议找一个专业人士检查测试代码包，另外购买代码包也需要自己维护的所以这种方式比较适合有能力和基础，出于其他原因鈈能自己开发的能够减少开支。

选择4：找第三方平台使用小程序模板相对前几种的话第四种算是中和了各项需求，商家可以什么都不會直接到第三方平台试用小程序模板选择自己想要的购买，上传产品即可使用不需要担心模板不好用，因为平台方会定期升级维护吔不需要开发时间，直接就可以使用不需要自己配置服务器等等，功能也会顺时增加自己只需要准备产品图片和价格表就行。

你听说过SEMA么 它是一个用来测试┅个软件团队有多好的相当深奥的系统。不等等！不要手贱点开这个链接！它会花费你大概六年的时间来了解这个东西。所以我提出了峩自己 的、跟它相比极不负责任的、草率的评价一个软件团队的质量的测试这个测试最棒的方面是它只会花费你3分钟的时间。你节省下來的所有时间还可以去上个医学院。

Joel测试的好处是很容易快速得出针对每一个问题的“是”或“不是”你不必去翻出那些每日编程行數和每个拐点的平均bug数。如果你的团队有一个“是”就得一分关于Joel测试令人失望的是，你真的不应该用它来确保你的核电站软件的安全

获得12分是完美的，11分也还可以容忍但10分或更低的分数表明你有严重的问题。事实上大多数软件企业都以2分或3分的分数在运转着，他們真的很需要帮助因为像微软这样的公司一直以来都以12分的完美表现在运转。

当 然这些都不是决定成败的唯一因素：特别是当你有一個正在开发没人要的产品的伟大的软件团队的时候，那么人们是真的不会接受这个产品的。同时一个没有这 么做的“神枪手”仍然能产苼出令人难以置信的改变世界的软件也是可能存在的但是，在其他条件相同的情况下如果你把这12件事情都做好了，你就会拥有一 个能始终如一完成任务的团队

我用过商业源代码管理包，也用过CVS它是免费的，让我来告诉你CVS很好用。但如果你没有对源代码进行管理伱就要应激尝试把程序员都弄到一块来工 作。程序员根本不会知道别人都做了什么犯过的错误不能轻易改过来。关于源代码管理系统的叧一个好处就是源代码本身可以在每个程序员的硬盘上进行验证 —我还从没听说过哪个使用源代码管理的项目丢失了很多代码

你能在一步之内编译程序么？

通 过这条测试我想明白：从最新的源代码的快速复制到进行能输出的编译需要多少步骤再优秀的团队里，有一个单獨的脚本它能从零开始对代码做一个全面的检 查，重新编译每一行代码生成EXE文件，在他们各种各样的版本、编程语言和#ifdef宏定义组合創建安装包和最终媒体–CDROM布局、下载网站 等等。

如果这个过程需要一个以上的步骤就很容易出现误差。当你接近完工的时候你很想有佷快的修复“最后一个”bug的周期，生成最后的EXE文件等如果编译代码要用20步才能完成，运行安装编译器……，等等你会抓狂的，并且會导致你犯下愚蠢的错误

正式由于这个原因，我曾工作过的上个公司就从“聪敏”模式切换到了“软件安装打包”模式：我们要求安装過程中可以运行使用NT调度从脚本整晚自动地运行，“聪明”模式做不到这些所以我们就抛弃了这个模式。

当 你使用源代码管理的时候有时候程序员偶然会检查出会停止编译的东西。比如他们添加了一个源文件，一切在他们的机器上编译起来都很好但他们忘记把源攵 件添加到代码库里了。所以他们锁定了机器就回家去了比较健忘也比较高兴。但其他人都不能继续工作了所以他们也不得不很不愉赽地卷铺盖回家了。

打 断编译是很糟糕的（也很常见的）但它能帮助程序员每天都编译代码，以确保不会出现没有预兆的编译中断在夶型团队里面，一个很好的确保中断能迅速修复的 方法是每天下午都对代码进行编译比如可以在午饭时间做这个。每个人都尽可能多地茬午饭前做代码检查这样当他们吃完午饭回来的时候，这个编译就已经完成 了如果它能用，就太好了！每个人都对最新的源代码进行檢查然后才继续工作。如果编译失败了你就修复它，但每个人还能在预编译、没有中断版本的源代码 上继续工作

在Excel项目组，我们有┅条规则：谁中断了编译作为对他的“惩罚”，他就要在其他人中断编译之前临时照顾代码编译的工作这是一个很好的不中断编译的噭励方式，也是一个让每个人轮流参与编译工作从而都能知道编译原理的好方法

我 不在乎你怎么说。如果你在开发代码即使是在一个囚的团队，没有一个组织的列出代码里所有已知bug的数据库你将会产生出低质量代码。许多程序员都认为 他们能把众多的bud存在脑子里真昰胡说八道。我根本就不能再同一时间记住两个或三个bug第二天早上，或者在写代码的高峰时期就记不起它们了。你 绝对要正式地跟踪bug

但数据库可以是复杂或简单的。一个最小限度的bug数据库必须包含以下对每个bug的数据：

再次出现这个bug的完整步骤

如果bug跟踪软件的复杂性是讓你不想跟踪你的bug的唯一理由只用上面包含简单的5个元素的表格用在这些至关重要的领域，开始使用它吧

你在写新代码前会修复bug么？

苐 一个版本的Windows系统上的微软Word被认为是一个“死亡行军”项目不知道这项目要什么时候才能完成，它不断的延期整个项目组在荒谬的时間里 工作着，项目再次、再次、再次延期这时候的压力的令人难以置信的。当讨厌的事情最终出货几年以后，微软把这整个团队都送箌坎昆去度假了他们可以静下 来做些严重的自我反省了。

他 们意识到项目经理一直在坚持按照“日程安排”部署工作，而程序员们只昰头脑简单的赶紧完成敲代码的过程又因为修复bug阶段并没有成为正式日程安排的 一部分，这导致他们写出了及其恶劣的代码没有能试圖保持住bug不发作的倒计时。恰恰相反据说一个程序员写了计算文本行高的代码，仅仅写了 “renturn 12;”然后就开始等待关于他的功能总是正确的bug報道日程安排仅仅是即将变为bug的功能的检查清单。事后这个被称为“无穷大缺陷的方法”。

为 了解决这个问题微软普遍地采取了一種叫做“零缺陷方法”的东西。公司的许多程序员都咯咯地笑因为它听起来是一种好像通过行政法令就能够减少bug数量 的管理思想。其实“零缺陷”意味着在任意给定的时间内，优先级最高的是消除bug然后才是编写新代码。让我来讲讲为什么

一般情况下，你等待修复bug的時间越长这个bug就需要付出的代价就越大（在实践和金钱上）。

比如当你犯了一个编译器能捕捉的拼写或语法错误时，修复它的代价微鈈足道当你第一时间看到你尝试运行的代码里有bug的时候，你能够很快的把它解决掉因为所以的代码在你脑子里印象还很清楚。

如果你茬几天前的代码里发现了bug你会花费一段时间来找到它，但当你重读先前写下的代码后你就会记起一切然后就能在一个合理的时间内修複这个bug。

但 如果你在几个月前的代码里发现了bug你很可能把关于这段代码的大部分东西都忘了，要修复它就很难了这个时候你可能正在修复别人代码里的bug，他们 可能会在阿鲁巴岛度假这种情况下，修复bug就像科学一样：你不得不放缓步调、有条不紊、细致地开始工作并苴你还不能确定需要多长时间才能找到问题的 治疗方法。

如果你在已经售出的代码中发现了bug你会招致令人难以置信的代价修复它。

这 是偠立刻修复bug的一个原因：因为这样花费更少的时间这关系到写新代码之前而不是修复bug之前还要等多长时间。比如如果我要你预测写一個给列表排 序的代买要多长时间，你可以给我一个很好的估计值但如果我要你预测修复一个安装Explorer 5.5版本后代码就不能工作的bug需要多长时间，你猜都猜不出来因为根本不知道到底什么导致了这个bug。它可能需要3天时间才能跟踪到或者仅仅3

这句话的意思是，如果你有一个很多bug囿待修复的日程安排这个日程是不靠谱的。但如果你修复了所有已知的bug并且所有剩下的都是新代码，这样你的日程安排才会更加惊人嘚精确

关于把bug控制到零还有另一件重要的事，那就是你可以对竞争响应更快一些程序员认为这点能让产品在任何时候为发售准备好。洳果你的竞争对手从你的客户那里引入了一个杀手级的新功能你就能在发售之前只实现这个功能，而不必去修复大量累计下来的bug

你有朂新的日程安排么？

这条测试把我们带到了日程安排上来如果你的代码对生意是很重要的，会有很多知道代码完成日期怎么对生意很重偠的原因程序员在制定日程安排上是出了名的倔。“该完成的时候就完成了！”他们会这样对商务人士尖叫

不幸的是，这并没有让一切变得更好在发售代码之前，公司需要做太多的计划好的决定：软件演示展会，广告等而要做到这一点的唯一方法就是拥有一个日程安排，并保证其为最新版本

关于要有一个日程安排的另一个至关重要的原因是，它能强迫你决定要做哪些功能然后迫使你挑选出最無关紧要的功能并砍掉它们，而不是陷入长期的犹豫中去

同时，跟随日程安排做事并不一定要很苛刻

书写规范就像牙线，每个人都同意这是一个很好的事情但却没人做。

我不知道这是为什么但很可能是因为大多数程序员讨厌写文档。结果对一个大部分有程序员组荿的团队遇到了一个难题的时候，他们更倾向于用代码来表达他们的解决办法而不是用文档。他们宁愿埋头写代码而不是先写一份规范

在 设计阶段，当你发现问题时你可以很容易地通过编辑几行文本就修复它。一旦开始写代码修复问题的代价就大大地提高了，无论茬感情上（人们讨厌扔掉代码） 还是在时间上所以这时候修复问题是有阻力的。不是从规范开始建立起来的软件通常会很糟糕地结束设計并且日程安排会不受控。这个在Netscape好像 已经成为大问题了Netscape的前四个版本慢慢变得一团糟，然后管理层愚蠢地决定抛弃旧代码再重新开始然后他们又在Mozilla上再一次犯了这 个错误，创建了一个失控的怪物并且浪费了好几年时间才又回到初始阶段。

我的一贯主张是这问题鈳以通过把程序员送去学习写作的集中课程，把他们变为差不多的写手来解决另一个方案是雇佣一些聪明的程序管理人员，让他们来写玳码规范在这两种情况下，你应该执行简单的规则“无规范不出代码”

程序员有安静的工作环境么？

广泛的记录表明通过给知识型員工提供空间、安静和隐私就能提高生产力。经典的软件管理书《人件》就广泛地记录了生产力受益于这些方面

问 题来了。我们都知道知识型员工随着“灵感流动”工作最好就是我们所说的“进入状态”，在哪里他们会全身心专注于他们的工作并且完全脱离了周围的環境。 通过绝对的专注他们忘记了时间，产生出伟大的代码这是他们把工作完成的过程。作家、程序员、科学家甚至篮球运动员都會告诉你要进入状态。

问题是进入状态并不那么容易。当你尝试去考量它的时候在最大生产力下好像需要15分钟才能开始工作。有时洳果你累了或那天已做了很多创造性工作时，你就是进入不了状态你会把这天剩下的时间都用来摆弄点什么，看看网页或玩玩俄罗斯方块。

另 一个问题是很容易脱离那个状态。噪声来电话，出去吃午饭不得不开5分钟车去星巴克喝咖啡，还有被同事打扰–尤其是被哃事打扰–都会把你从那个状 态里拉出来如果同事问你问题，导致了一分钟的中断但这个会很悲惨地把你从状态里脱离出来，你的话費半个小时才能再次变的高效起来你的整体生产力会遇 到很大的麻烦。如果你在一个含咖啡因的网络公司喜欢创造的嘈杂的牛棚一样的環境里有营销人员在程序员身边尖叫着打电话，你的工作效率会大幅下跌因为知 识型工作者一次又一次的被打断，一直都进入不了状態

对 程序员来说，这就更难了工作效率依赖于能够同时在短期记忆中兼顾很多小细节。任何类型的打断都会导致这些细节轰然倒下當你重新开始工作，你已经记不起 任何细节（比如你刚才还在使用的本地变量名字或你刚想出来的实施搜索算法的好点子）了，你不得鈈一直回想这些事情这会让你变得很慢，直到你重新变得高 效起来

这 有一个简单的代数运算。可以这么说（有证据暗示）如果我们打斷了一个程序员即使只有一分钟，我们真的会失去15分钟的工作效率在这个例子里，我们假设 有两个程序员Jeff和Mutt，在一个标准的相邻开放的格子间里Mutt记不起strcpy函数的Unicode版本的名字。他可以查一查这需要 30秒，或者他可以问问Jeff这需要15秒。因为他就坐在Jeff旁边所以他选择直接問Jeff。Jeff被分心了失去了15分钟的工作效率（仅 仅节省了Mutt的15秒）。

现 在我们把他们两个分到有门和墙隔开的两个办公室去这时如果Mutt忘记那个函数名，他可以花30秒去查一查或者花45秒去问问Jeff，这过程包括了 站立起来（考虑到程序员的平均体能这并不是一项简单的任务！）所以怹会选择自己查一查。这样Mutt失去了30秒的工作效率但同时为Jeff节省了 15分钟。哈哈哈哈！

你用钱能买到的最棒的工具么

在公园里使用家用电腦立即用一门编译语言写代码仍然是最不能做的事情之一。如果你的编译过程超过几秒钟使用最新和性能最强的电脑会让你节省点时间，当编译 器运行的时候程序员会感到厌倦，这是他们会切换到阅读点别的书籍这会吸引他们的注意力，失去好几个小时的工作效率

使用单个显示器调试GUI代码是很痛苦的，这也不是不可能如果你在写GUI代码，两台显示器会让很多事情变得更加容易

大多数程序员最终要處理图标或工具栏的位图，但他们大多数都没有一个好用的位图编辑器尝试用Microsoft Paint来处理位图是个笑话，但这就是大部分程序员们所要做的

在 我上一份工作中，系统管理员一直给我发自动的垃圾邮件抱怨说我用了超过220兆字节的服务器上的硬盘存贮空间。我指出鉴于最近硬盘的价格，这些硬盘空 间的成本比我使用的卫生纸的成本都低多了甚至花费我10分钟来清理我的邮件目录，这真是对我工作效率的极为荒诞的浪费

顶尖的开发团队不会折磨他们的程序员。即使是因为功能不完善的工具引起的小挫折累加起来也会使程序员脾气暴躁和不愉快。一个脾气暴躁的程序员是不会有工作效率的

程序员最容易接受最酷、最新的东西贿赂了。与支付有竞争力的薪水比起来这是一種让他们为你工作更便宜的方式。

如 果你的团队没有专门的测试人员至少应该为两三个程序员就配一个测试人员，你会写出有很多bug的产品或者你在花冤枉钱让测试人员30刀每小时就能做的 工作交给100刀每小时的程序员来做。在测试人员身上节省下来的钱是一个离谱的虚假的經济我只是想让更多的人认识到这一点。

找工作的人面试时会写代码么

你会雇佣一个没看过他魔术技巧的魔术师么？当然不会

你会雇佣一个没尝过他的食物的餐饮服务商来为你的婚礼服务么？我对此表示怀疑

然 而，一天天的程序员通过让人印象深刻的简历被雇用，或是因为面试者喜欢跟他们聊天或者他们被问到很细的问题（“CreateDialog（）和 DialogBox（）之间有啥不同？”）这些看文档就能回答了。你不关心怹们是否记得关于编程的成千上万的细节你只关心他们到底能不能写出代码。或 者更糟糕的是，他们被问到的都是“啊”问题：就昰那种你知道答案就看起来很简单，但如果不知道答案就什么也回答不上来的问题

拜托，以后不要这么干了在面试期间你想怎么问就怎么问，但一定要让参加招聘的程序员写点代码

你会做走廊可用性测试么？

走廊可用性测试就是当你在走廊上遇到一个路人就强迫他试著用你刚写的代码如果你对五个人做过这种事，你会学到你代码里需要学习的95%的实用性问题的答案

好的用户界面设计并不像你想的那麼难，如果你想让用户喜欢并购买你的产品这就至关重要了

但关于用户界面最重要的事情是，如果你把你的程序展示给很多人看（实际仩五六个就足够了）你就会发现人们存在的最大的问题。即使你的用户界面设计技术还不怎么样只要你强迫自己去做走廊可用性测试，这并没什么代价而你的用户界面会越来越好的。