Смотрел я недавнее интервью с гуглЁршей, которое тут по соседству постили, и один момент зацепил мое внимание. Один из основных критериев, по которым решается вопрос о повышении — сложность технологий, которые ты использовал. Чем сложнее, тем лучше — вполне официальная политика. Что хорошо объясняет, почему всё зачастую делается настолько через жопу.
Ну и, для сравнения:
„Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать.“
В общем, печально это всё, и просвета не видно.
Здравствуйте, Codealot, Вы писали:
C>Чем сложнее, тем лучше — вполне официальная политика. Что хорошо объясняет, почему всё зачастую делается настолько через жопу.
Гугл скатился не только из-за сложности. Ключевой фактор в том, что в гугле не отвечают за результат.
1) Они не отвечают перед пользователями за результат поискового запроса. Выдали абсолютно не релевантную информацию, ну так бесплатно же.
2) Они не отвечают перед рекламодателями за эффективность рекламы. А доказать, что там всё состоит из накруток и нецелевой аудитории так просто не получится.
3) Они не отвечают перед создателями содержимого. Тихо с...ил и ушёл, называется нашёл. Добро пожаловать в поисковые системы интернета.
И вот люди спрашивают, "Да мы всё понимаем, но щито делать?". Могу сказать лишь, что нужно создавать собственную экспертную систему. Нет, не очередной рекламный поисковик беспрерывно месящий тонны говна созданного лишь для продажи рекламы.
Нужно переходить на создание более качественного содержимого хотя бы для себя лично. Это так же включает собственное индексирование и обработку данных, но начать можно хотя бы с документации текущих данных.
C>Смотрел я недавнее интервью с гуглЁршей, которое тут по соседству постили, и один момент зацепил мое внимание. Один из основных критериев, по которым решается вопрос о повышении — сложность технологий, которые ты использовал. Чем сложнее, тем лучше — вполне официальная политика. Что хорошо объясняет, почему всё зачастую делается настолько через жопу. C>Ну и, для сравнения: C>„Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать.“ C>В общем, печально это всё, и просвета не видно.
Это надо ещё помжножить на:
1) микросервис головного мозга,
2) отсутствие тестирования (agile не разрешает тестировщиков (С)),
3) полное отсутствие внятной документации (код — это и есть лучшие коментарии (С) и документацию никто не читает (С)),
4) погоня за модными технологиями,
5) неглубокое понимание тех технологий, которыми пользуешься
6) архитектора, которых или нет или же которые только рисуют красивые картинки.
Здравствуйте, Ватакуси, Вы писали:
В>3) полное отсутствие внятной документации (код — это и есть лучшие коментарии (С) и документацию никто не читает (С)),
Истина, ИМХО, лежит где-то посередине.
Лучшие комментарии — это комментарии. (И HTML, сгенерированный из них). Но ни в коем случае не написанные из-под палки! А то будет потом:
int _ItemCount; /// The number of items.
Что касается отдельной документации, если только она не описывает ключевые алгоритмы, представляющие небывалую ценность для продукта, она имеет тенденцию скатываться в графоманство, начинающееся со слов: «Смеркалось». Ну и, конечно, кто её такую будет читать?
S>Лучшие комментарии — это комментарии. (И HTML, сгенерированный из них). Но ни в коем случае не написанные из-под палки! А то будет потом:
S>
S>int _ItemCount; /// The number of items.
S>
Это как раз самый главный аргумент у подобных личностей (я не про вас)!
S>Что касается отдельной документации, если только она не описывает ключевые алгоритмы, представляющие небывалую ценность для продукта, она имеет тенденцию скатываться в графоманство, начинающееся со слов: «Смеркалось». Ну и, конечно, кто её такую будет читать?
Да полно чего можно и нужно описывать. Если это не примитивная программа, то общую архитектуру (и отдельных модулей, если нужно), движение данных, авторизация, сложные алгоритмы, БД, авто-тесты, как это запустить у себя, как заливать на сервера, API и т.п.
Здравствуйте, Ватакуси, Вы писали:
S>>Лучшие комментарии — это комментарии. (И HTML, сгенерированный из них). Но ни в коем случае не написанные из-под палки! А то будет потом:
S>>
S>>int _ItemCount; /// The number of items.
S>>
В>Это как раз самый главный аргумент у подобных личностей (я не про вас)!
Но согласитесь, это же позорище, когда подобное встречаешь в MSDN, например.
S>>Что касается отдельной документации, если только она не описывает ключевые алгоритмы, представляющие небывалую ценность для продукта, она имеет тенденцию скатываться в графоманство, начинающееся со слов: «Смеркалось». Ну и, конечно, кто её такую будет читать? В>Да полно чего можно и нужно описывать. Если это не примитивная программа, то общую архитектуру (и отдельных модулей, если нужно), движение данных, авторизация, сложные алгоритмы, БД, авто-тесты, как это запустить у себя, как заливать на сервера, API и т.п.
А возьмите, например, Direct3D. Или что-нибудь похожее (по порогу вхождения, сложности и так далее). Как вы их изучали? Читали хедеры и собирали сэмплы, не так ли? Хотя там есть место общей архитектуре, движению данных, сложным алгоритмам и тому, как это всё у себя запускать. Или Sciter: вместо кучи графомании — сэмплы, сэмплы, сэмплы. Что и правильно (я считаю).
Фишка в том, что у Direct3D и Sciter'а сами знаете сколько клиентов. Есть смысл морочиться и писать все эти сэмплы для обучения. Причём, тут даже не в количестве дело, а в строгой изоляции. (Даже имея доступ к исходникам, кто из ISV туда полезет? Своих приключений мало?) А когда контора работает над ин-хаус проектом, делать у себя человеческое разделение на ядро/SDK и клиентские слои… В общем, так не бывает (я реалист). И люди начинают в качестве эрзаца писать документацию, которую потом всё равно никто не читает.
И, кстати, я думаю, не бывает потому, что это неудобно. Если бы у меня был выбор, я бы всегда предпочёл дойти до автора Direct3D и спросить лично. Если нельзя — тогда в сэмплы посмотреть. Ну а уж на крайний случай — читать «Смеркалось. Видеокарта пылала, обрабатывая вершинный буфер…» И я, объективно, далеко не самый малограмотный. Читать я люблю больше, чем средний разработчик.
Здравствуйте, Codealot, Вы писали:
S>>Если бы у меня был выбор, я бы всегда предпочёл дойти до автора Direct3D и спросить лично.
C>Отличный способ потратить зря и свое время, и его.
S>Но согласитесь, это же позорище, когда подобное встречаешь в MSDN, например.
Это уже, по-моему, автокоментарии.
S>>>Что касается отдельной документации, если только она не описывает ключевые алгоритмы, представляющие небывалую ценность для продукта, она имеет тенденцию скатываться в графоманство, начинающееся со слов: «Смеркалось». Ну и, конечно, кто её такую будет читать? В>>Да полно чего можно и нужно описывать. Если это не примитивная программа, то общую архитектуру (и отдельных модулей, если нужно), движение данных, авторизация, сложные алгоритмы, БД, авто-тесты, как это запустить у себя, как заливать на сервера, API и т.п.
S>А возьмите, например, Direct3D. Или что-нибудь похожее (по порогу вхождения, сложности и так далее). Как вы их изучали? Читали хедеры и собирали сэмплы, не так ли? Хотя там есть место общей архитектуре, движению данных, сложным алгоритмам и тому, как это всё у себя запускать. Или Sciter: вместо кучи графомании — сэмплы, сэмплы, сэмплы. Что и правильно (я считаю).
Это подразумевает чрезвычайно высокий уровень у программистов. Который, к слову, только падает (в среднем) последнии лет 20.
S>И, кстати, я думаю, не бывает потому, что это неудобно. Если бы у меня был выбор, я бы всегда предпочёл дойти до автора Direct3D и спросить лично. Если нельзя — тогда в сэмплы посмотреть. Ну а уж на крайний случай — читать «Смеркалось. Видеокарта пылала, обрабатывая вершинный буфер…» И я, объективно, далеко не самый малограмотный. Читать я люблю больше, чем средний разработчик.
Вот мне (в очередной раз) достался проект, где
а) Предыдущий гений чё-то накарябал и свалил в голубую даль. Его перед сваливанием заставили что-то написать по теме, но вышло крайне хреново. Он повторяется по 2-3 раза про то, что и так понятно, но совершенно пропускает откуда берутся данные, как это добро запустить и как заливать. Я не говорю про доступ и т.п.
б) Проект не запускается ни с бубном, ни без него (хоть всё и в докере)
г) тесты падают так как нет данных (про которые неизвестно ничего)
д) Архитектор(!) ничего не знает про эту подсистему
Здравствуйте, Ватакуси, Вы писали:
S>>А возьмите, например, Direct3D. Или что-нибудь похожее (по порогу вхождения, сложности и так далее). Как вы их изучали? Читали хедеры и собирали сэмплы, не так ли? Хотя там есть место общей архитектуре, движению данных, сложным алгоритмам и тому, как это всё у себя запускать. Или Sciter: вместо кучи графомании — сэмплы, сэмплы, сэмплы. Что и правильно (я считаю). В>Это подразумевает чрезвычайно высокий уровень у программистов. Который, к слову, только падает (в среднем) последнии лет 20.
Пардон, не понял: у изучающих? Или у проектирующих? Чей уровень имеется в виду?
S>>И, кстати, я думаю, не бывает потому, что это неудобно. Если бы у меня был выбор, я бы всегда предпочёл дойти до автора Direct3D и спросить лично. Если нельзя — тогда в сэмплы посмотреть. Ну а уж на крайний случай — читать «Смеркалось. Видеокарта пылала, обрабатывая вершинный буфер…» И я, объективно, далеко не самый малограмотный. Читать я люблю больше, чем средний разработчик. В>Вот мне (в очередной раз) достался проект, где В>а) Предыдущий гений чё-то накарябал и свалил в голубую даль. Его перед сваливанием заставили что-то написать по теме, но вышло крайне хреново. Он повторяется по 2-3 раза про то, что и так понятно, но совершенно пропускает откуда берутся данные, как это добро запустить и как заливать. Я не говорю про доступ и т.п. В>б) Проект не запускается ни с бубном, ни без него (хоть всё и в докере) В>г) тесты падают так как нет данных (про которые неизвестно ничего) В>д) Архитектор(!) ничего не знает про эту подсистему
В>Мощно, да?
Я могу только плюсануть предыдущего комментатора: SNAFU.
S>>>А возьмите, например, Direct3D. Или что-нибудь похожее (по порогу вхождения, сложности и так далее). Как вы их изучали? Читали хедеры и собирали сэмплы, не так ли? Хотя там есть место общей архитектуре, движению данных, сложным алгоритмам и тому, как это всё у себя запускать. Или Sciter: вместо кучи графомании — сэмплы, сэмплы, сэмплы. Что и правильно (я считаю). В>>Это подразумевает чрезвычайно высокий уровень у программистов. Который, к слову, только падает (в среднем) последнии лет 20.
S>Пардон, не понял: у изучающих? Или у проектирующих? Чей уровень имеется в виду?
Которым с работать нужно работу.
В>>Мощно, да?
S>Я могу только плюсануть предыдущего комментатора: SNAFU.
А была бы приличная документация (которую не в полследнюю неделю заставили написать из под палки), было бы совсем иначе.
И это не шарашка, это контора, которая ворочается сотнями миллионами валюты в месяц.
Здравствуйте, Ватакуси, Вы писали:
S>>>>А возьмите, например, Direct3D. Или что-нибудь похожее (по порогу вхождения, сложности и так далее). Как вы их изучали? Читали хедеры и собирали сэмплы, не так ли? Хотя там есть место общей архитектуре, движению данных, сложным алгоритмам и тому, как это всё у себя запускать. Или Sciter: вместо кучи графомании — сэмплы, сэмплы, сэмплы. Что и правильно (я считаю). В>>>Это подразумевает чрезвычайно высокий уровень у программистов. Который, к слову, только падает (в среднем) последнии лет 20.
S>>Пардон, не понял: у изучающих? Или у проектирующих? Чей уровень имеется в виду? В>Которым с работать нужно работу.
Если под «работать работу» подразумевается создание конечного продукта, то я считаю, что всё наоборот: ничего проще для них не придумать. Делать вместо SDK с сэмплами многостраничные мануалы — ИМХО, лучший способ оттолкнуть от себя новичков (да хоть кого). Даже туториалы (укрупнённые, так сказать, сэмплы) сильно обламывают, потому, что слишком много вещей за раз оказывается в фокусе внимания.
Я предлагаю сравнить подход Direct3D/Sciter с… приведите примеры сами.
Здравствуйте, Shtole, Вы писали:
S>Делать вместо SDK с сэмплами многостраничные мануалы — ИМХО, лучший способ оттолкнуть от себя новичков (да хоть кого). Даже туториалы (укрупнённые, так сказать, сэмплы) сильно обламывают, потому, что слишком много вещей за раз оказывается в фокусе внимания.
Для меня — наоборот. Сначала почитать или хотя бы пролистать хорошую книгу, чтобы иметь общее представление о самых важных моментах. Потом самому что-нибудь написать. Это если она (книга) есть, конечно.
Видимо, я не хоть кто
Здравствуйте, Codealot, Вы писали:
S>>Делать вместо SDK с сэмплами многостраничные мануалы — ИМХО, лучший способ оттолкнуть от себя новичков (да хоть кого). Даже туториалы (укрупнённые, так сказать, сэмплы) сильно обламывают, потому, что слишком много вещей за раз оказывается в фокусе внимания.
C>Для меня — наоборот. Сначала почитать или хотя бы пролистать хорошую книгу, чтобы иметь общее представление о самых важных моментах. Потом самому что-нибудь написать. Это если она (книга) есть, конечно. C>Видимо, я не хоть кто
Понятия не имею, кто вы и что написали (и написали ли вообще хоть что-нибудь). Я ориентируюсь на то, какие подходы демонстрируют коммерчески успешные продукты (я аж два всем известных примера привёл). Приведите другие. А мы сравним.
Здравствуйте, Shtole, Вы писали:
S>Понятия не имею, кто вы и что написали (и написали ли вообще хоть что-нибудь).
Не хами.
Тебя на работе обидели, что ли? Ну так я к этому вообще никак не причастен.
S>Я ориентируюсь на то, какие подходы демонстрируют коммерчески успешные продукты (я аж два всем известных примера привёл).
Theranos тоже был вполне коммерчески успешным.
S>Приведите другие. А мы сравним.
>>Которым с работать нужно работу.
S>Если под «работать работу» подразумевается создание конечного продукта, то я считаю, что всё наоборот: ничего проще для них не придумать. Делать вместо SDK с сэмплами многостраничные мануалы — ИМХО, лучший способ оттолкнуть от себя новичков (да хоть кого). Даже туториалы (укрупнённые, так сказать, сэмплы) сильно обламывают, потому, что слишком много вещей за раз оказывается в фокусе внимания.
S>Я предлагаю сравнить подход Direct3D/Sciter с… приведите примеры сами.
В последнее время не приведу
Даже МСДН скатился куда обычно.
Совершенно все делают примеры типа "привет, мир". Если тебе нужно что-то сложное, то тысячи часов поиска по инету тебе в помощь. Или интуиция. Или опыт.
Вообще, не представляю, как молодёжь должна это осваивать.
Вот берём Постгрес. Отличная база, но документация описывает только типичные задачи.
А что они сделали с настройками? Они по-умолчанию, просто задница какая-то.
Или питон. Там вообще швах с документацией.
Про сраный HDF5, или какой-нить npm или докер я даже не говорю. Там даже прямые копии инструций или не существуют или работают очень выборочно. Особенно мне "нравится" HDF5 и его прослойки в питон или там C++. Его ни под Окна, ни под Мак поставить "просто так" — невозможно! Нужно читать тонны странниц разны "рецептов".
Под Линуксом он встаёт только после установки десятков разных доп. пакетов и вообще даже не с помощью "официальной" команды с их сайта. Такое ощущение, что всем насрать на любого пользователя, который хочет чуть более сложного, чем "привет, мир".
У многих вообще есть только одна версия Линукса. Какой-то Линукс. А какой? Хрен знает.
Здравствуйте, Ватакуси, Вы писали:
В>Совершенно все делают примеры типа "привет, мир". Если тебе нужно что-то сложное, то тысячи часов поиска по инету тебе в помощь. Или интуиция. Или опыт.
И я, объективно, далеко не самый малограмотный. Читать я люблю больше, чем средний разработчик.
