ARTS|Week 1 第一次使用 LeetCode
ARTS 是极客时间推出的一个打卡活动,通过 100 天的关于 Algorithm、Review、Tip 和 Share 的刻意训练,来实现进阶。
1. Algorithm
要求:每周至少做一个 LeetCode 算法题,为了编程训练和学习。
实际时间花费:90 分钟
算法题目
算法题链接:Two Sum
给定一个整形数组和目标值,从数组中找出两个数,其和等于目标值,并输出这两个数的索引。
题目分析
本题主要有两种方法:暴力(brute force)和映射(hash map)
暴力解法:通过两层循环遍历数组以得到所有的组合,将组合数与目标值进行对比,若相同则结束循环(因为假设 1 的存在)
映射:通过增加一个映射表以将循环缩减至一层。遍历数组中的元素,通过目标值与元素的差值与映射表中记录的元素进行对比,若符合则结束循环。
代码
我是通过 Python 来对算法进行实现。
暴力解法:
通过字典来优化:
两种算法的运行效率对比:
2. Review
阅读并点评至少一篇技术文章,通过英文技术文章来学习英文。
实际时间花费:40 分钟
前 Apple 工程师谈 iOS 13 和 Catalina 如此 Buggy 的 6 个原因
文章链接:https://tidbits.com/2019/10/21/six-reasons-why-ios-13-and-catalina-are-so-buggy/
我的点评
关注 Apple 动态的人,可能都感受到了 iOS 13 和 Catalina 系统的不稳定。本文是有着 18 年 Apple 软件工程师经验的 DAVID SHAYER 在 2019 年 10 月写的一篇文章,阐述了他的一些看法,共 6 点。
要做的新功能太多了,而 iOS 和 macOS 的系统更新的日期是固定的,导致没时间打磨。
崩溃问题永远是高优先级的问题,但是 Apple 内置的崩溃报告并不能报告一些非崩溃的问题。
在开发后期阶段,主要是修改影响新功能或者导致崩溃的一些严重的 Bug,并且会优先处理 Support 提交的问题,这导致很多不是很常见或不严重的问题一直往后排。
唯 Regression 主义,导致一些一直存在的 bugs 很有可能永远都不会被修复了。
自动化测试覆盖率不高,只有部分部门,如电池、Safari 等才引入大量的自动化测试。
Apple 软件生态的复杂性一直在爆增,如多核、多线程、不同设备之间的通讯等。
新词:Schedule Chicken
Schedule Chicken 是项目管理或软件开发过程中的一个概念。当一个目标涉及到多方参与时,即使在知道不可能在时间表内达成目标,也都声称会按照原定计划来完成自己的任务。每一方都期望另一方能率先承认/暴露自己的失败,从而为大的目标的延期而担责。
3. Tip
学习至少一个技术技巧,为了总结和归纳日常工作中遇到的知识点。
实际时间花费:每天 5 分钟
善用 GTD
日常工作中,一般会有每周计划,并且通过 GitHub 的 issues 来管理要做的事情,但还是属于比较「泛」的计划,到真正每天要去做事情时,粒度还是太大。
周末时,终于在自己的日常生活和工作中,将 GTD 方法和工具用了起来,我是通过 Things 3 来计划和管理每周(周日做一个整周的大致计划)及每天(前一晚 Review 并重新计划)的事情。对一些较为大的目标,可以通过 Things 3 来分解为更小粒度的待办事项,从而更好的计划和跟踪。
通过待办事项,能相对「机械」的去完成工作内容,且相对更有条理。
4. Share
分享一篇有观点和思考的技术文章,为了建立影响力、输出价值观。
实际时间:90 分钟
初识 LeetCode
由于我是通过 ARTS 这个活动,第一次使用 LeetCode,这周便针对 LeetCode 的使用做了一个简单的介绍
主要是介绍了 LeetCode 是一个 Online Judge 平台,包含大量真实的面试题库,有完善的社区、讨论和参考,内置的编辑器能让练习者专注于算法的实现。 对我来说,为什么要刷 LeetCode,以及一些关于 LeetCode 的参考文章。
具体文章可参考:https://blog.csdn.net/puran1218/article/details/106379678
版权声明: 本文为 InfoQ 作者【Puran】的原创文章。
原文链接:【http://xie.infoq.cn/article/12ad8f28efec9b13fd0983706】。文章转载请联系作者。
评论