Record

区块链记录你的初心
营销地产创业创新求职面试Word技巧金融职场工作区块链Excel教程财经PPT教程产品运营
你已经是一个成熟的码农了,这些思维习惯你要有

你已经是一个成熟的码农了,这些思维习惯你要有

测试写代码代码开发习惯码农

不想成为好程序员的码农不是好工程师。出色的码农都具备怎样的思维习惯?这里有25条成熟的小建议。「即使进行小的软件变更也很困难!」「进行变更会破坏软件的特性。」「修复一个 bug 的同时又引入了一个新的 bug...」「实现的是没有必要的代码。」「代码太复杂了!几乎不可能向其中添加新的特性。」「这产品永远不会交付不了了!」「抛弃旧代码吧!重头开始写。」你是否对上面的这些话感到熟悉呢?世界上每个角落的开发者,每一分钟都在说着(或想着)这些,亚历山大到想哭!这是为什么呢?这些都是开发者们经常讨论的常见问题。每个开发团队都经历过这些故事。有许多小的因素会逐渐侵蚀开发人员的项目。它们不会立即造成破坏,而是日积月累,甚至一年或更长的时间内都看不出来。所以当有人指出这些因素时,通常听起来没有什么危害。即使你开始实施,也可能看起来一切正常。但随着时间的推移,尤其是随着这些东西越积越多,情况也会变得越来越复杂,直到你成为这个「常见恐怖故事」的又一个受害者。为了避免成为受害者之一,你应该牢记几条软件的基本定律。你应该培养一种开发者必备的思维模式。这种思维模式会帮助你在日常编程过程中做出更好的决定。你可以让你的软件尽可能的简单,防止它成为一个无法管理的复杂系统。接下来,本文将列出25条开发者必须掌握的要点。1. 构想软件的用途首先,你需要明白软件的用途。也就是说,实际上所有软件的用途只有一个:帮助人们!请记住:软件的用途并不是炫耀你有多聪明。不能构想出软件用途的开发者将写出糟糕的软件。什么是糟糕的软件呢?就是那些对人们没什么帮助的系统。在对软件做出决策的时候,你应该牢记下面的指导原则:我们如何才能为人们提供帮助?你甚至可以通过这种方式对软件特性的请求进行优先级排序。2. 明确软件设计的目标每个程序员都是一个设计师。当难以创建或修改软件时,开发者往往会将大部分时间花在让软件「能用就行」,而不是关注如何帮助用户。软件设计的目的是尽可能简化开发人员的工作,这样他们就可以专注于重要的事情。你将创建能够帮助用户的软件,并且你的软件将在很长一段时间内持续对用户提供帮助。然而,如果你设计了一个糟糕的系统,你的软件生命周期将会很短。这就向我们指明了软件设计最重要的目标:设计出开发人员能够尽可能容易创建和维护的系统,从而使这些软件能够持续地为用户提供帮助。所以设计时有两个关键点:方便自己,帮助他人。3. 正确理解自己开发的东西无法完全理解自己作品的开发者往往会开发出复杂的系统。这会招致一个恶性循环:对软件的误解会导致复杂性增加,反过来又会进一步加深对软件的误解,循环往复。事实上,提升设计技能的最佳方法之一就是:保证你对开发的系统和工具有充分的理解。对软件的理解程度是优秀开发者与蹩脚开发者之间最关键的差别。蹩脚的开发者并不能理解他们所做的东西,而优秀的开发者则对此有很清晰的认识。就是这么简单。4. 简洁简洁是终极的复杂达芬奇。编程是化繁为简的艺术。「蹩脚的开发者」无法降低程序复杂性,而「优秀的开发者」会尽其所能简化其代码,使其易于被其他开发者理解。一名优秀的开发者会创建一些易于理解的东西,这样就很容易发现所有的bug。现在的开发者都是聪明人,没有人喜欢被当做傻瓜来对待。具有讽刺意味的是,有时候这种心态却会导致他们创造出复杂的东西。他们大体上是这么想的:「其它的开发者会能够理解我写的这些代码。所以我应该写出一些难以理解的绝妙代码,这样他们就会认为我很聪明。」这是一种不良心态导致的错误,并不一定是由于缺乏编程技巧。大多数编程中的失败都是由这样的心态造成的。炫耀你有多聪明并不能帮你写出好程序。刚接触你的代码的开发者对这样的代码并没有什么了解,他们必须研究一阵子。所以,你应该问自己:「我是想让人们理解我的代码并感到快乐,还是希望他们感到困惑和沮丧呢?」事实上,如果其他阅读代码的开发者能够很容易地理解它,这说明你的代码写得很棒。复杂与智慧无关,简单却与之相关。LarryBossidy那么问题来了:「应该让代码有多简洁?」你的答案应该是:「让它变成傻瓜式的代码,任何人都能读懂。」5. 控制复杂度控制复杂度是计算机编程的本质。BrianKernighan复杂性是许多软件失败的根源。一开始,你要做的可能是一个在一个月内就能完成的项目。接着,你增加了程序的复杂性,使得这项任务需要三个月才能做完。然后,你又开始加入了一些满足其它用途的新的特性。由于你无缘无故地扩展了软件的用途,这件事开始变得十分复杂,需要六个月才能完成。但是,这还没完。接下来,你考虑了每个特性并让整个软件变得更复杂,导致软件需要九个月才能完成。然后,由于代码的复杂度提高,又引入了许多新的bug。自然而然地,你开始着手修复这些bug,然而你并没有考虑到这些修复对程序的其余部分有何影响。最终,即使是很小的更改也会变得十分困难。当bug修复开始引入新的bug时,你将不得不面对最流行的编程恐怖故事:从头开始重写代码!那么,你是如何成为这个恐怖故事的受害者的呢?或者说,更多人应该关心:我们如何才能避免成为这个受害者?其实很简单。首先,你需要确切地弄清楚你软件的用途及其定义。其次,你需要使你所编写的每段代码尽可能简洁。第三,当一个新的特性或变更请求出现在讨论表中时,你需要基于你软件的用途对它们进行评估,并提出问题。作为一名开发者,你的第一反应应该是抵制(不必要的)软件变更。这将防止你向软件中添加不必要的代码。当你确信这项变更是必要的时,你可以去实现它。有许多因素会提高软件的复杂度,但本文提到的这些是最常见的因素。除此之外,你还应该遵循一条原则:你的主要目的是降低复杂度,而不是增加复杂度。6. 维护维护是软件开发中最重要的事情之一。很遗憾,开发人员通常会忽略它的重要性。快速编码和快速交付看起来比代码维护更重要。这就是错误的所在忽视未来的代码维护。总有一些变更需要实现。不仅必须实现,你还要随着时间的推移维护它们。作为开发人员,考虑未来变更的维护是你的主要职责之一。所有的变更都需要维护。
抓包工具--charles

抓包工具--charles

测试it

首先安装一下这个软件 这个相信很多人电脑里应该都安装了,没安装的搜charles破解版也能很容易搜到。如果没安装java环境,首次进入charles会提示让你安装java包得,直接给你链接是苹果官网的,去下一个一键安装就行了。 安装完成后先打开,在进行下面操作。 然后去自己电脑的系统偏好设置-》网络-》选中现在连着的网(大部分人应该都是WiFi吧)可以查到自己这个电脑在现在这个wifi里的IP地址,比如我现在这个就是192.168.0.105(建议最好用私人网络,用公司网络的话可能会有限制会出现没反应的问题) 然后找到自己手机也连着这个同名的wifi,然后选中右边的蓝色i。 然后进入到了这个无线局域网的高级设置页面。进去之后拉到最下方,找到HTTP代理字样。然后选中手动代理,并在服务器中填自己电脑查到的ip地址,然后把端口调8888,最后点击左上角返回。返回值后系统会自动设置代理重新连接。 这时候你的手机上网的过程中就要经过你的电脑了。刚用手机打开一个联网的程序,你的电脑上应该会显示一个弹窗问你【allow】还是【deny】肯定不能拒绝啊就点allow吧。这个只有第一次才弹窗,图没截上,你到时候看见肯定能看懂的。点了同意之后你手机发出的每一个请求都会被拦截出痕迹。 拿网易新闻举例,以前就练习这写过网易新闻的项目,其中网易的接口全是用charles拦截的。拦截到了网易发请求时发的是什么,然后在练习项目中需要获取数据的地方也把这一串链接直接拿过来用即可。
产品开发初期测试人员应该做什么?

产品开发初期测试人员应该做什么?

测试

产品开发初期需要测试人员吗?如果需要,他们要作哪些工作?这些问题曾经被很多朋友问起。据我个人了解,很多国内中小型公司是不注重产品开发初期乃至整个开发过程中的测试工作的。例证一:有些公司认为在设计初期投入测试人员是代价高昂且无意义的,所以他们会要求产品开发的第一个周期结束后,开始设计测试用例。例证二:认为测试工程师不需要参与到制定需求中,他们只要接受就可以了。于是乎,就出现了市场部门和开发部门直接沟通项目需求,测试经理直接参考需求设计文档的状况。例证三:测试经理确实在产品开发初期参与项目需求的制定,并写出测试计划。但产品质量却是现场部署的工程师说了算。到了现场,发现这里不合用户的意,那里运行不过。为了赶时间,只好坐在用户现场直接调试。改代码的改代码,调试的调试,哪里还管着产品是否需要全面的测试,只要能运行起来,用户能用,就是胜利权且不说这些管理行为是否更加浪费工钱,我们应该很容易得到关于产品开发初期测试人员该做些什么的一致答复:测试计划在开发初期能写挺好,不写也没什么问题。测试一定要做的。但把怎样的产品交给用户是不确定的。目标就有一个,让用户用上再说无论是对一个已经经营多年的产品,还是一个刚起步的公司其实,对测试的理解不是点头说,测试很重要就够了; 对测试的理解不是去声称,我们有一柜子完整的测试文档;对测试的理解也不是只关心做与不做,而全然不理测试的有效性。软件测试该如何理解如何执行,是一个很大的题目。在这里,我更关心的是在项目设计初期,我们该不该忽略测试人员,而测试人员又该做些什
程序员要有产品和测试思维

程序员要有产品和测试思维

测试

软件开发进度落后了,加大人员招聘,多找程序员呀,这是很多老板或者产品经理的想法,软件开发和搬砖一样,人越多进度越快。而实际情况呢?你加派人手可能不但没有变快,可能还会变得更扯皮变慢,多花冤枉钱。软件开发是一种讲求团队协作的工作,和打仗一样,不一定是人数多就能取胜,现在的快速反应部队人数都不多,但战斗力却可能抵御百倍的敌人。越是业务逻辑复杂的软件,越高价值的软件,越需要靠团队的技术积累和配合。当然,国内很多外包软件公司做的软件多是拷贝粘贴的工作,这种类型软件可能是需要人多,但产品质量方面就很让人堪忧了。早期的谷歌一直强调软件工程师以一当百,根本不相信当时流行的观点,一个大任务细化后,让初级程序员也能写代码,谷歌最著名的GFS和MapReduce框架,从设计到实现,一共三四个人干了2年,而据说同样的事情,微软投入上百人做了5年。在当前软件开发行业,越来越强调用户需求的快速反应能力。老的开发方式文档堆积,需求文档按要求刚写好,可能需求又发生变化了,导致很多文档其实是远远落后于实际代码情况的。之前,做了一次钉钉智慧门店的对接,发现文档的很多地方都和实际情况又出入,大公司尚且如此,更不用说很多中小公司了。团队开发想要敏捷起来,光学习敏捷理论知识是完全不行的,团队程序员个人能力到位才是策略真正能够执行到位的根本。快速反应部队是在军事课堂里面听课训练出来的吗?快速反应部队从选人,训练,演习和实战都有成套的体系,软件开发团队要敏捷起来也是一样的,需要精选基础好和自学能力强的有潜力的程序员,而且还需要经过反复的理论培训,练习培训和实战来提升个人技能和团队协作能力。优秀的程序员必须是具有产品思维和测试思维的,最好还有运维的思维并且沟通能力强,为什么呢?现在普遍的思想是术业有专攻,产品经理负责产品,程序员负责开发,测试团队负责测试,似乎是分工明确,但实际情况是什么样的呢?看看下面的左右两组圆环,左边的4个看似覆盖了更大的面积,但之间的连接是不牢固的,右边的4个圆环有一定重叠,相互 的连接是非常牢固的,同理,软件开发团队成员之间知识没有重叠,则协作是脆弱的。越是复杂的项目,团队协作就越重要,因为团队协作导致的BUG应该在80%以上,而且因为团队成员相互不了解对方的情况和思路,导致相互扯皮和责任推诿情况非常严重。管理技术团队10多年,常常看到开发的前端和后台互相只强调自己的观点,而听不懂对方的观点,导致技术讨论陷入相互对牛弹琴的抬杠僵局,常常需要我给他们双方进行协调解释。反之,如果大家相互理解对方的领域,就容易实现全局最优的认识,而全局最优才是软件开发团队真正需要追求的。因为相互理解,就会在己端开发中考虑到对方的方便,就和球队传球队员要考虑接球队员方便一样。下面我列举一些典型的团队协作当中的问题。产品方面的误区产品经理认为软件开发就是敲敲代码,功能实现不了是程序员能力不行,而且软件修改起来是很容易的。而且很多产品经理因为没有做过编程,导致功能设计前后本身就有逻辑矛盾问题,后期又进行调整,导致程序员有抵触情绪,尤其是在任务紧的情况下,持续进入一个恶性循环。如果公司对产品经理进行KPI考核,则产品经理就网上到处去抄功能,反正提出的功能越多说明能力越强,而不去全面考虑这些功能当前是否真正能运营起来,是否真的能够带来经济效益,因为人家火的不代表自己就能火,而这些没有经过仔细思考的功能都压向开发团队。我遇到很多产品经理希望和淘宝等大公司比,说你看人家淘宝加载请求多快呀。就这个问题,他不明白淘宝图片加载快,是有多少CDN支撑着呢,当然开发是可以通过一定优化改善加载,但很多硬性条件是不好和大公司比较的,你这样比较,难免会引起开发团队的反感。开发方面的误区开发团队认为产品经理为啥不能把需求一次都搞明白了,为啥要变来变去,因为他们不知道即使
产品经理入门 ——产品测试

产品经理入门 ——产品测试

测试产品

关于测试一、测试的定义测试是使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。测试的对象包括文档、数据、程序。测试越早越好。前期缺陷修复成本很低,越后期修复缺陷的成本就越高,且指数增长!二、产品测试中的相关概念1、白盒测试和黑盒测试(1)白盒测试:是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法,溢出,路径,条件等等中的缺点或者错误,进而加以修正。(2)黑盒测试:又被称为功能测试、数据驱动测试或基于规格说明的测试,是通过使用整个软件或某种软件功能来严格地测试。2、冒烟测试冒烟测试就是完成一个新版本的开发后,对该版本最基本的功能进行尽可能全的测试,保证基本的功能和流程能走通。如果不通过,则打回开发那边重新开发;如果通过测试,才会进行下一步的测试(集成测试、系统测试等等)。3、系统测试产品经理测试验收产品一般是在系统测试阶段,系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、兼容性测试、性能测试。其中功能测试是最主要的一种测试类型,一般说测试就是功能测试。功能测试主要针对包括功能可用性、功能实现程度(功能流程业务流程、数据处理业务数据处理)方面的测试。(1)功能测试:对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到所要求的功能。(2)界面测试:也称UI测试,测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯。此外还要测试界面操作便捷性、导航简单易懂性,页面元素的可用性,界面中文字是否正确,命名是否统一,页面是否美观,文字、图片组合是否完美等。(3)可靠性测试:对软件或者硬件的一种质量测试,用来检测产品是否存在不可靠因素,比如硬件老化。(4)易用性测试:指用户使用软件时是否感觉方便,主要特点为易理解性、易学性、易操作性、吸引性、易用的依从性,比如是否最多点击鼠标三次就可以达到用户的目的。易用性和可用性存在一定的区别,可用性是指是否可以使用,强调软件可运行性,而易用性是指是否方便使用,强调用户体验,是交互的适应性、功能性和有效性的集中体现。(5)兼容性测试:主要测试软件是否能在不同的操作系统平台上兼容,是否能在不同的设备上兼容;软件本身能否向前或向后兼容;软件能否与其他相关的软件兼容;数据是否兼容,主要是指数据能否共享等。(6)性能测试:通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试。性能测试可以分为: 应用在客户端性能的测试:主