Размышления о том, как начинать проекты с суперкомпьютеров и постепенно превращать их в тяжелых, медленных, вялых слонов
Некоторое время назад, когда я работал над проектом по разработке программного обеспечения, я был поглощен множеством различных продуктов и технологий - среди них набор установок Windows Server, .NET framework, SharePoint, SQL Server, IIS, C #, WebParts, JavaScript, и много скомпилированного или интерпретируемого исходного кода. Приближаясь к «рабочему решению», я начал замечать производительность колосса, над которым мы работали, или, скорее, недостаток производительности.
Когда ЛАМПА правила миром
Это напомнило мне о моем опыте работы над веб-проектами с открытым исходным кодом, возможно, двадцать лет назад с PHP и MySQL - простота, скорость и гибкость платформы LAMP были убедительны. Прошло несколько лет с тех пор, как мне довелось поработать с PHP, и я должен признать, что временами мне это не хватало.
Javascript везде
Node.JS, конечно, появился и смел все до него, но я не могу избавиться от некоторого дискомфорта по этому поводу. Если вы не знакомы, обещаем, что вы сможете писать как серверный, так и клиентский код на JavaScript, тем самым сокращая набор навыков и, надеюсь, повышая стабильность и надежность за счет того, что вам не придется интегрировать разрозненные платформы.
Но вот в чем дело - между сервером и клиентом уже есть волшебный слой под названием HTTP. Он был изобретен таким образом, что сервер и клиент могли быть совершенно чуждыми друг другу. Именно поэтому Интернет взорвался.
На самом деле не скомпилирован
Написание серверного кода на JavaScript может быть привлекательным предложением для тех, кто знает только JavaScript, но это никогда не уходит от того факта, что это интерпретируемый язык. Хотя компиляторы JavaScript появились и значительно улучшились в последние годы, мы попадаем в сумасшедшую ситуацию, когда нам нужно точно знать, как писать код, который «подходит» компилятору. Разница в производительности между шаблонами кода, которые нравятся и не нравятся компиляторам, огромна.
Оглядываясь назад
Когда я закончил колледж (20+ лет назад!), C ++ был новым языком, а OS2 обещала мир, которого никогда не будет. Я научился программировать на Паскале, немного знал C, немного ассемблера - и с первого дня меня учили, что великие разработчики пишут чистый, быстрый и элегантный код. Когда я вошел в мир профессиональной разработки программного обеспечения и обнаружил, что коммерческое давление почти всегда приводило к тому, что программное обеспечение никогда не было так хорошо, как могло бы быть, это стало настоящим шоком.
Конечно, существует разрыв между решениями и продуктами - в то время как решения, как правило, умирают из-за тысячи сокращений, чтобы соответствовать расписанию или бюджету, продукты могут развиваться. Интересно, что в последние годы продукты превратились в услуги благодаря внедрению «программного обеспечения как услуги» и лицензий на основе подписки.
Открытый исходный код остается путеводной звездой
Параллельно с моей ранней карьерой движение за открытый исходный код росло, как сорняк, и я не случайно в конечном итоге включился в него - написал сценарий раннего ведения блога и систему управления контентом. Они были разработаны с нуля для обеспечения скорости, минимальной занимаемой площади, практичности, ремонтопригодности, ясности и элегантности. Я полагаю, что во многом они были реакцией на колоссальный Win32 API, ад DLL, ActiveX, «почти ANSI SQL-совместимый» движок базы данных Jet и различные другие кошмары коммерческого мира того времени, связанные с автокатастрофами.
Открытый исходный код не был идеальным - он все еще не идеален, - но это был лучший подход, чем все, что было раньше, и открывал дверь к продаже услуг, а не продуктов.
.NET Framework лучше, чем многие думают
Хотя может показаться, что я постоянно критикую коммерческие продукты, стоит отметить, что платформа .NET и, в меньшей степени, C # являются чертовски большим достижением. То же самое и с Visual Studio. Конечно, они крадут идеи из многих других языков разработки программного обеспечения (в основном из Java), но при этом присутствует ясность мысли и глубина реализации, которые невероятно впечатляют.
Большинство разработчиков признают, что Microsoft всегда предоставляла одни из лучших инструментов для разработки программного обеспечения. С самого начала они играли в долгую игру - предоставляя лучшие инструменты для создания приложений для своей платформы, и это сработало - Windows захватила мир (настольных компьютеров).
Кстати, я склонен думать, что Microsoft упустила огромный трюк, не позволив нам компилировать код .NET непосредственно в машинный код. .NET Framework компилирует промежуточный язык и кэширует его - почему бы не позволить разработчикам сделать это заранее?
Обидно
Кажется позором иметь фантастическое оборудование, гремящее где-то в серверной комнате, а затем накладывать на него операционную систему, которая ограничивает любой доступ к оборудованию, фреймворки выполнения кода, которые компилируются и кэшируются по запросу, бесчисленные библиотеки для расширения возможностей, за которыми следуют многочисленные клиентские фреймворки для стандартизации практики кодирования.
Я должен постоянно напоминать себе, что нам больше не нужно беспокоиться об управлении памятью, дескрипторах файлов, указателях, стеках, адресном пространстве, сборке мусора и различных других демонах, которые десятилетиями преследовали разработчиков программного обеспечения.
Строим слона
Я полагаю, это похоже на то, что в некоторые дни мы начинаем каждый проект с суперкомпьютера, гудящего на серверной ферме, и мы медленно превращаем его в слона ... действительно тяжелого, медленного, вялого слона.
Первоначально опубликовано на https://jonbeckett.com 18 января 2021 г.
