软件开发中的妥协

- 比如说 [Dribbble](https://dribbble.com/) 这些漂亮的设计稿，有多少会向技术妥协？
- 比如说 [Technology Radar | ThoughtWorks](https://www.thoughtworks.com/radar) 这些牛逼哄哄的新鲜技术，又有多少要向需求妥协？
- 乏善可陈的遗留代码，再好的测试驱动开发和重构方法论，又有多少要向短暂的时间周期妥协？
- 不能有重复代码的完美主义，追求复用性的诱惑，又会有多少要向业务领域的不同而刻意建模妥协？

当计算机科学的抽象层级越高，你到底该专注于什么？业务、产品、设计、宣传…

被减少的开发成本，又应当如何最大程度减少浪费？在没有出问题之前，是否就应该最大程序地相信当前的方案选择？=> 开源方案的靠谱性，现有轮子对开发成本的利弊分析，ref: [开源软件那么多，我们该如何选择 – ThoughtWorks洞见](http://insights.thoughtworkers.org/how-to-choose-oss/)

当你使用 `requests.get()` `requests.post()` 这样的简洁的 API 就可以轻松处理数据的通信问题之后，你是不是该更加专注于前端的数据展示？

当你使用现成组件就可以构建具有清晰的结构性页面时，你是不是就该更加专注于样式以及排版设计？

```jsx

```

当设计风格与交互逻辑越来越趋于一致（iOS 扁平化，Android 材料化设计）之后，你是不是该更加专注于产品本身的内容价值？

```yaml
---
layout: post
title: 基于 GitHub 的敏捷学习方法之道与术
categories: [思考]
tags: [学习, GitHub, 成长, 敏捷, 知识]
published: True

---
```
------

资深人士诱导、发掘、整理用户需求——反复折腾原型
高手选择、创建适合的运行框架——多方论证、攻击
熟手实现、丰富具体的功能——基本不会歪、不会折腾了

via [软件开发中没有所谓正确的方法 | 外刊IT评论](http://www.vaikan.com/there-is-no-right-way-to-develop-software/)