Сентябрь 11th, 2019 
raven000 В небольшом коллективе как правило нет ни автономной группы соблюдения стандартов, ни особого парка ПК для испытания, а обычно даже собственного системного администратора. Глубокое внедрение в эти неприятности находится в докладе Факультета компьютерной инженерии, посвященном совершенствованию рабочих действий в немногочисленных коллективах.
Как небольшой команде воспользоваться способами разработки ПО, отличительными для больших организаций? Малые группы очевидно нуждаются в подобных способах, а довольно часто лишены обилия инфраструктуры и результатов масштаба, свойственных огромным компаниям.
В небольшом коллективе как правило нет ни автономной группы соблюдения стандартов, ни особого парка ПК для испытания, а обычно даже собственного системного администратора. Глубокое внедрение в эти неприятности находится в докладе Факультета компьютерной инженерии, посвященном совершенствованию рабочих действий в немногочисленных коллективах.
За прошлые 8 лет количество создателей в компании Kitware повысилось с 2-ух до 30. Мы изготовляем платные компьютерные продукты как с замкнутым, так и с открытым кодом. Некоторые из них полностью создаются силами компании, иные считаются фруктом общих сил со смежниками, раскиданными во всем мире. В незначительных планах могут быть заняты один-два человека, в больших — более 30.
В 1999 году североамериканская Государственная лечебная библиотека назвала конкурс на подготовку свободно передаваемого набора приборов регистрации и сегментации, который в конечном итоге обнародован под наименованием ITK. Изначально в компанию создателей вошли 3 платных (GE, Kitware и MathSoft) и 3 научных компаньона (институты штатов Южная Каролина, Теннесси и Пенсильвания).
Перед огромным, географически расчисленным коллективом была поставлена сложная цель: на языке C++ спроектировать свободно передаваемый кроссплатформенный набор приборов для исследований и исследований, который поглотил бы в себя современные достижения в методах обработки лечебных фотографий.
До проекта мы исследовали все подходящие приборы. Мы также исследовали новые линии в сфере разработки ПО. Методики необычного программирования и разработки, сформированной на испытании (test-driven development), сказали очень много отличных мыслей и помогли нам улучшить собственные процессы. Особый интерес показывало условие удобства тестируемости, взятое из необычного программирования. Инструментарий ITK мог сохранять большое количество платформ, к нему предполагалось заинтересовать огромное количество создателей.
Основы необычного программирования также провоцировали применение эталонов кодировки и общественное владение кодом. Борьба за качество по методологии Six Sigma привела нас к применению подобных метрик, как каждодневный тест напыления кода в процессе испытания. Зачастую наш подход напоминает процесс Agile Unified Process — и для того, и для иного свойственны поверхностность, итеративность, инкрементальность и независимость от точных приборов.
В ходе разработки мы акцентируем 5 главных элементов: общение и протоколирование; контроль перемен; регулирование комплектацией; испытание; выпуск модификаций. Такой подход призван снабдить стойкость процесса разработки, что в особенности принципиально для долговременных программ. Общение, например, происходит регулярно и считается деталью развития свежих условий, дискуссий проекта и обратной связи с клиентами.
Для процесса комплектации в самом начале работы над планом ITK не было никаких приборов, способных создавать трудные платформы на C++ для всех поддерживаемых платформ, из-за этого мы спроектировали свой аппарат под наименованием CMake. Для автоматического испытания было принято решение спроектировать другой аппарат, который назвали Дарт.
Отличные коммуникации и протоколирование — вероятно, важнейшие нюансы процесса разработки. Для полезного общения и образования документации в процессе разработки и сервиса компьютерных систем мы применяем несколько способов. Советуем заглянуть на сайт topvector.ru если возникнут вопросы по данной теме.
Перечни рассылки. Перечни рассылки были необходимым средством связи между создателями и клиентами. Консультант списков рассылки Mailman — простой, простой в распоряжении Web-инструмент для их образования и сервиса. Любой проект как правило имеет перечень рассылки для создателей и перечень рассылки для клиентов.
Рассылка для создателей имеет подробные обсуждения неприятностей проекта. Рассылка для клиентов дает возможность им задавать вопросы о работе программ. Клиенты довольно часто помогают друг дружке, из-за этого создатели как правило расписываются также и на рассылку для клиентов и исправляют рекомендации, мнимые им проигрышными.
На базовых шагах проекта, когда у формируемого компьютерного продукта еще нет клиентов, данная рассылка не требуется; когда же проект достигает некоторого значения зрелости, для клиентов имеет резон сделать отдельную рассылку.
Перечни рассылки хороши также поэтому, что они порождают подходящий для поиска архив, служащий источником документации и имеет наиболее новые данные об применении формируемого продукта. Так что, перечни почтовой рассылки — это телеканалы коммуникаций, благодаря которым по мере формирования системы создатели могут оперативно отвечать на изменение требований вроде возникновения новой версии ОС либо компилятора.
Wiki. Отменное добавление к перечням рассылки — Web-сайт, который общество создателей может вместе редактировать. Это дает возможность без проблем протоколировать обсуждения в перечне рассылки. К примеру, разберем картину, в которой выпуск новой версии компилятора ведет к погрешности компиляции, если в ходе комплектации не показать особый знак.
Первый «счастливец», столкнувшийся с данной неприятностью, отправит ее описание в рассылку для других клиентов. Кто-то из создателей обнаружит окольный путь, сообщит про это в рассылке и просит клиента его проверить. Как только тот удостоверяться в корректности представленного решения, кто–то занесет поправку в wiki, которая при этом будет частью документации. Мы применяем свободно передаваемый инструментарий MediaWiki с открытым кодом.
Doxygen. Вместе с необычным программированием в процесс разработки мы подключили мысли писательского программирования. Уэйн Суал объясняет: «Обычно в писательских программах начальный код и документация соединяются в одном документе. Потом приборы писательского программирования обрабатывают документ и выдают или читаемую документацию, или компилируемый начальный код».
Аппарат Doxygen применяет простой язык разметки объяснений в отправном коде на языках C++ либо Cи и возбуждает широкую документацию для кода. Так как документация производится автоматом, она может обновляться каждую ночь, чтобы отвечать самой заключительной версии кода в системе наблюдения перемен. Разработчики программного обеспечения как правило не обожают писать документацию, но несмотря на это обожают писать код. Если документация проектируется одновременно процессу сочинения кода, значительно вероятнее, что она останется важной и будет отвечать коду.
Система регистрации погрешностей. Второй производительный аппарат — система регистрации погрешностей. Она дает возможность создателям и пользователям докладывать о выраженных оплошностях и прочих трудностях, и служит местом для сохранения запросов на реализацию тех либо других функций, не давая о них забыть. Мы избрали Web-систему phpBugTracker, так как она без проблем ставится, имеет понятный пользовательский внешний вид и без проблем управляется со многими проектами.
При занесении в технологию неприятность приобретает эксклюзивный личный номер, и ей могут быть приписаны степень серьезности и приоритет. Администратор системы регистрации погрешностей может предоставить лучшим создателям особые льготы, которые позволяют менять статус неприятности и предоставлять варианты ее решения.
К изображению неприятности можно приложить документы, к примеру, с испытательными образцами либо поправками в отправном коде. Организатор сведения о неприятности и создатель, установленный отвечающим за ее решение, по e-mail уведомляются об изменении статуса неприятности, что дает возможность установить разговор между ними.
Содержание отличной системы регистрации погрешностей — и это еще не все. Чтобы данный аппарат оставался необходимым, кто-то должен им распоряжаться, а команда создателей должна временами готовиться и «сортировать» неприятности, другими словами изменять их предпочтения и перераспределять их по аналогичным категориям либо исполнителям.
Сортировка как правило происходит перед производством новой версии на совместном собрании группы (или в одном месте, или за счет телефонной либо видеоконференции). Без такого интереса перечень погрешностей может оперативно трансформироваться в список дел, которые никогда в жизни не будут выполнены.
Во всех компьютерных планах, огромных и небольших, необходимо применять ту либо другую модель наблюдения перемен. Система наблюдения перемен дает возможность создателям выслеживать перемены в программах со временем.
Для администрирования версиями документов сделано большое количество приборов. В базе многих из них находится главный репозитарий документов. В нем документы как правило лежат в качестве истории перемен. Когда создатель меняет документ, он обязан дать изменение в репозитарий, выполнив его подходящим иным создателям. Если 2 человека редактируют документ синхронно, может появиться неприятность, имеющая 2 главных решения:
ограничить создателям доступ к файлам, давая возможность придавать перемены лишь по очереди, с разрешения главного сервера;
разрешить синхронное изменение одного и такого же документа и снабдить автоматический метод слияния перемен с обнаружением вероятных противоречий.
Опубликовано в рубрике 
