Новое исследование Массачусетского технологического института предполагает, что новая категория инструментов может помочь программистам разобраться в существующих проектах, анализируя способы соединения объектов.
Учитывая, что объектно-ориентированное программирование существует уже 40 или более лет, мы должны были к настоящему времени выработать основы того, как эффективно использовать объекты, но нет.
Если вы когда-либо присоединялись к зрелому объектно-ориентированному проекту, вы знаете, что время, необходимое для того, чтобы понять, как все это сочетается друг с другом, и стать продуктивным членом команды, обычно довольно долгое. Это более серьезная проблема, когда дело касается программного обеспечения с открытым исходным кодом, которое обычно почти не имеет документации, исходя из предположения, что код говорит сам за себя — этого не произойдет, пока вы не узнаете его как свои пять пальцев. Одним из преимуществ, заявленных для открытого исходного кода, является то, что вы можете «настроить» его, добавив несколько строк кода, чтобы заставить его делать все, что вы хотите, поэтому такая крутая кривая обучения вызывает затруднения.
Так почему же так сложно понять, как работает объектно-ориентированный проект?
Ответ может заключаться в том, что вам нужно знать, какие объекты существуют и как они были разработаны для взаимодействия, прежде чем все это обретет смысл. Очень сложно сосредоточиться на одном или двух предметах, чтобы выполнить конкретную задачу.
MatchMaker — это новый инструмент, изобретенный лабораторией компьютерных наук и искусственного интеллекта Массачусетского технологического института и описанный в документе, который будет представлен на конференции SPLASH в этом году, ежегодном мероприятии, охватывающем все аспекты создания и доставки программного обеспечения и объединяющем все фракции технологий программирования. .
MatchMaker использует программу динамической трассировки DeLight для определения связей между объектами. На основе этих данных он автоматически сгенерирует связующий код, необходимый для функционирования объектов. Обычно это включает создание экземпляров новых объектов, выполнение вызовов API и переопределение методов.
Звучит легко, но прочтите статью, чтобы узнать, сколько работы необходимо сделать для обратного проектирования отношений. Эвристика используется для угадывания отношений между объектами на основе шаблонов вызовов, возникающих при использовании программы.
Вы не можете не думать, что было бы проще, если бы создатели кода нашли время, чтобы сделать некоторую документацию. Однако в документе утверждается, что типичные «простые» методы документации, такие как документация на основе классов, например JavaDoc особенно бесполезен, потому что он фокусируется на отдельных классах, а не на взаимодействиях между классами. Очевидное решение — учебное пособие или практическое руководство — также не является хорошим решением, потому что оно требует не только много времени, но и подвержено ошибкам. Затем возникает проблема определения того, относится ли учебное пособие или инструкции к конкретной проблеме, которую вы пытаетесь решить. Аргумент состоит в том, что возможность ввести запрос в MatchMaker и заставить его генерировать код, необходимый для соединения объектов вместе, по крайней мере, дает вам отправную точку, которая может быть разработана в полном решении.
MatchMaker был протестирован на базе кода Eclipse IDE, и оказалось, что он позволяет сэкономить примерно 50% времени, необходимого новичку для решения конкретной проблемы. Это впечатляющие результаты, и они кажутся достаточно общими. Однако Eclipse — особенный проект. Он почти одержимо объектно-ориентирован и использует спецификацию базовой инфраструктуры OSGi для создания объектов среды выполнения в виде служб, которые могут взаимодействовать весьма специфическим образом. Это делает его нетипичным для больших объектно-ориентированных приложений. Возможно, новичку сложнее понять, как взаимодействуют его объекты, и автоматическому инструменту также легче выполнять эту работу. Короче говоря, если MatchMaker — решение проблемы, необходимо продемонстрировать, что он работает с более широким диапазоном типов проектов, чем только Eclipse на основе OSGi.
Однако ясно, что если открытый исходный код должен выполнить свое обещание быть изменяемым случайным образом, нам действительно нужны такие инструменты, как MatchMaker. Альтернативным решением могут быть инструменты, упрощающие создание действительно полезной документации.