Лично знаю 2 примера, когда слишком торопливо выброшенный на рынок продукт почил в бозе, а конкуренты через полгода вышли с отлаженной схемой и загребли рынок.
В зависимости от задачи, я могу в ней держать string в виде строкового кода валюты держать. «RUR», «EUR» и т.п.
И об этом вы не догадаетесь до тех пор, пока не увидите логику работы с этой переменной.
Вы рассуждаете как Торвальдс — «компилятор сам знает, что там» :)
Я же рассматриваю ее с точки зрения удобства чтения кода человеком, а не компилятором.
Аналогично с названиями переменных в виде x и xx. Правда есть общепринятые исключения в виде e для ошибок, i,k — для счетчиков циклов, n — для размерностей и несколько еще.
Со времен динозавров существует венгерская нотация же. Не смотря на критику, ИМХО, крайне удобный подход, независимо от строгости типизаций используемого языка.
Поговаривают, где-то уже пробовали и это. Гимны там поют, оды читают, на «партсобраниях» в добровольно-принудительном порядке рассказывают, почему они счастливы, работая в ХХХ, возносят хвалы «отцам-основателям».
По-моему, вы невнимательно прочли статью. В ней прямо в том самом месте, которое вы процитировали, написано:
Найти работу для fullstack гораздо проще, чем для разработчика одной технологии. Но найти высокооплачиваемую работу все же сложнее. Парадокс, да? Тем не менее, в подавляющем большинстве случаев, так оно и есть (если конечно мы хотим использовать фуллстек, как фуллстек, а не как «программиста Java»). Там, где много платят с первых дней/месяцев работы, обычно не требуется «и швец и жнец, и на дуде игрец» — там требуется еще одна хорошо смазанная шестеренка в общий механизм, которая будет делать ровно одну задачу, и делать ее хорошо, так, как сказал тимлид.
Вы же зачем-то приводите как раз тот случай, где фуллстек выполняет роль «шестеренки». Разумеется, для такой задачи (которую вы приводите) эффективней будет нанять узкого специалиста (команду разноплановых специалистов). Но даже в вашем случае фуллстеком вполне может быть тимлид/архитектор — человек, который понимает на приемлемом уровне во всех применяемых технологиях, способен разрабатывать/вести архитектуру проекта, а так же управлять разработчиками, поддерживая общий баланс проекта. Про это тоже написано.
И тенденции что якобы всё больше людей нужны на фуллстэк, я, признаться, совсем не наблюдаю.
Счастливые люди лучше работают — это факт. Просто для некоторых критерий «счастье» — это деньги, а не корпоративы, тимбилдинги и прочее. :)
Было бы неплохо развернуть эту тему подробней. Как компания пришла к выводу, что всем в команде нравятся «Крутые корпоративы, шумные вечеринки, командные спортивные игры, веселые фотосессии, “тайные Санты”…» (и прочие инструменты, делающие людей более счастливыми)?
Знавал я в конце прошлого века одного дядечку, который специально запутывал свой код так, что без бутылки не разберешься. Эдакая ручная обфускация.
На вопрос — «а зачем?» был шикарный ответ: «Чтобы меньше криворуких смогло разобраться в моих идеях и скопировать их».
Хотя дяденьке на тот момент было за 40, подростковая глупость и гордыня так и не покинули его.
Он почти всегда так вырастает. Но если изучать одновременно 5-10 технологий, вы в любом случае не сможете так же хорошо, как человек, который изучает и работает только в одной-двух. Просто не хватит времени.
Но поддерживать знания «исходной технологии» на приемлемом (т.е. если были условным «синьором», то ниже вряд ли опуститесь) уровне разумеется можно.
Грубо говоря, у приложений, которые под ключ сделаны одним человеком, имхо всегда много мелких косяков (если говорить про малый бизнес) во всех областях
Мягко говоря, это не совсем правда.
Все перечисленные проблемы встречаются в абсолютном большинстве крупных и не очень продуктов, над которыми работает команда «не-аникеев». И криво спроектированные БД, и кривой фронт. И костылей в исходном коде встречается даже побольше, чем в «коробке одного работника».
И зависит это в большинстве случаев не от того, сделан ли продукт одним человеком или командой, а
в зависимости от опыта изначального разработчика
Чем выше опыт, тем меньше ошибок.
Проблема (а скорее ограничение) fullstack не в подходе к проектированию, даже не в качестве кода, а в том, что после определенного предела масштабов проекта, он перестает умещаться в одном разработчике. Как в плане количества используемых технологий, так и в плане временных рамок.
И вот в таком случае fullstack без проблем может стать его архитектором, нанимая, руководя и направляя специалистов в нужном русле. Хотя бы потому, что он имеет хорошее представление, как все это работает изнутри, а не отдавать на откуп весь проект команде, мол раз они спецы, значит сами знают, как лучше (из такого подхода часто получается лебедь рак и щука, и как итог — абсолютно несбалансированное приложение/проект, срывы сроков и т.п.). Сколотить команду не как «партнеры по интересам», а нанять конкретных специалистов, которые нужны для ликвидации узких мест в проекте. Направлять их именно туда, где они нужны, максимизировать производительность разработки.
На мой взгляд, это никак не коррелирует с термином «аникей».
Здесь все зависит от того, как вы видите этот «низкий уровень». Поделитесь вашей шкалой, чтобы иметь общее представление, стоит ли вступать с вами в дискуссию?
Да, все верно. Это и называется «конечность ресурсов». Т.е. вы уперлись в свой потолок производительности в рамках данного проекта (он перестал вмещаться в вас и требует дополнительных ресурсов) и совершенно логично сокращаете круг задач, чтобы повысить производительность. Я как раз об этом и писал:
Работа в одну каску подразумевает конечность ресурсов. Т.е. вы не сможете реализовать по-настоящему крупный программный продукт. Даже если хватит знаний, не хватит времени.
Поэтому грань здесь весьма тонкая.
И об этом вы не догадаетесь до тех пор, пока не увидите логику работы с этой переменной.
По сути, это тоже венгерская нотация:
Я же рассматриваю ее с точки зрения удобства чтения кода человеком, а не компилятором.
Со времен динозавров существует венгерская нотация же. Не смотря на критику, ИМХО, крайне удобный подход, независимо от строгости типизаций используемого языка.
Но увы, не платят :(
Сам лично не сталкивался, но говорят, да…
Вы же зачем-то приводите как раз тот случай, где фуллстек выполняет роль «шестеренки». Разумеется, для такой задачи (которую вы приводите) эффективней будет нанять узкого специалиста (команду разноплановых специалистов). Но даже в вашем случае фуллстеком вполне может быть тимлид/архитектор — человек, который понимает на приемлемом уровне во всех применяемых технологиях, способен разрабатывать/вести архитектуру проекта, а так же управлять разработчиками, поддерживая общий баланс проекта. Про это тоже написано.
Я про такое даже не упоминал.
Было бы неплохо развернуть эту тему подробней. Как компания пришла к выводу, что всем в команде нравятся «Крутые корпоративы, шумные вечеринки, командные спортивные игры, веселые фотосессии, “тайные Санты”…» (и прочие инструменты, делающие людей более счастливыми)?
На вопрос — «а зачем?» был шикарный ответ: «Чтобы меньше криворуких смогло разобраться в моих идеях и скопировать их».
Хотя дяденьке на тот момент было за 40, подростковая глупость и гордыня так и не покинули его.
Не будьте такими дядечками.
Я так пробовал. Хватило ненадолго, все равно обратно затянуло :)
Но поддерживать знания «исходной технологии» на приемлемом (т.е. если были условным «синьором», то ниже вряд ли опуститесь) уровне разумеется можно.
Мягко говоря, это не совсем правда.
Все перечисленные проблемы встречаются в абсолютном большинстве крупных и не очень продуктов, над которыми работает команда «не-аникеев». И криво спроектированные БД, и кривой фронт. И костылей в исходном коде встречается даже побольше, чем в «коробке одного работника».
И зависит это в большинстве случаев не от того, сделан ли продукт одним человеком или командой, а
Чем выше опыт, тем меньше ошибок.
Проблема (а скорее ограничение) fullstack не в подходе к проектированию, даже не в качестве кода, а в том, что после определенного предела масштабов проекта, он перестает умещаться в одном разработчике. Как в плане количества используемых технологий, так и в плане временных рамок.
И вот в таком случае fullstack без проблем может стать его архитектором, нанимая, руководя и направляя специалистов в нужном русле. Хотя бы потому, что он имеет хорошее представление, как все это работает изнутри, а не отдавать на откуп весь проект команде, мол раз они спецы, значит сами знают, как лучше (из такого подхода часто получается лебедь рак и щука, и как итог — абсолютно несбалансированное приложение/проект, срывы сроков и т.п.). Сколотить команду не как «партнеры по интересам», а нанять конкретных специалистов, которые нужны для ликвидации узких мест в проекте. Направлять их именно туда, где они нужны, максимизировать производительность разработки.
На мой взгляд, это никак не коррелирует с термином «аникей».