每周完成一个 ARTS：

Algorithm: 每周至少做一个 LeetCode 的算法题

Review: 阅读并点评至少一篇英文技术文章

Tips: 学习至少一个技术技巧

Share: 分享一篇有观点和思考的技术文章



Algorithm

LC 49. Group Anagrams

class Solution {
    public List<List<String>> groupAnagrams(String[] strs) {
        if (strs.length == 0) return new ArrayList<>();

        Map<String, List> ans = new HashMap<String, List>();
        for (String s : strs) {
            char[] ca = s.toCharArray();
            Arrays.sort(ca);
            String key = String.valueOf(ca);
            if (!ans.containsKey(key)) ans.put(key, new ArrayList());
            ans.get(key).add(s);
        }
        return new ArrayList(ans.values());
    }
}



Review

Advanced iOS tutorial: Use MVVM to tackle complicated TableView

这看这篇文章的时候，这个网址还是可以正常打开的，但是要写review的时候网站却怎么都打不开了，只好凭着记忆写一写。

这篇文章主要讲的是，在tableview比较复杂时（每个cell都有不同的业务逻辑），通过将一个大的view model拆解成每个cell对应一个小的view model，来降低工程复杂度；通过定义通用的protocol来复用代码。

我自己最近开发的需求参考了这篇文章的思路，整体应用下来还是比较顺畅的：

1. vc持有所有view model，并在cell创建时set过去;

2. 交互事件继续由view controller来转发，这样会有一些便利，如日志上报；



Tips

使用JXCategoryTitleView实现了一个两级列表功能，接入过程比较顺畅，感觉这个库已经很成熟了。

目前碰到一个问题还没有解决，就是刚进入界面，跨多个title切换时，content区域动画过渡没法修改。



Share

“不要冲出前灯范围” -- 《程序员修炼之道》

冲出前灯范围指的是事情发展超出掌控。务实程序员的应对原则是：小步前进---由始至终。总是采用经过深思熟虑的小步骤，同时检查反馈，并在推进前不断调整。把反馈的频率当做速度限制，永远不要进行“太大”的步骤或任务。

怎么样的任务才算太大？任何大到需要“占卜”的任务。比如：

• 估计未来几个月之后的完成日期

• 为将来的维护或可扩展性预设方案

• 猜测用户将来的需求

• 猜测将来有什么技术可用



看完这节，想起了自己曾经做teamleader，总是试图去规划，去找事情做。这段经历的结果并不美好。一年多时间里，我自认为并没有找到很好的规划。这段经历就是比较典型的“超出前灯范围”：没有什么事情比着眼于眼前，解决、推进问题，随着车子稳步前进，一段时间后，回过头看就会发现其实已经做了不少事情。