Мне удалось поработать в разных программистских командах - от 5 до 5000 человек и в разных парадигмах управления процессом. Что я вынес: 1. Для большинства задач, которые стоит решать, оптимальным является "метод главного программиста", определённый по-моему Бруксом младшим. Максимум эффективности и минимум менеджмента. Команда - до 10 человек. Что творится внутри никто не знает, но на выходе замечательный работающий код. 2. Когда человек от 10 до пары сотен - хороши средства управления проектом. Только не очень заорганизованные, как теперешние. Когда-то я их сам писал. С задачами, группами и авторассылками. Теперешние вроде Jira имеют достаточный функционал, но требуют чисто технического мышления, как мне кажется. В них хорошо работать инженерам, но не учёным. Плюс пара единиц админов в штате. 3. В больших проектах - система управления проектом - это единственное средство, позволяющее менеджерам хоть как-то понимать, что происходит. Хотя на деле находятся умники, правящие код без учёта в системе, что сильно снижает эффективность. Кроме того, о "методе главного программиста", похоже забыли. Это превращает продукт в кошмарную кашу из заплат, которые ставят вчерашние студенты на коде вполне зрелых спецов. Спасает ситуацию производства реально хорошего программиста в высшие менеджеры - это спасает проект. А потом - снова неразбериха, стресс, переработки и недовольные пользователи продукта. 4. Контроль версий хорош всегда, даже если в него не заглядывать по пол-года. Когда-нибудь он поможет быстро решить багу. 5. Моё поколение выросло на статье "Настоящие программисты не используют Паскаль". Вернее, те, кто её приняли и поняли, до сих пор рулят процессом и вполне дружат со средствами его организации.
Да, про Рефал. Поскольку язык не линейный, разобраться в логике быстро несколько сложнее привычными методами если что-то сломалось или логика хромает. Поэтому дисциплина разработчиков должна быть на высоте (комментарии и читаемость кода). Возможно, лучше всего анализировать код средствами того же Рефала. Т.е. помимо компилятора нужен IDE с плагинами на Рефале. И сообществу Рефала выгодно его развивать. Я слышал про разработки на базе eclipse, но там Java (?) в основе и не слишком складная среда по моему мнению. И охочая до ресурсов памяти. У меня IDE в плане, но не в близком. >Понедельник, 2 декабря 2019, 18:04 +03:00 от Andrei Klimov >andrei_AT_klimov.net <refal@botik.ru>: > >On Mon, Dec 2, 2019 at 5:30 PM Александр Коновалов a.v.konovalov87_AT_mail.ru >< refal@botik.ru > wrote: >>Как это ни парадоксально, но так и должно быть. Но только в сочетании с >>системой управления версиями и системой управления проектом (таск-трекером, >>баг-трекером: Bugzilla , Redmine , Jira , issues в GitHub …). >>При этом должна соблюдаться определённая дисциплина (пересказываю статью >>Gaperton ’а «Миф о документации, продолжение»). >>1. Любой код пишется только в рамках заявки (« тикета », «бага», >>«таска») в таск-трекере . Заявка — или ошибка ( багрепорт ), или задача, >>поставленная руководителем. Самодеятельность запрещена. >>2. Обсуждение задачи должно вестись только в комментариях к заявке (не в >> чятиках , не в курилке, не в личной переписке). Таск-трекеры интегрируются >>с почтой, поэтому можно писать письма таск-трекеру с соответствующей темой, >>они сами подошьются к заявке (и разошлются другим, подписанным на заявку). >>3. В сообщении коммита пишется понятный осмысленный комментарий и номер >>заявки, к которой код относится. Желательно в один коммит не валить правки >>разного назначения (стилевые, рефакторинг , содержательные, по разным >>задачам). >>4. Коммит перед публикацией в системе контроля версий проходит ревью у >>другого программиста. Ревьюер должен проверить код как содержательно (решает >>ли он поставленную задачу), так и на читабельность, понятность, актуальность >>комментариев и соответствие стилю оформления. Ревьюер разделяет >>ответственность за код. >Александр, для бизнес-программирования, когда коммиты сразу идут в сборку и в >работу, действительно, это все полезно. >Но есть многие программистские задачи, когда это "over-management". Он не >менее вреден и удорожает разработку, чем "недо-менеджмент". >Например, во всех случаях, когда код не идет сразу в работу, а система >достаточно долго развивается и тестируется внутри коллектива разработчивов. >Скажем, таковой является разработка компилятора. > >Каждому менеджменту свое место. Следование методологиям по книжкам – это по >молодости. > >Андрей > С уважением, Александр Гусев gusev_aleksa...@mail.ru
