Website development
CSS
JavaScript
Build automation
TypeScript
Comments 37
0

Здравствуйте! Давно не видели историй о вашем интересном проекте.


А как в MAM реализовать приватное API модулей? Судя по всему, все имена глобальны, можно заиспользовать любой класс в любом другом, а это чревато тяжелыми последствиями, если будет нужно зарефакторить какую-то часть кода.

0

Если кто-то воспользовался вашим внутренним классном вместо задокументированного API, то:
1) Оно ему действительно надо.
2) Он берёт на себя всю ответственность за возможные тяжёлые последствия.


Тем не менее, предполагая, что кто-то мог воспользоваться вашим классом, вы можете рефакторить и не ломая его интерфейс, а создавая новый. К старому же добавляя deprecation варнинг с инструкцией по переходу на новый интерфейс.

0

Как документировать API в MAM структуре? Желательно, не руками, а генерацией из исходников

0

Что именно генерировать? Страничку с сигнатурами функций? Гораздо лучше и быстрее эту информацию предоставит IDE.

0

есть два класса, $my_class_one и $my_class_two. Как понять, какой из них публичный, а какой – нет?

0

Можете добавить doc-коментарий к этим классам, можете назвать их так, чтобы было очевидно, что есть что.

0

Значит, ответ на изначальный вопрос такой и будет: приватное API определяется doc-комментариями. Ясно, спасибо за ответ.

0

Примечательно, что вы дали ссылку на graceful-fs — модуль, который исправляет косяки оригинального fs. И это замечательно, что есть возможность написать graceful-fs, а не давиться кактусом, пока команда ноды не хочет решать проблемы в fs.

+5
И все вместе решают проблемы с этой библиотекой, если они вдруг возникают. А не так, что одни уже обновились и бьются над проблемой, а у других хата с краю и они ни чем не помогают.
Здравствуйте, меня зовут Дмитрий Карловский, и я… люблю писать фантастику. В жанре «магический реализм».

Ответ стейкхолдера на предложение потратить часть бюджета на решение какой-то проблемы в новой версии библиотеки, ибо иначе продукт у кого-то там не заводится: Дракарис!
0

Когда я слышу такие рассуждения, мне всегда представляется бедный студент, перебивающийся от халявы к халяве и жалующийся, что на дорогу до неё приходится тратиться.

+3
Похоже это не магический реализм, а отрицание реальности.

Окэй, возьмём «одну компанию» из текущей статьи:
В итоге, по истечении 2 недель спринта, было решено… отложить обновление фреймворка до лучших времён, так как business value сам себя не создаст, пока команда возвращает технический долг, взятый с, как выяснилось, адскими процентами.

Эта компания вместо каких-то технических обновлений решила делать business value. А теперь представим, что эта компания выкинула ExtJS, Angular, Dart и так далее, у них теперь $jin $mol, MAM и розовые единороги с бабочками. Теперь у них тот же спринт выглядит так:

  1. Посреди спринта внезапно подкралось обновление библиотеки (библиотека тоже использует философию MAM, но она движется вперёд). Она теперь требует новую версию TS (MicroSoft слишком большие, чтобы смотреть на какой-то хайповый МАМ и делают всё по-старому, с богопротивными версиями) и кучу всего. Мы не можем не обновить: наш проект просто перестал собираться, ибо это философия МАМ! Обновляем свой старый код.
  2. Параллельно выяснилось, что новая версия библиотеки плохо работает на тех юзкейзах, которые характерны для нашего продукта. Сообщество помогает нам исправлять.
  3. Параллельно нам пришлось выделить 3 команды на помощь сообществу с другими проблемами, которые у нас решены.
  4. Мы не можем в этом спринте увеличить ценность продукта, ибо занимались техническим долгом (или правильней это назвать «техническим прерыванием?»). И посему весь скоуп спринта переехал на следующий спринт (разбить и перенести, ага).


Что мы имеем в итоге? Бизнес получает те же самые проблемы (обновление версий из окружающего мира), только теперь это стало вынужденным. И если стейкхолдерам сейчас очень важно сделать бизнес-ценность, например выкатить важную фичу перед переговорами о новом раунде инвестиций (стейкхолдеры наши — бедные студенты, перебивающиеся от халявы к халяве, поэтому пусть речь идёт об очередных $15 млн инвестиций), то они получат фигу. И, учитывая, что эта компания за две недели так и не перешла с Ангуляр@3 на Ангуляр@5, то нет никаких гарантий, что это «техническое прерывание» не займёт и весь следующий спринт. И да, сообщество по-прежнему помогает исправлять те просадки, которые выявились в новой версии — с этим всё по-прежнему не ясно.
0

Не могли бы вы вести себя более культурно? Заранее брагодарен.


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


У меня нет репрезентативной статистики, но по моему опыту держать проект постоянно в тонусе обходится в конечном счёте дешевле, чем делать это скачкообразно, когда припекает. Думаю вам стоит попробовать поработать с экосистемой MAM прежде чем фантазировать про 3 команды и сорванные спринты.


А если уж фантазировать про переход с Ангуляра на $mol, то могу вас заверить, что высвободившихся в результате такого перехода ресурсов хватит, чтобы пилить той же командой в 3 раза больше фичей, не пренебрегая обновлениями и рефакторингом. Достаточно взглянуть на эту статистику, чтобы понять размер трагедии:



И это при том, что в $mol куда больше функциональности, чем в Angular.

0
но по моему опыту держать проект постоянно в тонусе обходится в конечном счёте дешевле, чем делать это скачкообразно, когда припекает.

А по моему — наоборот.
0

Это как так получается?


В какой вселенной проще обновлять пакеты всем скопом, а не поштучно?

0
Эм… Об этом речи не было. Я о том, что каждый пакет проще обновлять не каждый раз.
+1

Да, но что делать, если сегодня у нас приложение собирается, и всё хорошо, а завтра автор внешней библиотеки выкатывает какой-нибудь фикс, который внезапно создаёт нам баг? Притом не важно, где происходит сборка: локально у разработчика или на CI-сервере.

+2

Ага, тратим целый день (как минимум) на анализ чужой библиотеки, отправляем пулреквест, а автор говорит: «Ок, спасибо, посмотрю как буду свободен».

0

Тоже бывало такое, в некоторых случаях будеь удобней форкнуть и положить в корпоративный репозиторий (или просто в npm), тогда и другие коллеги смогут использовать/поддерживать просто как зависимость. А через несколько месяцев, когда автор проснётся и примет PR, вернуться на оригинальный пакет.

-3

Чинить баг в своём коде. Не путайтесь в показаниях. Если же автор библиотеки закоммитил баг, а не фикс, то пинаете автора. Если автор тормозит, откатываетесь на предыдущую ревизию и продолжаете работу. Если автор совсем в спячке — форкаете и откатываете. Ну а если чувствуете в себе силы — чините самостоятельно. Вариантов много, и вы прекрасно сами все их знаете. В том числе и временная фиксация ревизии. Экстраординарные обстоятельства требуют экстраординарных решений. Ну а если один и тот же автор постоянно косячит — это хороший повод переключиться на альтернативу.

+2

Я не путаюсь в показаниях. Речь именно о баге во внешней библиотеке, повлекшей баг в собственном проекте.


Значит предлагается зафиксировать ревизию, если нет возможности быстро обновиться? Чем же это отличается от фиксации версии или использования ^x.0.0 в семвере? По сути обязанность автора библиотеки — в случае внесения обратно несовместимых изменений создать новый проект с увеличенным номером, но если ему трудно соблюсти семантическое версионирование, то вряд ли он будет соблюдать МАМ-версионирование, которое выглядит более трудоёмким. Гарантий опять же никаких нет. К тому же «новую» версию популярной библиотеки могут засквоттить недоброжелатели.

0

В статье есть ответы на все ваши вопросы:


Мы фундаментально не можем решить проблему несовместимости при обновлениях. Но мы можем научиться как-то с этим жить.

...


Заведите себе собственный неймспейс (для примера — acme) и пропишите в нём ссылки на ваши проекты (для примера — hello и home ):
+1
Не могли бы вы вести себя более культурно? Заранее брагодарен.
Я себя где-то не культурно веду? Например считаю, что вы отрицаете реальность? А как это сказать более культурно? «Сударь, не будете ли вы любезны вернуться в нашу реальность»? Да и с каких пор вы, ведя себя всегда в комментариях резко и вызывающе (прямо скажем — некультурно), стали таким неженкой?

Поясню почему ваш стейкхолдер производит такое впечатление.
Дело не в моём стейкхолдере (и вообще сейчас у меня с этим всё хорошо). Дело в простом и понятном примере на пальцах. С одной стороны — простые потребности бизнеса (потребности организации, которая функционирует в текущих окружающих условиях для получения прибыли). А с другой стороны — ваши эфемерные рассуждения о каком-то идеальном обществе и предложение бизнесу тратить больше денег.

… то могу вас заверить, что высвободившихся в результате такого перехода ресурсов хватит, чтобы пилить той же командой в 3 раза больше фичей
Не надо заверять, я уже видел вживую совершенно обратный результат в «одной компании».
-1

У меня с вами лишь одно пересечение по компаниям и то было задолго до появления $mol, так что не вводите окружающих в заблуждение. Далее у меня нет ни времени, ни желания с вами сраться.

0

Ой ли? Мой первый рабочий день был на следующий день после вашего увольнения. Или переименовав $jin в $mol тут же родилась новая библиотека?


Я и не предлагаю сраться, я указал на пробел в вашем замечательном рассказе. К сожалению, вы не смогли в ответ рассказать что-либо, кроме эмоций и заверений. А то что вы любое несогласие с вами воспринимаете как агрессию — это ваша проблема.

+3

Между этими библиотеками нет ничего общего, кроме организации кода по принципам МАМ. Мне очень жаль, что вам пришлось ковыряться с тем кодом, написанном на яваскрипте с кастомной системой описания классов и не самой оптимальной по сегодняшним меркам реализацией реактивности. К сожалению, у меня не было возможности переписать его на тайпскрипте.

0
Например, однажды в одной компании стартанули проект на актуальном на тот момент Angular@4 (или даже 3)


Это такой подвох для внимательного читателя? Angular 3 никогда не существовал, сразу перескочив на 4, как раз из-за перехода на semver и решения проблем зоопарка версий ключевых модулей.
0
На Хабре столько раз обсуждалось, что в ТС-варианте 3-я версия пропущена, а для Дарт-варианта не пропущена… Технически вы правы, если под словом Angular подразумевать только TS-вариант. Но, как мне кажется, автор подразумевал именно Дарт-вариант (несмотря на эпатажность и заскоки автора, он всё-таки разбирается в предметной области). И вообще в контексте статьи этот вопрос не важен :)
+1

Это не так. Третьей версией я, разумеется, назвал Angular2 с модулями, добравшимися, до 3+ версии. Впрочем, конкретные цифры не важны в повествовании.

0
Идея хороша, но хотелось бы, чтобы дев-версию проекта можно было запускать без сборки.
0

Буквально только что пофиксил багу с прода привнесённую минификатором.


Идея: Что если у девелопера будет крутиться абсолютно тот же код, что и на проде?

0
Некоторые пункты применимы и без внедрения собственно МАМ:

— Соглашения вместо конфигурирования
— Инфраструктура отдельно, код отдельно
— Не платить за то, что не используешь
— Минимум лишнего кода

А собственно версионирование — необходимое зло для поддержания порядка, но которое можно обуздать.
Only those users with full accounts are able to leave comments. , please.