写代码

一、 啊啊啊啊啊，李健好帅啊！ 男神男神！ 健哥翻唱的等你下课好听炸了，为什么有声音这么苏的人哪！每首歌都很仙~ 清华高材生，温文尔雅，才华横溢，唱歌巨好听，啊嘛，我的心脏砰砰跳，迷恋上你的微笑~ 从此我也是有男神的人了！ 二、 华为的模拟机试也是够了 说好的什么语言都行呢？还不是限制了c和javao(╯□╰)o 常年用python的我，已经不记得C++行末要加分号变量要定义了..(灬ꈍ ꈍ灬) 三、 好像发现时间都是怎么溜走的了。 打开编辑器想写个代码，噢开个音乐边听边写吧，哎这个酷狗怎么不能添加音乐啦，那我去下个网易云吧，嗯电脑怎么这么卡？我先去卸载几个软件再去安装吧，诶这个软件卸载好慢呀我先去吃个饭吧，嗯吃个饭回来该睡觉了，睡醒想着该写代码了，欸我打开编辑器就想去听个歌。。。。。。 所以啊，做事情要一心一意，不能开新进程，写代码的时候音乐能听就听不能听换手机听就没那么多事了。 四、 ？？？现在的人这么疯狂了吗？ 不说了，我也想做大神的女朋友。。。。或者男朋友也行。 来源： https://www.cnblogs.com/EstherLjy/p/9322139.html

“如果你喜欢一个人，就应该尽量少说那些甜言蜜语。”不知道大家是否听过某些恋爱专家的肺腑之言。对于程序员来说，如果你热爱编码，那么我也劝你：“能少写一行代码就尽量少写一行。” 可能有些同学觉得这话听起来有点玄乎：“代码写得少，不就意味着缺乏实战经验吗？那我何年何月才能进一线大厂，成为真正的大神呢？” 如果你要这么理解的话，我就必须要纠正你一下。我表达的意思是这样的，来通过两行简短的代码表情达意吧。 if (str == null || "" .equals(str)) {} if (StringUtils.isEmpty()) {} 就上面这两行代码来说，我的第一选择是使用第二行代码来进行判空操作，因为它的代码量更少——简洁明了，也更不容易出错。 如果我们程序员没有这种（写更少代码的）追求的话，那我们的编程技艺就只会原地踏步，长此以往的后果就是各种避免重复造轮子的第三方类库就不会出现。 就判空操作来说， str == null || "".equals(str) 已经干得非常漂亮了（null 和空字符串都考虑在内了），但性能仍然有待优化，可以使用更高效的 str == null || str.length() == 0 来替代。为什么这么说呢？ 因为 Sting 类的 equals() 方法本身是很沉重的，其源码如下所示。 public boolean equals (Object

“如果你喜欢一个人，就应该尽量少说那些甜言蜜语。”不知道大家是否听过某些恋爱专家的肺腑之言。对于程序员来说，如果你热爱编码，那么我也劝你：“能少写一行代码就尽量少写一行。” 可能有些同学觉得这话听起来有点玄乎：“代码写得少，不就意味着缺乏实战经验吗？那我何年何月才能进一线大厂，成为真正的大神呢？” 如果你要这么理解的话，我就必须要纠正你一下。我表达的意思是这样的，来通过两行简短的代码表情达意吧。 if (str == null || "".equals(str)) {}if (StringUtils.isEmpty()) {} 就上面这两行代码来说，我的第一选择是使用第二行代码来进行判空操作，因为它的代码量更少——简洁明了，也更不容易出错。 如果我们程序员没有这种（写更少代码的）追求的话，那我们的编程技艺就只会原地踏步，长此以往的后果就是各种避免重复造轮子的第三方类库就不会出现。 就判空操作来说， str == null || "".equals(str) 已经干得非常漂亮了（null 和空字符串都考虑在内了），但性能仍然有待优化，可以使用更高效的 str == null || str.length() == 0 来替代。为什么这么说呢？ 因为 Sting 类的 equals() 方法 本身是很沉重的，其源码如下所示。 public boolean equals(Object

可以从代码的规范性、完整性、健壮性、扩展性等几个方面提高代码的质量。 （1） 代码的规范性 书写清晰、布局清晰、命名合理； 书写清晰：可以写慢一点，但是字迹清晰； 布局清晰：缩进，以及代码的风格统一； 命名合理：变量命令，函数命名，尽量用容易理解的命名；不用魔数等； （2） 代码的完整性 是否完成了基本功能、输入边界值是否能得到正确的输出、是否对各种不合规范的非法输入做出了合理的错误处理： 从功能测试、边界测试和负面测试三方面设计测试用例； （2.1.1）普通功能测试 比如面试题要求完成的功能是把字符串转换成整数，应聘者就可以考虑输入字符串“123”来测试自己写的代码。这里要把零、正数（比如123）和负数（比如-123）都考虑进去。 各种边界值的测试用例： （2.1.2）边界测试 很多代码都包含有循环或者递归。如果代码是基于循环，那么结束循环的边界条件是否正确？基于循环的代码要特别注意开区间和闭区间的使用； 如果代码是基于递归，递归终止的边界值是否正确？ （2.1.3）非法输入测试（负面测试） 应聘者写出的函数除了要顺利地完成要求的功能之外，当输入不符合要求时，面试官还希望他能做出合理的错误处理。 （3） 扩展性以及可维护性 在软件开发过程中，永远不变的就是需求会一直改变。如果应聘者在面试时写出的代码能够把将来需求可能的变化都考虑进去，在需求发生变化时能够尽量减少代码改动的风险

有自己的开发风格，在我看来是一个开发成长过程中的里程碑。 我也是最近才敢意识自己有一些风格了。在这里简单说说。 首先JavaScript： 方法要求单一职责原则。 一个方法一定有完整的逻辑开始部分和结束部分，是一个整体。 方法尽可能减少无用的变量声明。除了降低副作用还要避免多余的变量占用内存。 考虑用设计模式解决复杂问题。目前成功应用的有策略模式来解决多条件选择问题。 职责链模式解决多异步先后执行问题。 状态模式解决多状态问题。 考虑用面向对象简化问题。 利用分流函数控制不可控的浏览器行为。 利用防抖函数控制人为的点击行为。 减少全局作用域的使用，尤其window。不使用window，至少可以减少一层作用域链。 利用闭包实现全局变量的缓存效果。 要有合理的注释。 开发单页面的一些风格或者原则。以vue为例说明。 使用混用mixin减少代码重复。 使用组件化封装组件，实现组件复用。 使用全局拦截器做一些共用的ajax逻辑。 使用vue的原型，将全局配置挂载在上面。 页面销毁时候清除定时器。 css部分 使用编译器时候，利用编译器减少重复代码。 利用deep 修改组件内部的样式 考虑多屏，考虑屏幕的变化，即便是在做pc端开发 考虑缩放效果 考虑用户的使用习惯 多使用类优于id和行内 html 文字用p 标题用h系列 icon用i 标签用label 块占用用div 内联无意义用span

也许文章的标题起的带有讽刺的味道，其实这也是本人的一个小小的疑问。 一个项目的领导者该不该对技术有一点深度的了解或者说项目经理应该是一个不错的高级程序员。我的头跟我说项目经理不需要写代码也不需要对技术有多了解，只要对项目的进度有个整体的把控就OK了。这种观念一开始我不太赞同，项目经理对技术的实现没有一定的了解，在安排进度的时候是不是会草率的了事。给程序员预留的时间也不能准确的控制好，是不是会导致项目的进度控制的不太合理； 在参与开发项目的时候尤其是有一定技术含量的时候，更要项目经理对技术的实现有自己独特的见解，能帮助程序员理清头绪。但是话说回来，项目经理不可能帮每个程序员都去解决技术问题。在一些中小企业，项目经理显的很“肥胖”，这种“肥胖”完全是脱俗的，对技术似乎已经到了一种炉火纯青的高度，总觉得技术无非就是增、删、改、查。这也是我的头跟我说的，程序员就是做增、删、改、查的。没有多少技术含量，敲来敲去都是那些东西。做为程序员的我们不太喜欢听这样的话，技术的深奥是不能用这种片面的话来概括的。 我们搞技术的，在领导看来常常有一种毛病，什么毛病呢？就是我们在解决技术问题的时候，喜欢较劲。领导会这么想也有他的道理，领导希望能把项目赶紧做完。在进度上领导永远最关心，不喜欢我们为了一个小小的技术问题，而耽误大量的时间。哪怕换一种相当麻烦的实现手段也行，保证进度第一。如果没个程序员都这样想

写呀写代码，2019 你都写了多少行代码呀 文章目录 自己动手实现一个代码统计工具 导入所需的库 定义要读取的文件地址 指定你要读取的文件类型 遍历目录 / 文件 代码分析 读取代码行数 代码测试 全部代码 打包成可执行程序 注意： 如果只是需要代码运行的可以直接点击目录中的 全部代码 哦 自己动手实现一个代码统计工具 导入所需的库 这个程序需要用到的库有：os，time 这两个库都是 Python 自带的，所以我们直接 import 就行 import os import time 现在我们已经导入要使用的库了，可以直接写代码了 定义要读取的文件地址 首先，我们定义一个路径吧，因为要读取文件统计代码行数嘛 # 指定读取的路径 base_dir = './' # 定义一个文件列表 file_lists = [ ] base_dir ：假设我们读取的是当前目录下的目录 / 文件 file_lists：因为我们读取的文件不止一个，所以使用列表来存储 指定你要读取的文件类型 file_type = [ 'py' ] 这里以 Python 文件为例，因为代码是用 Python 写的嘛，所以读取 py 为后缀的文件 遍历目录 / 文件 上面我们定义了路径是 ./ （当前目录下），文件类型是 py 的，接下来我们需要遍历一下当前路径中的文件，代码如下： # 定义一个 getDir_or

大学毕业一年后，一个不是程序员的同学问：为什么程序员总是看着别人的代码不顺眼？当初的我，感觉这是对程序员赤裸裸的挑战，直接否认了：不是这样的吧？我就感觉某些人的代码挺好的。但是这个问题却一直记在心上。 工作了这么多年，一次测试提了一个Bug单，让我修改。这个模块我不太熟悉，但凭经验感觉不难，可是看到代码时，我的内心是：“唉呀妈呀，你个傻X，你写的这个是什么？”，但是我转念一想，对方这样写代表了他对这个功能的理解，只是我没有理解。忽然我好想找到了问题的答案。 程序员这个岗位和其他岗位有一个很大的差异：深度的思想合作。从业务理解，到方案设计，到实施时类的命名、变量名称、参数顺序。你的每一个决定，都会被合作者接触到，被以后的维护人员接触到，你的每一个决定都在和其他人的想法碰撞。所以能让人舒畅的理解意图，是多么的重要呀。难怪《Clean Code》这本书第一章，用了整整一章的篇幅来讲代码可读性的重要性。 这个就是我同学开始提出问题的答案：我认为程序员之间互相就看着不顺眼的主要原因是——没有能很好的使用程序语言表达意图。 我重新阅读代码，想找到问题原因 方法命名不好吗？看起来都挺对的。 变量命名不好吗？也不差。 函数太长吗？基本都在20行内，短得令人发指。 圈复杂度高吗？函数都不长，能复杂到哪里去呢？ 看起来代码符合各种开发规范，过程质量很不错，但是结果还是不易读。 经过一段时间的思考

效果图 html <!DOCTYPE html> < html > < head > < meta charset = " UTF-8 " > < title > Document </ title > < style > * { margin : 0 ; padding : 0 ; } .container { width : 840px ; background : #cccccc ; margin : auto ; padding-left : 10px ; overflow : hidden ; } .container ul { width : 200px ; margin-right : 10px ; float : left ; list-style : none ; } .container ul li { width : 200px ; position : relative ; background : white ; margin-top : 10px ; } .container ul li img { width : 100% ; height : 90% ; background : url("./images/timg.gif") no-repeat center ; } .container ul li p { height : 30px ;

测试分类 黑盒测试：不需要写代码，给输入值，看输出值是否与期望值相同。 白盒测试：需要写代码，关注程序具体的执行流程。 Junit使用白盒测试 步骤： 定义一个测试类（测试用例） 建议： * 测试类名：被测试的类名+Test ：CalculatorTest * 包名：xxx.xxx.xx.Test cn.edu.test 定义测试方法：可以独立运行 建议： * 方法名：test测试的方法名 testAdd（） * 返回值：void * 参数列表：空参 在方法上添加@Test 导入Junit依赖环境 判定结果： 红色：失败 绿色：成功 一般我们会使用断言操作来处理结果 Assert.assertEquals(期望的结果，运算的结果)； 补充： @Before: 修饰的方法在测试方法执行前被自动执行 @After： 修饰的方法会在测试方法执行后被自动执行。 来源： CSDN 作者： weixin_43649997 链接： https://blog.csdn.net/weixin_43649997/article/details/103927716