coding programming software-development open-source debugging business github npm

Как помочь сообществу разработчиков, решив собственные проблемы

15 апреля 2022 г.

Привет! Меня зовут Майк Альфа. И я хотел бы поделиться своими мыслями об открытом исходном коде.

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

Я говорю о решениях с открытым исходным кодом, которые экономят нам десятки тысяч часов разработки и миллиарды долларов, а также спасают нас от миллионов ошибок. Только представьте, вы начинаете новый проект и вам нужно заново изобретать Backend framework с нуля, чтобы написать простенький CRUD. Или создание каждого из ваших новых интернет-магазинов как реактивного фреймворка, написанного с нуля в стиле тех, что были написаны до React и Angular.

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

Возможно, со временем некоторые компании выпустят на рынок свои более-менее эффективные и качественные программные решения (ну тот же Бэкенд/Клиент frameworks) и продайте их нам. Это было бы «круто» — если вы хотите преобразовать [JSON в Excel] (https://www.npmjs.com/package/exceljs) во внешнем интерфейсе с помощью пары строк кода — вы заплатите 100 долларов ( за месяц, это подписка!).

Что, если вы хотите видеть, кто в вашей команде написал код рядом с вами? Когда? Какие изменения? Что было написано 2 года назад в четверг в 16:59 и поднять эту версию локально? Ну, ты должен еще $100-500 в месяц!

Представьте себе мир без Open Source (построенный на плечах энтузиастов, которые бесплатно тратят свое время на решение чужих проблем). Я не думаю, что кто-то хотел бы оказаться в таком крайне мрачном будущем завтра.

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

Все это не особенно способствует написанию бесплатного, качественного и доступного кода под рукой. Но решение есть и оно очень простое.

Вы пишете то, что можете использовать не только вы и в своем проекте. Или, может быть, вы просто планируете повторно использовать его в другом проекте? Отлично - эта сущность отделима и может быть выбрана. Его можно оформить в отдельный проект.

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

И, наконец, это нужно не только нам, разработчикам. Мы не пишем код, чтобы похвастаться тем, у кого он лучше или быстрее (по крайней мере, у большинства из нас), мы пишем его для решения БИЗНЕС-проблем, которые приносят деньги бизнесу.

А бизнес в первую очередь интересует такая тривиальная проблема, как, например, пресловутая генерация Excel на клиенте, решаемая за несколько часов (ну максимум - дней), а не месяцев, поэтому бизнес должен помогать развитию Open Source не меньше, чем сами разработчики.

Выделите время на то, что описано в абзаце выше. Спонсируйте качественные и полезные решения для всего мира. Поощряйте стремления ваших разработчиков в этом направлении (а если таких стремлений нет, покажите им эту заметку).

Надеюсь, с этим "хорошего" в мире станет больше, ваши задачи будут решаться быстрее, и вы будете тратить меньше денег на простые банальности, а вместо того, чтобы придумывать очередное как добавить 10 пробелов слева, ваши разработчики смогут раскрасить кнопку именно того цвета, который вы хотите :ухмыляясь:.

Не стесняйтесь следовать [моему] (https://github.com/alphamikle) примеру и вносить свой вклад.

Оригинал

Как помочь сообществу разработчиков, решив собственные проблемы

Recent Post

Дизайнеры должны перестать быть менеджерами по продуктам и перейти к проектированию

Небольшие коммиты, большие победы: как атомные изменения преобразуют жизнь разработчика

Начало работы с государственным управлением в Still.js

Однородность и нормальность: как проверить ваши экспериментальные данные

Революционизация QA: Мой путь к созданию уникального аудита, который сокращает затраты и повышает эффективность

Categories