下午意外接到一个猎头的电话,居然打到公司来了.心想着我没有在网上挂简历啊,猎头怎么可能会找到我呢.再一想,可能是公司的的资料外泄出去了.接到电话时,对方直接说是猎头公司的,问我方不方便聊聊,我当时正忙,就直接说现在没时间.对方又问什么时候方便,我就说下班后吧,6点.
6点的时候猎头又打电话来了,于是随便聊了下.猎头问了下我使用的语言,职业规划,工作多长时间,对什么样的工作感兴趣,外语口语如何等等.于是发给我两份中英文模版,希望我能填填发给她.
转眼来上海工作都满两年了.每天工作都很忙,都没时间停下来反思,总结自己.也不知道自己是否真的学到了什么,价值几何了.是否真的应该检验下呢?
每天的工作:
沟通,与德国和美国同事沟通.一上班就要查看mail,回复紧急邮件.
计划,安排任务,.分配一天的task或bug给相应的team member.
完成自己部分的项目任务.
回答组员的问题,帮组作一些技术,方案上的决策,确任任务完成情况.
Daily report. 每天给全体组员发一份bug status 报告等.
Weekly meeting,每周一电话会议.
Weekly report.每周五一份report,报告本周主要做的事情及下周的工作安排.
Weekly总结会,组员在一起共享上周主要做的事情,一些心得体会,经验总结等等.
留心,总结一些项目经验,书面化共享至sharepoint.
与QA沟通,回答一些问题,确认一些defect的重现等等.
与PM沟通,汇报一些项目进展情况,处理一些杂事,如汇总加班情况等等.
... ...
总结起来主要是:
沟通:Tech lead, teamer, PM,PD,QA,
任务分配，时间安排。
决策.
总结.
进度表反映最新开发进展。维护一份稳定的schedule，再维护一份最新更改。
工作量最好先由每个人自己估算。
对意见不一的defect，可以开三国会议，要有一个明确的决策过程。
Weekly Report：目前进度，可能风险，质量状况，各种工作进展等。
Weekly Meeting：Team meeting,spec review meeting, bug triage meeting.
Sharepoint. Knowledge share.
定期组织team 成员开展组内training.
当你做决定，做变化时，告诉大家原因。只有tell me why 了才能更好的Understanding。
让Dev也能看到Test Plan\Case。都是为了同一个目的走到一起的，可以提高质量。项目中所有的东西都应是对大家透明的。
性能测试不要等到所有feature都完成后才做。应早测早改正。
成品应有统一的错误处理机制和报错界面。
要让team的每个成员了解项目的商业意义，激励。
产品各部分的界面和操作习惯应一致，就像是一个人写出来的一样。
Team Building: 增强团队凝聚力。
Team Logo. T-Shirt
Team Web Side.
Team Morale Activity:每月一次，吃饭，唱歌，outing, 打球，卡丁车等。
#include <windows.h>
#include <string>
//////////////////////////////////////////////////////////////////////////////
// Use of templates to call WIN32 API functions.
namespace win32 {
//////////////////////////////////////////////////////////////////////////////
template< class _Ch >
struct module_traits;
//////////////////////////////////////////////////////////////////////////////
class module {
typedef HMODULE _Myhandle;
public:
typedef _Myhandle handle_type;
typedef DWORD size_type;
static const size_type max_length = MAX_PATH;
module() :
m_handle(GetCurrentModule())
{ }
// No need to close module handles.
// TODO: check this assumption
~module()
{ }
// Using ::GetModuleFileName, obtain the full path name of m_handle.
template< class _Ch >
std::basic_string< _Ch >& get_filename(std::basic_string< _Ch >& _fn)
{
typedef module_traits< _Ch > _Tr;
_fn.resize(max_length);
size_type _n = _Tr::GetFileName(m_handle, &*_fn.begin(), max_length);
_fn.resize(_n);
return _fn;
}
// Using ::GetModuleFileName, obtain the full path name of m_handle.
template< class _Ch, class _AfxTr >
ATL::CStringT< _Ch, _AfxTr >&
get_filename(ATL::CStringT< _Ch, _AfxTr >& _fn)
{
typedef module_traits< _Ch > _Tr;
size_type _n = _Tr::GetFileName(m_handle, _fn.GetBuffer(max_length), max_length);
_fn.ReleaseBufferSetLength(_n);
return _fn;
}
// Using ::GetModuleFileName, obtain the full path name of m_handle.
template< class _Ch, size_t _Len >
size_type get_filename(_Ch (&_buff)[ _Len ])
{
typedef module_traits< _Ch > _Tr;
return _Tr::GetFileName(m_handle, _buff, _Len);
}
// Using ::GetModuleFileName, obtain the full path name of m_handle.
template< class _Ch >
size_type get_filename(_Ch* _buff, size_t _len)
{
typedef module_traits< _Ch > _Tr;
return _Tr::GetFileName(m_handle, _buff, _len);
}
private:
// TODO: implement this.
_Myhandle GetCurrentModule()
{ return NULL; }
_Myhandle m_handle;
};
//////////////////////////////////////////////////////////////////////////////
template< >
struct module_traits< char > {
static char space() { return ' '; }
static DWORD GetFileName(HMODULE _h, char* _buff, DWORD _size)
{ return ::GetModuleFileNameA(_h, _buff, _size); }
};
template< >
struct module_traits< wchar_t > {
static char space() { return L' '; }
static DWORD GetFileName(HMODULE _h, wchar_t* _buff, DWORD _size)
{ return ::GetModuleFileNameW(_h, _buff, _size); }
};
//////////////////////////////////////////////////////////////////////////////
}; // namespace win32
Client 1:
try {
// Get our module path and file name and save as m_self.
win32::module _self;
_self.get_filename(m_self);
// Locate our "home" directory and any other interesting places
// and tuck them away for later reference via GetApp().
int _slash = m_self.ReverseFind(_T('\\'));
if (_slash >= 0) {
m_bin = m_self.Left(_slash);
m_home = FindHome(m_bin);
} else {
m_bin = _T(".");
m_home = m_bin;
}
// This is our resource path.
m_res = m_home + _T("\\Resource");
// This is our help path.
m_help = m_home + _T("\\Help");
// Welcome dialog is entire application
//CWelcomeDlg welcomeDlg;
//m_pMainWnd = &welcomeDlg;
//welcomeDlg.DoModal();
m_pMainWnd = &m_WelcomeDlg;
m_WelcomeDlg.DoModal();
// Must not let MFC try to close this window!
m_pMainWnd = NULL;
}
catch (const std::exception& _ex) {
CString _what(_ex.what());
AfxMessageBox(_what);
}
Client 2:
// Provides standard stream output for CString.
template< class _Ch, class _Tr, class _AfxTr > inline
std::basic_ostream< _Ch, _Tr >&
operator<<(std::basic_ostream< _Ch, _Tr >& _out,
const ATL::CStringT< _Ch, _AfxTr >& _str)
{ return _out << static_cast<const _Ch*>(_str); }
int main(int _argc, char** _argv)
{
using namespace std;
win32::module _module;
std::string _filename;
_module.get_filename(_filename);
cout << "I am module: " << _filename << " -- hello, world!" << endl;
std::wstring _wfilename;
_module.get_filename(_wfilename);
wcout << L"I am module: " << _wfilename << L" -- hello, world!" << endl;
CStringA _cfilename;
_module.get_filename(_cfilename);
cout << "I am module: " << _cfilename << " -- hello, world!" << endl;
CStringW _cwfilename;
_module.get_filename(_cwfilename);
wcout << L"I am module: " << _cwfilename << L" -- hello, world!" << endl;
char _afilename[ 300 ];
_module.get_filename(_afilename);
cout << "I am module: " << _afilename << " -- hello, world!" << endl;
win32::GetModuleFileName(NULL, _afilename);
cout << "I am module: " << _afilename << " -- hello, world!" << endl;
return 0;
}
下午去博库书城看了下书.经不住诱惑,走的时候又买了两本: 曼昆的经济学原理下册宏观经济学部分和一本国际政治经济学.
来上海后平时有时间的时候经常去书店逛,在这里经常可以看到一些人提着购物篮买书,看着想要的就往篮子里仍,跟在超市买菜似的,而且好像书都不要钱一样,想想自己,碰到喜欢的还要左看有看价格,琢磨半天才能痛下决心.看看那些提着篮子买书的人,真似让人羡慕,心里暗想,等以后有钱了,也推个车子过把瘾:)
关于bug的管理，今天有了新的想法：
一。将所有bug都整理了下，将类似的，相关的，重复的，或原因相同，解决方案相同的bug各取一个简单的title然后放在一起。清晰明了。如：
Configuration:(解决方案相同)
50003....
50004....
Toolbar issue:
50005...
50006...
Caused by...
50007...
50008...
二： 决定每天向全体成员通报bug status情况，并用不同的颜色标识出来，包括
bug list，
当天新报的bug，
当天解决的bug，
正在研究的bug，
已经解决的bug
谁解决的，解决日期。等。
昨天整个Dev team 和QA team 参加bug bush。这是我第一次参加bug bush。
前天下午我们就放下手中的bug开始准备工作：排列test metrix，安装虚拟机，os，相应软件，看相应feature的spec和test plan。一下午安装相应的软件对有的人来说够用，但是对我来说不够。我测试的是Replicator部分，因为很忙，我直到快下班的时候才有时间开始准备工作，结果到晚上九点半的时候都没有把我要测试部分装好，这个部分我本身就不熟悉，其安装有很复杂，装过它的QA又都回去了。没办法只好第二天上班再安装了。
分给我测试的feature我一点都不熟悉，spec 和test plan没时间看，只好打印了spec回家争取能扫一眼，足足四份，几十页啊。事实上，紧张了一天，回家后根本就看不进去，何况还是英文的。
结果昨天又花了一天时间，我这部分的环境还是没装好。怎么测？不过光安装过程就发现了好几个bug，赶紧报了上去。快下班的时候就放弃了，随便点点看看能不能测出点什么。另外，应为spec，test plan都没看，根本就不知道要测什么，不过还是发现了几个一二级的bug，纯粹意外。
可能是白天太紧张了，晚上做了好多梦，梦里全是bug，bug，bug！醒了好几次，每次醒来的时候梦里发现的bug清晰可见，不过现在不记得了：）
bug bush的体会：
1. Test metrix 还是要精心设计一下的。比如一个同事要测试一个feature，但是她被分配的Role没有权限使用那个feature的全部功能，这就不周全了。
2. 这次Bug bush 安排developer 只装两台server，因为我要测Replicator，所以也装server，其他的人都是client。但是，可能是我再配置Replicator的网络的时候破坏了其中一台server，结果导致整个team突然全部都不能login进去那台server，下午3，4点的时候bug bush就进行不下去了。所以，如果是依赖于网络的话，一定得小心，最好是有应急方案。
3.这次Developer参加Bug bush原则上不能测试自己写的那部分。但是developer对别的feature有不熟悉，spec和test plan可能都没时间看。这时候测试效果就大打折扣了！这时候如果还是要求Developer也象QA一样把所有test case全部跑一边是不现实也不合理的，因为dev没测一个case需要一步一步先看描述再测试，这是很花时间的。一天的时间bug bush根本就测不了几个case，而且很有可能测试的那些case早就没有bug了，这不是浪费时间吗？
那么，该该采取怎样的策略呢？我也没想好。至少让dev象qa一样先熟悉所有的case也是不可能的，因为dev正忙于fix bug，根本就没有时间。
I have seen that you are sometimes using try blocks with empty catch() handlers.
Please don’t do it like this.
In last years we have also done it like that, but ‘hiding the symptoms is not the cure to the disease’
In any case, if something goes wrong, use the trace facilities in application to log something to the errlog.
And additionally you can use ASSERT(FALSE) statements to force a break into the debugger in debug builds.
Or you can leave the try catch altogether. The user then will get a crash dump he can send to us for further analysis.
Role | Name | Contact Info. |
Product Manager |
|
|
Product Marketing | ||
Product Design(PD) |
|
|
Project Management(PM) |
| |
SWD Developer |
|
|
SWD Manager |
|
|
Test Engineer(QA) |
|
|
Test Engineering Manager | ||
Usability Engineer | ||
DSS Engineer |
|
|
Localization | ||
Customer Support | ||
B&I |
Globalization and Localization.
Documentation.
Trademark and Credits.
Product name.
Building and Installation. (B&I)
Platform
DataBase
Performance
Project Status
Spec Status
Weekly Meeting
Weekly Report
Milestone | Date |
Concept Complete | |
Product Contract | |
Spec Freeze | |
Code Complete | |
Feature Complete | |
Installer Complete | |
Beta Release; Gunslinger | |
Message Freeze | |
SCO Freeze | |
ECO Freeze | |
Hard CCB( | |
Stopship CCB | |
ß-Testing with Selected Customers to Start | |
RTM | |
FCS |
For Reference: Personal Skills Tool
This table provides a selection of personal skills to choose from in the Personal Skills section of the Self Review and Development Plan.
Results focus & output | Meets commitments, deadlines and goals through job knowledge and application of skills. Focus on bottom-line results and proper planning. Can complete complex tasks and succeed. |
Analytical problem solving | Identifies problem situations in an appropriate time frame. Resourceful in gathering information to quickly analyze and resolve issues. |
Creativity | Seeks different perspectives when solving problems. Brings new solutions and ideas that have a constructive impact on the work environment. Inspires others to see problems from different angles. |
Quality | Accuracy, thoroughness, attention to detail. |
Cooperation | Cooperates with his/her team and other employees in the organization. Can understand other perspectives and act upon mutual goals. |
Communication | Clear, concise and meaningful written and verbal communication skills. Uses appropriate communication vehicles to keep others informed. Effective listening and comprehension skills, perceptive questioning techniques. Refers also to communication skills with customers (internal or external). |
Influencing others | Works cooperatively in group situations. Assists in diffusing issues. Good mediation skills. |
Planning ahead & dependability | Work prioritized and organized well. Sets measurable, realistic, well planned goals. Able to follow up and close action items independently. |
Flexibility | Adapts easily to changes in job or work environment. Deals with competing demands in an appropriate manner. Handles conflicting situations professionally. |
Technical competence | Expert in his/her work, facilitates and coaches other employees, is well appreciated by others for his/her professional knowledge – a center of technological knowledge. |
Time management | Able to organize own time on daily basis, prioritize tasks by identifying tasks of secondary importance and concentrate on high-priority tasks. |
Applicable to manager level only | |
Performance management skills | Addresses performance issues in timely manner. Provides employee feedback on regular basis to ensure alignment with established goals and objectives. Delegates responsibility appropriately. Plans the work and effectively solves problems accordingly. Facilitates the work of others by coaching, providing direction and exercising positive control when needed. |
Leadership skills | Able to influence others in support of work to be completed. Has established and maintains good working relationships with staff and peer group. |
Identification with company | Aligned with company needs/policy and represents the company to his/her team or department. |
Role | Name | Contact Info. |
Product Manager |
|
|
Product Marketing | ||
Product Design(PD) |
|
|
Project Management(PM) |
| |
SWD Developer |
|
|
SWD Manager |
|
|
Test Engineer(QA) |
|
|
Test Engineering Manager | ||
Usability Engineer | ||
DSS Engineer |
|
|
Localization | ||
Customer Support | ||
B&I |
Globalization and Localization.
Documentation.
Trademark and Credits.
Product name.
Building and Installation. (B&I)
Platform
DataBase
Performance
Project Status
Spec Status
Weekly Meeting
Weekly Report
Milestone | Date |
Concept Complete | |
Product Contract | |
Spec Freeze | |
Code Complete | |
Feature Complete | |
Installer Complete | |
Beta Release; Gunslinger | |
Message Freeze | |
SCO Freeze | |
ECO Freeze | |
Hard CCB( | |
Stopship CCB | |
ß-Testing with Selected Customers to Start | |
RTM | |
FCS |
优秀团队领导的四项素质：
核心成员的基本素质：
普通成员的主要指标：
出现link2019时可能的两种解决方法：
1. 可能是工程中缺少某个cpp文件。
方法： add 某个.h/.cpp文件。
2.设置 treat wchar_t as build-in Type 为yes.
方法：project property->C/C++->Language->Treat wchar_t as build-in Type 设置为yes.
VC7.1中此选项默认为no,而vc8默认为yes.
这里先将平时看书时记下的一些OO设计的原理，规则等整理了一下，罗列出来：
OO Basic
Abstraction
Encapsulation
Inheritance
Polymorphism
OO Objective
Reusable
Extensible
Maintainable
OO Bad Smells
Fragility
Rigidity
Immobility
Viscosity
OO Principles
SRP -- The Single Responsibility Principle.
A class should have only one reason to change.
OCP -- The Open Closed Principle.
Software entity should only be open for extension but
closed for modification.
LSP -- The Liskov Substitution Principle.
Subclasses should be substitutable for their base classes.
DIP -- The Dependency Inversion Principle.
Depend upon Abstractions. Do not depend upon
concretions.
ISP -- The Interface Segregation Principle.
Many client specific interfaces are better than one
general purpose interface
LoD -- The Law of Demeter
Any object receiving a message in a given method must
be one of a restricted set of objects.
CARP:
OO Rules
Rule1: Design to interfaces not implementation
Rule2: Favor composition over inheritance
Rule3: Encapsulate what varies
Rule4: Only tall to your friends
Rule5: Don't call us, we'll call you
Rule6: Depends on Abstraction not concrete class
Rule7: A Class should have only one reason to change
Rule8: Strive for loosely coupled designs between objects
that interact
Rule9: Strive for high cohesion
Rule10: Decoupling a problem domain into responsibility
Principles of Package Architecture
REP-- The Reuse Release Equivalency Principle.
The granule of reuse is the granule of release.
CCP-- The Common Closure Principle Principle.
Classes that change together, belong together.
CRP-- The Common Reuse Principle.
Classes that aren't reused together should not be grouped together.
ADP-- The Acyclic Dependencies Principle.
The dependencies betwen packages must not form cycles.
SDP-- The Stable Dependencies Principle.
Depend in the direction of stability.
SAP-- The Stable Abstractions Principle.
Stable packages should be abstract packages.
(To be continue…)
一直以来都想写一点东西，但是项目一忙起来就没有时间了，这个想法也一直的往后拖。每天面对的都是一堆又一堆的bug，埋头于大量的，琐碎的code之中感觉总也fix不完。每天好像都很忙，几乎没有时间静下来好好的思考，总结一下。偶尔问问自己我究竟在忙什么？学到了什么？又提升了多少？回答似乎有些苍白。
项目终于release了，终于有了一段奢侈的大块的时间来好好反思一下了，也算是对自己工作一年来的一点点总结。COMPASS 代码看了也将近一年了，还是感觉很陌生，对她的了解还是无法上升到设计，架构的层面。这样复杂而又灵活的的一个系统，当初如果没有一个宏观的而又思维严密的架构设计是不可能走到今天的。可以说，COMPASS的精髓我们还没有体会到。
考虑到以前学习模式时一直苦于没有很多的经验，看的多半是一些toy code, 而模式作为一个开发人员应具备的最基本的素质之一，对其理解没有一定的实际的经验是很难的。好在COMPASS中使用了很多的模式，而且一般也不是简单的套用GoF中的经典模式，而是有所超越，这是学习模式很好的实例。这里先给出已经看出来的一些模式列表，后面再一一说明。当然，COMPASS中的模式肯定不是只有这么一点，还需要不断的学习，发掘。
Pattern list of COMPASS:
1. Design Pattern in Compass ---Preface
2. Design Pattern in Compass ---OO Principle, Pattern and Design.
3. Design Pattern in Compass ---Evolution of Simple Factory, Factory Method and Abstract Simple Factory
Factory Method
Abstract Factory
4. Design Pattern in Compass ---Factory
CModuleFactory
CModuleContainerFacory
CDBObjDef
CChild
5. Design Pattern in Compass ---Singleton
CConnectionFactory
CConnectionList
CTempFileNaneFile
CUlmConfig
CDesigner
6. Design Pattern in Compass ---Builder
Menu
ToolBar
7. Design Pattern in Compass ---Command
CPublicFuncCMP
CSubstFunc
CIntervalTask
CADOCommand
8. Design Pattern in Compass---Proxy
CMultiFomatProxy
CDataBaseAccessItem
9. Design Pattern in Compass---Composite
CDBObjDef
UI
10. Design Pattern in Compass---Mediator
CEditKernel
11. Design Pattern in Compass---Observer
Add-In
12. Design Pattern in Compass--- Strategy
13. Design Pattern in Compass--- Template Method
14. Design Pattern in Compass---Iterator
15. Design Pattern in Compass---Façade
CObjectModel
16. Design Pattern in Compass---Iterpreter
17. Design Pattern in Compass--- Chain of Responsibility
18. Design Pattern in Compass--- Flyweight
Folder_*
Env
19. … …
模式的学习过程：
孔子有曰：吾十有五而志于学，三十而立，四十而不惑，五十而知天命，六十而耳顺，七十而从心所欲不逾矩。
―――《论语•为政》
孔子自言进道顺序的这段话，道出了他在不同的生命阶段不同的人生体验，然而异中有同，对于模式的学习我们同样也有这样的过程：
[十五志于学]：没有太多实践项目的经验，OO的思想也是处于混沌状 态，对模式的了解只是听说过这个词而已，写出的代码也只是局限于能实现功能。面对不断变化的需求，看着支离破碎的代码，欲哭无泪。。。这时，该学学模式了。
[三十而立]： 背熟了经典的23种模式，但也多半只是理论上的理解。能很快的识出别人用了哪些模式，看上去都很美，因此也急于在实践中运用，恨不得写一个hello world都要用上七八中模式。在设计却又困惑于不知道怎么运用模式，何时该用何种模式，何时又不该用。
[四十而不惑]：有了大量的实践经验，对模式的理解更加深刻了，能熟练的使用各种模式，重要的是理解了模式与模式之间的联系，能综合的运用模式了，但还不能算是有效的运用，设计中容易出现over-design的情况。
[五十知天命]：终于悟出了OO的真谛，能从OO Design Principle的角度看待各种模式，对模式的使用也趋于理性而娴熟。
[六十而耳顺,七十而从心所欲不逾矩]：一个优秀的架构师诞生了。。。
关于pattern的书：
自从95年GOF写出模式的经典之作后，市面上各种关于模式的书都接踵而出，网上关于模式的文章也多于牛毛。下面仅列出我看过的几本，网上对于它们的书评都很多，这里我也仅说一点自己的看法，他们都有自己的特点，各有侧重点。当然还有很多很好的，但没看过就不敢乱发一言了。
Design Pattern s:Elements of Reusable Object-Oriented Software
经典！优点就不多说了，就是过于简洁了一些，初学不太好懂。不过或许正是应为这种简洁才使它成为了经典。罗素曾经说过："我的雄心壮志是用十句话说出别人用一整本书说的话，说出别人用一整本书没说出来的话。"作者只用了23个词总结了23种常用而又有效的模式，后面很多人写的关于模式的书多半都使对其进一步的解释而已。
Design Patterns Explained
浅显易懂，入门级别的。
Java与模式
中国人写的，符合中国人的语言习惯，比较容易懂，也是入门级的，一千多页的砖头，一两天就可看完了，能很快的对各种模式很快就有个大致的印象。
Refactoring to Patterns
从Refactorying 的角度阐述如何一步一步将模式重构出来，看完后就有体会:噢，原来模式是这样被搞出来的！
http://projectserver/sites/MSD_DM/CompassPreview/Lists/Tech%20Discussion/DispForm.aspx?ID=23&Source=http%3A%2F%2Fprojectserver%2Fsites%2FMSD%5FDM%2FCompassPreview%2FLists%2FTech%2520Discussion%2FAllItems%2Easpx
Agile Software Development: Principle,Patterns, and Practices
侧重于从OO principle 的角度讲解各种模式。
Modern C++ Design
template 与模式的完美结合。属于高级篇了，买来半年多了尝试看了三次都夭折了。
Applying UML and Patterns
侧重于OO分析与设计中运用UML和Pattern.
.NET Patterns:Architecture, Design, and Process
介绍.net平台下开发的一些新的模式，基本上与GOF的模式不同了，很多模式的思想还是挺开眼界的。
Core J2EE Patterns: Best Practices and Design Strategies
Java 企业应用级的模式，架构师之路上必修课之一。不过一直都没时间看。
