We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
这周要发版本,没问题,由于工作量太大,加上自己效率不足以轻松完成此工作,那就只能加班了,当然,不是我自己,是我们的小 Boss、Team 成员和两个测试。一直弄到了凌晨三点半,有点累。明天是周六,或者说今天是周六,一会就需要去找我的女神去了,这一天见到她肯定可开心,那就回家睡两个小时然后去吧。可是问题是到家里开不开门了,被室友反锁了,这防盗意识还是很不错的,不过我怎么进去呀!门铃也没什么反应。席地而坐,用电脑连 WiFi 写点这周工作的一点关于程序员的一点思考吧。
什么意思?根据用户使用习惯、大量用户数据的使用习惯分析,加上产品经理对产品的定义,会出来用户需求。这个需求指的是用户痛点,该应用就应该去思考怎么去满足用户的这些痛点,交给 UI 进行设计和开发进行程序实现。其实这个时候就会出现一个问题。
这个需求是不是真的满足了用户的需求,这个需求会不会变,这个需求以后会怎么进行版本迭代,会怎么改!
哇,这个问题好难!我其实不是很关心这个需求对用户的帮助,而是更关心以后会怎么变,现在写的代码如何去适应这种变化。老实说,其实现在写代码之前,比较少的去考虑这些,也没有特别多的设计,这也导致了一个问题,日后改起来真的会让人抓狂,根本不清楚自己曾经写过什么,当时的一些做法也完全弄不懂是为什么要这么干,程序能大致按照预期去执行已经很不错了,更多的情况是不能很好的执行。
这是问题呀!我大学学的专业是:软件工程。软件工程和计算机科学与技术最大的不同也体现在软件工程专业把很多的关注点和精力放在了如何让项目正常推进,如何去保证项目稳定安全的发布出去,如何保证不会延期,如何保证代码质量。这不是靠程序猿的自我修养,这是要去思考要去想办法达到的目标的。这里会有好多的问题。之所以说到这个问题,是因为现在的代码已经完全乱掉了,维护起来已经比较吃力了,各种奇奇怪怪的逻辑已经让程序变得复杂,不同的代码规范已经让程序没有人能完全适应,对于程序中的很多耦合关系已经成为互相关联的关系网,动其中任何一个角都有可能打破这个脆弱的平衡。用一句话形容:
Bug 与事件起飞,状态影响共长天一色
这样的代码会导致有很多问题被隐藏其中,当某一天从一个点爆发出来,就可能如洪水泛滥一发不可收拾!当然了,比较幸运的一点是我们现在需要做的仅仅是一个应用,不是一个庞大的系统,并且在一个可预见的未来,这个项目规模并不会爆发式增长,并且写代码的人都还在!还可以维持这个状态,还可以让这种状态继续下去,维护这个项目的程序猿需要有更多的耐心和细心,当处理一些问题时,注意尽量找出各方面的关联吧!
如果有一天能重构代码,真的有那么简单吗?未必,保持现在的这样一个状态,维持到这个项目结束可能更是一个好的选择。
话说回来,为什么这个项目中用到了那么多的事件(EventBus),我们都知道这个东西很方便,确实呀,的确好用。我们也知道这个东西会随着时间的发展逐渐造成项目的难以维护,没办法,有好必有弊嘛,问题是我们没有很好的在这些好处和弊端中进行一个很好的折中,导致了很多的滥用。甚至有的时候还有一种既然这个地方都已经这么做了,那干脆就这么干吧这样的一种心态。这个问题需要再考虑考虑吧。
最后想写一点的就是在开始写代码的时候,仔细去考虑考虑,也许用五分钟考虑好了之后,这个问题就会变得豁然开朗,不禁大叫:“我靠,代码还可以这么写,太漂亮了!”
希望这个项目能好起来,有时间或做到什么地方就逐渐想办法让代码变得更好吧!
20170826 早
The text was updated successfully, but these errors were encountered:
👍
Sorry, something went wrong.
@Eamonnzhang 谢谢呀😉
No branches or pull requests
前言
这周要发版本,没问题,由于工作量太大,加上自己效率不足以轻松完成此工作,那就只能加班了,当然,不是我自己,是我们的小 Boss、Team 成员和两个测试。一直弄到了凌晨三点半,有点累。明天是周六,或者说今天是周六,一会就需要去找我的女神去了,这一天见到她肯定可开心,那就回家睡两个小时然后去吧。可是问题是到家里开不开门了,被室友反锁了,这防盗意识还是很不错的,不过我怎么进去呀!门铃也没什么反应。席地而坐,用电脑连 WiFi 写点这周工作的一点关于程序员的一点思考吧。
正文
怎么去考虑将要做的功能?
什么意思?根据用户使用习惯、大量用户数据的使用习惯分析,加上产品经理对产品的定义,会出来用户需求。这个需求指的是用户痛点,该应用就应该去思考怎么去满足用户的这些痛点,交给 UI 进行设计和开发进行程序实现。其实这个时候就会出现一个问题。
哇,这个问题好难!我其实不是很关心这个需求对用户的帮助,而是更关心以后会怎么变,现在写的代码如何去适应这种变化。老实说,其实现在写代码之前,比较少的去考虑这些,也没有特别多的设计,这也导致了一个问题,日后改起来真的会让人抓狂,根本不清楚自己曾经写过什么,当时的一些做法也完全弄不懂是为什么要这么干,程序能大致按照预期去执行已经很不错了,更多的情况是不能很好的执行。
这是问题呀!我大学学的专业是:软件工程。软件工程和计算机科学与技术最大的不同也体现在软件工程专业把很多的关注点和精力放在了如何让项目正常推进,如何去保证项目稳定安全的发布出去,如何保证不会延期,如何保证代码质量。这不是靠程序猿的自我修养,这是要去思考要去想办法达到的目标的。这里会有好多的问题。之所以说到这个问题,是因为现在的代码已经完全乱掉了,维护起来已经比较吃力了,各种奇奇怪怪的逻辑已经让程序变得复杂,不同的代码规范已经让程序没有人能完全适应,对于程序中的很多耦合关系已经成为互相关联的关系网,动其中任何一个角都有可能打破这个脆弱的平衡。用一句话形容:
这样的代码会导致有很多问题被隐藏其中,当某一天从一个点爆发出来,就可能如洪水泛滥一发不可收拾!当然了,比较幸运的一点是我们现在需要做的仅仅是一个应用,不是一个庞大的系统,并且在一个可预见的未来,这个项目规模并不会爆发式增长,并且写代码的人都还在!还可以维持这个状态,还可以让这种状态继续下去,维护这个项目的程序猿需要有更多的耐心和细心,当处理一些问题时,注意尽量找出各方面的关联吧!
如果有一天能重构代码,真的有那么简单吗?未必,保持现在的这样一个状态,维持到这个项目结束可能更是一个好的选择。
话说回来,为什么这个项目中用到了那么多的事件(EventBus),我们都知道这个东西很方便,确实呀,的确好用。我们也知道这个东西会随着时间的发展逐渐造成项目的难以维护,没办法,有好必有弊嘛,问题是我们没有很好的在这些好处和弊端中进行一个很好的折中,导致了很多的滥用。甚至有的时候还有一种既然这个地方都已经这么做了,那干脆就这么干吧这样的一种心态。这个问题需要再考虑考虑吧。
最后想写一点的就是在开始写代码的时候,仔细去考虑考虑,也许用五分钟考虑好了之后,这个问题就会变得豁然开朗,不禁大叫:“我靠,代码还可以这么写,太漂亮了!”
最后
希望这个项目能好起来,有时间或做到什么地方就逐渐想办法让代码变得更好吧!
20170826 早
The text was updated successfully, but these errors were encountered: