Предположим, есть задачи реализовать важный функционал в своем продукте. Очень срочный и крайне важный. Весь функционал задач основан на новом и ранее неизученном материале 3-й стороны. Но из-за срочности задач надо постоянно переписывать код и изучать. «Новое и неизученое» как правило большое и весит где-то более 1 млн строк. То есть изучать чужой код библиотек — вариант, но, наверное, последний. Экспертов рядом нет, в интернете найти что-либои — та еще задача, ChatGPT выручает, но мало (без него вообще бы не взялись за такие задачи).
Отказываться от таких задач не вариант. Изучение кода библиотек — вариант, но я бы предпочел найти более эффективное решение. Бесконечные вопросы на форумах — тоже не самый быстрый способ.
Сейчас подход применяется такая пилится куча тасок на "исследование задачи <такой-то> попытка подхода <номер>" и просто ловишь ощущение безисходности.
Что посоветуете? Бывало ли у вас что-то подобное? Как решали? Делитесь трюками
Здравствуйте, r0nd, Вы писали:
R>Что посоветуете? Бывало ли у вас что-то подобное? Как решали? Делитесь трюками
Читать код, в вашем случае сторонних библиотек.
Лучше всего начать с тестов или примеров использования если они есть.
Тру стори: когда я занимался Microsoft SharePoint, то для получения сведений о том, как оно работает, я в ILSpy открывал сборки и читал код. Это дало больше всего знаний.
Для меня отладка это первейший способ изучать сторонний код. Просто читать исходники смысла мало. А под отладкой уже не миллион строк кода, а, грубо говоря, 1000 строк, по которым проходит управление для интересующего юз-кейса. 1000 строк понять уже можно.
Если дебаг по каким-то причинам настроить не получается, можно глазами код выполнять. Но это, конечно, куда менее удобно и быстро.
Здравствуйте, r0nd, Вы писали:
R>Что посоветуете? Бывало ли у вас что-то подобное? Как решали? Делитесь трюками
У тебя по сути классический пример. Огромное количество программистов ищут ответ на этот вопрос. У меня есть книги, которые я отношу к категории "проекты и команды". Это такие авторы как Том Демарко, Фредерик Брукс и другие.
А проблема та же самая, что и новичка в программировании, то есть стажёра, джуна и прочих людей, которые не преодолели планку по конкретной специализации. Только тут речь конкретно про какую-то область в программировании.
Просто принято называть всех программистов вне зависимости от специализации программистами. А ведь даже если программист в одной области достиг высот, в другой он может быть хуже новичка.
В итоге я изучал два дополняющих друг друга метода.
1. Личная база знаний.
2. Карточки интервальных повторений.
Личные базы знаний это хранилище справочник в котором лежат все знания, включая свой и чужой код сколь бы значительным он не был, книги, уроки, программы. Очень медленно в ручном режиме это позволяет перерабатывать знания.
После переработки и улучшений можно заливать знания в мозг для долгосрочного использования. Для этого и нужны карточки интервальных повторений с многострочными полями ввода.
Но вернёмся к "проектам и командам". Как утверждают авторы подобных книг никакая мотивация не поможет, если команда не имеет компетенции. Получается нужно увеличивать компетенцию в данной области. Но на увеличение компетенции тратится время, которого у дедлайновых проектов попросту нет.
Если удариться в фантазии, то у меня есть мысль про программу, которая бы позволяла многократно ускорить набор личной базы знаний и разбор кода. Но я не дошёл ещё до того, чтобы вместо совершенствования собственных мыслительных процессов полагаться на генератор строк ИИ.
Хотя я не против различных анализаторов, хоть ИИ, хоть не ИИ, если это пойдёт на пользу.
Мифы про обучение:
1) У каждого человека есть доминирующий стиль обучения.
2) Люди делятся на тех, кто мыслит левым и правым полушарием.
3) Многозадачность не менее, а то и более эффективна однозадачности.
4) Люди используют лишь 10% мозга.
5) 10'000 часов сделают из вас эксперта в любой области.
Не работающие методики:
1) Перечитывание книг и прочего.
2) Подчёркивание текста в книгах.
3) Мнемоника на основе ложных данных.
Работающие методики:
1) Распределённое во времени повторение.
2) Активное воспроизведение знаний (тесты лучше чтения, SSSS хуже SSST, SSST хуже STTT).
3) Интервальные повторения (объединяет первый и второй методы, плюс весь топик об этой теме) (Janki 1, Janki 2, Вайнер, Возняк).
4) Чередующаяся практика (темы A,B,C, неправильно учить в порядке AAABBBCCC, правильно учить в порядке ABCABCABC).
5) Задавать себе вопросы во время обучения.
6) Запоминание конкретных, а не абстрактных идей.
7) Объяснение самому себе.
А какой способ запоминания ты считаешь более эффективным?
В контексте, наверное, самый эффективный. Просто прикол в том, что когда вы учите слова без контекста, вы потом не понимаете, где их можно употребить. Я, если хочу выучить новое слово и пополнить запас, я учу его сразу в предложении. А лучше сразу с несколькими, потому что часто слова можно употребить совершенно в разных контекстах.
То есть код, который пытаешься проанализировать или по русски разобрать является множеством деталей находящихся в контексте. И каждая деталь определяется не только самой собой, но и её окружением.
Например, чем по виду в C++ отличается объявление или определение локального переменного значения от глобального переменного значения?
А ничем не отличается, точно такая же конструкция, но в другом контексте. И без анализа контекста чисто по виду только самой переменной невозможно понять глобальная она или локальная.
Код это по сути такой же текст, как и любой другой, только написанный по своим правилам, тогда как в другом тексте свои правила. Не существует осмысленного текста, который не имеет никаких правил.
Не понимание правил по которым написан проект и создаёт проблемы в его изменении. Почему любят тот же Си, да потому что там правил меньше, а значит быстрее изучать и проще разбирать код.
Потому что программные системы растут и рано или поздно люди доходят до того, что не могут изучить объёмы кода созданными другими.
Если не считать анализаторов, то есть помощников для разбора чего-то, то главный трюк, которыми люди делятся с другими состоит в том, что они задрачивают какую-то тему до дыр.
Если есть эффективная методика задрачивания, то можно повысить скорость сэкономив время. Если используемая методика крайне не эффективна, то результат может быть не достигнут никогда. И есть что-то среднее между этим.
Почему когда читаешь код не можешь ничего понять. Да потому, что там написано что-то вроде.
空虚 主要的()
{
}
А на самом деле я написал на китайском.
void main()
{
}
Но даже просто какой-то условный синоним или сокращения, который не подходит собственному сознанию мешает читать код. Да, многие программисты "рвут на себе телняжку" и рассказывают какие они полиглоты. Но по факту это всё неудобно. И на это ещё накладывается непонимание контекста.
Здравствуйте, paucity, Вы писали:
P>тут противоречия
Нет здесь никаких противоречий. Конечное решение по выбору библиотек и подбора подходов к разработке происходит через, в том числе, исследование рынка возможных решений. Когда уже есть понимание продукта с точки зрения бизнеса, и что продукт будет реализовывать через «А» и «Б» библиотеки разработки с использованием технологического «В» подхода. То высчитываются риски, например:
есть ли знания в области применения у членов команды,
есть ли иная документация/база знаний, какова оценка ее,
какова сложность конечного решения продукта,
развернуты ли тестовые стенды и какие возможности по тестирования итд итп.
На основании коэффициентов риска у вас либо уменьшается цена разработки либо увеличивается. Решение стартовать проект на том или ином стеке принимается согласно риску. Конечно же, AI сейчас существенно уменьшают коэффициенты риска. Влияние настолько большое, что теперь ( в моем случае ) стало возможным заходить в области не имея опыта в технологии, чего ранее не было рентабильно. Но из-за того, что продукт сложный — ранее невозможные задачи стали сложными.
Наконец, с этим связан мой вопрос, как решать сложные задачи, как увеличить финансовый рычаг здесь, достаточно ли подход оптимален и эффективен или существуют дополнительные точки роста? Невозможные задачи невозможно решить, иначе они бы были просто сложными.
R> То есть изучать чужой код библиотек — вариант, но, наверное, последний. Экспертов рядом нет, в интернете найти что-либои — та еще задача,
Это не последний, а первый, самый правильный и надежный вариант.
Беда только в том, что на собеседованиях соискателей просят написать код. Вместо того, чтоб заставлять код читать...
Здравствуйте, gandjustas, Вы писали:
G>Тру стори: когда я занимался Microsoft SharePoint, то для получения сведений о том, как оно работает, я в ILSpy открывал сборки и читал код. Это дало больше всего знаний.
IlSpy или reflector? Ilspy же только il может декомпилировать.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Тру стори: когда я занимался Microsoft SharePoint, то для получения сведений о том, как оно работает, я в ILSpy открывал сборки и читал код. Это дало больше всего знаний.
S>IlSpy или reflector?
Ilspy
S>Ilspy же только il может декомпилировать.
А рефлектор что может декомпилировать?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>IlSpy или reflector? G>>Ilspy S>>>Ilspy же только il может декомпилировать. G>>А рефлектор что может декомпилировать?
S>Исходники из il, а вот какой прок читать il -- ?
Открой IlSpy, очень удивишься
SD>Беда только в том, что на собеседованиях соискателей просят написать код. Вместо того, чтоб заставлять код читать...
Очень даже заставляют, исполнять в уме всякие шизофренические c++ные ребусы и говорить какой выведет результат. Вместо того чтобы проверять умение (и желание) писать код, дружественный к пошаговой отладке (другим разработчиком, которому распутывать нагромождения паттернов будет некогда, потому что продакшен упал).
Здравствуйте, r0nd, Вы писали:
R>Что посоветуете? Бывало ли у вас что-то подобное? Как решали? Делитесь трюками
Задачи бывают сложными и трудными. Трудная — это яму копать, сложная — в высоту прыгать.
Твоя больше похожа на трудную, чем на сложную.
Если вам там выдали миллион строк чужого кода, я не понимаю, зачем вы его изучаете. Вам надо его приладить, он, как я понимаю, не прилаживается. Вот это "не прилаживается" надо формализировать: не компилируется, работает неправильно и т.п. Если компилируется, но работает неправильно, должно быть описано, как воспроизвести (желательно в виде теста). Ну и если там 100500 вариантов неправильного поведения, надо каждый выделить и описать отдельно.
Потом надо решить, кто разбирается с этими проблемами: вы или поставщик этого миллиона строк. Ну и соответственно, или дрючить поставщика, тыркая его мордой в тесты, или самим разгребать.
В любом случае, я не понимаю, зачем этот миллион строк просто так изучать? Это что, какая-то особая форма мазохизма?
Если этот код в принципе работает, пусть и с нареканиями, значит пусть он и остается непонятым. Чтобы починить багу в миллионе строк кода, совершенно не обязательно понять весь миллион. А если он в принципе не работает, значит надо решать вопрос о том, чем и когда его заменять.
Pzz> Если компилируется, но работает неправильно, должно быть описано, как воспроизвести (желательно в виде теста). Ну и если там 100500 вариантов неправильного поведения, надо каждый выделить и описать отдельно. Pzz>Потом надо решить, кто разбирается с этими проблемами: вы или поставщик этого миллиона строк. Ну и соответственно, или дрючить поставщика, тыркая его мордой в тесты, или самим разгребать.
На личном опыте: написать repro/test очень часто намного сложнее, чем исправить баг.
Здравствуйте, SkyDance, Вы писали:
Pzz>>Потом надо решить, кто разбирается с этими проблемами: вы или поставщик этого миллиона строк. Ну и соответственно, или дрючить поставщика, тыркая его мордой в тесты, или самим разгребать.
SD>На личном опыте: написать repro/test очень часто намного сложнее, чем исправить баг.
Да.
Но я и еще крамольную мысль скажу: взять на себя миллион чужих строк плохого кода часто намного сложнее, чем переписать все нафиг. Ну а если код не плохой, то и взять его не слишком-то сложно.
Здравствуйте, Pzz, Вы писали:
Pzz>Задачи бывают сложными и трудными. Трудная — это яму копать, сложная — в высоту прыгать.
Pzz>В любом случае, я не понимаю, зачем этот миллион строк просто так изучать? Это что, какая-то особая форма мазохизма?
Так а что вы предлагаете? У вас есть опыт решения сложных задач?
Здравствуйте, r0nd, Вы писали:
R>Что посоветуете? Бывало ли у вас что-то подобное? Как решали? Делитесь трюками
Нужно решать некие задачи верхнего уровня, начиная с простых и понятных, а потом уже смотреть как работает сторонний код.
И постепенно углубляться. От простого к сложному.
Просто читать код без знания концепции достаточно сложно. Да и не нужно.
Там обычно куча вспомогательного кода.
Хорошо начать с иерархии классов итд.
и солнце б утром не вставало, когда бы не было меня
?
