Всё упирается в требования. При ужесточении требований к качеству, стоимость ПО растет по экспоненте, что не выгодно никому. Клиент, очевидно, хочет дешевле. Клиент предпочтет бажную версию сейчас, чем готовую позже, т.к., даже в бажном исполнении, программа уже может экономить ему время и тем самым приносить прибыль. Да вспомните хоть, как народ дерется за доступ в бету к всяким-разным играм :-)
С другой стороны, разработчику тоже нужны деньги пораньше — чтобы довести продукт до ума при перерасходе бюджета (что при разработке ПО встречается сплошь и рядом), ну или чтобы просто отдать пораньше кредит в банк, сэкономив на процентах.
И не нужно говорить, что раньше софт был качественней — раньше софт сыпался в access violation через раз из-за несовершенного инструментария.
Из-за отсутствия интернета не было возможности взять и накатить патч, так что да, тестировали и вылизывали как могли. Что не лучшим образом сказывалось и на сроках разработки, и на цене. А дешевое и некачественное всегда конкурентноспособнее дорогого и качественного. Тот же айфон — это редкое исключение. Было.
Для меня это выглядит так, как будто async/await бесполезен в реальных проектах. Допустим, у нас есть 3 функции:
function authenticateUser(login, password) {} //возвращает Promise<userId> при успехе
function getUserDetails(userId) {}
function getUserAvatar(userId) {}
И я хочу запустить authenticateUser, а по его завершению — getUserDetails и getUserAvatar параллельно.
Через `then` это делается элементарно, включая обработку ошибок — достаточно проверить результирующий промис:
let detailsAndAvatar = authenticateUser(login, password).then(function(userId) {
return Promise.all(getUserDetails(userId), getUserAvatar(userId));
});
И правда, какое-то странное деление. Для начала, существуют самые разные формы управления:
1. гендиректор, IT-директор он же продукт овнер и несколько команд разработчиков с лидами.
В этом случае ни первая, ни вторая категория в описанном варианте не пройдут — для владельца бизнеса некомпетентный техдир — это прямые убытки. Другой вопрос, что с рабочего места программиста не видно, почему им командует именно этот человек. Помимо IT-квалификации, есть целая куча других причин держать этого человека. Например, доверие к этому человеку, или его высокая энергичность, или хорошее видение продукта. Либо — то, что выглядит как некомпетентность, на самом деле является стратегией. Конторы-соковыжималки например.
2. Компания побольше, где между IT-директором и лидами добавляются линейные менеджеры. В такой схеме главная обязаность линейного менеджера — работать так, чтобы не доставлять проблем своему начальнику. А что является проблемой для начальника — это уже зависит от культуры организации, так что от линейного менеджера ничего не зависит.
3. Крупные компании. В них у лида обычно два начальника — технический (архитектор) и организационный (линейный менеджер). От второго умение программировать по-хорошему не требуется, да и нет у него на это времени. Такие люди весь рабочий день проводят в письмах и совещаниях.
И, коллеги, давайте все-таки признаем, что большинство программистов — люди асоциальные и оторванные от реальности :-) Мы хотим писать только идеальные, вечноживущие системы, в которых всё прекрасно. Мы презираем всех, кто не является программистом и при этом пытается нами командовать. Мы видим только одну сторону вопроса — техническую.
Поэтому мы и видим то, что мы видим. Бизнес старается ставить менеджеров между программистами и заказчиками — т.к. заказчик программиста или не поймет вообще, или поймет неправильно. Бизнес не говорит программистам, что этот софт надо сваять как можно быстрее без оглядки на качество — он ставит программистов в такие условия, что они сами начинают делать, как надо) Бизнес нанимает аналитиков, специалистов по юзабилити, дополнительных менеджеров — потому, что программисты в большинстве своем не понимают, что программы пишутся для людей, а не для машин. И т.д. и т.п. Суровые реалии.
Селфи мамы гораздо проще сохранить через десятилетия, чем чертежи или корпоративные данные. Как? Очень просто. Нужно их держать в папочке на домашнем компьютере + регулярно бэкапить. Когда обновляется железо, папка копируется на новый комп. Когда старый формат данных устаревает, файлы перегоняются в новый формат. Никто же не будет переходить на какой-нибудь jpegV2, не дав доступ пользователям к конвертору данных?
Мораль — данные живут, только пока ими пользуются. Неиспользующиеся данные деградируют, как и неиспользующиеся программы.
Идея очень интересная для всех тех продуктов, которые покупаются для разработчиков. Закрытые СУБД, ИС, брокеры очередей, библиотеки компонентов. Особенно полезны могут быть нагрузочные тесты на инфраструктуре покупателя.
Если бы я продавал какой-нибудь «крутой пивот» или «дешевый и сердитый SSO для ентерпрайза», я бы задумался над этим вопросом…
Другой вопрос, что почти ни у кого нет такой культуры, чтобы иметь изолированные тесты :-). Или требуется тестовая инфраструктура, которую невозможно воссоздать за пределами компании, или тестовый билд с дополнительными API, или пачка дополнительных тестовых сервисов, или сам запуск тестов — процедура нетривиальная.
Отличная статья. Напрямую с хранилищами не работал, но в попытках родить модель данных для 15-летней системы, с которой работает с десяток разных команд, участвовал.
у sbt одна из самых простых *идей управления сборкой*
А вот реализация… вырвиглазный DSL, отсутствие качественной документации, для любых нетривиальных вещей надо идти смотреть исходники. А исходники написаны на идеоматической (считай, нечитаемой) скале с минимумом комментариев. А так да, сбт я люблю…
SpockFramework офигенен. Мне пришлось с него слезть только из-за перехода на Scala. Ну и из-за непонятного будущего самого языка — groovy-eclipse-plugin, например, уже мертв.
Так много людей сидят на JavaEE? Я, честно говоря, думал, что это технология вымирает из-за своей сложности и монструозности. Как в свое время вымерла CORBA.
Почему вы думаете, что это было написано непрофессионалами? Троян простой, эффективный и, главное, использует только стандартные фичи ОС и белый софт. Т.е. лучше совместимость с разными версиями ОС и меньше шансов быть перехваченным проактивной защитой.
Нужно иметь 10 публикаций с рейтингом +50 или аккаунт трехлетней давности. Вкратце, пишешь 10 успешных статей бесплатно и тогда тебе оплатят одиннадцатую.
Почему столько минусов? Всё же чистая правда. JRE уже много лет шпыняют за очень медленный старт. .NET решает эту проблему продуманной модуляризацией и оффлайн компиляцией модулей. Что же касается Java, то сначала Sun, а теперь Oracle только обещают. Поэтому GUI приложения и не пишут на Java, несмотря на весьма хорошую кроссплатформенность: юзер не будет ждать 3-5 секунд после клика на иконку приложения.
С памятью получше, аккуратным тюнингом можно добиться разумных цифр, но до С++, конечно, далеко.
С другой стороны, разработчику тоже нужны деньги пораньше — чтобы довести продукт до ума при перерасходе бюджета (что при разработке ПО встречается сплошь и рядом), ну или чтобы просто отдать пораньше кредит в банк, сэкономив на процентах.
И не нужно говорить, что раньше софт был качественней — раньше софт сыпался в access violation через раз из-за несовершенного инструментария.
Из-за отсутствия интернета не было возможности взять и накатить патч, так что да, тестировали и вылизывали как могли. Что не лучшим образом сказывалось и на сроках разработки, и на цене. А дешевое и некачественное всегда конкурентноспособнее дорогого и качественного. Тот же айфон — это редкое исключение. Было.
И я хочу запустить authenticateUser, а по его завершению — getUserDetails и getUserAvatar параллельно.
Через `then` это делается элементарно, включая обработку ошибок — достаточно проверить результирующий промис:
Как это будет выглядеть на async/await?
1. гендиректор, IT-директор он же продукт овнер и несколько команд разработчиков с лидами.
В этом случае ни первая, ни вторая категория в описанном варианте не пройдут — для владельца бизнеса некомпетентный техдир — это прямые убытки. Другой вопрос, что с рабочего места программиста не видно, почему им командует именно этот человек. Помимо IT-квалификации, есть целая куча других причин держать этого человека. Например, доверие к этому человеку, или его высокая энергичность, или хорошее видение продукта. Либо — то, что выглядит как некомпетентность, на самом деле является стратегией. Конторы-соковыжималки например.
2. Компания побольше, где между IT-директором и лидами добавляются линейные менеджеры. В такой схеме главная обязаность линейного менеджера — работать так, чтобы не доставлять проблем своему начальнику. А что является проблемой для начальника — это уже зависит от культуры организации, так что от линейного менеджера ничего не зависит.
3. Крупные компании. В них у лида обычно два начальника — технический (архитектор) и организационный (линейный менеджер). От второго умение программировать по-хорошему не требуется, да и нет у него на это времени. Такие люди весь рабочий день проводят в письмах и совещаниях.
И, коллеги, давайте все-таки признаем, что большинство программистов — люди асоциальные и оторванные от реальности :-) Мы хотим писать только идеальные, вечноживущие системы, в которых всё прекрасно. Мы презираем всех, кто не является программистом и при этом пытается нами командовать. Мы видим только одну сторону вопроса — техническую.
Поэтому мы и видим то, что мы видим. Бизнес старается ставить менеджеров между программистами и заказчиками — т.к. заказчик программиста или не поймет вообще, или поймет неправильно. Бизнес не говорит программистам, что этот софт надо сваять как можно быстрее без оглядки на качество — он ставит программистов в такие условия, что они сами начинают делать, как надо) Бизнес нанимает аналитиков, специалистов по юзабилити, дополнительных менеджеров — потому, что программисты в большинстве своем не понимают, что программы пишутся для людей, а не для машин. И т.д. и т.п. Суровые реалии.
Мораль — данные живут, только пока ими пользуются. Неиспользующиеся данные деградируют, как и неиспользующиеся программы.
Если бы я продавал какой-нибудь «крутой пивот» или «дешевый и сердитый SSO для ентерпрайза», я бы задумался над этим вопросом…
Другой вопрос, что почти ни у кого нет такой культуры, чтобы иметь изолированные тесты :-). Или требуется тестовая инфраструктура, которую невозможно воссоздать за пределами компании, или тестовый билд с дополнительными API, или пачка дополнительных тестовых сервисов, или сам запуск тестов — процедура нетривиальная.
Буду периодически перечитывать для вдохновения.
А вот реализация… вырвиглазный DSL, отсутствие качественной документации, для любых нетривиальных вещей надо идти смотреть исходники. А исходники написаны на идеоматической (считай, нечитаемой) скале с минимумом комментариев. А так да, сбт я люблю…
Если кому интересно: Хаордический — chaordic — Chaordic organization — организация, сочетающая в себе элементы хаоса и порядка.
А статья очень познавательная.
С памятью получше, аккуратным тюнингом можно добиться разумных цифр, но до С++, конечно, далеко.