……你这问题也是云里雾里啊，交接 1800 行的汇编和 1800 行的配置的工作量能是一回事？有没设计文档？代码干什么的？

对于不那么大的多数 repo，我还就是“理论上是不是应该是 branch 出来改，阶段性改完再 merge 回 master”这样做的。这个做法最大的问题是自己有强迫症能统一就好说，跟别人协作的时候就未必那么痛快了。
“经常改一些注释说明，过一会儿又想起来了稍微改点，就频繁 commit 了”，这种情况（特别是同一个文件原地更新）属于同一个 feature 没做完，squash commit 是应该的。而且至少 git 做这个很容易（像 hg 这种历史不容篡改强迫症嘛……不过好歹有 mq ）。实际上更坑的经常是 push 太早了得 --force ……
测试用参数一般属于每用户配置，公开的 repo 不 commit，直接 ignore 排除掉。当然，如果你就是为了保存自己的配置才开的 repo 自然另当别论，取决于你愿意什么改动能在之后找得到。
另外，有的 repo 维护者会要求 squash/merge 优先，这个情况一般自然客随主便。

理想情况下，一个 feature 的固定改动能分隔依赖保持原子性且逻辑上含义明确的，那就应该切得越细越好。
不过有些太大的长期性 repo，实际有被 VCS （不一定是 git，有几个 VCS 之间同步的需求）性能太差而倒逼的情况，为了 commit 数不爆炸，就压缩 commit 了，十几个甚至几十个逻辑上的更改合并成一个（甚至把小的 feature branch 也直接压扁了），然后另外附加 log 描述局部改动。这样虽然工作量更大，但溯源起来反而更简单了。（想想 mozilla-central 的性能，那整个就是呵呵……）
相对来说，维持粒度的手工操作是很头疼但不是影响很大的问题，最大的问题是手工维护的工作量太大这件事……根本上来讲，VCS 要是不懂程序的语义（只会基于文本 diff ），这个问题是无解的，凉拌吧。

@VWWWWWWW 方校长不是自称常备几个威屁恩“测试”吗……（

除非是网红项目，hosting site 不用考虑社交属性。
我自己的某些 git repo 是几个主流的站上都放的，顺带当备份。不过另外有用 hg 的，因为 BitBucket 明年下线，大概还是得自己内网糊个 Phabricator 之类的实例……

好吧，其实是 LZ 在 7L 先跑题……
那就多说两句好了。
我说科班里在象牙塔的，指的是专门以学术研究讨生活的从业者。这些人大部分是和“写好代码”无缘的，因为衡量他们工作的绩效主要是看水了多少能发挥影响的 paper，普遍缺少适合他们解决的、需要把代码写好来体现完成度的问题。（因为工业界胡搅蛮缠的需求，研究怎么替人的烂代码擦屁股的倒是有不少，比如 pointer analysis……）这些人中很多比大部分其他人都有资质写好代码，但真能写好代码的又很少有兴趣呆的住。
OJ 玩家是另一个群落。OJ 选手最重要的素质是现场应变，知识积累和代码干净程度相对次要。好的 OJ 选手应该能避免“特么我一个小时前写的代码真傻×”“特么我一个小时前没想出这种解法拖了那么久真傻×”的情况，这和一般意义上写“好”代码解决更长效问题的人（实际上短时间得写好代码的运维或者安全操作人员你一般不会叫他们“写代码的”）不一样，后者不见得会在乎这类临场问题，但“特么那个谁（可能是自己）一年以前写的代码真傻×”的问题对这些“写代码的”可能就是灾难性的。这两方面的素质需要很不同的能力，同时具备两者能转型成功的很少，所以整体上没法比较。但一般来说，好汉不提当年勇，社招不是储备人员就不大待见只会刷题的本事了——出来混几年都没别的更能拿的出手的经验，你当你来应聘 OI 教练？这部分科班出身的落差就比较明显。
剩下的大多人……其实不太有机会能让你分辨出到底是不是科班出来的。因为基础教学上科班质量普遍不咋地，所以跟培训班出来的相比，未必能有直接的胜算。（当然，敢在简历造假的，正常来讲一段时间都会被刷掉。）

@enaxm 所以说是你先跑的题……
问题虽然是经，然而必要性上……恰恰相反，也许大多数人都需要反省——比如说，为什么会觉得算法和数据结构对写好代码重要？
倒不是说数据结构跟算法不重要，但是大部分现实情况下更重要的显然有很多，比如对要首先解决的问题本身的清晰理解，比如你所谓的“学科的知识体系结构”；反过来，上来就讲算法和数据结构如何关键的，基本就是外行。
实际上，对数据结构跟算法一窍不通的情况下，许多人已经有很多机会足够写出能合理解决问题的“好”的代码了。需要做的无非就是自己发明一遍当前需要的具体数据结构跟算法罢了。这比发明整个知识体系可是容易得多；能写“好”代码的，大概人人都有自己造出过没学过的算法和数据结构轮子的经历。（反倒是见得多了就没那么容易造新的了。）
另一方面，只会解决点书本题目而实际工作中用不大会的（不管科班不科班）到处都是一大把，还真没法指望“哪怕就只是当成工具来用会用比不会用的人当然要强”。
按你思路理解的科班在系统的学科知识积累上应该有明显优势，基于一般人对高等教育的认识来讲，看似是顺理成章地没问题；可惜现实就是这行的科班的专业整体教学质量从根本上就特别不咋地，观感落差巨大。我之前主要就是提醒这点事实罢了。
我说的科班还真不止是本科教育。像我拿来当例子的 PL 课一般本科阶段根本就不会开。（要算上跨专业什么的，本科教学质量其实还算是比较好的了。）
当然，本科教育是批判的重点：因为“写好代码”现实根本不会被作为专业和研究方向，之后的课程撑死能教的是“写怎么样的代码”，却不会再继续教“怎么写好代码”，没在本科阶段教好或者至少能让学生找到方向养成习惯，那基本就完犊子了。所以这里再怎么水也不应该流于通识教育。
而我说的质量差，主要也不是出自教学方法的问题（否则也不只是个别专业的问题），而是从材料质量开始的低劣——基础都别指望能教清楚。
你讲的另一方面则是显得叶公好龙，实在没法让人参考。
——形式化方法？和写好代码的关系是什么？你真的了解你在讲什么吗？你有应用过这样的方法解决过你遇到的“写好代码”相关的问题过吗？
我得说你明显发散过头了。形式化方法在“写好代码”相关的领域中专指建立特定的模型实现几个很具体的目的（现在能以代码体现的，基本只有规格化和验证）手段，知识工程的模型都很难算得上多少形式化，啥时候还和 consulting 行业能攀亲带故了？
LZ 另一个关心的话题是“哲学问题”。超过这个范畴，形式化方法和正经的哲学相关的部分还真有点关系，但这里都没提到，也都是陈年旧帐了，还没提什么前沿理论的必要。

@GentleSadness 在家福报咋地，，，

@augustheart 我本人不习惯依赖代码提示、lint 或者日常编辑时运行的工具检查代码，所以这方面体验不太深刻。
据我所知 VS 除了 cl 以外的这种代码处理的杂活外包给了 EDG frontend，这坨是给很多其它编译器当公版用的实现，所以至少不应该特别差； jb 这种没相关技术积累的厂商短时间想自己整一套，打不过是正常的。
但有个问题是，在关注准确度的场合（例如编译器），EDG 和 cl 长期都不如 clang++（以前经常是 cl 不靠谱，现在变成 EDG 落后了）；而且 EDG 和 cl 之间的不一致通常会比“慢”导致更大的体验问题。（因此我现在也基本把 IntelliSense 什么的都关了，不是因为会更快，而是红线眼不见为净。）
只是考虑代码提示，准确性自然可以再放宽，不过仍然是越准确越好。效率不够高主要是实现本身不够优化的问题，技术上这不应该成为瓶颈。可以预见现在语言迭代得那么混乱，不管是哪个厂商都还会把 conformance 视为第一顺位的 feature，所以 clang 想要快可能还需要一段时间；另一方面我看不到 VS 里的实现具体是因为什么优势而快，很难说这段时间 VS 里的实现为了改善准确性就不会渐渐变得和 clang 一样慢了。

@enaxm 虽然 LZ 的看法不怎么上道，但你也不要盲目拔高科班的水平。
为了妥协学生对知识接受能力不足的现状，科班的基础课普遍偏向通识教育，说白了就是水货——甚至有的基本课程一大坨（比如说，C 语言）就是错的或者聊胜于无（比如说，组成原理）。不但科班的象牙塔指望的靠谱的科研水准根本就没法靠科班堆砌出来，搞工程也不能指望。
更进一步地，系统性地理解上的不靠谱，这不仅是隔行隔山的问题。即便是相关专业方向的教育，不少也是挺水的。例如，像专门上过 PL 课的学生，在 referential transparency 这种基础概念的理解来讲相比真正搞相关方向科研的专业人士也是弟中弟，因为教科书上根本就不会全面概括，导致除了最相关的方向以外这些人以外的理解普遍上都稀里糊涂的：
http://www.itu.dk/people/sestoft/papers/SondergaardSestoft1990.pdf
注意我特别举这个例子，是因为这个概念早就不只是科研上过气没显著性，而工程界像什么 dssq 一样各种瞎扯；然而能凭自己的本事知道这里有 misconception/inconsistency，并找到靠谱来源的，又有几个？恐怕 99%的科班出身的童鞋都达不到“有能力注意到问题在哪”的资质，更别说解决问题避免不靠谱的结论扩散了。

@xiaotianhu 如果你真只是纠结写代码，那么到最后就是自己撸语言——设计怎么写代码的根本方案，没有别的出路。2L 所谓的形式化方法到最后也就是撸一坨知道得人稍微多一点的 DSL 的套路而已，哲学上跟着 Hilbert 之流早就破产了。
UNIX 设计哲学跟写代码的问题差远了，而且跟怎么写代码相比完全是下游的位置，而不是指导或决定怎么把代码写好的。强行搅在一起就不可避免会扯到一大坨烂摊子。某种意义 UNIX 为代表的玩意儿整体上为什么不得不设计成这样，也是因为没法一次搞干净“（让用户）怎么写代码”的问题：
https://github.com/FrankHB/pl-docs/blob/master/zh-CN/about-operating-systems.md

@augustheart C++用 clang_tidy 这种不是什么大问题，clang 出来就是有“你们 IDE 厂别自己管自己撸一套半吊子辣鸡，能我上就我上”的意思。反过来 VS 的 IntelliSense 和自家的 cl 两套都是半吊子，划红线那个效果真是 mdzz……
这里真正显示 jb 家的问题在于，这种语言相关复杂度又高的活都给更专业的擦屁股完了，整合个 UI 外壳就好，居然体验还是那么辣鸡……

套不套壳都是翔啊。
不数落 Web 本身了，你先给我整个同时支持 XUL 和 WebExtensions 的浏览器外壳出来？
外壳技术混乱不值一提的话，光说脚本引擎好了——你给我整个完整支持 ES6 并且不歧视 JIT 的实现？

https://github.com/FrankHB/pl-docs/issues/6#issuecomment-445440510
坚持 1803 路线不动摇，，，

@zhangjinglongi 就算这里 title 上的都是叒鸡，你 JVM 啥时候能自举啊……
@mamahaha 那么问题来了，拿什么来实现入门的作业？
@abcbuzhiming 一样逃不出格林斯潘第十定律的魔爪。

@exploreXin 分工来说，工程师这类职业，只要有跟得上业界发展的素质，理应是凭经验越老越吃香的，实际呢……恐怕还真不如农民了。
贱人贱己贱行业，早就不是个别人的问题了。

因为“工程”对这些人实际的干活来讲就没什么存在感，只是在头衔上占坑不是不觉得更可悲吗……

草，写反了，，“尽量依赖 native API 的 wxWidget 就比自造轮子的 QtWidget 靠谱”→“尽量依赖 native API 的 wxWidget 就不会比自造轮子的 QtWidget 靠谱”……