Это значит, что на Солнце нужно смотреть через чёрные очки.
Я потерял несколько десятков процентов зрения, читая книги. Кстати говоря, раньше очкариков было не меньше, чем сейчас.
Это очень полезный опыт. Плох тот солдат, который не мечтает стать генералом, чтобы ему построили дачу. Сам строил, но недолго. И не генералу.
Сообразить проект на троих - это очень вредно для последствий. Я бы им не доверял (шутка не моя, и я тут ни при чём).
Нет, Вы всё верно оцениваете. Уверенность тут ни при чём. Можно вносить новые баги с уверенностью, а можно без - эффект один
1 лайк
Теоретически можно всегда. Но я говорил о статистически значительной вероятности.
В своих проектах я знаю что делает что, поэтому при добавлении фичи - прокручиваю в уме всё с чем она может контактировать, таким образом исключая 99% багов. И вот я говорю - делая изменения в компиляторе, я не могу так же пройтись по остальным фичам.
Но вообще что меня больше волнует, так это то что вы сами не пытаетесь. Даже при том какие простые были изменения в фиксе uses-in - вы в комментах спрашивали какие могут быть проблемы.
Делая тот фикс - я успокоил себя несколькими логическими цепочками, объясняющими откуда ошибка точно не может прийти. Поэтому я тут сказал что хуже этого фикса не должно быть. То есть что другие части компилятора вряд ли сломаются.
А теперь внимание: проблема описанная в том же комменте - в итоге оказалась из за дубля реализации. В своих проектах если что то уже 1 раз реализовано - я по максимуму использую этот же код. И если нужно написать ещё раз с небольшим изменение ради производительности - пишу рядом и как то выделяю (к примеру комментами) что если менять в 1 месте - то и в другом тоже.
И в своих логических цепочках я основывался на этом и нескольких других правилах. Но uses в модуле подключённом по uses-in использовал совершенно отдельный кусок кода, который кроме всего прочего, на честном слове работал. Или, если на языке программистов - по принципу “работает - не трогай”.
Далее: проблема на которую указали вы (“что будет после ошибки”), это то, о чём я вообще не подумал. Почему? Потому что я не понимал (и всё ещё не понимаю) где используется текущий каталог. Я увидел что в начале компиляции текущий каталог насильно устанавливает на папку, содержащую .pas файл.
То есть если консольный компилятор запущен в папке:
D:\1\2
И затем вызывается компиляция файла:
3\0.pas
Текущий каталог в любом случае изменит на:
D:\1\2\3
Перед тем как компиляция начнётся.
(Я это не проверял, это только исходя из того кода что я видел)
Поэтому я решил что 1 из 2:
- Вы где то в другом месте, которое я не нашёл (и не сильно искал), возвращаете текущий каталог на то, что было до старта компиляции.
- Вам вообще без разницы что будет с текущим каталогом.
И это всё в простейшем фиксе, всего <10 строк.
То есть в итоге:
- Моя логика вообще не всегда работает, потому что легаси-код всюду.
- Я не знаю даже базовых вещей, так что мне не о чего отталкиваться.
Поэтому я говорю о уверенности в том что делают. А точнее о её отсутствии. И о том на сколько это серьёзно.
ну, это жизнь. А что вы предлагаете? Это большой код, он поддерживается более 15 лет разными участниками
В свои 20 лет я был почти уверен, что закончу институт и переверну мир. В 25 - что еще 3-6 лет - и я покажу всей стране пример, как надо работать. В 29 - что все это фигня и надо заниматься семьей, а прочее - по остаточному принципу.
-
Расписать где то на видном месте (потому что не только мне может быть надо) какие части процесса компиляции делают что. На столько подробно, на сколько хватит времени. Прям всё, разумеется, невозможно расписать, но это не повод и не пытаться.
-
Поддерживать нормальную связь. На форуме вы не редко игнорите всё на что неудобно/долго отвечать.
По-хорошему этим должны были заниматься те, кто и писал код, ибо они лучше в нём понимали, чем “посторонние” разработчики. Возможно, не хватало мотивации и времени заниматься документированием кода, но это привело к тому, к чему привело - приходят новые разработчики, возможно, частично понимая чужой код и начинают писать свой, забывают о чём-то и здесь появляются неожиданные ошибки, потом этот круг повторяется снова. Всё накапливается и потом имеем “здесь упало, там упало”, замазываем проблему здесь, ибо предыдущие разработчики не удосужились постараться и написать документацию, она появляется в другом месте. @Admin следовало бы ставить вопрос ребром перед другими разработчиками - или пишите код с документацией или не пишите. И самому быть для них примером. Но здесь иная проблема - а как мотивировать писать документации? Чем? Более того, а хватит ли времени на всё это у самого руководителя проекта и иных разработчиков? Здесь, я бы сказал следующее - лучше дольше, но качественней. За кем гнаться? Выпустят версию на неделю, две позже, подождут люди, но взамен разработчикам будет комфортнее с кодом работать, а потом и людям - ошибок в таком коде будет меньше. Код - это своеобразная книга, её тоже надо красиво оформлять, чтобы вновь пришедшие разработчики могли в ней разобраться.
Попытаться исправить ситуацию можно и сейчас, но время уже ушло…
Видимо писали те, кто увлекался в свое время олимпиадами )))
Ясно.
1 лайк
Dа прям код кругом недокументированный… Какие-то сложные вещи документированы. Pосмотрите Compiler.cs, NETGenerator.cs, CodeFormatter.cs, PCUReader.cs, PCUWriter.cs. А еще есть документированный формат PCU.
3 лайка
Подробнее ищите в коде. Где-то есть комментарии (и их больше чем в рослине…)
1 лайк
Можете кстати и сами документировать, разбираясь в коде.
1 лайк
Компилятор - это не тот случай, когда нужно лезть в чужой код
1 лайк
Должен сказать, что вы меня сильно огорчили.
Требовать от разработчика проекта написать полную архитектурную документацию только потому что вам так хочется - это я даже не знаю, как назвать. Более того, вы не удосужились заглянуть в раздел сайта “курсовые и дипломные работы”, где многие архитектурные вопросы освещаются.
Должен заметить, что это свидетельствует о ваше непрофессионализме в первую очередь. Если вы придёте в какой-нибудь программистский проект как джуниор и начнёте требовать от начальника чтобы он обязал всех своих подчинённых написать подробную документацию по всем частям проекта чтобы вы могли в нем разобраться, то дни ваши в этой кампании сочтены.
Замечу также, что по вашей маленькой части, связанной с реализацией uses in, никакой рефакторинг кода проведён не был - а была сплошная негативная критика. Кроме того, документации от вас тоже по реализации этой фичи как-то не возникло. Любой студент, которому я бы поручил подобное мероприятие, обязательно это бы сделал.
По поводу того, что я не отвечаю на какие-то вопросы, - это тоже странно слышать. Если вы разрабатываете какую-то функциональность, то берёте на себя ответственность и разбираетесь в коде. Настойчиво обязывать кого-то вам помочь - это странно, а требовать от руководителя чтобы он всю архитектуру проекта вам расписал - это вообще полный треш. Если вы не можете разобраться, это свидетельствует о вашем непрофессионализме в первую очередь, и не надо об этом особо кричать.
По поводу документирования кода - код документирован в целом лучше чем многие большие аналогичные проекты. Например, внутренняя архитектура проекта Roslyn нами тоже узнавалась непосредственно из кода - его архитектура на уровне для разработчика нигде не описана. И - нет ни одного проекта такого же уровня, где бы в открытом доступе детально была бы описана архитектура. Никто при этом не плачет - все разбираются.
Ещё раз повторюсь - мне очень жаль от вас всё это читать.
1 лайк
Да, я уже понял, есть несколько источников в которые стоило заглянуть в первую очередь… Я на столько привык не ожидать этой информации - что и не попытался искать, но теперь понимаю что никогда нормально и не проверял.
@Admin но всё же
Где именно и в каком виде должна быть документация? Я оставил комментарии, но получается надо ещё что то? Я с процессом созданий поручений студентам вообще не знаком.
И - рефакторинг я не делал потому что боялся что тогда вы точно не примите, сказав что я нагородил тонну кода для мелкой фичи. С GraphABC уже была похожая история.
Правильно ли я понял что с нормальной документацией - рефакторинг приветствуется?
Я и не рассматриваю вас как студента.
Практика такая. В любом проекте - OpenSource или каком-то - если разработчик замечает дублирование кода, он проводит рефакторинг если сроки реализации проекта это позволяют.
После этого он пишет хорошее покрытие тестами , ясно показывающее, что в результате рефакторинга не внесено новых ошибок.
Изменяемый код рекомендуется помечать коротким комментарием вида // SSM 18.01.20 Issue #2020 - и // end #2020
Либо же без номера Issue - уникальным коротким идентификатором.
Где-то в главном месте среди всех правок данной функциональности пишется чуть более подробный комментарий (если нужно) о том, что делает данная правка и возможно какие риски, что следовало бы рефакторить ещё.
Документация по правкам в объёме, большим чем этот, не пишется.
Если необходимы более серьёзные пояснения - например, разработчик разобрался в механизме работы select_function, - то на github пишется md-файл с короткой документацией, и из проекта - комментарий со ссылкой на этот md. Я бы так сделал. тот файл просто поправить и в нем написать, что эта документация есть где-то ещё.
Фраза “хуже чем уже было быть не может” очень плохая и должна быть заменена на фразу "реализован следующий функционал uses … in, следующий функционал еще не реализован, но желателен, следующие ситуации автор не дотестировал, но считает, что там нет ошибок, следующие ситуации нуждаются в доп. тестировании.
2 лайка
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021