Maverick_ 10 Posted September 24, 2018 · Report post собственно сабж в теме прошу поделиться опытом Quote Ответить с цитированием Share this post Link to post Share on other sites
quato_a 0 Posted September 24, 2018 · Report post собственно сабж в теме прошу поделиться опытом - есть один ведущий по проекту, остальные разработчики - на основе ТЗ должны четко определиться что и как делать, разделить ответственность по функциональным блокам. осуждение до тех пор, пока все не станет прозрачно и ясно (стремиться к этому) - четкое определение протоколов / времянок / интерфейсов / сигналов взаимодействия между блоками - работа в разных ветках svn/git, потом слитие в главную ветку. либо работа в одной, но без пересечений - проверка / верификация блоков после написания, перед слитием в главную ветку - должны быть тестовые стенды на каждые функциональные блоки, покрывающие максимальное кол-во возможных режимов работы блоков - крайне желательно, выработать единый стиль написания кода как то так :laughing: ... - на основе ТЗ должны четко определиться что и как делать, разделить ответственность по функциональным блокам. осуждение до тех пор, пока все не станет прозрачно и ясно (стремиться к этому) ... обсуждение :biggrin: хотя осуждение тоже подходит Quote Ответить с цитированием Share this post Link to post Share on other sites
Maverick_ 10 Posted September 24, 2018 · Report post - есть один ведущий по проекту, остальные разработчики - на основе ТЗ должны четко определиться что и как делать, разделить ответственность по функциональным блокам. осуждение до тех пор, пока все не станет прозрачно и ясно (стремиться к этому) - четкое определение протоколов / времянок / интерфейсов / сигналов взаимодействия между блоками - работа в разных ветках svn/git, потом слитие в главную ветку. либо работа в одной, но без пересечений - проверка / верификация блоков после написания, перед слитием в главную ветку - должны быть тестовые стенды на каждые функциональные блоки, покрывающие максимальное кол-во возможных режимов работы блоков - крайне желательно, выработать единый стиль написания кода как то так :laughing: обсуждение :biggrin: хотя осуждение тоже подходит Спасибо,. Жаль что так мало людей деляться опытом... Quote Ответить с цитированием Share this post Link to post Share on other sites
Leka 0 Posted September 24, 2018 · Report post Один с головой, генерит и воплощает идеи, делает только то, что другие не могут, никакой черновой работы. Остальные работают мальчиками на побегушках. Quote Ответить с цитированием Share this post Link to post Share on other sites
eugen_pcad_ru 0 Posted September 24, 2018 · Report post Да, принцип Покрышкина: один сбивает, другие загоняют ) Иногда проект ведется поэтапно. Одновременная правка проекта приводила к непонятным результатам. Quote Ответить с цитированием Share this post Link to post Share on other sites
x736C 0 Posted September 24, 2018 · Report post Еще бы добавил из книги Reuse Methodology Manual for System-on-a-Chip Designs такую банальность. Использовать стоит стандартные шинные интерфейсы для всех блоков всех участников проекта. Более того, если это, например, Альтера, то лучше прямо их Avalon и использовать. Это сильно упрощает, ускоряет интеграцию и отладку проекта. Совсем непопулярная мысль среди разработчиков, но тем не менее это мое личное мнение, которое никому не навязываю. Не стоит сильно думать, имхо, о переносимости проектов между вендорами. 99,99% таких забот оказываются невостребованными. Наоборот, лучше использовать стандартные процы и корки от производителей ПЛИС. Т.к. бывает текучка кадров, то найти замену, и самому разработчику будет легко въехать в стандартный проц. Поддержки много, вагон информации, примеров, средства отладки и все такое. В общем, пром. стандарт он и есть. Quote Ответить с цитированием Share this post Link to post Share on other sites
Koluchiy 0 Posted September 25, 2018 · Report post Правильный ответ на Ваш вопрос сильно зависит от размера коллектива, масштабности задач и их количества. 1000 маленьких проектов делаются не так, как один большой. Quote Ответить с цитированием Share this post Link to post Share on other sites
lexx 0 Posted September 26, 2018 · Report post quato_a выше уже высказал основную мысль, Четкое разделение по задачам и срокам (стараться их соблюдать, но всегда подразумевается изначальная поправка по срокам). Интерфейсы должны быть однозначно документально и подробно описаны, многие проблемы идут из-за недопонимания друг друга, даже если это кажется прозрачно. Один никак не потянет бОльшую часть проекта, основная идея может быть, но не все. Денег это не добавит (при нормальном руководстве нет супер звезд, но много профессионалов), только гемор и куча переработки (не всегда оплачиваемой). Поэтому изначально куча документации по дизайну, больше расскажешь - меньше проблем с интерфейсами. Далее стандартная имплементация, если не лезть на другую половину, то сроки можно предсказать. На какой размер/проект рассчитана команда, в зависимости от задачи размер и специализация тимы/тимов будут различны. Где-то дизайн/тестирование/имплементация это различные тимы, а где-то один человек, все по разному, зависит от уровня работ, величина и периодичность проектов. P.S. я больше по ASIC, с FPGA все немного по другому Quote Ответить с цитированием Share this post Link to post Share on other sites
Viktuar 0 Posted September 26, 2018 · Report post Совсем непопулярная мысль среди разработчиков, но тем не менее это мое личное мнение, которое никому не навязываю. Странно, что не популярная, Алексей. Мне казалось, что это вполне очевидно для большинства. :wacko: :wacko: :wacko: А чем аргументируют? Quote Ответить с цитированием Share this post Link to post Share on other sites
Нивхурил 0 Posted September 26, 2018 · Report post А чем аргументируют? Содомиты окрестъ, азъ же единъ Добрыня Никитичь есмь! В общем, любят велосипеды изобретать и самых умных из себя строить. при этом, конечно, определённых вполне измеримых преимуществ они достигают, зато, как правило, даже не задумываются над ситуацией, когда хоть что-то пойдёт не так. Quote Ответить с цитированием Share this post Link to post Share on other sites
x736C 0 Posted September 26, 2018 · Report post Странно, что не популярная, Алексей. Мне казалось, что это вполне очевидно для большинства. :wacko: :wacko: :wacko: А чем аргументируют? Вы меня с кем-то перепутали, я не Алексей. Но аргументируют тем, что не хотят привязываться к вендору, есть стремление сделать платформонезависимый проект. Оно и понятно, и логично. И есть проекты, когда так и надо проектировать. Но в большинстве случаев для проектов на ПЛИС (без ASIC перспектив) намного раньше, чем необходимость сменить вендора, случаются иные события. Увольнения, закрытие проекта и т.п. Сегодня основной критерий, через который надо оценивать приемлемость подходов, это время воплощения проекта в жизнь. Причем не только на уровне предприятия или коллектива, но и на своем сугубо личном уровне, исходя из своих шкурных интересов. Все остальное очень сильно вторично. Намного более вторично, чем многие считают. Все выше сказанное всего лишь мое скромное мнение, основанное в том числе на разных «фейлах». Quote Ответить с цитированием Share this post Link to post Share on other sites
