面试时怎么描述项目经历

[u013043408]

本人已有5年C++开发经验，但做过的项目都是技术很简单，业务逻辑复杂那种。
昨天去面试，介绍了一个做了半年才完成的项目，被面试官嘲讽我的项目太简单了。
心里很委屈，技术虽然简单，但功能多、内部逻辑复杂、还需要了解行业知识才能懂需求。

想问一下，面试官不关注项目功能、业务逻辑吗？
光说技术，80%的代码都是if else等简单语法，怎么破？

[ooolinux]

什么项目被面试官炒粉简单的，数据库增删改查吗？如果都是自己设计（包括数据库定义），也是很有含量的。

[伽利略打小怪兽]

引用 1 楼 ooolinux 的回复:

什么项目被面试官炒粉简单的，数据库增删改查吗？如果都是自己设计（包括数据库定义），也是很有含量的。

一个客户端，界面用的MFC，内部基本就是逻辑代码了。感觉她不关心业务逻辑，重点就在我用MFC自绘控件这种简单的事情上了，还一直说为什么不用开源的界面库呢。

[赵4老师]

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George 前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

[636f6c696e]

要讲的复杂，如果项目真的很简单的话，可以讲讲遇到的一些比较难的问题，以及如何克服的