Да. Но, это не всегда очевидно. Одна библиотека тянет за собой кучу зависимостей и среди них может оказаться одна, заточенная под nix.
Я не раз сталкивался с багами под вин из-за того что разработчики банально не тестировали под нее (например рассчитывали только на линуксовые разделители файлов) и не собирались этого делать в будущем. По началу я думал: «ок, исправлю, сделаю пулл реквест», но потом надоело — зачем плыть против теченья?
Но это сервера и бэкенд. Наверное если бы я занимался каким-нибудь gamedev, то наоборот нужна была бы win.
С этим не поспоришь. Я имел ввиду выбор ОС как таковой. Например, под линукс проще собирать опен-сорс код, а под windows — головная боль, а многие проекты и не заработают вообще. Это уже аргумент бизнесу.
А насчет библиотеки — если потребовалось разбираться в исходном коде — это сигнализирует либо о недостаточно хорошей документации, либо обнаруженном баге. Ведь если api удобный и понятный, то в этом смысла нет, кроме как любопытство.
Насчет быстро (хотя лучше наверное эффективно, ведь надо брать в рассчет расход системных ресурсов тоже) — нужно рассматривать конкретную решаемую задачу. Например если библиотека читает данные из кафки, я ожидаю при среднем размере записи упереться в скорость сетевой карты. Если я вдруг не могу этого сделать и эта библиотека ест мой CPU или создает сотню потоков — что-то не так, правильно? Если явных косяков не заметно, то надо сравнивать с конкурентами. Если большой разницы нет (естественно гнаться за долями процента в ущерб коду не стоит) — то переходим к качеству кода. Если есть — оптимизируем.
Я согласен с тем что код мог бы быть лучше, по стандартам 2018.
Но и как с какой-нибудь библиотекой — тут вопрос приоритетов:
1. она должна работать без багов,
2. она должна работать быстро
3. она должна быть хорошо написана
3 — это головная боль разработчиков этой библиотеки, т.к. качество кода сказывается на трудоемкости её развития, поддержки и тестирования для выполнения первых двух пунктов.
Так и с линуксом — я в его код не лезу и пока он развивается и работает — меня все устраивает.
Во многих компаниях разработчики вполне себе принимают решения какую систему использовать. Бизнесу зачастую не важно что там в технологическом стеке.
Автор просто ноет.
Конечно, доля правды есть, особенно в вебе. Но все логично объясняется.
Во-первых никто не отменял законы экономики, спрос и предложение. Если что-то перестает удовлетворять потребителей — обязательно появится конкурирующий продукт, соответствующий требованиям. Ну и если покупают неэффективные решения — значит устраивает за их цену.
Во-вторых рассуждения о «слоях дерьма» — это какая-то самоуверенность. Остановитесь на секунду и просто представться себе что реально происходит при выполнении вашей простой программы. Готовы ли вы писать все сами? Шифрование, HTTP, или тот же терминал самостоятельно сделать? Операционную систему сами с нуля сваяеете?
Докер и ко не были нужны 20 лет назад, потому что и требований как сейчас никто не предъявлял. А сейчас CI, масштабирование, отказоустойчивость — это уже норма. Что прикажете делать? Нанимать штат в 3 раза больше чтобы все это сделать без него? Ну и чем собственно он вам навредил? У докера оверхеда почти нет.
Еще сравнение «простых» текстовых редакторов с игрой…
Такие простые редакторы для которых каждый может написать расширение для синтаксического анализа языков программирования, подсветки, сворачивания кусков кода и даже рефакторинга.
И игра — конечный продукт, оптимизированный до умопомрачения под одну конкретную цель. Игра, которая работает быстро, потому что Nvidia специально под это разработала железку, которая рисует вам эти миллионы полигонов и при этом стоит как все остальное вместе взятое в компе.
Крупные часто могут нанимать с прицелом на будущее, выращивать своих спецов так сказать.
Мелкие чаще нанимают чтобы быстрее сделать конкретный проект и у них нет времени на обучение конкретным технологиям\фреймворкам.
Как программист, я, например, жду тестового задания и считаю его основным критерием. Если его нет — у меня сразу подозрения что в компанию набирают кого попало.
Последующее очное интервью — для работодателя способ убедиться, что я делал задание сам, а для меня — будет ли мне комфортно работать там в социальном плане (коллектив, офис, печеньки).
Ну и да, если последнее проводится жестко, с прессингом (а стресс есть всегда), то это ошибка работодателя, тк. пропадает желание идти в такую компанию.
Ну оно и понятно, ведь Java изначально ООП язык, да еще с многолетним багажем. А вот почему народ с нее не хочет переходить на Scala мне остается непонятным. И это при том, переход плавный и экосистема та же — не то что Haskell учить.
Асинхронный код не сложен для чтения если используется функциональное программирование. Просто люди из последних сил цепляются за динозавра\ не хотят учить новое.
Можно еще так (фантазирую конечно):
1. Соединяем через некий интерфейс реальный и виртуальный мозг.
2. Синхронизируем их. В этот момент сознание человека должно распределиться на оба мозга. Дожидаемся пока реальный мозг и тело будут восприниматься сознанием как внешняя часть тела.
3. Отрубаем реальный мозг.
Себестоимость — это стоимостная оценка используемых в процессе производства продукции (работ, услуг) природных ресурсов, сырья, материалов, топлива, энергии, основных фондов, трудовых ресурсов и других затрат на её производство и реализацию.
Зарплаты девелоперов (по-больше токарей немного) + аренда оффисов + сервера (затраты могут быть приличными, одними ноутбуками не обойдешься).
Ну конечно, в «Hello world» любое разделение кода будет выглядеть ненужным размножением сущностей. В реальном приложение у вас не 3 строчки кода же?
Подход с репозиториями — проверенный временем. Не спроста о нем в кинжках пишут.
Пара советов для правильной реализации в контексте .NET:
Отключите LazyLoad
Возвращайте IEnumerable либо конкретные типы
Тогда не будет у вас leaky abstractions и будет счастье.
А если удариться в демагогию, то кругом компромиссы.
Нет идеального решения, такого чтобы и писать мало кода и все замечательно тестировалось и поддерживалось.
Вы сами должны решить где для вас наилучший баланс.
Однако он там будет только для вас и конкретно вашего проекта.
Не надо сразу евангелизировать это.
Я не раз сталкивался с багами под вин из-за того что разработчики банально не тестировали под нее (например рассчитывали только на линуксовые разделители файлов) и не собирались этого делать в будущем. По началу я думал: «ок, исправлю, сделаю пулл реквест», но потом надоело — зачем плыть против теченья?
Но это сервера и бэкенд. Наверное если бы я занимался каким-нибудь gamedev, то наоборот нужна была бы win.
С этим не поспоришь. Я имел ввиду выбор ОС как таковой. Например, под линукс проще собирать опен-сорс код, а под windows — головная боль, а многие проекты и не заработают вообще. Это уже аргумент бизнесу.
А насчет библиотеки — если потребовалось разбираться в исходном коде — это сигнализирует либо о недостаточно хорошей документации, либо обнаруженном баге. Ведь если api удобный и понятный, то в этом смысла нет, кроме как любопытство.
Насчет быстро (хотя лучше наверное эффективно, ведь надо брать в рассчет расход системных ресурсов тоже) — нужно рассматривать конкретную решаемую задачу. Например если библиотека читает данные из кафки, я ожидаю при среднем размере записи упереться в скорость сетевой карты. Если я вдруг не могу этого сделать и эта библиотека ест мой CPU или создает сотню потоков — что-то не так, правильно? Если явных косяков не заметно, то надо сравнивать с конкурентами. Если большой разницы нет (естественно гнаться за долями процента в ущерб коду не стоит) — то переходим к качеству кода. Если есть — оптимизируем.
Для меня быстрая сортировка — одновременно красивый и понятный алгоритм.
Как иначе можно оценить красоту алгоритма, не поняв его?
Вот оптимизированный код\алгоритм может быть сложнее и менее изящен.
Но и как с какой-нибудь библиотекой — тут вопрос приоритетов:
1. она должна работать без багов,
2. она должна работать быстро
3. она должна быть хорошо написана
3 — это головная боль разработчиков этой библиотеки, т.к. качество кода сказывается на трудоемкости её развития, поддержки и тестирования для выполнения первых двух пунктов.
Так и с линуксом — я в его код не лезу и пока он развивается и работает — меня все устраивает.
Во многих компаниях разработчики вполне себе принимают решения какую систему использовать. Бизнесу зачастую не важно что там в технологическом стеке.
Конечно, доля правды есть, особенно в вебе. Но все логично объясняется.
Во-первых никто не отменял законы экономики, спрос и предложение. Если что-то перестает удовлетворять потребителей — обязательно появится конкурирующий продукт, соответствующий требованиям. Ну и если покупают неэффективные решения — значит устраивает за их цену.
Во-вторых рассуждения о «слоях дерьма» — это какая-то самоуверенность. Остановитесь на секунду и просто представться себе что реально происходит при выполнении вашей простой программы. Готовы ли вы писать все сами? Шифрование, HTTP, или тот же терминал самостоятельно сделать? Операционную систему сами с нуля сваяеете?
Докер и ко не были нужны 20 лет назад, потому что и требований как сейчас никто не предъявлял. А сейчас CI, масштабирование, отказоустойчивость — это уже норма. Что прикажете делать? Нанимать штат в 3 раза больше чтобы все это сделать без него? Ну и чем собственно он вам навредил? У докера оверхеда почти нет.
Еще сравнение «простых» текстовых редакторов с игрой…
Такие простые редакторы для которых каждый может написать расширение для синтаксического анализа языков программирования, подсветки, сворачивания кусков кода и даже рефакторинга.
И игра — конечный продукт, оптимизированный до умопомрачения под одну конкретную цель. Игра, которая работает быстро, потому что Nvidia специально под это разработала железку, которая рисует вам эти миллионы полигонов и при этом стоит как все остальное вместе взятое в компе.
Крупные часто могут нанимать с прицелом на будущее, выращивать своих спецов так сказать.
Мелкие чаще нанимают чтобы быстрее сделать конкретный проект и у них нет времени на обучение конкретным технологиям\фреймворкам.
Как программист, я, например, жду тестового задания и считаю его основным критерием. Если его нет — у меня сразу подозрения что в компанию набирают кого попало.
Последующее очное интервью — для работодателя способ убедиться, что я делал задание сам, а для меня — будет ли мне комфортно работать там в социальном плане (коллектив, офис, печеньки).
Ну и да, если последнее проводится жестко, с прессингом (а стресс есть всегда), то это ошибка работодателя, тк. пропадает желание идти в такую компанию.
1. Соединяем через некий интерфейс реальный и виртуальный мозг.
2. Синхронизируем их. В этот момент сознание человека должно распределиться на оба мозга. Дожидаемся пока реальный мозг и тело будут восприниматься сознанием как внешняя часть тела.
3. Отрубаем реальный мозг.
Зарплаты девелоперов (по-больше токарей немного) + аренда оффисов + сервера (затраты могут быть приличными, одними ноутбуками не обойдешься).
Подход с репозиториями — проверенный временем. Не спроста о нем в кинжках пишут.
Пара советов для правильной реализации в контексте .NET:
Тогда не будет у вас leaky abstractions и будет счастье.
А если удариться в демагогию, то кругом компромиссы.
Нет идеального решения, такого чтобы и писать мало кода и все замечательно тестировалось и поддерживалось.
Вы сами должны решить где для вас наилучший баланс.
Однако он там будет только для вас и конкретно вашего проекта.
Не надо сразу евангелизировать это.