Category: финансы

Category was added automatically. Read all entries about "финансы".

flow

Утечки информации

Увидел очередное упоминание старого трика, как владельцы могут отслеживать упоминания своих сайтов в чужой закрытой корпоративной переписке, теперь из мессенджеров типа Slack: http://justinjackson.ca/slack/

Сейчас не девяностые, и современные браузеры давно поддерживают rel="noreferrer", надёжно и полностью закрывающий эту дыру. Но в том же Slack есть только возможность включить доисторический фикс с blind redirect, который по дефолту выключен.
flow

Код это не активы

Недавно читал историю проекта OS/2, операционной системы от IBM, которая некоторое время позиционировалась как альтернатива Windows. Забавный факт - разработчики и менеджеры гордились большим количеством строк кода, сравнивали, соревновались. Подобные "специальные олимпиады", как и любые другие тенденции, ведущие к увеличению количества кода, десятилетиями гробят большие и малые проекты. До среднеменеджеров долго доходит, что код это не активы.

Я ненавижу программировать. И другим не даю. Код хорош в research, быстро приходит и быстро уходит. В production он остаётся висеть вечным грузом.

Каждая строчка исходника (на выбранном вами языке программирования) или датасета это расходы, кредит с процентами. Постоянные затраты на осознание, отладку, поддержку, модернизацию. Это _всегда_ минус. Плюсы проявляются косвенно - счастье пользователя (не путать с количеством фич), прибыль бизнеса (не путать со счастьем пользователя), etc. Или не проявляются вообще.

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

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

Можно сократить код и данные. Заменить несколько страниц кода на компактную таблицу коэффицентов. Или наоборот, таблицу на выражение-однострочник. Главное - не плодить методологии. В этом смысле полезны EDSL, так как позволяют минимизировать количество кода, и, при этом, всё же интегрировать работу с данными своей предметной области в общую методологию проекта. Но вредны DSL, так как заведомо привносят отдельные методологии.

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

Кроме того, сторонние технологии могут стать лимитирующим фактором. Если плохие методологии и Java-style-overengineering это просто увеличение расходов, то использование Eclipse platform это гарантия дерьмового пользовательского интерфейса в вашем продукте. Впрочем, увы, слишком много факторов могут стать такой же гарантией.

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