Эта программа поощрения авторов только усугубляет ситуацию, стимулируя писать статьи, интересные самой широкой аудитории, а потому априорно средне-низкого уровня сложности. Ведь чтобы оценить узкоспециализированную статью, нужно платить экспертам в этой области, при этом беря на себя ответственность перед авторами за качество такой экспертизы. А это уже не только про деньги, но и про значительные интеллектуальные усилия.
Деградация Хабра будет продолжаться до тех пор, пока его администрация не начнет платить авторам качественных и глубоких статей. А то что получается — Хабр распиарился на умных статьях, расширил свою аудиторию, хорошо так поднял денег, но по какой-то причине не хочет делиться ими с аудиторией, которая ему и помогла стать тем, тем он стал с ее помощью. Да еще отдала оценку этих статей на откуп школьникам, у которых еще не выветрилось из памяти изучение букваря.
Но, как говорится, жадность фраера сгубила — еще пару лет и на Хабр удобнее всего будет заходить с поисковика, чтобы не копаться в отходах информационной жизнедеятельности в поисках нужной информации. Да и то, чтобы найти материалы многолетней давности, так как свежие материалы в большинстве своем являются свежими только по дате упаковки, но протухшие по содержимому.
Так что уже можно начинать делать всем локальные архивы Хабра, чтобы в какой-то момент не получить платный доступ к старым качественным материалам.
Ключевыми элементами эффективного управления является целеполагание, обратная связь и кадры. Целеполагание в разработке предполагает четкое видение контуров и функционала будущего продукта. Обратная связь — это своевременная и объективная информация о расхождениях между желаемым и текущим состоянием разрабатываемого продукта. Ну а кадры, как известно, решают все, а потому требуют к себе индивидуального подхода буквально к каждому специалисту, если он в команде.
В теории это довольно простые вещи. Но вот на практике для своего эффективного воплощения они требуют соблюдения ряда условий. Необходимым условием является наличие развитого и тренированного ума у руководителя. Причем совершенно не важно, на чем был прокачан этот ум, важно чтобы это не был ум ботана с гипертрофировано развитым одним участком мозга и атрофированной остальной частью. Достаточным же условием является требование познания себя. В первую очередь развитие навыка быть всегда честным перед самим собой. Потому что с комплексами и стереотипами (тараканами в голове) управление людьми превращается в полет на самолете с неисправными датчиками, гарантированно ведущим к аварии с жертвами.
С этой точки зрения описанное в статье использование различных методик и инструментов свидетельствует о банальной ситуации дураков во власти, которая лечится исключительно хирургическими способами.
Мне кажется, что когда говорят про Apple, то это не про технологии, а про бабки. Когда говорят, что производительность телефонов/планшетов Apple на ARM почти не уступает производительности компьютеров Apple на Core i7/i9, то это всего лишь говорит об избыточной мощности архитекторы x86 для программного обеспечения, которое работает на оборудовании Apple.
Отсюда для бизнесменов из Apple следует достаточно очевидный вывод, сформулированный по результатам проведенного функционально-стоимостного анализа (ну или как там это сегодня называется), что в их продукцию можно легко впихнуть более дешевый процессор без потери потребительских свойств оборудования для конечного пользователя (то есть для фанатов Apple).
Вот только нужно предварительно провести маркетинговые мероприятия по раскрутке новой крутой архитекторы собственных процессоров, чтобы после снижения себестоимости фанаты продолжили бы покупать продукцию Apple по старой цене. В результате и фанаты довольны, и у Apple растет прибыль. Как говорится «ничего личного, это просто бизнес».
Все, что описано в статье, довольно жизненно. Вот только оно касается практически всех профессий, а потому не понятно, причем здесь 1С? Если уж говорить об 1С, то интересно было бы узнать про модели лицензирования (для пользователей) или покупки франшизы 1С (для подрядчиков) с точки зрения уровня оплаты труда. Может быть юридические аспекты работы с 1С и не предполагают высокий уровень заработной платы для рядовых программистов 1С?
Если же говорить о программистах промышленного предприятия, то было бы интересно услышать о порядке формирования фонда оплаты (ФОТ) труда ИТ-подразделений, а также о механизмах распределения ФОТ между сотрудниками подразделения (премии, КТУ и т.п.). Может быть дело в том, что на промышленном предприятии увеличение заработной платы для конкретного сотрудника ИТ-подразделения можно реализовать только за счет уменьшения заработной платы другого? И это ни для кого не является каким-то откровением?
Указанные Вами библиотеки вводят дополнительные уровни абстракций, упрощая программирование за счет снижения производительности и увеличения объема кода. Предлагаемые же предложения направлены на реализацию такой функциональности на уровне движка браузера.
Речь не идет ни о каких DSL, а только о повышении функциональности существующих DOM-элементов, чтобы ими можно было легко управлять средствами JS. Например:
1. Для элемента table сделать горизонтальную и вертикальную прокрутку, при этом чтобы элементы td не прокручивались, а лишь менялось содержимое данных таблицы, чтобы можно было делать большие таблицы без просадов по памяти.
2. Сделать нормальные компоновщики в виде html-элементов вместо CSS-костылей в виде Flexbox Layout и Grid Layout.
3. Сделать дочерние окна, в том числе вызываемые alert, prompt и confirm, в виде компонента типа div, для которого можно настраивать содержимое штатным образом и устанавливать режим модальности.
4. Реализовать примитивы типа меню, различных табов и т.д., чтобы не сочинять их каждый раз, а только настраивать их внешний вид средствами CSS.
Это то, что сразу приходит на ум, когда сравниваешь создание интерфейсов на Java и JavaScript. И еще раз подчеркну, речь идет о приложениях типа Excel и 1С, которые востребованы именно в корпоративном секторе.
Для инфраструктурных проектов такое положение дел в порядке вещей. Просто в последние годы сложность элементарных вещей на фронтенде начинает просто зашкаливать. И если тот же Google со своим движком V8 не будет ничего делать в этом направлении, то на ровном месте может появится его конкурент, который в один прекрасный момент сделает ненужным все эти TypeScript, React, Angular и прочие костыли для JavaScript.
Для начала это будет браузер, ориентированный на корпоративных клиентов, позволяющий писать легкие и быстрые SPA на JS в ООП-стиле без всякого рода прокладок в виде фреймворков. Затем через некоторое время для этого браузера будет реализован веб-офис (почта, текстовый редактор, электронная таблица), который будет не ползать, а летать. Ну а дальше начнется экспансия этого браузера в попсовый интернет, может медленная, а может и взрывная.
Ну, еще не все закончено. В принципе, концепция стандарта html5, предполагающая разработку отдельных модулей, позволяет постепенно вносить в модель DOM нужные изменения.
Например, возьмем модули Flexbox Layout и Grid Layout, в которых по какой-то странной причине управление размещением компонентов определено на уровне CSS, а не на уровне HTML. В результате из JS-кода приходится работать не напрямую с DOM, а генерить кучу лишнего кода для работы с CSS-файлами, так как из JS кода нет доступа к модели данных CSS, а это означает периодическое обращение к медленному диску, пусть даже и SSD.
Так вот, теоретически в дополнение к компоновке на уровне CSS можно сделать реализацию компоновки на уровне HTML, чтобы работать из JS напрямую с контейнерами, которые бы автоматически меняли все размеры при добавлении компонентов в ту или иную область. Чтобы просто писать теги
<flex-layout>...</flex-layout>
вместо использования конструкции
<div class="flex-layout">...</div>
c определением в CSS-файле
flex-layout { display: flex;}
В общем идея применительно к данному модулю заключается в том, чтобы переместить из CSS в HTML любой функционал, который определяет не внешний вид, а поведение отдельных компонентов страницы. Ну а для совместимости оставить функционал в CSS, который будет работать не напрямую с движком браузера, а через DOM-моделью.
Хочу поддержать автора, пусть даже он и перегибает палку. Но зайду немного с другой стороны — а для чего вообще нужна разного рода компиляция для интерпретируемого языка? На мой взгляд проблема кроется не в криворукости фронтендеров, а в отсутствии нормальных DOM-примитивов, которыми можно было бы эффективно управлять из JavaScript. По идее, сегодня для создания фронтенда нужен только JS и CSS, для HTML же остается только ниша статики.
Вот только производители браузеров по какой-то причине не хотят сделать нормальные нативные DOM-примитивы, которые позволяли бы не заниматься разного рода извращениями, а писать простой и понятный код, сдабривая его CSS-оформлением. Приведу только один пример, близкий мне. Вот почему для DOM-элемента table нет реализации горизонтальной и вертикальной прокрутки таблицы, размеры которой превышают заданный прямоугольник? Лично мне не понятно.
Ладно раньше, когда Microsoft козлячил, пытаясь двигать свои стандарты поперек сообщества. Но сегодня-то что мешает? Отсюда и разного рода извращения, по разному реализованные у Google, Microsoft и других разработчиков, чтобы реализовать ту же таблицу, которую в Java 1.1 более 20 лет назад можно было сделать с нуля за неделю, а затем использовать в Java-апплетах.
Ну ладно корпорации, которым выгодно создавать на пустом месте рынки сбыта для своей продукции. Но вот почему эта тема не звучит в профессиональном сообществе? Предлагаю поднять этот вопрос на площадке Хабра.
Ок. Попробую уточнить свою позицию. Для меня важно лишь то, что человек СДЕЛАЛ, что ему помогло добиться результата, что ему мешало, и как он смог обойти препятствия. Также интересен неудачный опыт, но опять же в ключе что было СДЕЛАНО, что помогало и что мешало.
Вы же указываете лишь на сферы Ваших интересов и Вашей деятельности, при этом не уточняя реальные проблемы, связанные с ограничениями того или иного языка, с которыми Вы лично сталкивались, и которые не смогли преодолеть. То есть нет даже намека на СДЕЛАНО. Уж извините, но жалобы на отсутствие фичей в том или ином языке для меня относится к области «на вкус и цвет товарища нет».
Просто в своей практике мне приходилось сталкиваться с ситуациями, когда некий программист вовсю расхваливает C# и чморит Java, но при этом не может сделать нормальные индексы в MS SQL. Другой программист топит за TypeScript и модные фреймворки и воротит нос от классического JavaScript, но при этом не может внятно сформулировать, какие преимущества дают его любимчики для конкретного прикладного решения, а то, что переход требует времени и денег, его вообще не колышет. Третий же пишет на Java, ориентируясь на версию 1.2.2, создавая под себя необходимые библиотеки, но при этом у него все летает и сидят довольные пользователи.
Поэтому лично для меня хаяние любых языков программирования является однозначным признаком низкого профессионального уровня. Профессионалы, в моем понимании, обсуждают имеющиеся возможности того или иного языка применительно к решению конкретных задач с учетом ограничений по времени и ресурсам. Уж извините за резкость.
P.S.: Хотя я сам был бы рад опциональной типизации и поддержке интерфейсов в JavaScript.
Изложенная в статье позиция имеет право на существование. Вот только это позиция программиста, решающего частные задачи по заказу команд, работающих над крупными проектами. Программиста, для которого язык программирования является не способом общения с коллегами по цеху, а инструментом решения частных проблем. Своего рода аутсорсера, ограниченного рамками техзадания и сильно лимитированного по времени.
Первое, что сразу бросается в глаза, это избыток местоимения «я», и полное отсутствие «мы». Также обращает на себя внимание отсутствие в статье даже намека на собственные решения по обходу ограничений того или иного языка, которые непроизвольно вырабатываются при работе над крупным проектом в течение длительного времени. В конце концов, сам автор указывает на максимальный срок реализации самой большой фичи — это 2 месяца.
По этой причине не вижу особого смысла в обсуждении обозначенной проблемы в силу ее крайней субъективности. Автору же можно посоветовать вписаться в крупный проект для приобретения нового жизненного опыта. Вот немцы тоже давно обсуждают, что негоже числа произносить задом наперед (вместо «двадцать два» они говорят «два и двадцать» одним словом), но до сих пор не могут что-то изменить в этом казалось бы на первый взгляд простом вопросе, хотя при этом особо не страдают от отсутствия синтаксического сахара в немецком языке.
Согласен, что многие вещи действительно «далеки от хороших практик». Тем не менее, это был проект, в основном завершенный в 2016 году, после чего многие организационные вещи были приведены в классический вид, в том числе вопросы предоставления прав доступа. Кроме того, многие технические и организационные проблемы, напрямую не связанные с проектом, были оптимизированы под его влиянием.
Данный перечень был приведен как пример того, что на момент создания нового продукта существуют не только технические, но и организационные трудности, решать которые, на мой взгляд, лучше всего архитектору как специалисту, имеющему целостное видение конечного результата и препятствий по его достижению.
При этом, как это часто бывает в жизни, некоторые задачи либо приходится делать самому, так так альтернативой этому является откладывание их решение до лучших времен. Как пример, это реализованное в самом начале проекта временное решение по прокачке данных на уровне MS SQL, альтернатива которому была сформирована только к концу проекта. А до этого времени приходилось делать это самому, так как программисты не понимали бизнес-логику, а экономисты не имели опыта работы с SQL-базами.
Еще одно важное замечание связано с тем, что некоторые организационные решения являются гораздо более эффективной альтернативой программной разработке некоторого функционала. И такие вопросы опять же могут быть решены только архитектором, обладающим видением конечного результата и критериев его эффективности.
На мой взгляд роль архитектора в проекте можно определить как переводчик с языка предметной области на язык программистов и обратно. И так как предметная область и область программирования оперируют практически непересекающимися сущностями, то качественный перевод предполагает конструирование сущностей для каждой стороны исходя из задаваемых противоположной стороной рамок в виде пожеланий или недовольства.
Данный тезис можно продемонстрировать на примере задач, выполняемых мной в в качестве архитектора в проекте создания программного обеспечения для экономических подразделений крупной промышленной Компании. В проекте было задействовано помимо меня в разное время от 1 до 3 программистов и от 2 до 3 специалистов предметных областей. На начальном этапе количество пользователей составляло около 100 человек, в настоящее время количество активных пользователей превышает 1000 человек. Проект разрабатывался с 2009 по 2016 год.
Итак, функции архитектора специализированного программного обеспечения (далее ПО):
1. Разработка и развитие модели хранения данных и расчетной модели.
2. Настройка и расширение структуры данных ПО (объекты учета, типы и классы объектов учета, системные справочники).
3. Настройка компонентов подсистемы бизнес-транзакций ПО (бухгалтерские счета, проводки, документы, связи документов, фильтры счетов и проводок).
4. Расширение возможностей архитектуры действующей версии ПО и новой версии ПО 2.0 под новые задачи подразделений.
5. Организация перевода работы строительного подразделения Компании из замороженной версии ПО-Строительство на типовую модель данных ПО-Экономика, используемой экономическим подразделением Компании.
6. Постановка задач по развитию функциональности подсистемы бизнес-транзакций ПО и переносу форм устаревшей архитектуры на новую модель бизнес-транзакций.
7. Постановка задач перед внешними подрядчиками по разработке отдельных функций в новой версии ПО 2.0.
8. Адаптация настроек действующей версии ПО под требования программы переноса данных из действующей версии ПО в новую версию ПО 2.0.
9. Настройка автоматической прокачки данных документов на уровне базы данных MS SQL на языке Transact SQL и встроенного языка формул ПО с помощью подключаемого расчетного модуля в действующей версии ПО.
10. Создание и настройка форм пользовательских документов посредством конфигурационных файлов на Python-подобном упрощенном синтаксисе с последующей их компиляцией в конфигурационные файлы ПО в формате XML.
11. Создание колонок документов в базе данных и настройка формул для формульных колонок.
12. Помощь сотрудникам экономического подразделения Компании в настройке формул строк документов с особо сложной предметной логикой.
13. Поиск и исправление логических ошибок в расчетной системе ПО.
14. Предоставление прав доступа к ПО сотрудникам Компании.
15. Настройка расширенных прав доступа и предоставление в ним доступа сотрудникам предприятий Компании для решения специфических задач.
16. Консультирование подразделений Компании, применяющих ПО в своей работе, по эффективному применению ПО.
17. Контроль и координация деятельности сотрудников отдела информационного обеспечения в рамках текущего сопровождения ПО.
18. Контроль и координация деятельности всех сотрудников Компании, задействованных в процессе настройки и использования ПО, через трекер задач.
19. Разработка и проведение курсов подготовки пользователей ПО на площадке учебного центра Компании.
20. Арбитраж сложных организационных ситуаций, возникающих в процессе эксплуатации ПО между сотрудниками предприятий Компании, подразделений Компании и отдела информационного обеспечения.
Согласен, что такой незаменимый человек является узким местом, которого любой бизнес в здравом уме всегда будет пытаться избегать. Для решения этой проблемы есть идея создания профессиональной ассоциации экономистов-плановиков, аналоги которых существуют в других профессиях. Со своими стандартами, периодической переподготовкой и аттестацией, членством в ассоциации, классными чинами, этическим кодексом, корпоративной солидарностью и т.п. Ну и конечно же со своим профессиональным программным обеспечением. Чтобы бизнес был спокоен, что если накосячит один из членов сообщества, то его всегда подстрахуют его коллеги.
Тогда еще тема для размышления уже из собственного опыта. Сам я специализируюсь на разработке систем экономического планирования и анализа, выступая в качестве постановщика, архитектора и тестировщика, плюс разрабатываю схемы баз данных. Написанием кода занимаются другие люди. Проработав в этом направлении более 10 лет с несколькими командами разработчиков, всегда сталкивался с довольно неприятной проблемой.
На начальном этапе, когда реализуется базовый ввод/вывод данных, разработчики достаточно глубоко погружаются в предметную область. Но со временем, когда работа в основном фокусируется на различных прикладных алгоритмах, разработчики постепенно перестают понимать суть предметной функциональности, которую они воплощают в коде. И это несмотря на периодические лекции на тему экономики, максимально четкие формулировки задач в трекере и т.д. И здесь начинают проявляться описанные в статье проблемы — невыполнение сроков, кривой код, отсутствие не то что тестов, но даже простейших комментариев к процедурам и т.п.
На сегодня решение данной проблемы я вижу в максимальном разделении программного кода и пользовательского API, чтобы из кода полностью исключить предметную область. Но здесь тоже не все так просто. Обычно пользователи не заморачиваются в четком формулировании своих хотелок. В предложенной же схеме им приходится не просто озвучивать четко свои хотелки, но и воплощать их в виде настроек программного продукта. Но таких людей довольно мало, то есть в наличии проблема дефицита профессиональных кадров в сфере экономического планирования. С другой стороны, при наличии даже одного экономиста высокого класса, который на «ты» с ИТ, существенно снижаются требования к профессиональному уровню рядовых сотрудников экономических подразделений, так как их просто загоняют в своеобразный управленческий ИТ-конвейер с хорошей защитой от дурака.
Статья понравилась. Вот только не увидел в ней описание проблемы необходимости погружения разработчика в предметную область заказчика. Поясню. У моего знакомого начальство периодически требует, чтобы он составил техзадание на свой продукт, который давно и успешно эксплуатируется на предприятии. Он обычно футболит такие запросы, но когда сильно достают, то тогда отправляет в качестве техзадания Налоговый кодекс РФ. И начальство затыкается после этого на пару лет, так как понимает, что людей, способных перевести текст Налогового кодекса в нечто похожее на техзадание, просто нет, а даже если бы они и были, то разработка такого ТЗ всегда бы запаздывала по установленным государством срокам внедрения тех или иных налоговых новаций.
То есть, будучи чистым разработчиком, он не только выступает в качестве архитектора, но также и постановщика задач самому себе, работающего на основе постоянно меняющихся нормативных документов в сфере бухгалтерского учета и налогообложения. Результатом такого подхода является продукт, функциональность которого не могут даже в первом приближении воспроизвести наиболее раскрученные продукты фирм 1С или SAP.
Им разработана собственная библиотека, упрощающая доработку существующей функциональности и добавление принципиально новой. Вот только эта библиотека ориентирована не на повышение эффективности работы с кодом, а на возможность использования данной библиотеки тетеньками, владеющими навыками программирования, которые более-менее разбираются в предметной области. И такой подход вполне себе эффективно работает, справляясь с большинством описанных в статье проблем.
Отсюда и возникло первоначально озвученное сомнение, что попытка облегчить труд разработчиков по написанию качественного кода может оказаться тупиковым решением, если не будет учитывать специфику предметной области или ориентироваться на некоего абстрактного заказчика.
Да какая разница с какого языка начинать. На мой взгляд, главное в процессе обучения — это обеспечить баланс между наглядностью (осязаемостью) результатов и пониманием происходящих «под капотом» процессов. Причем в зависимости от личности обучающегося нужно делать крен в ту или иную сторону.
В этой связи вполне себе может оказаться работоспособной связка языков с похожим синтаксисом, например С (для понимания) и JavaScript (для наглядности). Это как одновременное изучение, например, английского и немецкого языков.
Лично у меня первый опыт программирования связан с освоением стекового калькулятора Электроника МК-61. Офигенно интересная штука, хотя для жизни оказалась бесполезной, кроме элементарных вещей. Для понимания изучал С, но лучше зашел Assembler. Для прикладных же вещей 20 лет назад лучше всего оказалась Java, сегодня же это JavaScript.
Можете конечно так считать. Просто мне самому лично приходилось разрабатывать коммерческие договоры с научными организациями, предметом которых являлось выполнение определенных работ, которые изначально никому не были нужны, а потому оплата таких работ по своей сути являлась чистой благотворительностью.
Но, как говорится, жадность фраера сгубила — еще пару лет и на Хабр удобнее всего будет заходить с поисковика, чтобы не копаться в отходах информационной жизнедеятельности в поисках нужной информации. Да и то, чтобы найти материалы многолетней давности, так как свежие материалы в большинстве своем являются свежими только по дате упаковки, но протухшие по содержимому.
Так что уже можно начинать делать всем локальные архивы Хабра, чтобы в какой-то момент не получить платный доступ к старым качественным материалам.
В теории это довольно простые вещи. Но вот на практике для своего эффективного воплощения они требуют соблюдения ряда условий. Необходимым условием является наличие развитого и тренированного ума у руководителя. Причем совершенно не важно, на чем был прокачан этот ум, важно чтобы это не был ум ботана с гипертрофировано развитым одним участком мозга и атрофированной остальной частью. Достаточным же условием является требование познания себя. В первую очередь развитие навыка быть всегда честным перед самим собой. Потому что с комплексами и стереотипами (тараканами в голове) управление людьми превращается в полет на самолете с неисправными датчиками, гарантированно ведущим к аварии с жертвами.
С этой точки зрения описанное в статье использование различных методик и инструментов свидетельствует о банальной ситуации дураков во власти, которая лечится исключительно хирургическими способами.
Отсюда для бизнесменов из Apple следует достаточно очевидный вывод, сформулированный по результатам проведенного функционально-стоимостного анализа (ну или как там это сегодня называется), что в их продукцию можно легко впихнуть более дешевый процессор без потери потребительских свойств оборудования для конечного пользователя (то есть для фанатов Apple).
Вот только нужно предварительно провести маркетинговые мероприятия по раскрутке новой крутой архитекторы собственных процессоров, чтобы после снижения себестоимости фанаты продолжили бы покупать продукцию Apple по старой цене. В результате и фанаты довольны, и у Apple растет прибыль. Как говорится «ничего личного, это просто бизнес».
Если же говорить о программистах промышленного предприятия, то было бы интересно услышать о порядке формирования фонда оплаты (ФОТ) труда ИТ-подразделений, а также о механизмах распределения ФОТ между сотрудниками подразделения (премии, КТУ и т.п.). Может быть дело в том, что на промышленном предприятии увеличение заработной платы для конкретного сотрудника ИТ-подразделения можно реализовать только за счет уменьшения заработной платы другого? И это ни для кого не является каким-то откровением?
1. Для элемента table сделать горизонтальную и вертикальную прокрутку, при этом чтобы элементы td не прокручивались, а лишь менялось содержимое данных таблицы, чтобы можно было делать большие таблицы без просадов по памяти.
2. Сделать нормальные компоновщики в виде html-элементов вместо CSS-костылей в виде Flexbox Layout и Grid Layout.
3. Сделать дочерние окна, в том числе вызываемые alert, prompt и confirm, в виде компонента типа div, для которого можно настраивать содержимое штатным образом и устанавливать режим модальности.
4. Реализовать примитивы типа меню, различных табов и т.д., чтобы не сочинять их каждый раз, а только настраивать их внешний вид средствами CSS.
Это то, что сразу приходит на ум, когда сравниваешь создание интерфейсов на Java и JavaScript. И еще раз подчеркну, речь идет о приложениях типа Excel и 1С, которые востребованы именно в корпоративном секторе.
Для начала это будет браузер, ориентированный на корпоративных клиентов, позволяющий писать легкие и быстрые SPA на JS в ООП-стиле без всякого рода прокладок в виде фреймворков. Затем через некоторое время для этого браузера будет реализован веб-офис (почта, текстовый редактор, электронная таблица), который будет не ползать, а летать. Ну а дальше начнется экспансия этого браузера в попсовый интернет, может медленная, а может и взрывная.
Например, возьмем модули Flexbox Layout и Grid Layout, в которых по какой-то странной причине управление размещением компонентов определено на уровне CSS, а не на уровне HTML. В результате из JS-кода приходится работать не напрямую с DOM, а генерить кучу лишнего кода для работы с CSS-файлами, так как из JS кода нет доступа к модели данных CSS, а это означает периодическое обращение к медленному диску, пусть даже и SSD.
Так вот, теоретически в дополнение к компоновке на уровне CSS можно сделать реализацию компоновки на уровне HTML, чтобы работать из JS напрямую с контейнерами, которые бы автоматически меняли все размеры при добавлении компонентов в ту или иную область. Чтобы просто писать теги вместо использования конструкции c определением в CSS-файле
В общем идея применительно к данному модулю заключается в том, чтобы переместить из CSS в HTML любой функционал, который определяет не внешний вид, а поведение отдельных компонентов страницы. Ну а для совместимости оставить функционал в CSS, который будет работать не напрямую с движком браузера, а через DOM-моделью.
Вот только производители браузеров по какой-то причине не хотят сделать нормальные нативные DOM-примитивы, которые позволяли бы не заниматься разного рода извращениями, а писать простой и понятный код, сдабривая его CSS-оформлением. Приведу только один пример, близкий мне. Вот почему для DOM-элемента table нет реализации горизонтальной и вертикальной прокрутки таблицы, размеры которой превышают заданный прямоугольник? Лично мне не понятно.
Ладно раньше, когда Microsoft козлячил, пытаясь двигать свои стандарты поперек сообщества. Но сегодня-то что мешает? Отсюда и разного рода извращения, по разному реализованные у Google, Microsoft и других разработчиков, чтобы реализовать ту же таблицу, которую в Java 1.1 более 20 лет назад можно было сделать с нуля за неделю, а затем использовать в Java-апплетах.
Ну ладно корпорации, которым выгодно создавать на пустом месте рынки сбыта для своей продукции. Но вот почему эта тема не звучит в профессиональном сообществе? Предлагаю поднять этот вопрос на площадке Хабра.
Вы же указываете лишь на сферы Ваших интересов и Вашей деятельности, при этом не уточняя реальные проблемы, связанные с ограничениями того или иного языка, с которыми Вы лично сталкивались, и которые не смогли преодолеть. То есть нет даже намека на СДЕЛАНО. Уж извините, но жалобы на отсутствие фичей в том или ином языке для меня относится к области «на вкус и цвет товарища нет».
Просто в своей практике мне приходилось сталкиваться с ситуациями, когда некий программист вовсю расхваливает C# и чморит Java, но при этом не может сделать нормальные индексы в MS SQL. Другой программист топит за TypeScript и модные фреймворки и воротит нос от классического JavaScript, но при этом не может внятно сформулировать, какие преимущества дают его любимчики для конкретного прикладного решения, а то, что переход требует времени и денег, его вообще не колышет. Третий же пишет на Java, ориентируясь на версию 1.2.2, создавая под себя необходимые библиотеки, но при этом у него все летает и сидят довольные пользователи.
Поэтому лично для меня хаяние любых языков программирования является однозначным признаком низкого профессионального уровня. Профессионалы, в моем понимании, обсуждают имеющиеся возможности того или иного языка применительно к решению конкретных задач с учетом ограничений по времени и ресурсам. Уж извините за резкость.
P.S.: Хотя я сам был бы рад опциональной типизации и поддержке интерфейсов в JavaScript.
Первое, что сразу бросается в глаза, это избыток местоимения «я», и полное отсутствие «мы». Также обращает на себя внимание отсутствие в статье даже намека на собственные решения по обходу ограничений того или иного языка, которые непроизвольно вырабатываются при работе над крупным проектом в течение длительного времени. В конце концов, сам автор указывает на максимальный срок реализации самой большой фичи — это 2 месяца.
По этой причине не вижу особого смысла в обсуждении обозначенной проблемы в силу ее крайней субъективности. Автору же можно посоветовать вписаться в крупный проект для приобретения нового жизненного опыта. Вот немцы тоже давно обсуждают, что негоже числа произносить задом наперед (вместо «двадцать два» они говорят «два и двадцать» одним словом), но до сих пор не могут что-то изменить в этом казалось бы на первый взгляд простом вопросе, хотя при этом особо не страдают от отсутствия синтаксического сахара в немецком языке.
Данный перечень был приведен как пример того, что на момент создания нового продукта существуют не только технические, но и организационные трудности, решать которые, на мой взгляд, лучше всего архитектору как специалисту, имеющему целостное видение конечного результата и препятствий по его достижению.
При этом, как это часто бывает в жизни, некоторые задачи либо приходится делать самому, так так альтернативой этому является откладывание их решение до лучших времен. Как пример, это реализованное в самом начале проекта временное решение по прокачке данных на уровне MS SQL, альтернатива которому была сформирована только к концу проекта. А до этого времени приходилось делать это самому, так как программисты не понимали бизнес-логику, а экономисты не имели опыта работы с SQL-базами.
Еще одно важное замечание связано с тем, что некоторые организационные решения являются гораздо более эффективной альтернативой программной разработке некоторого функционала. И такие вопросы опять же могут быть решены только архитектором, обладающим видением конечного результата и критериев его эффективности.
Данный тезис можно продемонстрировать на примере задач, выполняемых мной в в качестве архитектора в проекте создания программного обеспечения для экономических подразделений крупной промышленной Компании. В проекте было задействовано помимо меня в разное время от 1 до 3 программистов и от 2 до 3 специалистов предметных областей. На начальном этапе количество пользователей составляло около 100 человек, в настоящее время количество активных пользователей превышает 1000 человек. Проект разрабатывался с 2009 по 2016 год.
Итак, функции архитектора специализированного программного обеспечения (далее ПО):
1. Разработка и развитие модели хранения данных и расчетной модели.
2. Настройка и расширение структуры данных ПО (объекты учета, типы и классы объектов учета, системные справочники).
3. Настройка компонентов подсистемы бизнес-транзакций ПО (бухгалтерские счета, проводки, документы, связи документов, фильтры счетов и проводок).
4. Расширение возможностей архитектуры действующей версии ПО и новой версии ПО 2.0 под новые задачи подразделений.
5. Организация перевода работы строительного подразделения Компании из замороженной версии ПО-Строительство на типовую модель данных ПО-Экономика, используемой экономическим подразделением Компании.
6. Постановка задач по развитию функциональности подсистемы бизнес-транзакций ПО и переносу форм устаревшей архитектуры на новую модель бизнес-транзакций.
7. Постановка задач перед внешними подрядчиками по разработке отдельных функций в новой версии ПО 2.0.
8. Адаптация настроек действующей версии ПО под требования программы переноса данных из действующей версии ПО в новую версию ПО 2.0.
9. Настройка автоматической прокачки данных документов на уровне базы данных MS SQL на языке Transact SQL и встроенного языка формул ПО с помощью подключаемого расчетного модуля в действующей версии ПО.
10. Создание и настройка форм пользовательских документов посредством конфигурационных файлов на Python-подобном упрощенном синтаксисе с последующей их компиляцией в конфигурационные файлы ПО в формате XML.
11. Создание колонок документов в базе данных и настройка формул для формульных колонок.
12. Помощь сотрудникам экономического подразделения Компании в настройке формул строк документов с особо сложной предметной логикой.
13. Поиск и исправление логических ошибок в расчетной системе ПО.
14. Предоставление прав доступа к ПО сотрудникам Компании.
15. Настройка расширенных прав доступа и предоставление в ним доступа сотрудникам предприятий Компании для решения специфических задач.
16. Консультирование подразделений Компании, применяющих ПО в своей работе, по эффективному применению ПО.
17. Контроль и координация деятельности сотрудников отдела информационного обеспечения в рамках текущего сопровождения ПО.
18. Контроль и координация деятельности всех сотрудников Компании, задействованных в процессе настройки и использования ПО, через трекер задач.
19. Разработка и проведение курсов подготовки пользователей ПО на площадке учебного центра Компании.
20. Арбитраж сложных организационных ситуаций, возникающих в процессе эксплуатации ПО между сотрудниками предприятий Компании, подразделений Компании и отдела информационного обеспечения.
На начальном этапе, когда реализуется базовый ввод/вывод данных, разработчики достаточно глубоко погружаются в предметную область. Но со временем, когда работа в основном фокусируется на различных прикладных алгоритмах, разработчики постепенно перестают понимать суть предметной функциональности, которую они воплощают в коде. И это несмотря на периодические лекции на тему экономики, максимально четкие формулировки задач в трекере и т.д. И здесь начинают проявляться описанные в статье проблемы — невыполнение сроков, кривой код, отсутствие не то что тестов, но даже простейших комментариев к процедурам и т.п.
На сегодня решение данной проблемы я вижу в максимальном разделении программного кода и пользовательского API, чтобы из кода полностью исключить предметную область. Но здесь тоже не все так просто. Обычно пользователи не заморачиваются в четком формулировании своих хотелок. В предложенной же схеме им приходится не просто озвучивать четко свои хотелки, но и воплощать их в виде настроек программного продукта. Но таких людей довольно мало, то есть в наличии проблема дефицита профессиональных кадров в сфере экономического планирования. С другой стороны, при наличии даже одного экономиста высокого класса, который на «ты» с ИТ, существенно снижаются требования к профессиональному уровню рядовых сотрудников экономических подразделений, так как их просто загоняют в своеобразный управленческий ИТ-конвейер с хорошей защитой от дурака.
То есть, будучи чистым разработчиком, он не только выступает в качестве архитектора, но также и постановщика задач самому себе, работающего на основе постоянно меняющихся нормативных документов в сфере бухгалтерского учета и налогообложения. Результатом такого подхода является продукт, функциональность которого не могут даже в первом приближении воспроизвести наиболее раскрученные продукты фирм 1С или SAP.
Им разработана собственная библиотека, упрощающая доработку существующей функциональности и добавление принципиально новой. Вот только эта библиотека ориентирована не на повышение эффективности работы с кодом, а на возможность использования данной библиотеки тетеньками, владеющими навыками программирования, которые более-менее разбираются в предметной области. И такой подход вполне себе эффективно работает, справляясь с большинством описанных в статье проблем.
Отсюда и возникло первоначально озвученное сомнение, что попытка облегчить труд разработчиков по написанию качественного кода может оказаться тупиковым решением, если не будет учитывать специфику предметной области или ориентироваться на некоего абстрактного заказчика.
В этой связи вполне себе может оказаться работоспособной связка языков с похожим синтаксисом, например С (для понимания) и JavaScript (для наглядности). Это как одновременное изучение, например, английского и немецкого языков.
Лично у меня первый опыт программирования связан с освоением стекового калькулятора Электроника МК-61. Офигенно интересная штука, хотя для жизни оказалась бесполезной, кроме элементарных вещей. Для понимания изучал С, но лучше зашел Assembler. Для прикладных же вещей 20 лет назад лучше всего оказалась Java, сегодня же это JavaScript.