На мой взгляд самое простое с чего можно начать процесс улучшения кода — это продумывание архитектуры приложения с точки зрения возможности его автоматизированного тестирования (не суть каким инструментом).
Наличие автоматизированных тестов — это правильный начальный шаг, позволяет быстро обеспечить достойный механизм проверки кода на регрессию.
Дальше нужно двигаться в сторону unit-тестирования и конечно же парного программирования.
У нас распределенный проект, планы по тестированию, тестовые наборы, кейсы и сам процесс прохождения тестов расположены в одном месте: www.devprom.net
Создаете базу тестовых наборов и тестировать может кто угодно из команды, результаты тестирования видны кому нужно и связаны с дальнейшими задачами по исправлению ошибок, а также с требованиями и т.п. Рекомендую.
интересный проект! ждем дальнейшего развития. А от себя предложу систему управления процессом разработки Вашего проекта: www.devprom.net, на мой взгляд она поможет быстрее развиться проекту в правильном направлении, которое подскажут пользователи.
И теперь самый главный вопрос: как ваша система позволяет определить сроки реализации некоего скоупа? и как система позволяет оценить скорость команды в целом?
1) как я понял, Вы хотите минимизировать риски и стоимость разработки своего решения. Если так, то именно с этой точки зрения и нужно выбирать технологическую платформу.
- Вы оценили во сколько встанет разработка мультиплатформенного решения на C++? разные машины, разные версии ОС (каждая версия со своими особенностями), нужные специалисты с опытом работы на mac/nix/windows
- Вы оценили стоимость сопровождения мультиплатформенного решения в связи с появлением новых версий ОС (всех возможных версий и вариантов)? Люди будут меняться, будут нужны постоянно сильные специалисты и целый зоопарк железа и софта со штатом сопровожденцев всего этого.
- Вы оценили знание командой (а как оценить знание людей со стороны?) всех тех инструментов и технологий, с которыми хотите работать? Если хотите быстро занять нишу или потеснить конкурентов, то должны очень быстро делать качественный продукт. Вашей команде под силу с этим справиться на C++ или Java?
- Вы оценили, что же больше всего нужно покупателям: ГУИ-конфетка? фукнциональность? портируемость? простота установки? Важно понимать, что между всем этим в любом случае будут компромиссы и сделать идеальное решение встанет очень дорого.
2) на мой взгляд в исходной постановке сделано несколько ошибок:
- крайне сложно и дорого сделать программу, которая будет работать ВЕЗДЕ, не используя при этом широкораспространенной абстракции (например, JVM). Необходимо сократить количество поддерживаемых платформ/версий ОС и для начала поиметь успех на этой нише. Если это случится, то у Вас будет достаточно средств для портирования или переписывания кода под нужную платформу.
- технологическая платформа должна выбираться исходя из опыта и умения тех людей, с кем Вы планируете работать. Не поддавайтесь желанию программистов познать новый инструмент за Ваш счет. То что идеально может использовать команда и нужно использовать.
- необходимо четко определиться в том, что Вы хотите продать рынку: красивую ничего неделалку или делалку с некоторыми ограничениями? Множества софта, который сделал кучу денег разработчику не особенно привлекателен и не соблюдает все современные тенденции в юзабилити - все же главное, это его функции.
3) исходя из всего этого мне видится, что
- если Вам действительно нужна возможность запустить приложение везде где только можно, то необходимо использовать Java и забить на красивости доступные в нативных библиотеках. Дешево и сердито.
- если Вам нужно очень качественное снаружи решение, простое в установке, минимально занимающее место, выполняющее все необходимые функции, длительное в разработке и сопровождении и при этом команда состоит в основном из C++еров, то лучше отказаться от многоплатформенности, портируемости (на время) и использовать C++
- если Вам нужно очень качественное снаружи решение, выполняющее все необходимые функции и сделать это быстро, но пожертвовать размером дистрибутива и простой его установки, и при этом команда состоит в основном из C++еров или C#еров, то лучше также отказаться от многоплатформенности, портируемости (на время) и использовать C#
- все остальные изыски (до этого был mainstream) можете использовать только если у Вас есть подходящая сработавшаяся команда, которая все это знает и знает чего от всего этого ожидать.
1) Если ваши пользователи хотят коммуницировать с разработчиками, то для этого нужно использовать соответствующий инструмент (багтрекинг или еще что-то). Коммуникация довольно быстрая и чистая: пользователь написал - разработчик (в общем смысле) увидел и отреагировал, пользователь видит результат (или его отсутствие, что тоже некоторый результат использования разрабатываемого продукта).
2) Любая активность, которая отражается на программном коде продукта проходит строго определенный набор фаз: анализ, проектирование, разработка/проверка, тестирование/багфиксинг, документирование. Все что касается остальных задач вытекающих из специфики данного продукта - это тоже некие активности, но выполняющиеся на одной из этих фаз.
3) Состояния, в которых может находиться, например, бага, определяются исключительно бизнес-процессом используемым в той или иной команде/организации. Но есть и безусловно обязательные: Назначено, Открыто, Выполнено.
То есть не нужно путать элементы стандартного процесса девелопмента (фазы имплементации) с организационной спецификой обработки некоторой задачи.
Общение пользователей и разработчиков просто обязано быть публичным вне зависимости от того, что пользователь хочет сообщить разработчикам или о чем узнать. Пользователь будет общаться неформально, поэтому описать такое общение багой, фичей или еще чем-то задача неблагодарная и непрактичная.
Другое дело, что круг пользователей может быть совершенно различным: постоянные пользователи, которым интересно развитие продукта - обязательно публичное общение с разработчиками, с большей степенью открытости; просто покупатели продукта, которых все устраивает - достаточно отправки сообщения по email.
Конечно не стоит заставлять пользователя искать ранее введенные похожие баги и т.п. Это должны делать разработчики, поскольку только им известно, что есть дубль, а что нет. Но пользователю НУЖНО показывать как заведенную им багу, так и все с ней связанные, заведенные другими пользователями, это даст возможность глубже понять проблему или шире понять контекст (например, Oracle Metalink)
В некоторых системах (JIRA, DEVPROM.net) пользователю предлагается вводить т.н. Issue (проблема по-русски). Что это на самом деле ошибка или доработка или просто бред - решать разработчикам (их менеджерам и аналитикам).
В процессе разработки любое Issue проходит по одному и тому же циклу разработки, поэтому нет смысла в отдельных workflow для каджой разновидности issue, при том что семантика такой разновидности может быть далеко не однозначной.
Планирование составов релизов и управление релизами/итерациями по методологиям семейства Agile отлично реализовано в Системе управления процессом разработки - http://www.devprom.net
а еще, все идеи по проекту очень пригодятся будущим разработчикам, таким образом нужно сформировать определенный информационный контекст без отрыва от контекста разработки.
можно было бы интегрироватья с уже готовой системой управления проектами по разработке: http://www.devprom.net
Наличие автоматизированных тестов — это правильный начальный шаг, позволяет быстро обеспечить достойный механизм проверки кода на регрессию.
Дальше нужно двигаться в сторону unit-тестирования и конечно же парного программирования.
Создаете базу тестовых наборов и тестировать может кто угодно из команды, результаты тестирования видны кому нужно и связаны с дальнейшими задачами по исправлению ошибок, а также с требованиями и т.п. Рекомендую.
Это больше подходит для профессиональной разработки ПО
Но совершенно забыли про перегрузку функций и методов.
Вообще это типичная ошибка объяснения полиморфизма только через наследование и переопределение поведения.
Шаблоны и подобные им инструменты также являются примером полиморфизма, но более высокого порядка.
- Вы оценили во сколько встанет разработка мультиплатформенного решения на C++? разные машины, разные версии ОС (каждая версия со своими особенностями), нужные специалисты с опытом работы на mac/nix/windows
- Вы оценили стоимость сопровождения мультиплатформенного решения в связи с появлением новых версий ОС (всех возможных версий и вариантов)? Люди будут меняться, будут нужны постоянно сильные специалисты и целый зоопарк железа и софта со штатом сопровожденцев всего этого.
- Вы оценили знание командой (а как оценить знание людей со стороны?) всех тех инструментов и технологий, с которыми хотите работать? Если хотите быстро занять нишу или потеснить конкурентов, то должны очень быстро делать качественный продукт. Вашей команде под силу с этим справиться на C++ или Java?
- Вы оценили, что же больше всего нужно покупателям: ГУИ-конфетка? фукнциональность? портируемость? простота установки? Важно понимать, что между всем этим в любом случае будут компромиссы и сделать идеальное решение встанет очень дорого.
2) на мой взгляд в исходной постановке сделано несколько ошибок:
- крайне сложно и дорого сделать программу, которая будет работать ВЕЗДЕ, не используя при этом широкораспространенной абстракции (например, JVM). Необходимо сократить количество поддерживаемых платформ/версий ОС и для начала поиметь успех на этой нише. Если это случится, то у Вас будет достаточно средств для портирования или переписывания кода под нужную платформу.
- технологическая платформа должна выбираться исходя из опыта и умения тех людей, с кем Вы планируете работать. Не поддавайтесь желанию программистов познать новый инструмент за Ваш счет. То что идеально может использовать команда и нужно использовать.
- необходимо четко определиться в том, что Вы хотите продать рынку: красивую ничего неделалку или делалку с некоторыми ограничениями? Множества софта, который сделал кучу денег разработчику не особенно привлекателен и не соблюдает все современные тенденции в юзабилити - все же главное, это его функции.
3) исходя из всего этого мне видится, что
- если Вам действительно нужна возможность запустить приложение везде где только можно, то необходимо использовать Java и забить на красивости доступные в нативных библиотеках. Дешево и сердито.
- если Вам нужно очень качественное снаружи решение, простое в установке, минимально занимающее место, выполняющее все необходимые функции, длительное в разработке и сопровождении и при этом команда состоит в основном из C++еров, то лучше отказаться от многоплатформенности, портируемости (на время) и использовать C++
- если Вам нужно очень качественное снаружи решение, выполняющее все необходимые функции и сделать это быстро, но пожертвовать размером дистрибутива и простой его установки, и при этом команда состоит в основном из C++еров или C#еров, то лучше также отказаться от многоплатформенности, портируемости (на время) и использовать C#
- все остальные изыски (до этого был mainstream) можете использовать только если у Вас есть подходящая сработавшаяся команда, которая все это знает и знает чего от всего этого ожидать.
2) Любая активность, которая отражается на программном коде продукта проходит строго определенный набор фаз: анализ, проектирование, разработка/проверка, тестирование/багфиксинг, документирование. Все что касается остальных задач вытекающих из специфики данного продукта - это тоже некие активности, но выполняющиеся на одной из этих фаз.
3) Состояния, в которых может находиться, например, бага, определяются исключительно бизнес-процессом используемым в той или иной команде/организации. Но есть и безусловно обязательные: Назначено, Открыто, Выполнено.
То есть не нужно путать элементы стандартного процесса девелопмента (фазы имплементации) с организационной спецификой обработки некоторой задачи.
Другое дело, что круг пользователей может быть совершенно различным: постоянные пользователи, которым интересно развитие продукта - обязательно публичное общение с разработчиками, с большей степенью открытости; просто покупатели продукта, которых все устраивает - достаточно отправки сообщения по email.
Конечно не стоит заставлять пользователя искать ранее введенные похожие баги и т.п. Это должны делать разработчики, поскольку только им известно, что есть дубль, а что нет. Но пользователю НУЖНО показывать как заведенную им багу, так и все с ней связанные, заведенные другими пользователями, это даст возможность глубже понять проблему или шире понять контекст (например, Oracle Metalink)
В некоторых системах (JIRA, DEVPROM.net) пользователю предлагается вводить т.н. Issue (проблема по-русски). Что это на самом деле ошибка или доработка или просто бред - решать разработчикам (их менеджерам и аналитикам).
В процессе разработки любое Issue проходит по одному и тому же циклу разработки, поэтому нет смысла в отдельных workflow для каджой разновидности issue, при том что семантика такой разновидности может быть далеко не однозначной.
можно было бы интегрироватья с уже готовой системой управления проектами по разработке: http://www.devprom.net