天天写业务代码，感觉没长进，也没实际需求可以让自己写深入的技术代码，好焦躁相关问题去年有人问过了，似乎是同一个问题。
其实通常抱怨『每天都在写业务代码』 的同学，通常业务代码写的也不咋地。
有些人眼里看到团队一成不变的开发节奏，是『机会』，有些人就只会埋怨 。以前端为例，我遇到的几乎每个会有大量运营页的团队（够低端的需求吧），基本都会有个内部的运营页生成工具或系统的配套。 你觉得机会是留给能改善现状的人（比如产出工具的人），还是抱怨的人？。纯粹只是吐个槽
出自 &a href=&/question//answer/?group_id=343296& class=&internal&&是不是服务端编程刚开始都得从写业务开始？ &/a&&br&&br&业务逻辑复杂起来是很考验你的coding skill的。如果忽略技巧，用蛮力写业务逻辑，不追求代码之神，敲完就算，当然无聊啦。&br&&br&---&br&&br&你可以&br&&div class=&highlight&&&pre&&code class=&language-text&&switch （gender）:
case 'male':
if (level === 'gold') {
} else if (level === 'silver') {
case 'female':
if (level === 'gold') {
} else if (level === 'silver') {
case 'unknown':
if (level === 'gold') {
} else if (level === 'silver') {
这是一般业务逻辑程序员认为的“业务逻辑”，你每天写这种代码，当然觉得无聊。
&/code&&/pre&&/div&&br&你也可以&br&&div class=&highlight&&&pre&&code class=&language-text&&GENDER = {
MALE: 'male',
FEMALE: 'female’,
UNKNOWN: 'unknown'
GOLD: 'gold',
SILVER: 'silver',
BRONZE: 'bronze'
avatars = {
GENDER.MALE =& {
LEVEL.GOLD =&
LEVEL.SILVER =&
LEVEL.BRONZE =&
GENDER.FEMALE =& {
LEVEL.GOLD =&
LEVEL.SILVER =&
LEVEL.BRONZE =&
GENDER.UNKNOWN =& {
LEVEL.GOLD =&
LEVEL.SILVER =&
LEVEL.BRONZE =&
user.gender = (user.gender in GENDER) ? user.gender : GENDER.UNKNOWN
user.level
= (user.level in LEVEL) ? user.level : LEVEL.BRONZE
user.avatar = avatars[user.gender][user.level];
这样写业务逻辑就有趣多了。
&/code&&/pre&&/div&&br&后一种是Data Driven的思考方式，用数据，或者设计数据来驱动逻辑，让逻辑的外观从代码里消失，从而让代码更紧凑，节奏感更强，读起来更舒服，改起来更方便。这是在web开发里常用的技巧，游戏逻辑里应该也有不少数据驱动的场景，如果你能为特定逻辑设计出一目了然的数据，就能大大降低逻辑的复杂度，写出的东西更鲁棒，效率通常也更高，就不会觉得写这种业务无聊了，因为有技巧在里面。&br&&br&---&br&&br&你可以&br&&div class=&highlight&&&pre&&code class=&language-text&&for (items) {
item[..] =
return item
&/code&&/pre&&/div&&br&也可以&br&&div class=&highlight&&&pre&&code class=&language-text&&items.each(item =& process(item))
items.filter(item =& verify(item))
items.map(item =& update(item))
&/code&&/pre&&/div&&br&用好函数式，能帮你化解各种无聊的循环，外观上看，代码的抽象层次更高了，语句更清晰了，读起来更舒服了。&br&&br&---&br&&br&你可以&br&&div class=&highlight&&&pre&&code class=&language-text&&class {
showLogo () {
showBanner () {
showSidebar () {
&/code&&/pre&&/div&&br&也可以&br&&div class=&highlight&&&pre&&code class=&language-text&&class {
@decorated by AdDecorator
showBanner,
showSidebar
&/code&&/pre&&/div&&br&简单的Decorator，是不是让代码紧凑精简，有意思多了？ &br&&br&---&br&&br&你可以&br&&div class=&highlight&&&pre&&code class=&language-text&&s : string = 'thanks '
s = s + name
s = s + ' for purchasing
s = s + quantity
s = s + product
s = s + ..
&/code&&/pre&&/div&&br&也可以&br&&div class=&highlight&&&pre&&code class=&language-text&&t = &thanks {name} for purchasing {quantity} {product} ..&
s = t.compile({name, quantity, product})
&/code&&/pre&&/div&把比较脏的局部拼接逻辑变成一目了然的模版，品味高出截。&br&&br&---&br&&br&你可以&br&&div class=&highlight&&&pre&&code class=&language-text&&function attach() {
db.update(app.states)
function move() {
db.update(app.stats)
&/code&&/pre&&/div&也可以&br&&div class=&highlight&&&pre&&code class=&language-text&&app.on('change', 'stats', stats =& {
db.update(stats)
function attack() {
app.update(A ..)
function move() {
app.update(B ..)
&/code&&/pre&&/div&&br&...&br&&br&同样繁杂的业务逻辑可以写得拖沓重复，无聊透顶，也可以写得精粹漂亮，有乐趣和美感啊。只需要在敲键盘前多花点时间来构思，并不难。&br&&br&你确定底层编程需要更高阶的思想吗，其实只是数据和操作的形态不同罢了，思维和技巧还是适用的。再说要多底层才能满足你的虚荣心呢？&br&&br&* 以上代码为伪码，概念实现请参照编程语言。&br&* 支持你自己 &a href=&///?target=http%3A//jump.im/i6& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&jump.im/i6&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&
出自 业务逻辑复杂起来是很考验你的coding skill的。如果忽略技巧，用蛮力写业务逻辑，不追求代码之神，敲完就算，当然无聊啦。---你可以switch （gender）:
case 'male':
if (level === 'gold') {
} else if…
一个产品业务的开发过程中必然存在很多需要解决的问题，比如 崩溃，死锁，性能低下，延迟高，服务器不稳定，数据丢失，某些功能不知道怎么实现。&br&&br&产品业务如果要成功，这些问题必须要解决，至少解决其中绝大部分。&br&&br&谁解决这些问题谁就是大牛，你想去写业务逻辑公司也舍不得。&br&遇到这种问题直接退缩或者推给别人，就写一辈子业务逻辑吧。&br&&br&问题就是机会，你主动去解决问题，你没搞定别人也没搞定啊，万一搞定了就是你牛逼，多划算的买卖啊。&br&&br&以我多年解决问题的经验来看，其实大多问题并不难，只需要认真去google下跟踪调试进源代码深处就能解决，这种问题其实就是谁敢上谁就行。很多人不去解决，就是因为懒和怂。问题解决多了，就会越来越有感觉，别人也就更倾向把疑难杂症交给你。所以一个组里只有一两个人能成长起来，因为只要有一个人成长了其它人就失去了机会，并不是这一两个人比其他人优秀很多，只是他们是第一个敢于主动迎难而上的人。&br&&br&要不怎么说，性格决定命运呢。
一个产品业务的开发过程中必然存在很多需要解决的问题，比如 崩溃，死锁，性能低下，延迟高，服务器不稳定，数据丢失，某些功能不知道怎么实现。产品业务如果要成功，这些问题必须要解决，至少解决其中绝大部分。谁解决这些问题谁就是大牛，你想去写业务逻…
已有帐号？
无法登录？
社交帐号登录
前端工程师/leeluolee当前位置：&&&
程序员，为什么千万不要重写代码？ 读别人代码是一种怎样的体验
14:14&&来源：虎嗅网&
　　作为 100offer 程序员拍卖的运营，我们常常和用户交流讨论，有一个话题经久不衰：程序员入职新公司后接手已有的代码，怎么处理?
　　程序员都有一颗工程师的心，所以当他们到一片新的场地想做的第一件事就是，将旧的一切推倒重来。是的，他们决不会满足于简单的增量劳动。
　　或许这种微妙的心理定位可以解释：为什么程序员进入新项目组后宁愿丢掉旧代码重新写，也不愿意修修补补，他们认为旧代码简直一团糟。
　　但是，事实上真是这样吗?你之所以认为旧代码一团糟，其实是由编程的一个基本定律决定的，那就是：写代码容易，读代码难。
　　为什么你觉得旧代码异常混乱?因为读代码更难
　　这大概就是代码Reuse难以实现的原因，也可以解释为什么你组里的每个人都喜欢用不同的功能将分割的字符串转换成一个数组。比起猜测旧的功能是怎样实现的，重新写一个自己的功能要简单和有趣多了。
　　作为这个公理的推论，你可以问问身边的程序员他们正在奋战的代码怎么样?&简直是一塌糊涂!&他们肯定会这样说。&我简直想推倒重来!&
　　为什么认为代码这么糟糕呢?&额，看看这个功能，竟然有两页长!完全不知道这些东西为什么在这里!完全不知道这些API是干什么的。&他们会这样回答你。
　　漫画：读别人代码是一种怎样的体验?
　　曾经，Borland的创始人 Philippe Kahn当初就是向记者们吹嘘：Quattro Pro会比Microsoft Excel要好用得多，因为它是从头开始编写的，全部都是新的源代码!
　　但是，认为新代码比旧代码好简直就是荒谬。旧代码是已经运行过的，测试过的。无数的bug在被发现前都上线运行过，发现之后程序员们可能在花了好些日子才修复了这些bug。这种修复可能是一行代码，也可能是几个字符，无数的时间和精力都花在了这些bug修复上。
　　当你决定抛弃这些旧代码从零开始的时候，你也丢掉全部前任努力的结果。
　　新代码一定比旧代码好?NO，重写可能会带来更大的风险
　　对技术领导者来说，重写项目的代码也是一个异常艰难的决定。因为从公司层面说，重现代码甚至会威胁产品的市场竞争力。一旦决定重写代码，那么与竞品相比，你可能落后了2~3年&&在软件行业，这时间可够长的。
　　你理想中的新代码会带来产品功能的提升▼
　　但事实上，即便重写的新代码可以实现旧代码的所有功能和需求，但是为产品带来的市场竞争力只有边际提升。因为重写用的新技术、新语言、新框架并没有给产品带来质的飞跃。
　　更不用说在重写的漫长过程中可能会遇到一些意外情况，比如：
　　1、缺钱：资金链的断裂
　　2、缺人：核心程序员离职
　　最终导致效果不佳：达不到原产品应有的所有功能和需求，白白浪费了时间和金钱，也丢掉了市场竞争力。
　　所以重写代码意味着，你在把自己置身于非常危险的境地，可能几年后你也写不出比以前更好的代码。你只是花了一大笔钱把已经存在的代码又写了一遍。
　　当你觉得眼前的旧代码很烂时，该怎么办?
　　你觉得旧代码写的很烂，那又怎样呢?它们已经上线，已经在实际运行中经受住了考验。所以当你发现前任留下的代码乱七八糟的时候，不妨冷静下来，从以下三个方面入手理解代码、改善代码：
　　1、代码的结构有问题
　　如果一段网络代码突然弹出了自己的对话框，应该是UI代码需要被处理。这些问题可以被解决掉，你要一次次小心地移动代码，重构，改变接口。还需要一位细心的工程师立马仔细地检查这些改变是否有问题，从而不打扰到其他人。事实上，甚至比较大的结构变化也可以不扔掉代码来完成。
　　大牛程序员Joel Spolsky回忆说，曾经在某个项目中，他和他的团队花了好几个月重新架构在一点上：把代码动来动去、清理、创建有意义的基类，并创建了模块之间的完美接口。但是他们始终非常小心翼翼，并没有产生新的bug，也没有丢掉任何旧代码。
　　2、代码的效率不高
　　曾经，Netscape的渲染代码被传非常缓慢。但事实上，这只会影响该项目的一小部分，这部分是你可以优化甚至重写的。你完全不必重写全部代码。优化速度的1%工作量，会让你获得99%的爆炸性提高。
　　3、代码写得很丑
　　有些代码真的写的很丑，比如Joel曾参与一个项目，开始用下划线做开始的成员变量约定，但后来改用更标准的&M_&。所以一半的功能用&_&开始，一半用&M&开始，这看起来真的很丑陋。但这个问题5分钟就能解决，而不用从头开始写全部的代码。
　　最后，你要记住，从头开始再写一遍并不意味着你会写出比以前更好的代码。因为你没有参与到上一个版本的创建，所以你其实根本就不算有经验。一旦你准备推倒重写，你可能会再犯一遍版本一犯过的错，甚至会产生更多的新问题。
　　面对糟糕的旧代码，Keep Calm & Carry On!
　　在大型商业项目中，推倒重来是非常危险的行为。当然，如果你是在做实验，想到新算法可以随时重写。如果你跳槽、或刚接手一个新项目，面对看上去异常混乱的旧代码，请冷静下来，忍住推倒重写的冲动，想想上面这些经验之谈。
　　本文为 100offer 程序员拍卖原创，首发于 100offer 微信(ID: im100offer)及博客：/blog/posts/85
【版权与免责声明】如发现内容存在版权问题，烦请提供相关信息发邮件至，我们将及时沟通与处理。本站内容除非来源注明A5创业网，否则均为网友转载，涉及言论、版权与本站无关。
关注创业、电商、站长，扫描A5创业网微信二维码，定期抽大奖。
责任编辑：佩佩
作者：周萌萌Betty
延伸阅读：关键词：
分类排行榜
作者：苗元威
作者：木木博客
作者：朱海涛
作者：王吉伟
站长们都信赖的交易中介平台，安全、高效、便捷。
中小企业网络营销第一平台，解决流量、转化率、品牌。
免费发布技术需求信息，满意付款，全程担保交易。
高收益、移动广告、弹窗CPM、点击CPC、包月广告。
提供公众号出售、求购、代售等交易中介以及增值服务。
增值电信业务经营许可证：苏B2-
编辑热线：5
A5创业网 版权所有.
扫一扫关注最新创业资讯> 查看某个网站源代码时发现它页面下的某个按钮调用了JS事件可是却看不到事件代码的内容，但小弟我想知道这个代码如何写的，该怎么处理
查看某个网站源代码时发现它页面下的某个按钮调用了JS事件可是却看不到事件代码的内容，但小弟我想知道这个代码如何写的，该怎么处理
jjvv86 & &
发布时间： & &
浏览：72 & &
回复：2 & &
悬赏：0.0希赛币
查看某个网站源代码时发现它页面上的某个按钮调用了JS事件可是却看不到事件代码的内容，但我想知道这个代码怎么写的，该怎么办？查看某个网站源代码时发现它页面上的某个按钮调用了JS事件可是却看不到事件代码的内容，但我想知道这个代码怎么写的，该怎么办？
Ctrl+fjjwwde123 & &
& & （0）（1）在&chrome&打开调试面板，然后找到这个btn的id，如果有的话，然后ctrl&+&shift&+&f,就会跳到source面板，粘贴就能找到绑定给id的js了。
具体参考：
chrome调试
[url=http://chrome的调试jjwzolo & &
& & （0）（1）
本问题标题：
本问题地址：
温馨提示：本问题已经关闭，不能解答。
暂无合适的专家
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&淘宝宝贝描述里要写的代码怎么回事？_百度宝宝知道}