LINUX.ORG.RU

редакторы для программистов (?)

 ,


2

2

Для писателей есть специальные редакторы, которые облегчают контроль за персонажами, временем, событиями. Всякие заметки, закладки, связи, редакции.

Для программистов есть что-то подобное? Я ваще не в курсе. Писал скрипты, ничего было не нужно, а сейчас немного замахнулся и просто тону. Запутываюсь. Хочется какого-то уже придуманного контроля и порядка. Например, чтобы редактор показывал, что готовые модули А и Б затрагиваются, если меняешь структуру в модуле С (я сам буду указывать связь, но чтобы он мне напоминал). Ну и чтобы схема была: это выполнено, это нет, а вот тут какие-то заготовки и тесты. В каждом блоке список проблем.

Язык не важен. Любой. Хочу просто знать — есть такое или нет и ключевые слова для поиска.

Тебе хочется «высокоуровневой редактор»? Когда-то были такие продукты Rational для проектирования больших систем. Может, и сейчас есть.

dimss ★★★★★ ()
Ответ на: комментарий от rechnick

Если у вас нормальный проект, а не случайным образом высранная каша, много в голове держать не надо. А для описания достаточно небольшого txt файла. Если бы речь шла о достаточно больших проектах, требующих хорошей документации, уверен, этого разговора не было бы.

erfea ★★★★★ ()

Например, чтобы редактор показывал, что готовые модули А и Б затрагиваются, если меняешь структуру в модуле С (я сам буду указывать связь, но чтобы он мне напоминал).

Всё это не нужно. Если ты изменил модуль, то зависимые модули либо не скомпилируются, либо не будут пройдены некоторые тесты. Не пишешь тестов, и при этом не можешь держать в голове всю нужную информацию? Тогда ты занимаешься чем-то не тем

Crocodoom ★★ ()
Ответ на: комментарий от Crocodoom

Нужна просто напоминалка. Чтобы, поставив один раз меточку, в будущем экономить время. Смотреть на 25 вывалившихся ошибок любой дурак может. Хочется культуры труда и систематизации.

rechnick ()
Ответ на: комментарий от rechnick

Нужна просто напоминалка.

Подобное не сработает, либо будет срабатывать неверно. Что хуже? Вам решать.

Сейчас большинство пересаживаются на git. Можно сетевой, можно локальный. Он ничего не напоминает, но сохраняет историю изменений, в которую ты всегда можешь влезть и посмотреть, что да как было и как стало.

zvezdochiot ()
Ответ на: комментарий от zvezdochiot

Видимо, я действительно хочу странного. Работал в журнале, там у нас в редакции висела доска, на которой главред мелом писал общий план, дневной план, какие-то пометки. А ещё я завёл себе проверочный список, потому что держать в голове всё, что нужно проверить — невозможно. А так проверил, крыжик поставил и спокоен.

А тут хочется ещё большего контроля, а не ловли ошибок. К тому же, ошибки может и не быть! Но программа будет по-тихой работать в каком-то случае неправильно, потому что ты что-то забыл.

rechnick ()

Например, чтобы редактор показывал, что готовые модули А и Б затрагиваются, если меняешь структуру в модуле С (я сам буду указывать связь, но чтобы он мне напоминал)

Ну тут все просто, нужно всю жизнь учится писать так чтоб код был максимально доступен для понимания даже спустя время, это особенно важно при командной работе. Только представь - открыл код и все понятно! Поход к этому «все понятно» обычно происходт так: новый программист начинает писать код, запутывается в сложности, осваивает декомпозицию, раскидывая логику по методам, начинает подбирать удачные имена, зная или нет начинает соблюдать принципы SOLID. В какой-то момент он упирается в доступные абстракции языка и начинает искать более подходящий язык, обычно такой считается сложным в индустрии, потому что позволяет писать не плохо, а очень плохо, но не в случае нашего героя, этот знающий программист начнет на нем писать вещи просто и доступно, ну для него это просто, для окружающих - вопрос.

Aber ★★ ()
Ответ на: комментарий от Aber

Поход к этому «все понятно» обычно происходт так

Чаще происходит наоборот:

  1. Приходит программист в новый проект, пишет его по принципу «херак херак и в продакшн» пока ему не надоест, затем уходит.

  2. В этот проект приходит новый программист, смотрит на этот трешак, желает старому программисту гореть в аду, поддерживает это дерьмо пока ему не надоест, затем уходит.

В основном, программисты бесконечно зацикливаются на пункте 2. Везучим иногда удаётся прыгнуть на пункт 1, который неизбежно перетекает во второй.

WitcherGeralt ★★ ()

Вероятно, тебе нужен UML. Диаграммы компонентов, классов и всё такое.

К сожалению, все свободные UML-редакторы, которые я видел, либо глючные, либо заброшенные (Umbrello, ArgoUML). Лучшее, что есть под линукс - это проприетарный Visual Paradigm. Стоит денег и в полной версии - нехилых.

А ещё можно прочитать талмуд от создателей языка и рисовать UML-диаграммы на бумаге (как вариант — в каком-нибудь Visio или Dia).

hobbit ★★★★★ ()

Для писателей есть специальные редакторы, которые облегчают контроль за персонажами, временем, событиями.

Пример можно?

Что-то мне кажется, что многие из оных пишут тупо в ворде.

Zhbert ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Приходит программист в новый проект, пишет его по принципу «херак херак и в продакшн» пока ему не надоест, затем уходит.

Я был в этой роли на второй работе, думаю никто «херак херак» по своей воле не делает.

Кстати, там же я получил незабываемый опыт использования UML. В общем делали мы свой «херак херак», «срочно срочно», «фичи фичи», а потом вдруг заказчики решили, что нахватает планирования и после непродолжительного периода переосмысления парадигмы ведения разработки продукта была выстроена идеальная бюрократическая микросистема. В ней было три руководителя, два архитектора, ну и один программист. В той системе я был архитектором и начертил множество диаграмм, там были и диаграммы классов, состояний, какой то гибрид диаграмм из обоих перечисленных и мои любимые диаграммы последовательностей. Мы двигались вперед и только вперед со скоростью умирающей черепахи. Программист часто сидел без работы, потому как вносимые изменения тяжело проходили согласования между двумя верхними уровни перевернутой пирамиды. В общем UML это то что нужно! Серебряная пуля! Убьет и бессмертного.

Конечно проблема была не в UML, но кто-то решил что именно диаграммы могут решить все проблемы - карго культ.

Aber ★★ ()
Ответ на: комментарий от Zhbert

Одну такую программу даже пиарили на ЛОРе, но там ТС оказался неадекватом и в ответ на предложения поработать над текстом новости начал хамить, в результате чего новость сослали в толксы.

hobbit ★★★★★ ()
Ответ на: комментарий от Aber

Так на галерах всегда «фичи фичи» «срочно срочно», и как бы не хотелось обратного, это довольно быстро скатывается в «херак херак». В IT-гигантах, наверняка, не так, хотя бы от проекта к проекту, но мне пока не довелось в них работать, я этого не видел.

Как раз с галеры на днях увольняюсь (точнее уже). Пару лет у меня была череда небольших, но важных, побед перфеционизма, но в последнее время фич стало требоваться всё больше и позавчера.

Надо бы для разнообразия поискать место с активной практикой применения UML.

WitcherGeralt ★★ ()
Ответ на: комментарий от hobbit

Эпичный тред.
Порадовало, как он сто раз сказал, что программа отличная вообше и просто отлична.
Не понял, в чем проблема запустить это в линуксах, если оно на джаве.

Zhbert ★★★★★ ()
Последнее исправление: Zhbert (всего исправлений: 1)

Хм, а можно ли uml прикрутить к какой-нить ide?

-----

К хорошим советам ide (они могут показывать то, откуда вызываются методы и то, используются ли какие-то методы из подключенных библиотек) + git/svn добавлю, что есть куча плагинов, которые помогают в этом деле. Например, todo, который создает список задач для каждого отдельного файла или список методов и данных открытого файла и т.д. В общем, кроме проектирования настроенная ide покрывает все запросы.

EmgrtE ★★★ ()