Доброй ночи, Александр! Я по мере сил развиваю Рефал-5λ, который лежит на GitHub, и чисто для себя пользуюсь тамошним багтрекером <https://github.com/bmstu-iu9/refal-5-lambda/issues> для документации планов и задач. Ранее, когда я разрабатывал Модульный Рефал, у меня был (и остался) текстовый файлик <https://github.com/Mazdaywik/mrefal/blob/master/Documentation/Журнал/Changes.txt> , который исполняет роль таск-трекера (см. там запись от 20.10.2007). Когда я его начал вести, о таск-трекерах ничего не знал.
Так что таск-трекеры могут быть полезны и для маленькой команды вплоть до одного программиста (но без фанатизма конечно). По поводу IDE. Среда для Eclipse — она для Рефала Плюс. Писалась вроде лет 10 назад, не уверен, что она пойдёт на современных версиях Eclipse. Я её не устанавливал, поскольку на Рефале Плюс я не программировал. Для Рефала-5λ есть плагин для IntellJ IDEA: https://github.com/bmstu-iu9/RefalFiveLambdaPlugin Умеет подсвечивать синтаксис, выделять синтаксические ошибки и автодополнять имена функций и переменных. Впрочем, в основе этого плагина тоже лежит Java. С уважением, Александр Коновалов From: Александр Гусев gusev_aleksandr_AT_mail.ru [mailto:refal@botik.ru] Sent: Monday, December 2, 2019 11:17 PM To: refal@botik.ru Subject: Re[2]: Рефал-2, Рефал-5 и стиль программирования Мне удалось поработать в разных программистских командах - от 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 <mailto:refal@botik.ru> >: On Mon, Dec 2, 2019 at 5:30 PM Александр Коновалов a.v.konovalov87_AT_mail.ru <http://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 <mailto:gusev_aleksa...@mail.ru>
