Пару лет назад со мной произошел странный случай. Еще в 2015 году, проведя 9 лет в Остине (в основном по семейным обстоятельствам — моя жена американка), мы с женой навсегда переехали в Торонто. Два года спустя мне позвонили из консалтинговой/рекрутинговой фирмы в Хьюстоне и спросили, не хочу ли я вернуться обратно в Остин с оплатой переезда, чтобы устроиться на работу. Учитывая, что рассматриваемая компания специализируется на Smalltalk, либо набирает разработчиков Smalltalk, либо, в идеале, запускает проекты Smalltalk, в целом это не было бы так уж странно, ведь разработка Smalltalk — относительно нишевая область.

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

Причина, по словам рекрутера, заключалась в том, что менеджер по развитию рассматриваемой фирмы «не думал, что любой, кто «вырос» на Java, знает, как писать «правильный объектный код», и поэтому нанимал только разработчика. с большим опытом работы с Smalltalk. Если бы это была небольшая компания, это можно было бы списать на причудливую причуду конкретного менеджера по развитию, но это была не маленькая компания, и менеджеры по развитию в более крупных компаниях должны были заслужить значительный авторитет внутри компании, прежде чем финансы и HR. готовы позволить им баловаться дорогими причудами, что обычно означает, что они имеют заметный уровень успеха. Но почему наем (бывших) разработчиков Smalltalk может повысить уровень успеха в компании, которая не использует (и никогда не использовала) Smalltalk?

Поначалу это кажется крайним утверждением, но по мере того, как я думал об этом (спустя много времени после того, как отклонил предложение — я люблю Торонто), оно начало обретать больше смысла, потому что это не оценка способностей разных разработчиков, а утверждение об их перспектива. Я знаю много отличных разработчиков Java, которые никогда не касались Smalltalk, но рекрутер не говорил, что люди, которые «выросли» на Java, не знают, как писать хороший код, термин был конкретно 'правильный объектный код'. Когда я подумал об этом, я сосредоточился на том, что подразумевает «правильный объектный код» и почему это имеет значение. В конце концов, если код хорошо написан, организован, удобочитаем, тестируем и т. д., какое значение имеет создание «правильного объектного кода», какие преимущества это даст компании, если они будут платить дополнительно за то, чтобы он был написан? именно таким образом?

Smalltalk был первым языком, получившим прозвище «объектно-ориентированный» по той простой причине, что один из его главных архитекторов изобрел этот термин, Алан Кей. С тех пор он несколько сожалел об этом, но этот термин прижился, несмотря на его опасения, что, как правило, указывает на то, что он указывает на что-то важное, даже если люди не уверены, что именно.

Чем более общий или абстрактный термин, тем труднее точно сказать, как он согласуется с неустановленной онтологией (как мы понимаем, что есть что-либо). А такие термины, как «объект» и «ориентация», довольно абстрактны. Если мы думаем об «объекте» с точки зрения научных «объектов», составной термин становится по существу бессмысленным, он актуален только в том случае, если мы придерживаемся определенного значения объекта в языках программирования, которое, конечно же, возникло в Smalltalk и может быть выражено как «структура данных вместе со средствами ее модификации».

Итак, что касается «объекта», как насчет второго термина «ориентированный»? Когда мы ориентируемся, мы имеем дело (по крайней мере) с двумя вещами: на что мы ориентируемся — на и на что мы ориентируемся — на что. В термине объектно-ориентированный мы ориентируемся-на объекты и ориентируемся-на программу, которую пишем. Поскольку на момент написания программа еще не существует полностью, она может быть только воображаемой проекцией готовой программы, на которую мы ориентируемся.

Java синтаксически основан на более старых языках в линии, начинающейся с Algol, причем C является наиболее известным из этой линии. Наряду с основным синтаксисом способ написания Java аналогичен циклу записи/компиляции/сборки/тестирования. Это включает в себя определенную метафору, с помощью которой программисты понимают, что они делают. Метафора включает в себя текст на «страницах», которые хранятся в «файлах», которые затем хранятся в «папках» и «подпапках». Несмотря на то, что ни папки, ни файлы, ни любая другая часть метафоры не соответствует первоклассной языковой структуре Java, эта метафора ориентирует большинство программистов на Java, даже не задумываясь об этом, и является причиной того, что практически каждая среда разработки по своей сути является текстовым редактором. и файловый менеджер, какими бы продвинутыми они ни были. Как бы нам ни хотелось думать, что вы пишете объектный код, фундаментальная метафора, с которой неявно работает большинство Java-программистов, метафора, которая их ориентирует, ничего не говорит об объектах. На самом деле, это прямо противоречит объектно-ориентированной парадигме, поскольку фокусируется на коде, точнее, на «коде в файлах», а не на «структурах данных вместе со средствами их изменения».

Smalltalk не использует метафору «код в файлах». У него также нет циклов разработки: запись/компиляция/сборка/тестирование. Среда Smalltalk построена не на текстовом редакторе и файловом менеджере, а на различных браузерах, которые отображают объекты по-разному. Когда вы пишете код в методе, который находится в классе, это объект класса . Когда вы сохраняете этот код, он немедленно становится активным в среде, т. е. в какой бы степени вы только что не добавляли или изменяли код, сама среда немедленно изменялась.

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

Эта разница во взглядах меняет способ написания и организации кода — обычно он организуется вокруг структур данных. Обычный рефакторинг в Java заключается в перемещении кода в более подходящий класс, причем соответствие определяется структурой данных, присутствующей в классе. Но почему изначально код был не в том классе? В первую очередь потому, что программист проектировал программу не с точки зрения структур данных и связанных с ними методов, а с точки зрения кода, «кода в файлах».

Конечно, в Smalltalk, как и в Java, есть код, не относящийся к конкретной структуре данных. В обоих случаях этот код называется «функциональным» и часто реализуется в определенном стиле, часто как единственный метод в конкретном классе, который сам по себе может быть или не быть встроенным. Его можно записать как лямбду в Java 8+ или как блок в Smalltalk (также называемый замыканием блока), но в любом случае он не связан с конкретными данными. Однако «вспомогательные» классы, распространенные в Java для определенных типов данных, необычны для Smalltalk, поскольку более естественно реализовать эти методы в самом типе данных. Поскольку весь этот код написан на языке Smalltalk и доступен в среде на большинстве диалектов, сделать это несложно.

Вы можете писать совершенно хороший код на Java или других «объектных» языках, не придерживаясь ни одного из основных понятий, лежащих в основе «объектного кода», но, по крайней мере, для разработчика Smalltalk ваш код будет организован странно, при условии, что он все еще хорошо организован. Именно «организовано, но не правильно» большое количество превосходного Java-кода не является «правильным объектным кодом» для тех, кто постоянно ориентируется на объекты и пишет код с этой точки зрения.

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