Система контроля версий не плохая штука, помогает… Рефакторинг и кодревью использовать только в меру, не злоупотреблять. Рефакторинг не должен приводить к «Эффекту второй системы». Кодревью должно провеодиться часто для новых сотрудников и изредко для давно работающих, для того чтоб помочь увидеть того, что разработчик не заметил.
Использовал gSOAP в небольших проектах. Очень не плохая штука, когда надо быстро наладить транспорт меж клиентом и сервером. Оч хорошо при работе если клиент и сервер на C++. Был проект на C++ сервер и на PHP клиент — поимели немало проблем, но, думаю, это особенности работы с SOAP на PHP.
Модифицируем ваш пример немного, точнее его использование class TestClass
{
public:
...
void _setStr(std::string s)
{
propStr = s;
}
Property<std::string, TestClass, WriteOnly> testStr;
private:
...
std::string propStr;
};
int main()
{
TestClass t;
{
TestClass *t1 = new TestClass;
t1->testStr = "1";
t = *t1;
delete t1;
}
t.testStr = "12";
...
return 0;
}
И все падант. Почему? В пропертях нет конструктора копирования, а есть поинтер на владельца.
Не зря на собеседованиях по C++ много гоняют на конструкторы \ деструкторы. В определенный момент подобные лаги выхватываешь взглядом на первом проходе глазками по коду :)
Так же хотелось бы как-то избегать падений если я забыл вызвать Init для проперти, ну человеческое исключение хотяб кидать, а не просто вылетать по битому указателю.
Сеттеры хотелось бы писать в стиле void _setStr(const std::string &s)
{
propStr = s;
}
т.е. передавать значения по ссылке, не все пропертя могут быть легкими интегральными типами, мб. и тяжелые объекты
Согласен, у стартапа должен быть человек, т.е., тот, кто владеет идеей и, главное, видит как ее реализовать, внедрить.
Однако, зачастую, что мы имеем на самом деле: человек, что-то придумав, найдя или стащив идею, находит под нее инвестора, потом под эти деньги находится команда, все изображают рабочий процесс, причем не наигранно, а реально с эмоциями :)
Что происходит на самом деле: основной стартапер просто сидит и ничего не делает упивается свободой после офиса :), времена истерит, что надо что-то показать инвестору, но только когда тот его пнет никак не ранее, команда — каждый суслик в поле агроном, т.е. каждый пытается наиграться технологиями, которые ему были интересны, но не изучены и за счет инвестора прикрываясь благими идеями и не полной компетенцией основного стартапера, т.е учим, что себе интересно за чей-то счет.
Итог: проект зачастую загибается просуществовав некоторое время, мб до нескольких лет! Так и не дойдя до первого релиза. Члены команды тоже не остаются хорошего мнения друг о друге, так как в проекте были лебедем, раком и щукой, т.е. кому какая технология «в игрушки» была более интересна.
Считаю, что для выхода проекта в релиз команда должна быть дружна, должен быть четкий лидер принимающий решения и ведущий к цели, ТЗ или как можно блее близкое видение идеи оформленное в документе, хорошие комуникации с заказчиком ну и его адекватность.
class TestClass
{
public:
...
void _setStr(std::string s)
{
propStr = s;
}
Property<std::string, TestClass, WriteOnly> testStr;
private:
...
std::string propStr;
};
int main()
{
TestClass t;
{
TestClass *t1 = new TestClass;
t1->testStr = "1";
t = *t1;
delete t1;
}
t.testStr = "12";
...
return 0;
}
И все падант. Почему? В пропертях нет конструктора копирования, а есть поинтер на владельца.
Не зря на собеседованиях по C++ много гоняют на конструкторы \ деструкторы. В определенный момент подобные лаги выхватываешь взглядом на первом проходе глазками по коду :)
Так же хотелось бы как-то избегать падений если я забыл вызвать Init для проперти, ну человеческое исключение хотяб кидать, а не просто вылетать по битому указателю.
Сеттеры хотелось бы писать в стиле
void _setStr(const std::string &s)
{
propStr = s;
}
т.е. передавать значения по ссылке, не все пропертя могут быть легкими интегральными типами, мб. и тяжелые объекты
Однако, зачастую, что мы имеем на самом деле: человек, что-то придумав, найдя или стащив идею, находит под нее инвестора, потом под эти деньги находится команда, все изображают рабочий процесс, причем не наигранно, а реально с эмоциями :)
Что происходит на самом деле: основной стартапер просто сидит и ничего не делает упивается свободой после офиса :), времена истерит, что надо что-то показать инвестору, но только когда тот его пнет никак не ранее, команда — каждый суслик в поле агроном, т.е. каждый пытается наиграться технологиями, которые ему были интересны, но не изучены и за счет инвестора прикрываясь благими идеями и не полной компетенцией основного стартапера, т.е учим, что себе интересно за чей-то счет.
Итог: проект зачастую загибается просуществовав некоторое время, мб до нескольких лет! Так и не дойдя до первого релиза. Члены команды тоже не остаются хорошего мнения друг о друге, так как в проекте были лебедем, раком и щукой, т.е. кому какая технология «в игрушки» была более интересна.
Считаю, что для выхода проекта в релиз команда должна быть дружна, должен быть четкий лидер принимающий решения и ведущий к цели, ТЗ или как можно блее близкое видение идеи оформленное в документе, хорошие комуникации с заказчиком ну и его адекватность.