Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать


    Когда я только начал учиться кодить, я поверил старым мудрым засранцам с их мантрой «язык программирования не важен». У меня появилась идея фикс — быть разработчиком, который может всё. Парнем, который переносит опыт использования одной технологии на другую и возносится над деталями. Но эта затея с треском провалилась.


    Идея фикс — знать все


    Я изучил C# и .NET с разными областями применения (asp.net, wpf, xamarin), js/ts (react/redux, node) и убедил себя, что теперь-то могу действительно всё. Я абстрагировался, мыслю в нескольких парадигмах программирования одновременно и обладаю практическими знаниями во всех аспектах профессиональной разработки ПО. Можно смело начинать высмеивать этих сорокалетних сеньоров одной технологии, которые потратили полжизни на то, что я могу постигнуть за неделю. Можно утверждать что погружение в предметную область — для болванов, которые хотят всю жизнь проработать на одном месте, тогда как я — абстрагирован от неё.


    Всё вокруг одинаковое, и я увидел закономерность. Теперь, когда мне нужно поработать на каком-нибудь нелепом питоне, я говорю: «дайте немного времени на беглое чтение спеки, и я готов работать с этим говном на уровне senior. Ну что, в конце концов, там может быть такого сложного, чего я еще не видел?» Так я создал себе культ пренебрежения деталями. Пусть в деталях копошатся джуны, которые не могут в абстракции.


    Пробелы в знаниях неочевидны и незаметны


    Однажды я зафигачил дизайн на абстрактных классах в typeScript, и меня высмеяли. Потому что в тайпскрипте так не делают. Я, конечно же, сделал вид, что просто мои коллеги — бездарные идиоты. Обычно это помогало, но в этот раз остался осадок.


    Репутация хорошего разраба скрывает твои пробелы как от коллег, так и от тебя самого. Ты не знаешь огромное количество критичных специфичных штук, но не видишь этого, как раз потому, что не знаешь.


    Затем началась черная полоса. Фигак! Я не знаю, что там за типы индексов в SQL. Бам! Забыл, когда вызывается статический конструктор в шарпах. Упс! Я не могу правильно реализовать IDisposable без гугла. Пытаюсь мутировать стейт в реакт компоненте.


    Я заподозрил, что моя абстрагированность не работает. Что технологии все-таки разные, а детали — важны. В каждой технологической экосистеме свои уникальные лучшие практики. Опыт в .NET не помешает при работе с jvm, но и не заменит его. Мой самоприсвоенный скилл «Я научился быстро учиться» оказался неправдой. Я учился не быстрее, чем все остальные. И мне потребовалось слишком много времени, чтобы это понять.


    Мой скилл оказался как обоз — лебедь, рак и щука пытались тащить его в разные стороны. Я не стал автоматически сеньором во всем. Я просто стал мультимидлом, посмешищем для сорокалетних сеньоров одной технологии. И тогда я пришел к выводу, что выбирать путь фулстека — ошибка.


    И тут начинается самобичевание


    Проблема в том, что бизнесу нужны фулстеки. Только не такие, как я, а синьоры во всём, ребята, у которых за плечами по пять лет опыта в каждой из фулстечных технологий.


    Но таких не бывает, и бизнес идёт на самообман. Они берут слабого мидла в трех крупных технологиях, и называют его senior full-stack developer. Этот титул превращает человека в самозванца и становится неиссякаемым источником комплекса неполноценности. Любой обычный разраб, который шарит в одной технологии — шарит в ней лучше. И сейчас я хорошо понимаю, что не готов на равных правах работать в команде с людьми, которые шарят намного лучше меня. Иначе уже через неделю умру от самобичевания.


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


    А надо-то всего лишь признать, что разработка — это сложно не только для людей извне, но и для нас тоже. Не знать что-то на данный момент — нормально. Если у тебя есть пробел, это не значит, что ты стоишь меньше денег, и тебя надо изгонять в пустыню.


    Но на самых глубоких уровнях рефлексии в нас все равно остается самобичевание. Фулстеки грызут себя, что не знают технологии глубоко. Однояпные спецы — что не знают широко.


    Учить вширь vs учить вглубь


    Здесь старый конфликт: ты можешь изучать в глубь, а можешь вширь, но не то и другое одновременно. Я заметил такой эффект — когда начинаешь изучать новую технологию, старая становиться неинтересной. Но в IT если ты не обновляешь свои знания о технологии в течение года, ты уже не актуален.


    Если хочешь оставаться фулстеком, тебе придётся заставлять себя читать релиз-ноуты какого-нибудь TypeScript, заодно ещё и пробуя их в деле — даже если не хочется. Причём ты всё ещё будешь недосягаемо хуже разраба, который каждый день пишет исключительно на тайпскрипте.


    Главная проблема этого конфликта в том, что мы не знаем, как лучше. Мы-то, и особенно бизнес, хотим и так, и так. Что бы все шарили во всём, и шарили достаточно глубоко.


    Что лучше, я не знаю, но знаю, каково быть на этом пути фулстеком. Тебе придется тратить намного больше времени на обучение, чем разработчикам с одним языком. Так будет продолжаться всю карьеру, но по сравнению с ними твой уровень все равно будет ниже.


    Ты везде будешь свой, но везде среди чужих. Несмотря на твои огромные усилия, каждый знаток конкретного языка будет с пеной у рта доказывать, что ты не достоин называться сеньором.


    Ты станешь вечным мидлом.


    Я лично решил, что обратной дороги у меня нет. Я могу изучить что-то одно по-настоящему глубоко, могу попробовать уйти в управление — вот уж где нужны только поверхностные знания — но лучше останусь на своем пути и буду страдать, пока действительно не узнаю все обо всем.

    Поделиться публикацией
    Комментарии 724
      +3

      Можно писать исключительно на typescript и быть fullstack

        +1
        Это не правда. Во-1, Nodejs не всея руси, отнюдь не везде эта технология считается приемлемой. Во-2, сеньор бэкенд программист обязан знать как минимум sqlb ещё одну технологию, например, java или python.
          +3
          1. Сложно найти технологию, которая везде считается приемлемой.
          2. Я писал про фуллстек, а вы мне про сеньор бекенд. Ок.
            +1
            1. Python, Go, раньше java была.

            2. В статье же об этом речь. И, пожалуй, требование знать sql ко всем бэкендщикам относится.
              +2
              1. Python, Go, Java отличные технологии, но тоже не всея руси.
              2. Я не спорю, что чем больше технологий знаешь, тем лучше. Но использование SQL тоже не обязательно. Есть ORM, есть NoSQL базы данных.

              Мой первый комментарий не ставит под вопрос другие технологии, но NodeJS + TypeScript (JavaScript) впервые дали возможность быть FullStack и писать только на одном ЯП. Тем самым упрощая процесс профессионального роста.

                0
                C# -asp.core +Razor тоже даст вам такую возможность.
                  0

                  Поправьте меня если я неправ, но Razor — это по сути шаблонизатор. На нем клиентскую логику вы не напишете.

                    0

                    Чего только в наше время не выдумают: Blazor — Full-stack web development with C# and WebAssembly

                      0
                      Blazor — это конечно клево, но я бы лучше сразу писал на фронтовом языке вместо того чтобы постоянно огребать) Ну и blazor опять никак не решит проблему того, что сеньором во фронте не станешь, тонкости C# окажутся совсем не применимыми к фронту.
                        0
                        сеньором во фронте не станешь

                        А каким критериям должен удовлетворять уровень человека что бы можно было именовать его сеньором?
                          0

                          Наверно, надо уметь писать асемблерные вставки :)

                            0
                            Про это пишет автор статьи и я с ним в какой-то степени согласен.
                              +2
                              Сеньор — это человек самостоятельно решающий проблемы и не создающий в этом процессе проблем коллегам, в том числе будущие проблемы.

                              Обычно сеньор отличается от мидла лучшей проработанностью решения (на тестировании всплывают только миноры) и понятностью мышления (поскольку человек знает предметную область он использует наиболее простые и логичные методы решения, следовательно код легко понять в целом, а часто и в нюансах).

                              Мидл же может наворотить пачку костылей. Просто потому, что хуже знает систему и предметку, плюс часто хочет показать что «я вот так умею».

                              Ну и сеньор менее заметен в офисе, но более заметен в баг-трекере)
                                +1
                                Наверное наоборот:
                                «Ну и сеньор более заметен в офисе, но менее в баг-трекере»
                                  0

                                  Сеньоры разные бывают. Одни тащат задачи, другие любят потрындеть и покрасоваться. Я наверно 50 на 50. Хотя почти искренне верю, что первый тип)

                          –1
                          Если вся клиентская часть — это набор формочек, то помогут библиотеки jquery-ajax-unobtrusive и jquery-validation-unobtrusive, они настраиваются исключительно атрибутами.

                          Хотя фулстеком того кто пользуется только ими назвать сложно.
                          0
                          Если взять bridge.net — тогда да, фуллстек на одном языке.
                    0
                    Во-2, сеньор бэкенд программист обязан знать как минимум sqlb ещё одну технологию, например, java или python.

                    Зачем сеньору-то знать другую технологию? Он же не джун.

                    +1
                    Очень интересное утверждение. А можете привести пример триггера в какой-нибудь СУБД (SQL Server, MySQL, PosgreSQL, Oracle Database) на TypeScript?
                      +2

                      Не все приложения требуют использования триггеров. Я и не писал, что typescript на все случаи жизни.

                        +2
                        В таком случае нужно понимать что такое FullStack разработчик. В моем понимании это разработчик, который способен написать приложение от и до без посторонней помощи. А не так, что если нужны триггеры, то я уже не FullStack разработчик.
                          +12

                          Любой триггер можно реализовать программно вне СУБД. Естественно будут потери.


                          Так можно до бесконечности продолжать. Например у вас в проекте должен быть ИИ, а нейросеть вы строить не умеете. Вы уже не fullstack.

                            +3
                            >> Любой триггер можно реализовать программно вне СУБД. Естественно будут потери.
                            Насколько я понял статья именно об этом. Что люди которые считают себя всемогущими FullStack разработчиками в большинстве случаев просто не знают, что данную задачу (например, триггер) грамотнее реализовать при помощи СУБД, а не «программно» наступая на все грабли. Или я неправильно понял суть статьи?
                              +1
                              Что значит «грамотней»? По каким критериям?
                                +3
                                Грамотней означает, что для каждой задачи нужно применять тот инструмент, который для нее наиболее подходит, а не пытаться писать свой велосипед для любой задачи.
                                  0
                                  Подходит лучше технически или как?
                                    +1
                                    Любите вы поспорить. :)
                                    При решении любой задачи можно использовать различные подходы. Можно использовать решение проверенное временем от профессионалов (например, реализация триггеров Oracle Database), а можно взять и реализовать их самостоятельно. Можно и Web-серверы и СУБД реализовывать самостоятельно.
                                      +4

                                      Люблю, да. Особенно вижу категоричные суждения или оперирование общими оценочными категориями типа "грамотней" без указания критериев :)

                                        +5
                                        Скорее всего, самостоятельная реализация триггеров будет тормозить. Скорее всего, эти тормоза будут настолько не важными для проекта, особенно на ранней стадии, что ради них искать узкоспециализированного разработчика бд — пустая трата времени и денег.
                                        Когда бизнес молодой и развивается, ему важно как можно быстрее и проще провалидировать жизнеспособность своей модели. В этих условиях, человек-оркестр, способный в одиночку запилить и бэк, и фронт, намного выгоднее двух крутых специализированных бэк/фронт разработчиков.
                                        Другое дело — когда бизнес уже захватил основную часть аудитории, и начинается борьба за оптимизацию и увеличение конверсии. Тут нужен тюнинг перформанса и все остальное в таком духе, и нужны узкие спецы.
                                        Проблема узких спецов на старте — часто они сходу начинают оптимизировать под будущий «хайлоад», когда вообще не факт что бизнес вообще взлетит.
                                          +1
                                          Скорее не так. Использование триггеров, обеспечивает нам некоторую консистентность данных средствами DB (некоторую, потому что в триггере можно много чего сломать). И это круто — встроенное, надежное и известное решение.

                                          Но всё решают зависимости. В триггере мы можем обработать данные из той же БД, довольно шустро и без особых рисков.

                                          Но если, при изменении записи, нам надо взять данные не из DB, и как-то их по хитрому обработать… Тут возможно имеет смысл спроектировать слой над базой данных, а консистентность сохранить за счёт транзакционности и прямых рук. Это может оказаться, быстрее, надёжнее и даже проще реализовать.

                                          Но, кмк, нам намекают, что то, что можно сделать в триггере, лучше сделать в триггере. Например записать лог изменения записи, или поддержать волшебным образом денормализацию «на лету». И плодить хитрое решение на технологии, которую лучше знаешь, а не на той, на которой от тебя ждут решение… По моему это подготовка будещего мазохизма, притом не своего, а того, кто будет поддерживать твою систему «если что».
                                            +1

                                            Если от тебя ждут решения на конкретной технологии, то надо его как-то делать или сообщать, что не можешь. Но часто такие нюансы как реализация логирования остаются в лучшем случае на усмотрение команды, а и одного разработчика.

                                              +2
                                              В триггере мы можем обработать данные из той же БД, довольно шустро и без особых рисков.

                                              Проблема же в цене поддержки. Если бизнес-логика размазана по триггерам и хранимкам дб — это очень печально. Просто sql очень плохой язык с точки зрения промышленного программирования, вот и все.

                                                0

                                                Ну тут есть вариант: бизнес логика собрана в триггерах и хранимках. И на это может быть много причин. До сих пор.


                                                Кроме того, на триггер можно возлагать стандартные процедуры. Я уже упоминал логгирование, также принудительная генерация ключей в оракле, что бы исключить косоруков вручную ставящих id. Вообще да, триггер место для выстрелов в ногу, и много чего можно выносить на уровень приложения или хранимок.Но это не значит, что от триггеров надо отказываться принципиально.


                                                И опять же начало спора было о том, что для разных случаев разные инструменты. И знание вариантов инструментов нелишне.

                                                  0
                                                  Но это не значит, что от триггеров надо отказываться принципиально.

                                                  Об этом вроде никто и не говорил.

                                                    0

                                                    Ну значит мы друг-друга не поняли… в начале

                                                  0

                                                  PS. Sql в богатых расширениях(транзакт sql, pl/sql) это отличный язык для промышленного программирования. Просто нужно понимать какие, задачи решать на нём. Вы же не будете для построения статистики тащить 50 таблиц по миллиону записей на клиент) И пре и, пост обработку данных для некоторых операций проще делать хранимкой

                                        –1
                                        По критерию стабильности. Если есть два продукта (заливка в базу и редактирование с сайта) и недотриггер реализован програмно, то есть вероятность что только в одном месте (или неодинаково) и могут быть разные последствия. Просто один из вариантов.
                                        Можно ведь и не в СУБД хранить, а в файлах и всю логику держать на клиенте (вообще всю базу сразу отправлять на клиента, включая данные всех пользователей, а уж клиент будет делать выборку). Вполне можно реализовать, но мало кто назовёт это правильным.
                                          0
                                          Для этих целей существуют подпрограммы :-)
                                            0
                                            Для каких? Для замены триггеров? Не поможет при запросе в консоли или в программе, где этой подпрограммы нет (потому как не написали — сначала функция не планировалась, а потом реализовали).
                                              0
                                              А для этого есть библиотеки…
                                        0
                                        Ну не всегда это грамотнее, но вообще на мой взгляд как минимум иметь в виду такую возможность стоит.
                                          0
                                          Именно. Нужно понимать, что я не триггеры защищаю, а пытаюсь привести пример, который подтверждает содержимое статьи.
                                            0
                                            Ну статья по моему немного не о том все же, тут наоборот автор в таком подходе разочаровался.
                                          0

                                          FullStack хорош для запуска первой версии продукта или для небольших фирм. Когда требуется не "грамотная реализация", а реализация в принципе. По мере роста проекта уже требуются более узкие специалисты.


                                          А статья, если честно, ни о чем. Типа, если вы будете изучать технологии А, Б, В, то никогда не изучите технологию А также глубоко, как человек, который изучает только технологию А. Это очевидно.

                                            0
                                            >> Типа, если вы будете изучать технологии А, Б, В, то никогда не изучите технологию А также глубоко, как человек, который изучает только технологию А.
                                            Вот с этим абсолютно согласен. Уверен, что множество разработчиков в принципе никогда не станут Senior разработчиками даже если будут изучать хоть всю жизнь одну технологию.
                                              +1
                                              FullStack хорош не только для запуска, но и последующего контроля. Эволюция FullStack — это архитектор проекта.
                                                0
                                                На самом деле в большинстве случаев когда ищут FullStack'a — на самом деле предполагается что 95% времени он будет работать в одном стаке и изредка надо будет что-то поправлять в другом.
                                                  0
                                                  Ну не знаю, как так предполагается, то обычно пишется что-то вроде: PHP, знание JS будет плюсом. А если ищут именно фуллстэка, то предполагается что основные задачи будут на весь стэк.
                                                +1
                                                По-моему, если база не какая-то специфичная, то лучше всю логику делать в коде, а не «часть в коде, часть в базе»
                                                Код проще тестировать и поддерживать. Да и случаи замены базы, хоть и довольно редки, но все-равно случаются.
                                              +1
                                              Что значит «нужны»? Вот в бизнес-задаче декларируется «нужны триггеры»?
                                            +1
                                            > А можете привести пример
                                            pgxn.org/dist/plv8/doc/plv8.html
                                            не совсем ts, но можно его при желании сбоку прикрутить :)
                                              0
                                              deleted
                                                +8
                                                А можете привести пример триггера в какой-нибудь СУБД (SQL Server, MySQL, PosgreSQL, Oracle Database) на TypeScript?

                                                Есть же достаточно распространенное мнение, что использование триггеров (и вообще дергание скл руками) — code smell. В такой парадигме неумение использовать тригеры — конкурентное преимущество.

                                                  +1
                                                  Триггеры в данной ситуации лишь пример, а не предложение повсеместно их использовать т.е. вместо них можно придумать любой другой подходящий.
                                                    +2
                                                    (и вообще дергание скл руками)
                                                    +1
                                                    Уметь в SQL проще и продуктивнее чем уметь в ORM, разве нет?
                                                      +2
                                                      Уметь в SQL проще и продуктивнее чем уметь в ORM, разве нет?

                                                      Зависит от ситуации.
                                                      SQL, конечно, хорош в плане перформанса, но:


                                                      1. не всегда в принципе скорость запросов — бутылочное горлышко.
                                                      2. код на SQL, мягко говоря, не слишком удобен в плане поддержки.

                                                      В общем, как и всегда — есть разные задачи, есть разные инструменты, а серебряной пули нет.

                                                        –3
                                                        код на SQL, мягко говоря, не слишком удобен в плане поддержки.
                                                        просто надо использовать нужные инструменты для его поддержки. Если использовать хранимки, то в коде не будет запросов, все запросы в хранимках на сервере, к примеру для mysql есть интсрумент как DbForge, который позволяет писать, отлаживать, сопровождать хранимки. делать рефакторинг, и много ещё чего.
                                                        не всегда в принципе скорость запросов — бутылочное горлышко.
                                                        трудно не согласиться, но если есть возможность — надо ей пользоваться — к примеру поля даты можно уже в запросе привести у нужному виду, числа сформировать с нужными разделителями разрядов.
                                                          +2
                                                          Если использовать хранимки...

                                                          Если она будет ровно одна, то, возможно, не стоит.

                                                          к примеру поля даты можно уже в запросе привести у нужному виду, числа сформировать с нужными разделителями разрядов.

                                                          … однако, если у вас уже есть подсистема, которая форматирует данные, в том числе полученные не из БД, то этого делать не нужно. Особенно если там все по-взрослому, с подтягиванием настроек пользователя, определением региона, учетом смещений часовых поясов и всего такого.

                                                          ИМХО, спор про то, на чем правильно делать то или это в абстрактном проекте — беспредметный.
                                                            +2
                                                            А как например писать юнит-тесты на хранимки?
                                                              +2
                                                              Трудно, но можно. В postgresql, mysql и оракле такая возможность есть. Суть такова:
                                                              • Как язык SQL плох, но без него никак. Он динамический, имеет громоздкий синтаксис и на 90% состоит из весьма нудного бойлерплейта. Читать — легче. Понимать — ещё легче.
                                                              • Переписывать всю БЛ на хранимки, как предлагают некоторые горячие головы, равносильно отстреливанию себе в упор всех конечностей.
                                                              • Хорошие ОРМ значительно удешевляют разработку. Но чтобы уметь ими пользоваться, нужно по мимо ОРМ знать SQL.
                                                              • Даже с самой хорошей ОРМ писать SQL всё равно придётся.
                                                              • Использовать nosql только потому, что лень учить SQL или разбираться с ОРМ — такая же дичь, как и писать всё на хранимках, чтобы не учить условную java. Нужно учить CAP теорему и разбираться, когда использовать nosql 1) допустимо 2) приемемо 3) оправдано. Вопросы не тривиальные практически всегда.
                                                                +1
                                                                А есть ли возможность гонять эти тесты без непосредственно базы данных? Потому что для бэкенда как бы это практически всегда запросто. Более того, в моем родном дотнете скоро обещают возможность запуска owin-based-приложух прямо в памяти. Типа можно писать интеграционные тесты на ваш API вообще не запуская сервер.

                                                                Я сам вообще стараюсь хранимки использовать по минимуму. Понятное дело, что иногда они дают важный буст производительности, особенно учитывая, что ORM не серебрянная пуля и часто генерят диковатые запросы. Спросил не с целью «о, если мне еще юнит-тестов там подвезут, все буду на скулях писать», а с вопросом в духе «а чо, в мире есть проекты, где хорошо уживаются CI/CD, TDD и хранимки?» Потому что у меня на проекте они уживаются, но с очевидностью первое берет верх.
                                                              +2
                                                              просто надо использовать нужные инструменты для его поддержки. Если использовать хранимки, то в коде не будет запросов, все запросы в хранимках на сервере, к примеру для mysql есть интсрумент как DbForge, который позволяет писать, отлаживать, сопровождать хранимки. делать рефакторинг, и много ещё чего.

                                                              Я в эти сказки не верю после того, как столкнулся с развитием продукта построенного в основном на SQL. Боль заключается в том, что если на типичном бекендском языке можно разбить 2000 строк на 40 групп по 50 строк с дополнительным оверхедом в 200 строк, то на sql оверхед составляет ближе к 500-1000 строк. И это делает нецелесообразным попытки написать хороший код. Соблюдать DRY почти невозможно. Увы, SQL не имеет средств для нормального реюза кода. Т.е. развивать код на SQL можно только до определенных пределов.

                                                              В другой продукте использовались хранимки на SQL, но гораздо меньшие и более конкретные. И это было счастьем. За исключением того, что все хранимки стали выглядеть автоматизируемыми. Туда явно напрашивалась абстракция. Но существующие инструменты (ORM) слишком сильно были заточены под паттерн «хуяк-хуяк» и были малопроизводительными. Хранимки оказались наименьшим злом на тот момент.
                                                                +1
                                                                Угу. Все запросы — в хранимках на сервере, а история и blame — в гите. Вот и выросла цена сопровождения кода на пустом месте.
                                                                  0

                                                                  SQL-скрипты не версионируются в Git?

                                                                    +1
                                                                    А нам надо хранимки версионировать, а не скрипты.
                                                                      0
                                                                      а чем хранимка отличается от скрипта? Элементарно выгружается в текстовый файл — чистый скрипт. и элементарно версионируется.
                                                                        –1
                                                                        Это все тяжело автоматизировать чтобы было прозрачно.
                                                                          –1
                                                                          Администраторы субд делают это с закрытыми глазами, для них это основная работа — а по простому — просто запустить батник, который сделает дамп, и отправит на гит. так же можно и восстановить. Я в очередной раз прорекламирую инструмент для работы с субд — dbForge — позволяет просто делать резервную копию базы, как с данными, так и просто структуру с триггерами, вью, функциями, хранимками. можно для каждого разработчика иметь свой экземпляр и очень просто сливать в одну и её уже переносить в базу продакшена.
                                                                            0
                                                                            Каждому разработчику могут понадобиться их с десяток за день, а слияний за день может быть сотни. Сколько будет делаться дамп и восстановление с него на более-менее серьёзной базе?
                                                                              +1
                                                                              считай: перейти в ide — выбрать нужный файл -подтвердить действие — дождаться завершения, итого секунд 15.
                                                                              и дамп и восстановление.
                                                                              слияние — в ide -выбор в меню, выбор базы источника, выбор базы приёмника — сравнение — галочками отметить что слить — enter, итого секунд 30.
                                                                              из практики — ни о каких сотнях в день речь не идёт…
                                                                              дамп делается не всей базы а только выбранного -структуры, данных или отдельных выбранных элементов.
                                                                              каждому разработчику лучше иметь свой экземпляр базы, (лучше на своей машине) со своим набором даннх(они могут быть элементарно перенесены как с базы продакшена, так и с любой базы разработчиков)
                                                                              при слиянии отображается разница между базами-по каждому элементу как структуры так и данных.
                                                                              отладка также происходит в ide, хранимки можно отлаживать по шагам (запрос в хранимке -это один шаг).
                                                                              написали хранимку сохранили — выполнили — увидели результат. можно отдельно отлаживать запрос тогда и сохранять не надо просто написать — запустить — увидеть результат. и уже потом вставить в хранимку.
                                                                                0
                                                                                То есть только ручные слияния, ручные переключения, ничего подобного git checkout feature-name или git merge feature-name. Эта система не предполагает хранения истории версий, не обладает информацией о том, что версия 7 основана на версии 3, а версия 4 на версии 2 и при объединении версий 7 и 4 за основу нужно брать версию 2, а не 3 или 1?

                                                                                А сотня изменений в команде из десяти разработчиков за день создаётся легко.
                                                                                  –1
                                                                                  Всё дело в том, есть ли у вас желание получить в итоге качественную, быструю систему, а не просто срубить бабла, а там будь что будет. Вы можете меня убеждать сколько угодно, но пока вы сами не захотите работать (лили хотя бы поработать), и организовать всё версионность работы под себя — это будет разговор ни о чём. желающий ищет возможности, не желающий — отговорки.
                                                                                    0
                                                                                    У меня есть желание, обычно, сделать заказчика системы довольным. Я использовал много разных подходов к версионированию баз данных (не только таблиц, но и хранимок, триггеров и т. п.), но только с декларативным описанием таблиц в текстовых файлах (в SQL императивные команды на создание таблиц, впрочем как и все остальные — уж не знаю почему его считают декларативным языком ) получалось что-то сочетающее:
                                                                                    — скорость разработки
                                                                                    — возможность параллельной (или псевдопараллельной) работы над десятками фич или над несколькими фичами, затрагивающими много одних и тех же таблиц
                                                                                    — автоматическое разворачивание и обновление локально и на удалённых серверах

                                                                                    Причём даже с только с таблицами возникают ситуации, когда приходится предупреждать всех разработчиков, что собираешься, например, переименовать поле.

                                                                                    Я не чураюсь хранимок или триггеров, но для переноса в них части логики мне нужны очень веские основания. Главное — неперенос сделает работу какой-то конкретной фичи неприемлемо медленной для пользователей или заказчика. Но перенос для меня всегда оптимизация, которая делает систему быстрее за счёт уменьшения скорости разработки, её удорожания, ухудшения поддерживаемости и масштабируемости.
                                                                                      0
                                                                                      Причём даже с только с таблицами возникают ситуации, когда приходится предупреждать всех разработчиков, что собираешься, например, переименовать поле.
                                                                                      это будет в любом случае, если есть необходимость изменить структуру базы. Но используя IDE субд это делается просто — везде где надо поле переименовывается а в зависимых запросах можно добавить as «старое_имя» и в коде никаких изменений вносить не надо…
                                                                                      в этих ide и прочий рефакторинг делается просто.
                                                                                      Я не чураюсь хранимок или триггеров, но для переноса в них части логики мне нужны очень веские основания. Главное — неперенос сделает работу какой-то конкретной фичи неприемлемо медленной для пользователей или заказчика. Но перенос для меня всегда оптимизация, которая делает систему быстрее за счёт уменьшения скорости разработки, её удорожания, ухудшения поддерживаемости и масштабируемости.
                                                                                      Из практики — возможности хранимок увеличивают возможности, к примеру хранимки могут возвращать несколько результсетов, при добавлении записи в одну из связанных таблиц сразу добавляется и в другую… что сокращает обращений к базе. ну и, не маловажный фактор, защита данных, и полная защита от инъекций. Если не использовать специализированные ide для работы с базами — то это трудно и накладно, но ведь и никто не пишет проекты в блокноте…
                                                                                      я принял как стандарт — даже простейшие запросы оборачивать в хранимки — самое огромное преимущество — огромная быстрота быстрота их написания любой сложности и огромная быстрота отладки. написал — запустил — увидел результат. ни компиляции кода, ничего. даже в том же хибере, даже если ide помогает написанием запроса — то увидеть результат — надо сделать кучу действий. как минимум запустить какой-нибудь тест. В ide субд — только запустить на выполнение…
                                                                                        0
                                                                                        То есть в двух IDE постоянно работать и синхронизировать их код вручную?

                                                                                        А вы правите код непосредственно хранимки или какого-то скрипта CREATE OR REPLACE…?
                                                                                          0
                                                                                          Работа в двух ide — это не проблема. Синхронизировать их коды вообще не нужно, вот пример кода на java
                                                                                          try (Connection con = dataSource.getConnection(); CallableStatement proc = con.prepareCall("{call хранимка1(" + param + ")}");) {
                                                                                                      rs = proc.executeQuery();
                                                                                                      rs.next();
                                                                                                      userSession.getBasicRemote().sendText(rs.getString("av"));
                                                                                                  } catch (SQLException | IOException ex) {
                                                                                                      ex.printStackTrace();
                                                                                                  }
                                                                                          это конечно, примитивное использование, но показывает как это делается,
                                                                                          я написал вызов и обработку, в param набор передаваемых данных(вариантов прередыи несколько — выбор — повкусу и месту), на этом работ с java закончена.Открываю ide dbFogge и работаю с нужной хранимкой.
                                                                                          Я работаю непосредственно с хранимкой, всю остальную работу за меня делает ide. при запуске она спрашивает о сохранении хранимки и формочкадля ввода параметров(достаточно ввести один раз, в дальнейшем просто подвердить), иногда мне это надоедает я открываю запрос из храники (в том случае если хранимка состоит из одного запроса) в новой вкладке и просто запускаю его (предварительно организовав входные параметры(если они нужны :) )
                                                                                          добившись правильной и быстрой работы хранимки — сохраняю её. Всё. Никакой синхронизации.
                                                                                          если кто-то изменил что-то в базе, в огромном большинстве случаев в коде ничего менять не надо. Достаточно открыть хранимку она закричит о несоответствии чего-либо, просто её поправить, главное чтоб она возвращала «правильные» названия полей и их количество. Ну а — правильность данных в этом случае — это уже по месту. Чисто теоритически хранимка может представлять (на какомто этапе разработки) из себя заглушку, которая просто делает такое
                                                                                          select 0 as поле1 1, 'xxxx' as поле2 from table
                                                                                          union
                                                                                          select 3 as поле1 1, 'rrr' as поле2 from table;

                                                                                          этого достаточно чтоб отладит код. а специалист по субд может отладить хранимку(добавив к имени префикс)
                                                                                            0
                                                                                            Как минимум нужно синхронизировать параметры и результат. Переименовали столбец (или что там) av в хранимке, нужно переименовать его и в Java коде.

                                                                                            И как быть, если в базе что-то поменялось (например, таблица переименована кем-то), а хранимку не открывал? Или переименование таблицы реплицируется на все базы всех разработчиков и не только таблицы, но и её использование в хранимках? IDE для той же Java начнёт ругаться об ошибках с тем что-то не так вызывается, как только получит код, а не дожидаясь его закрытия или, тем более, запуска.
                                                                                              0
                                                                                              Как минимум нужно синхронизировать параметры и результат. Переименовали столбец (или что там) av в хранимке, нужно переименовать его и в Java коде.
                                                                                              ничего подобного делать не надо, достаточно использование алиас (as ) и всё. у вас в коде будет постоянное имя поля.
                                                                                              И как быть, если в базе что-то поменялось (например, таблица переименована кем-то), а хранимку не открывал?
                                                                                              я говорю о ide dbFogre (Devart, у этой фирмы есть ide для популярных субд) при переименовывании возникает вопрос о применении рефакторига — и изменения вносятся во все места где встречается место для смены имени таблицы, хранимки, вью, функции, использование as избавит от смены имен полей в коде.
                                                                                              можно использовать каждому свой экземпляр базы, и по завершению работы над куском задачи сливать в «общую».
                                                                                              этот процесс наглядный, простой, удобный…
                                                                                              при сливании показываются все отличия, так что сделать ошибку трудно.
                                                                                              хранимки поддерживают комметарии в коде.
                                                                                                0
                                                                                                Так эта IDE работает с базой непосредственно или с исходными кодами в текстовых файлах, а может синхронизирует их? Пока то, что вы описываете, больше напоминает какую-то крутую админку к базе, типа как плагин работы с СУБД в IDE от JetBrains, а не инструмент разработки приложений. Слияние баз, о котором вы говорите — это генерация нового дампа, в котором можно посмотреть отличия с предыдущим, генерация скрипта миграции или реальное слияние, типа подключились с дев-машины к проду и запустили синхронизацию локальной базы с продуктовой?
                                                                                                  0
                                                                                                  Работает непосредственно с базой, может иметь коннекты к нескольким базам, поддерживает подключение к удалённым базам по ssh.(я так обновляю у клиентов)
                                                                                                  больше напоминает какую-то крутую админку к базе,
                                                                                                  не просто крутую, а ОЧЕНЬ КРУТУЮ да, это не инструмент разработки приложений, а инструмент разработки запросов, функций, вьюшек, хранимок. Инструмент полноценной работы с базой
                                                                                                  Слияние баз, о котором вы говорите — это генерация нового дампа, в котором можно посмотреть отличия с предыдущим, генерация скрипта миграции или реальное слияние, типа подключились с дев-машины к проду и запустили синхронизацию локальной базы с продуктовой?
                                                                                                  это всё в одном. Есть два пункта «слияния» -для структуры и для данных. как результат — генерируется скрип, который можно посмотреть, а можно и запустить.
                                                                                                  подключаете ide к проду и к свой базе, сливаете необходимые данные и тестируете у себя на реальных данных.
                                                                                                  можно делать «резервную копию» — я так резервировал базу с клиента — 14гиг в зипе.
                                                                                                  все запросы можно строить в гуи,
                                                                                                  не идеальный, но отличный редактор для написания, с подстановкой, подсветкой кода, есть форматирование кода.
                                                                                                  есть «проводник» в котором перечислены все элементы, можете выбрать таблицу и увидите что от неё зависит, выбираете хранимку и видите от чего она зависит.
                                                                                                  наверно единственно чего не хватает — это работы с гит, но у них есть глосовалка и этот пункт набирает голоса.
                                                                                                  Ребята активно развивают продукт, активно откликаются на замеченные баги.
                                                                                                    0
                                                                                                    Я работаю с тремя IDE: PhpStorm, IDEA, DataGrid
                                                                                                    Так вот, BigDflz прав (а вы все же зря спорите) в той части, что он про tool for database — это вполне можно назвать «IDE для базы данных» либо «сильно крутая админка».
                                                                                                    Да, весь функционал по работе с БД присутствует.
                                                                                                    www.jetbrains.com/datagrip/features
                                                                                                    Вид

                                                                                                    P.S. Конечно, BigDflz вел речь о «другом» продукте, но они из одной ниши.
                                                                                                    P.P.S. Про саму концепцию «как писать» — я вмешиваться не хочу… у меня лично позиция, как и у вас, но BigDlfz я так же понимаю.
                                                                                                    Всему свое место )))
                                                                                                      +1
                                                                                                      А не прав он в том, что ручные операции в IDE называет «автоматизацией»…
                                                                                                        0
                                                                                                        Скорее с мощными IDE это частично автоматизированные операции.
                                                                                                          0
                                                                                                          поподробнее, что-то не понял… про автоматизацию
                                                                                                          0
                                                                                                          Вроде же все три имеют один модуль работы с СУБД (последняя ничего кроме него и не имеет по сути). Я его знаю и активно использую (PhpStorm обычно), в том числе и для хранимок. Но проблемы работы с логикой в СУБД как с обычным кодом он не решает, впрочем и со схемами/начальными данными тоже. По сути, когда вынужден что-то менять прямо в базе, чувствую себя как будто на 20 лет назад вернулся. Всё это версионирование через имена файлов/сущностей, бэкапы, слияние «глазами» и т. п.
                                                                                                            0
                                                                                                            Эм, пардоньте, но я даже линк с фитчами кидал от JetBrains… там и VCS (Git) есть, и «изменения в БД» (вкладка).
                                                                                                            Можно ведь делать в пару кликов выгрузку того же ddl и «в базу» лить скрипт. По крайней мере JetBrains гордится своим продуктом (на пустом месте?).
                                                                                                              0
                                                                                                              Может как-то не так его использую, но разве есть там маппинг файлов с кодом на схему? Типа файлик изменил или ветку переключил и изменения автоматом в базу попали, как попадают, например, исходные коды на удалённый сервер?
                                                                                                              0
                                                                                                              странно, но таких проблем не испытываю. может потому что работу над проектом начинаю с проработки базы.
                                                                                                              дак вопрос в чём?
                                                                                                              в преимуществах работы с хранимками или то что работа с базой «плохо версионированна»?
                                                                                                              если у вас текст запроса в коде, то при изменении имени поля в базе, разве не надо искать все вхождения этого поля по всем файлам проекта? Тогда как инструмент рефакторинга в IDE это сделает во всех хранимках, а чтоб не копаться в коде достаточно использовать алиасы в коде хранимке.
                                                                                                                0
                                                                                                                У работы с хранимками, вьюхами и прочим кодом, хранящимся на стороне СУБД, вернее в СУБД, есть и плюсы, и минусы. Один из минусов — отсутствие версионирования, отсутствие возможности (может в этой dbForge есть) работать с этим кодом через текстовые файлы с кодом этих хранимок и т. д. Для схемы таблиц эти вопросы худо-бедно решены через декларативные описания и генерацию миграций через диффы схем. Для исполняемого кода я чего-то удобного не видал. Удобного как для разработки, так и для автоматического раскатывания по серверам с каких-то CD серверов
                                                                                                                  0
                                                                                                                  работа с хранимкой — это работа в текстовом редакторе IDE, как с обычным текстом. с цветовым выделением, форматированием, подстановкой. Отсутствие версионирования не такая уж и проблема(хотя иметь возможность отката вещь приятная, тут не поспоришь) я тут уже описал свою технологию работы с хранимками.
                                                                                                                  Повторюсь несколько. Я использую все обращения к базе через хранимки, в запросах(которые в хранимках, я использую алиасы, это позволяет избежать зависимости от названия полей, таблиц в коде основного софта. если кто-то внешний изменит имя поля, в IDE есть рефакторинг, который найдёт все использованные имена и предоставит возможность их переименовать и сделает это автоматом в всей базе. в коде все останется по прежнему. Это как бы «подобие json» для обмена данными между базой и кодом. Чего нет при использовании запросов написанных в коде софта. когда я занимаюсь отладкой хранимки (в большинстве случаев — это простой селект) я правлю только текст хранимки и проверяю его работу, какие данные он выводит, как работает, смотрю план запроса. Это происходит быстро. Код софта при этом не трогается. Я могу проверить как работает код сделав хранимку-заглушку. Отладив хранимку(запрос в ней) проверяю как работает всё вместе и код и выборка данных. Ни каких 100+ вариантов хранимки мне не нужно. в хранимке можно комментировать любой фрагмент, в любом месте.
                                                                                                                  если надо хранить варианты, для этого есть команда продублировать. и в базе будет сделана копия элемента(хранимки, вью...)
                                                                                                                  для нормальной разработки лучше иметь у каждого свой экземпляр. базы.
                                                                                                                  Обычно использование хранимок воспринимают как перенос бизнес-логики в базу, но это не всегда так, хранимки — это разделение работы.
                                                                                                                  Вы написали вызов хранимки, перечень параметров, список возвращаемых полей, и этого достаточно что специально обученный DBA сделал оптимальный вариант обработки данных. Чего нельзя сделать при написании кода запроса в основном коде. DBA делает своё дело — вы своё. Это как разделение фронт-енд — бэк-енд, только добавляется бэйз-енд.
                                                                                                                    0
                                                                                                                    Дело не в возможности отката, дело в возможности разрабатывать параллельно фичи, затрагивающие одни сущности базы и удобно (в большинстве случаев автоматом) сливать их, а также просмотреть историю изменений удобно, как в виде различий, так и в виде «снэпшота». Все системы, претендующие на просмотр изменений, которые я пробовал, не могли предоставить её удобно. Даже просто таблицы взять: список команд CREATE TABLE ..., ALTER TABLE ..., ALTER TABLE ..., DROP TABLE ..., CREATE TABLE ..., ALTER TABLE ..., ALTER TABLE… — это не история изменений, это история команд на изменение.
                                                                                                                      –1
                                                                                                                      Тут проблема в том, вы вторгаетесь в область DBA со своим мерками, несмотря на то, что строго разграничиваете фронт и бэк. Область баз это такое же звено как бэк и фронт. Те проблемы что вы перечисляете по работе с базами — у DBA нет. Посетите www.sql.ru/forum/microsoft-sql-server. И что и как там решается. Либо научитесь работать с базами, либо наймите DBA. Это не в обиду, не в оскорбление, это просто многолетнее наблюдение, когда пишущие на C, java, php и пр. начинают заниматься базами… Почему из фронта не лезут в бэк и наоборот(если не фулстеки :) ), но почему все считают себя знатоками баз?

                                                                                                                        0
                                                                                                                        DBA есть отдельные, но это именно администраторы, а не разработчики. Схема базы — не область их ответственности, максимум могут порекомендовать переписать запрос, добавить индекс или изменить структуру. Ну и «наймите DBA» совет совсем не по адресу, когда говорим о разработке, а не о управлении разработкой.

                                                                                                                        P.S. я как раз фронт и бэк не разграничиваю строго, даже если они в разных репах лежат.
                                                                                                                          0
                                                                                                                          Тогда нужен специалист по работе с базами. Я вообще не разграничиваю — ни фронт, ни бэк, ни бэйз. И для меня не знакомы ваши проблемы с базами. Для меня просто странно выглядят эти разбросанные грабли по которым бродят, и жалуются на всякую ерунду. Сначала создадут запрос в коде, потом изменяют поле, и требуется изменить во всём коде… Ну нет этой проблемы, пользуетесь IDE для написания кода — так и для работы с базами есть инструменты. Я знаю контору в которой в одном проекте 900+ хранимок mssql, и все работает, развивается.
                                                                                                                            0
                                                                                                                            Я знаю контору в которой в одном проекте 900+ хранимок mssql, и все работает, развивается.

                                                                                                                            900+ хранимок — это проект уровня гостевой книги по размерам, такой можно разрабатывать как угодно и на чем угодно, проблем не возникнет.
                                                                                                                            Что если хранимок будет 900+ сотен?

                                                                                                                              0
                                                                                                                              могу сказать, что это проект уровня транспорта России.
                                                                                                                              Что если хранимок будет 900+ сотен?
                                                                                                                              тут уже нет разницы 900 или 900 сотен, они не запариваются над их количеством. только и всего.
                                                                                                                                0
                                                                                                                                тут уже нет разницы 900 или 900 сотен, они не запариваются над их количеством. только и всего.

                                                                                                                                То есть проект не поддерживается? Написали и выкинули?

                                                                                                                                  0
                                                                                                                                  проекту уже более 10 лет. живёт и развивается. просто у людей нет страха перед использованием хранимок и их количеством.
                                                                                                                                    0
                                                                                                                                    проекту уже более 10 лет.

                                                                                                                                    900 хранимок за 10 лет? То есть, по сути хранимки в проекте практически не используются?

                                                                                                                                      0
                                                                                                                                      То есть, по сути хранимки в проекте практически не используются?
                                                                                                                                      Придирки не приветствуются! Если вы думаете, что за 10 лет только добавляются — значит вы не поддерживали проект длительное время, как правило большая часть подвержена изменениям, причём очень частым — требования и законы меняются постояноо. и добавление не столь сложная задача как изменение существующего.
                                                                                                                              0
                                                                                                                              Да не в полях проблема, а в том что нет удобного инструмента синхронизации исходного кода в текстовых файлов с базой. Чтобы был у меня в гите файлик /sql/procedures/simpleproc.sql типа
                                                                                                                              ```sql
                                                                                                                              PROCEDURE simpleproc (OUT param1 INT) BEGIN
                                                                                                                              SELECT COUNT(*) INTO param1 FROM t;
                                                                                                                              END
                                                                                                                              ```
                                                                                                                              и какой-то вотчер, который любые изменения в этом файле «маппил» бы на базу, сам анализируя, какую команд(ы) конкретно запускать, например DROP при удалении файла и CREATE при создании. Ну и все прелести современной разработки типа навигации по именам, автозаполнения, обнаружения ошибок без обращения к базе и т. п. Чтобы поднимать базу мне приходилось только для тестов (так же в файлах лежащих) и отладки, а код мог спокойно писать без базы.
                                                                                                                                0
                                                                                                                                если для вас это проблема, и вы ставите крест на использование процедур, тогда запретите вообще процедуры во всех субд, обвините разработчиков субд в помехах программированию и будет вам счастье. Если для вас это проблема — может вы просто не научились их готовить?
                                                                                                                                У меня нет ваших проблем, ваших страхов, я использую хранимые процедуры по-полной и наслаждаюсь их возможностями.
                                                                                                                                Не нравится — не ешь, но зачем кричать, что это не вкусно?
                                                                                                                                  0
                                                                                                                                  Я не ставлю крест на их использовании из-за страхов. Я ставлю крест на их использовании по умолчанию из-за неудобства (читай — дороговизны) поддержки, отношу их использование по умолчанию к преждевременной оптимизации.
                                                                                                                                    –1
                                                                                                                                    это твоё право, твоё мнение — но не надо настаивать, как на истине первой инстанции
                                                                                                                0
                                                                                                                ---ошибка
                                                                          +3

                                                                          В целом зависит от задачи. И ОРМ придумали как раз для упрощения и увеличения продуктивности.

                                                                            0
                                                                            и еще видимо для абстрагирования от движка СУБД
                                                                              +1

                                                                              Не у всех ОРМ есть DBAL на самом деле.

                                                                        0
                                                                        Например, некоторые современные NoSQL-решения имеют возможность исполнять код на JS. Транспиляция TS->JS банальна.
                                                                        Конкретно по триггерам: blog.kloud.com.au/2018/01/30/cosmos-db-server-side-programming-with-typescript-part-4-triggers
                                                                          +1
                                                                          А можете привести пример триггера в какой-нибудь СУБД
                                                                          Да мы уже поняли что вы обожаете триггеры в бд и везде их пытаетесь сувать, не думаю что это характеризует вас как «Senior developer»
                                                                          0
                                                                          Node.JS научился в потоки?
                                                                            +1

                                                                            Вы об этом?

                                                                              0
                                                                              Не совсем, но для некоторых целей уже пойдёт.
                                                                          +10
                                                                          Имхо хорошая концепция быть крутым в одном и примерно понимать и немного практиковать окружение.
                                                                            +2
                                                                            Я думаю, что своё «вширь vs вглубь» можно варьировать, т.е. необязательно либо вширь, либо вглубь. Я бы сказал, что обе крайности опасны. Вширь — описал автор. Вглубь — другая проблема: сегодня ты сеньор технологии N, а завтра она выкинута на помойку (как не редко бывает в IT).
                                                                              +3
                                                                              У музыкантов на эту тему есть поговорка «сегодня ты играешь фьюжен а завтра никому не нужен».
                                                                            +43
                                                                            могу попробовать уйти в управление

                                                                            Вы знаете, то о чем Вы написали и есть путь в управление.ИТ Архитектор это и есть профессиональный дилетант.Знающий много технологий и "прокладывающий путь" проекту.
                                                                            Конечно, если архитектор делает фичи сам а не делегирует их более узкоспециализированным разработчикам,- может получится лажа.Архитектор строительный я думаю тоже может заштукатурить стену… но профессиональный штукатур сделает это лучше. Но штукатур не сможет быть архитектором.

                                                                              +10
                                                                              Только управление — это прораб/PM, а не архитектор. Совсем разные компетенции.
                                                                                0

                                                                                Только в крупных проектах есть и прораб и архитектор, в небольших все таки стараются совмещать (оттуда ноги и растут). И это не только в IT

                                                                                  +3
                                                                                  То есть мидл фулстек дев станет ещё и мидл архитектором и мидл PM?

                                                                                  Если честно, плохо себе представляю, что на небольшом проекте техстек будет выбирать человек, не пишущий код. Ну то есть как «не представляю» — видел, но больше не хочу.

                                                                                  И ведь его даже на смех то поднять нельзя.
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                +29
                                                                                А надо было учиться программировать.


                                                                                А надо было учиться разрабывать, а не программировать.
                                                                                Хотя постойте, не так.
                                                                                А надо было учиться решать проблемы бизнеса, а не разрабатывать.

                                                                                Вот что вы за занудством занимаетесь? Это как на галерные лычки наяривать: «я не программист, я сениор эксперт мастер рокстар девелопер».
                                                                                  +19
                                                                                  Понавыдумывали понятий — разработчик, девелопер, программист, кодер, инженер… и никто разницу понять не может
                                                                                    +20
                                                                                    Мало того — они еще и внутри этих классов норовят поделить на сеньоров-миддлов-джуниоров. Никак людям не живется без цветовой дифференциации штанов
                                                                                      +4
                                                                                      Там есть ещё экземпляры, со своими «гуру», «джедаями» и прочими «рокстарами» от которых хочется блевать
                                                                                        +9
                                                                                        Понравилось, вчера кто то из хабарожителей написал комент:
                                                                                        Мне нравится разделение по уровню ответственности:

                                                                                        Джуниор — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.
                                                                                        Миддл — работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.
                                                                                        Сеньёр — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.
                                                                                        +1
                                                                                        Беда в том, что есть очень много людей в ИТ сфере, которые даже не поняли вашу игру слов.
                                                                                          +2
                                                                                          Ханин мягко улыбнулся. — Творцы нам тут на ххх не нужны, — сказал он. — Криэйтором, Вава, криэйтором.
                                                                                        +9
                                                                                        Навешивание ярлыков и ваше деление людей на «кодеров» и «программистов» устарело уже лет на 20. Не смешно уже.
                                                                                        +9
                                                                                        Да да, в какой-то момент каждый задумывается об этом.

                                                                                        Насчёт «бизнесу нужны фуллстеки» — здесь есть нюанс. Бизнес разный бывает. И именно фуллстеки нужны обычно там, где человек по факту занимает несколько вакансий. То есть, в небольшом бизнесе или в стартапах. Не говорю, что там работать это плохо — это тоже может быть интересно, в особенности на начальных этапах, когда ты только познаёшь, чем хочешь заниматься.

                                                                                        Но если бизнес большой, а продукт сложный — здесь нужны достаточно узкие специалисты. И, к сожалению, просто нельзя одновременно быть сениор разработчиком фронта, бэка, мобилки, девопсом и архитектором СУБД (у меня был такой опыт, но я не могу покривить душой и сказать, что я был хотя бы миддлом сразу во всех областях сразу). Просто потому что технологии сейчас развиваются с большей скоростью, чем человек может их освоить. Опять же, «освоить» это не значит «прочитать анонсы». Это значит — попробовать вживую. Да, можно хорошо разбираться в 2-3 технологиях, но дальше начинается деградация знаний, и ты действительно становишься универсальным миддлом. Я от этого в какой-то момент устал и ушёл. И очень доволен таким решением.
                                                                                        Хотя я не говорю, что соседние стеки знать не нужно. Я считаю, что сениор должен обладать как минимум полноценным пониманием взаимодействия компонентов своего продукта и умением его отладки — хотя бы чтобы знать, где возникают проблемы, а не вопить, что они «на другом конце». Но понимать тонкости — уже излишне и слишком трудоёмко. Нужно честно признать, что ты развиваешься в конкретном направлении, а в остальных ты в лучшем случае миддл. Затем принять это и не комплексовать. Всегда найдутся люди, которые в чём-то разбираются лучше — поэтому мы и работаем не в одиночку, а командой.
                                                                                          +7
                                                                                          У Райкина была хорошая юмореска про узких специалистов: У нас узкая специализация. Один пришивает карман, один - проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть? И они — не портные, они — подмастерья.

                                                                                          Узкие специалисты нужны редко и ненадолго. Если нужен человек по конкретному интерфейсу SoС — его можно позвать на конкретную задачу. А нужны именно full-stack — спроектировать схему, развести её, спаять, отладить электрически, запустить SoC, потом RTOS, потом приложение.

                                                                                          Это должна быть очень крупная фирма, чтобы позволить себе держать специалиста по RS-485 или RS-232. И очень много разных платформ, чтобы у него был фронт работы.

                                                                                          Ну и потом, узкий специалист не может нормально отлаживаться. Ио работу кода мы отлаживаем осциллографом, а проблемы в железе ищем кодом.

                                                                                          Так что сеньор — это full stack, а «мастера по пришивке пуговиц» — джуны. Для того и было придумано разделение труда и узкая специализация — чтобы заменить десяток сеньоров сотней джунов.
                                                                                            +5
                                                                                            По мне вы описали слегка расширенного, но довольно специализированного разработчика встроенных систем. Когда для созданной железяки понадобится мобильное приложение или сервер сбора данных — это окажется за пределами компетенций описанного специалиста.
                                                                                            А ещё у меня сложилось предвзятое мнение, что чем лучше человек понимает схемотехнику и внутренности МК, тем хуже у него код для этих самых МК
                                                                                              +3
                                                                                              Угу, любой нормальный embedчик — это fullstack. А для редких задач мы привлекаем узких специалистов. Например, привлекали спецов по CAN и по MIL-STD-1553B. Мобильное приложение, сайтик, сервер — это все из другого мира. Того, где linux — достоинство, а не недостаток.

                                                                                              Хуже — это по каким параметрам? По количеству ошибок, по читаемости, по стабильности кода за 10 лет? Когда у вас для отладки только светодиод и осциллограф — есть смысл писать надежно и просто. То есть весьма-весьма дубово. Но это достоинство, а не недостаток.
                                                                                                +4
                                                                                                Кажется вы меня не до конца поняли. Описанный вами embedчик-fullstack — для меня выглядит, как узкий специалист. Хотя, возможно я лукавлю и задним умом считаю логичным разделять разработку железа и его программирование примерно также, как front-end и back-end.

                                                                                                Хуже — по поддерживаемости. В основном я видел спагетти код. При этом после двухмесячного перерыва в работе автор кода не мог понять что, как работает. SOLID, DDD, что это такое?
                                                                                                Если код надёжный и просто — то это замечательно, вот только для меня простота — это не отсутствие работы с указателями или каких-то хитрых вещей, а возможность прочитать совершенно незнакомый код и понять, как он работает. И в этом как раз помогает и SOLID, и другие идеи.
                                                                                                  0
                                                                                                  Узкие специалисты это: «элементщик» (тот, кто компоненты выбирает), закупщик, проектировщик схем, разводчик, оформитель схемы по ГОСТ (приглашали разок), технолог производства печатных плат (консультировались), монтажник, технолог пайки… Это только по стороне железа.

                                                                                                  А на стороне софта… у RS-485 есть терминаторные резисторы. Ну как настраивает резисторы обычный программист? Посмотрел осциллографом, поставил — и тест на сутки. Если больше одного сбойного байта за сутки — менять номинал. А узкий специалист сразу ставит нужный резистор.

                                                                                                  SOLID — это все-таки С++. Простой и читаемый код — это обычный Си, близкий к ассемблеру. См. драйвера linux — они довольно хорошо написаны.

                                                                                                  P.S. У нас в конторе есть всего один узкий специалист — это технический писатель по ГОСТ.
                                                                                                    +1

                                                                                                    Зачем вы в каждое обсуждение пихаете свою предметную область с отсылкой к "а у нас вот так, и поэтому весь мир должен думать так же"?


                                                                                                    BTW, SOLID — это не про С++ и принципы можно и нужно использовать и в не ОО-языках тоже.

                                                                                                      –1
                                                                                                      Это просто реакция на тех, кто считает, что весь мир делает web-приложения. Поэтому и рассказываю о том, что бывает за пределами узкого мирка web-архитектуры.

                                                                                                      А про SOLID в не ОО-языках — расскажите или ссылку дайте.
                                                                                                        +1

                                                                                                        Все принципы, кроме подстановки Лисков можно применять к процедурным и функциональным языкам, просто надо думать в чуть более широком смысле. Например, SRP — функция должна иметь конкретную зону ответственности. Interface segregation — подразумеваем интерфейс в широком смысле, не ключевое слово, а API. И так далее.

                                                                                                          –1
                                                                                                          Ну как раз что-то вроде принципа подстановки Лисков мы применяем в Cи-коде. Делается указатель на процедуру — и вперед. Примерно как onexit в Си.

                                                                                                          Просто нафига очевидные вещи называть громкими словами?
                                                                                                            0

                                                                                                            Принцип подставки Лисков говорит об отношениях между типами и подтипами, как это вы его используете в Си?
                                                                                                            onexit — это обычные коллбеки.
                                                                                                            Очевидные вещи:
                                                                                                            1) очевидны не всем;
                                                                                                            2) очевидны по-разному;
                                                                                                            Что и демонстрирует ваше непонимание очевидных другим вещей.

                                                                                                              0
                                                                                                              Читаем определение:

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

                                                                                                              Вот на callback и на weak-функциях оно и делается. Базовый тип — вывести информацию Специализации — вывести на RS32, на RS32 через ПЛИС, на CAN, на MIL-STD-1443b…

                                                                                                              onexit — как раз нормальный пример. Базовый тип — выполнить финализацию. А специфические подтипы делают конкретные вещи.

                                                                                                              В принципе группа weak-функций или callback дает вполне функциональную замену ООП. Даже с наследованием (можно выставить свою функцию на callback и в ней вызвать то, что было на callback раньше.
                                                                                                                +2

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

                                                                                                      0
                                                                                                      Мое видение таково

                                                                                                      Инженер: Если работает так как надо, то дальнейшие улучшения не требуются.
                                                                                                      Программист: Если результат не оптимален, то не будет работать как надо.

                                                                                                      У первого цель — рабочая программа.
                                                                                                      Цель второго — не ломающаяся программа.
                                                                                                    +3
                                                                                                    Как embedчик не соглашусь с вами. Железо и софт очень сильно отличается, и я еще ни разу за свою карьеру не видел человека, который был очень хорош и там, и там. Как правило, у каждого очень сильный перекос в какую-то из этих областей. Поэтому очень важна специализация каждого, чтобы выпустить качественный продукт. Конечно, если в компании два человека, делающие мелкосерийный продукт для конкретного заказчика со сроками «надо было сделать вчера», то понятно, что каждый должен уметь что-то в каждой области.

                                                                                                    Другое дело когда проект большой, сложный и массовый. Вот у меня сейчас проект — это кодовая база на несколько миллионов строк для МК и сотни людей. Попробуйте это поотлаживать светодиодом и осциллографом. Поэтому тут и SOLID, и юнит тесты, и blackbox тесты, Software-In-the-Loop, Hardware-In-the-Loop, Continuous Integration и т.д. Скажи такие слова человеку из мира железа, он и не поймет что это.

                                                                                                    Все-таки разделение труда — это главное достижение человечества.
                                                                                                      –4
                                                                                                      Миллион строк? Гм, простите, какой объем ПЗУ это занимает? И почему бы при таком объеме кода не использовать linux? А linux — это по моим понятиям уже не совсем embed. Ну или совсем не embed.

                                                                                                      Разделение труда (в пределе — конвейер) придумано, чтобы привлечь к работе низкоквалифицированный персонал. Брукс хорошо доказал, что увеличение численности не ускоряет разработку (если 9 беременных женщин собрать вместе, ребенок через месяц не родится), наоборот, в его конкретном случае, увеличение численности в 10 раз разработку замедлило.

                                                                                                      Поэтому вопрос в экономике. Нужна эффективность производства — делаете конвейер с сотней программистов. Нужно качество — обходитесь всего несколькими сеньорами.

                                                                                                      несколько миллионов строк для МК и сотни людей. Попробуйте это поотлаживать светодиодом и осциллографом.
                                                                                                      Поржал. Зачем это отлаживать на МК? Разработка и отладка 99.9% идет на windows. Да, приходится делать имитаторы и писать переносимый код. Но на windows отлаживается все, кроме очень специфичного для МК кода. Потом перенос на linux, потом — на МК.

                                                                                                      У меня был проект с доступным временем на отладку на реальном стане — 2 часа в месяц (130 тысяч строк кода). Ничего, справился без отладки.

                                                                                                      Software-In-the-Loop, Hardware-In-the-Loop, Continuous Integration и т.д. Скажи такие слова человеку из мира железа, он и не поймет что это.
                                                                                                      Ну и я таких терминов как SIL и HIL не знал. Но мы их применяли почти 20 лет назад. Как-то не сложно было независимо их изобрести.
                                                                                                  +4
                                                                                                  Был у нас на прошлой работе яжпрограммист, начальник отдела программных средств АСУ, а я, соответственно, был сеньором ведущим инженегром в отделе технических средств АСУ. Граница раздела компетенций отделов проходила по клеммникам подключения проводов к контроллерам. Ну вот исторически так сложилось и усиленно поддерживалось руководством. Техник — не лезь в дела программеров, без тебя разберутся, а твоя задача ТЗ написать, железо подобрать, чертежи начертить, процесс сборки проконтроллировать, протестировать, смонтировать, пусконаладить и сдать. А программистам — программистово, код напишут, зальют, посидят за ноутом на пусконаладке, а ты бегай, выполняй их указания, какой датчик попинать, чтобы заработало.
                                                                                                  Так вот этот товарищ усиленно не хотел разбираться в том, чем будет управлять програмирумый им ПЛК и как этот ПЛК, собственно, функционирует. Типа, мое дело писать код, ваше дело предоставить мне алгоритмы и заставить железо работать, либо алгоритмы вытрясайте у технологов.
                                                                                                  И вот настал тот последний проект, который мне в той фирме посчасливилось доводить до конца, от конструкторской документации и почти до пусконаладки. Система ответственная, для нефтехимпрома, контроллеры отказоустойчивые, вероятность отказа 0.(0)1%. Нарисовал схемы, собрали шкафы на сборочном участке, собрали стендики-эмуляторы сигналов, закупили калибратор за бешенные бабки для настройки аналоговых каналов. Начался этап тестирования софта, я подаю сигнал 4...20 мА, имитируя работу датчика, программист смотрит, что пришло, подгоняет единицы измерения — ток в паскали, мм, кубометры и прочее. Подаю я, значится, сигнал, яжпрограммист ждет, что там будет уровень в емкости 1 метр, а уровень то скачет немного, шумит младшими битами 12-битный АЦП в ПЛК. И тут возникает «шум АЦП» со стороны яжпрограммиста: ты что это, подлец и диверсант, делаешь, я ж прошу выставить уровень в емкости 1 м, а ты какого рожна выставляешь то 0.99, то 1.01 м, ты мне вынь да положь 1.000м, как я с буду программу отстраивать на работу с такими данными? Чуть я заикнуля про необходимость фильтрации, аппартаной или программной, как «шум АЦП» начал усиливаться, что это я лезу не в свое дело, мое дело должно быть маленькое, обеспечить нормальное функционирование техники, а не учить программистов работать, что это за препирания с начальством, да и вообще таким специалистам тут не место.
                                                                                                    +2
                                                                                                    Мне кажется что человеку который не знает что АЦП шумит не место в области.
                                                                                                      0
                                                                                                      Это аппаратная проблема, программисты этим не занимаются (с) анекдот.
                                                                                                      +2
                                                                                                      Типа, мое дело писать код, ваше дело предоставить мне алгоритмы и заставить железо работать

                                                                                                      Чуть я заикнуля про необходимость фильтрации, аппартаной или программной

                                                                                                      Тут всплывает весьма важный вопрос: а почему в предоставленном разработчику ТЗ и описании алгоритмов ни слова не было сказано про фильтрацию или сглаживание входных сигналов?
                                                                                                      На тему «это же очевидно» и «это же надо знать» — увы, нет, как минимум потому, что нередко можно встретить модули AIn с включенным по-умолчанию фильтром, и, следовательно, если его нет по ТТХ изделия, стоит явно сформулировать требование о наличии фильтрации, а не махать руками во время пусконаладочных работ, мол, «ты должен был знать».
                                                                                                      Так что, как говорится, «без подробного ТЗ результат ХЗ».
                                                                                                        +2
                                                                                                        Согласен, но как обычно есть несколько тонкостей.
                                                                                                        1. В ТЗ учесть всех нюансов невозможно, много интересных моментов вылазит на следующих этапах, а ТЗ уже утверждено заказчиком и переделке не подлежит.
                                                                                                        2. ТЗ пишется исполнителем (да, те самые отделы технических и программных средств), поэтому относятся к нему, как к формальности — отдельному пункту бюджета поекта. Таким образом, утвержденное заказчиком ТЗ является, прежде всего, документом, который в дальнейшем отсеивает необоснованные притязания заказчика к исполнителю по функциям и задачам системы. И уж во вторую очереди исполнитель обращается к собственноручно составленному ТЗ, чтобы посмортеть, а как же на самом деле надо реализовать ту или иную вещь. Возможно, в других отраслях заказчик приходит к исполнителю с готовым ТЗ, но у нас все наоборот.
                                                                                                        3. Фильтрация сигналов таки была прописана, это стандартный шаблонный пункт (да, мы используем предыдущие наработки в дальнеших проектах, не пишем «код» каждый раз с нуля).
                                                                                                        4. В модулях AI фильтр встроенный есть, на этапе работы с железом (в момент испытаний же!) стало ясно, что его возможности не удоволетворяют требованиям точности. Если железячники о причинах проблемы догадались сразу и тут же предложили метод решения, то яжпрограммист пошел по пути наименьшего сопротивления. Зачем создавать себе работу, если можно свалить проблемы на соседний отдел?
                                                                                                        Да черт с ним, с АЦП, это одна из историй, создавшая проблемы ровно на 2 рабочих дня, с учетом совещания у начальства (любую незначительную проблему выноси на повестку дня на планерке — n-ое правило ватокатства).
                                                                                                        Еще одна история из этого же проекта. Алгоритмы, по которым должна функционировать система, разрабатывались в одном ЭнскГИПроКакойтотампромышленности, разрабатывались в виде, так сказать функциональных диаграмм (дикая смесь FBD и LAD), но в отрыве от соответствующих стандартов. Возможно, авторы листали лет 30 назад справочную литературу по Ремиконтам. Ну не суть, в принципах работы создаваемой системы разобраться можно — что контролировать, что, когда и с какими задержками и блокировками включать. На изучение этой документации техотдел потратил 2 месяца, и потом все на пальцах объяснил программистам, описав алгоритмы в текстовом виде, заодно нашел множество нестыковок, косяков и прочего. Но, в ходе общения с Заказчиком, представителями ЭнскГИПроКакойтотампромышленности пришли к заключению, что «проект уже давно утвержден (лет 6 назад как), переделывать его никто не будет, это деньги и время, делайте как есть, на месте разберемся». ОК, раз есть такой приказ, яжпрограммист использует алгоритмы как руководство к действию, пишет программу.
                                                                                                        Тут поджидает засада. Проектировщики алгоритма знать не знали о стандартах IEC, о том, какие контроллеры будут использваться, какие там есть билиотечные функции. Напоминаю, что в IEC имеются таймеры, типа TON, TOF, TP. Проектировщики алгоритма предполагали одно поведение таймера, стандарт предполагает другое поведение. Яжпрограммист реализует структуру программы в точном соответствии с алгоритмом (проект же утвержден, что я буду отходить от него?), в итоге программа не работает. ОК, копья ломаются, АЦП шумит, проблема решается не без крови (потребовалось добавить к таймеру дополнительно RS-триггер, но в алгоритмах, хоть и предполагается такое поведение, явно это не указано!).
                                                                                                        Поехали дальше, следующая засада. Используются ПЛК двух типов, стандартные, для неответственной системы РСУ, и Safety для системы ПАЗ. Если стандартные контроллеры имеют широкую библиотеку функций, то Safety не дадут вам выстрелить в ногу, даже если очень нужно, поэтому библиотека функций урезана по самое небалуй. Проектировщики алгоритма этих тонкостей учесть не могли, т.к. им все равно, на каком железе это все будет работать. Программист об этом знает, но алгоритмы же утверждены! Итог? Опять неработающая программа.
                                                                                                        И все это в условиях вяло текущего дедлайна, со спецификой особо опасного производства, где любое нарушение технологии — катастрофа.
                                                                                                          +2
                                                                                                          > 1. В ТЗ учесть всех нюансов невозможно, много интересных моментов вылазит на следующих этапах, а ТЗ уже утверждено заказчиком и переделке не подлежит.

                                                                                                          Вообще-то у же на этапе реализации проекта может выпускаться т.н. «Исполнительная документация», которая отражает согласованные с заказчиком изменения проекта, которые были внесены на стадии его реализации. Ну то есть в проекте: «Язык программирования: BASIC, Система хранения: перфокарты», в исполнительной документации: «Язык программирования: Ocaml, Система хранения: Amazon S3» :)
                                                                                                    +6
                                                                                                    У вас какое-то слишком узкое понятие узости специалиста.
                                                                                                    Как ни странно, в российских реалиях обычно называют фуллстаком не того человека, который полностью знает один некий стек от фронта до бэкенда — а того, кто знает несколько стеков.

                                                                                                    А насчёт необходимости узких специалистов «редко и ненадолго» — это просто неправда с потолка.
                                                                                                    Где-то ненадолго нужен администратор Oracle 11g? Или, может, Java разработчик? Может, SQL аналитиков нанимают на месяц? Или где-то ищут одноразовых специалистов по машинному обучению?
                                                                                                      0
                                                                                                      Угу, у нас именно так. Подобного рода специалисты нам нужны лишь на время стыковки нашей части с тем, что пишут другие организации. Нанимали ненадолго специалиста по SCADA, чуть не наняли доктора наук по PID-регулированию, но справились сами. Насчет найма ненадолго специалиста по машинному обучению — уж думали, может быть и наймем.
                                                                                                        +6
                                                                                                        Сейчас поискал гуглом определение — вот вылезло:
                                                                                                        «A Full-Stack Web Developer is someone who is able to work on both the front-end and back-end portions of an application»

                                                                                                        Фулстэк — это тот, кто может работать как над бэкэндом так и над фронтэндом. Просто сейчас масса разработчиков, которые могут только angular, или только мобильные формы лепить, или только сервисы пишут последние 20 лет. Проблема с такими разработчиками, что комманду из таких невозможно нормально нагрузить работой. Всегда кто-то простаивает.
                                                                                                          0
                                                                                                          Вообще статья несколько шире, она не только о вебе судя по всему.
                                                                                                        +5
                                                                                                        отладить электрически, запустить SoC, потом RTOS, потом приложение.

                                                                                                        Вполне допускаю, что у вас не так, но из моего личного опыта разработчики такого широкого спектра «и железо и программы и жнец и на дуде игрец» пишут такой отвратительный код, что жалко глаза. Наблюдается какой-то поразительный шовинизм вида «мы тут Железку создали, что там какой-то код», из чего следует некоторая узость взглядов в сфере разработки ПО и отвратительный нечитаемый и неподдерживаемый код.
                                                                                                          –2
                                                                                                          я бы сказал отвратительный безошибочный читабельный и не меняемый годами код. Но общего тут только «отвратительный». :-) Правда коллега — программист, делать железо — это такое хобби-переросток.
                                                                                                            +2
                                                                                                            Вот в точку. Самый адовый, запутанный и кривой говнокод почему-то встречается именно у микроконтроллерщиков и ПЛКшников, причем часто в проектах для очень серьезных применений. И отговорки везде одинаковые: «тут своя специфика», «работает — не трогай», «доделывали на пусконаладке и нет времени переписать нормально» и подобное.
                                                                                                              0
                                                                                                              Я полагаю, схемы, сделанные программистами, тоже не без недостатков :) А насчет специфики — даже между специалистами по разным ЯП случается недопонимание. Скажем, кому-то сделать что-то с помощью побитовых операций — это правильное, изящное, эффективное решение. А в другом языке это будет порицаться как нечитаемое и неподдерживаемое.
                                                                                                                0
                                                                                                                Я полагаю, схемы, сделанные программистами, тоже не без недостатков :)
                                                                                                                Безусловно. Поэтому я и топлю за четкое разделение обязанностей. Каждый должен заниматься своим делом. Анализом предметной области, технологии процессов, формулированием ТЗ — технолог/аналитик, проектированием схем, разводкой плат, подбором компонентов — инженер-электроник, разработкой архитектуры ПО, написанием кода и тестов — программист. И налаженное взаимодействие между ними. Это, кстати, к вопросу про «фулл-стеков», да :)
                                                                                                                Скажем, кому-то сделать что-то с помощью побитовых операций — это правильное, изящное, эффективное решение. А в другом языке это будет порицаться как нечитаемое и неподдерживаемое.
                                                                                                                Тоже верно. Поэтому я обо всем и рассуждаю немного свысока, как человек, учившийся на специальности «промышленная электроника», большую часть своей карьеры копавшийся с микроконтроллерами, ПЛК и системами автоматики, а потом увлекшийся веб-разработкой и высоконагруженными сервисами :)
                                                                                                                  0
                                                                                                                  Я полагаю, схемы, сделанные программистами, тоже не без недостатков :)

                                                                                                                  Разумеется. Так о том и речь, что универсальная вещь делает всё, но делает всё хуже, чем специализированные по отдельности. Так и со специалистами — к вопросу о fullstack.
                                                                                                                  Конкретно с «железячниками» не раз сталкивался с отношением к вопросу — см. выше — «мы сделали железку, это 99% успеха, осталось только программку накидать, это фигня, за вечер управимся». Получается так себе. Лучше, конечно, чем если наоборот — написать программу, а потом «за вечер» накидать плату, но тем не менее. Т.е. здесь раз за разом встречаю отношение к программированию, как к игровой области, где нет никаких профессиональных стандартов, неважен опыт и навык, нет технологий разработки и этим может заниматься каждый с улицы. Да, порог вхождения, пожалуй, ниже, чем в «железо», но проблема остается.
                                                                                                            +1
                                                                                                            Не только бизнес накладывает ограничения, но и рынок труда. Я бы и рад нанять сеньор реакт дева, и одобрение сверху есть, но в моём городе (850к жителей) спецов в поиске просто нету. А переучивать джейэсников из веб-студий времени нет, быстрее самому написать.
                                                                                                              +1
                                                                                                              Если есть не только одобрение, но еще и деньги, то можно с москвы релокейтнуть
                                                                                                            0
                                                                                                            Можно попробовать компромисс. Смотрим «в ширину», что есть на рынке. Находим «вкусное», интересное, перспективное и изучаем именно это вглубь. После нескольких лет повторяем. Правда, простым это кажется только на словах.
                                                                                                              +2
                                                                                                              А в 40+ проводить итерацию «Находим «вкусное», интересное, перспективное и изучаем именно это вглубь» становится уже ни разу не интересно. Молодёжь всё равно сделает это лучше.
                                                                                                                +3
                                                                                                                Да вот не всегда, тк покопавшись в очередной «новейшей, перспективнейшей bleeding-edge technology» часто обнаруживаешь там решения, про которые тебе рассказывали седые профессора в универе лет 20 назад, а в литературе так вообще лет 50 описано.

                                                                                                                Например, тут вон недавно механический map-reduce на перфокартах пролетал…
                                                                                                                  +3
                                                                                                                  Что наводит на мысли нафига тратить на это время. Вот у меня например вызывает умиление как сейчас JSники открывают для себя прописные истины, которые для нас дедов сто лет в обед пройдены. Но вот начинаю сам писать JS по современным понятиям и ощущаю себя джуном, так как требуются некоторые другие навыки, что бы связать всю эту JS лапшу вместе и это вызывает не интерес, а отвращение, так как начинаешь думать нафига терять время на ковыряние с инструментарием, который ещё переживает детский возраст. А молодёжь открывает для себя чудеса типа строгой типизации и подсказок в IDE и писает кипятком. Что нам дедам там делать, мы всё это уже видели.
                                                                                                                    +4
                                                                                                                    Работу делать, пока они писают )
                                                                                                                      0
                                                                                                                      Android-разработчики недавно открыли для себя MVVM, хотя в WPF было это еще очень давно. Технологии развиваются и проходят один и тот же цикл…
                                                                                                                    +2
                                                                                                                    не согласен) Судя по конфам седые дяденьки уделывают школьников которые только за бесплатными обедами туда и ходят на раз-два тольно на одном практическом опыте).
                                                                                                                    А уж багаж знаний творит и вовсе чудеса).
                                                                                                                    Программиста может погубить только возрастная болезнь мозга, все остальное трудно но преодолимо (даже отстуствие зрения к примеру =) )
                                                                                                                  +2
                                                                                                                  да, но будучи фуллстеком вы сможете в каску поднять проект, не программный продукт конечно, но все же…
                                                                                                                    +4
                                                                                                                    вместо того что бы рассуждать фулстак или сеньёр, лучше бы накодили, что-то толковое.
                                                                                                                      +3
                                                                                                                      Вместо того чтобы рассуждать о том, что автор сделал или не сделал, лучше бы комментарий толковый написали.
                                                                                                                        +4
                                                                                                                        Вместо того чтобы комментарии толковые писать про комментарии бестолковые, лучше бы пирожок скушали. С малиной.
                                                                                                                      +1
                                                                                                                      МОлодо и зелено, сам был таким, но потом понял, что это всё ерунда… титулы, должности, самобичевание, понты, плюнуть и растереть :) Это пройдёт, наверное.
                                                                                                                        +16
                                                                                                                        Правильно — сразу мерить все деньгами и зовите хоть подмастерьем!
                                                                                                                          +7
                                                                                                                          Темную сторону я в тебе ощущаю:)
                                                                                                                            +1
                                                                                                                            Хочу стать долларовым миллионером… чтобы говорить, что не в деньгах счастье…
                                                                                                                          0
                                                                                                                          Стою ровно на такой же развилке. Fullstack это самообман, которые не так очевиден пока работаешь в одиночку или в непрофессиональной команде. Но роста тут никакого. Так что путь в что-нибудь вроде Technical Project Manager.
                                                                                                                            +3
                                                                                                                            Все верно. Это как RPG, если ты качаешь перса во все одинаково, то ты к концу игры будешь плох во всем. Я года 3 назад тоже схватился за голову, присел и сам себе сказал: «вот чего ты достиг, что ты умеешь?». И пошли ответы. Оказывается достаточно много, ведь 8 лет просто так без опыта не могут быть. А рас получил ответы, то задался вопросом: «что можно изменить или дополнить, что бы больше зарабатывать?». С тех пор по утрам я учусь. Всему. Старые знания я несколько раз переповторял, заново открывал книги, и уже в них находил ошибки. Я сейчас взял курс на руководителя. Это значит я должен знать все, что мне приносит прибыль, на 30% минимум. Что-то больше, что-то меньше. Но управление и маркетинг обязан знать минимум на 4-ку, т.к. там нельзя брать в процентном соотношении. И сейчас целенаправленно иду к этому.
                                                                                                                              +1

                                                                                                                              Все хорошо, только учить разные технологии — это не «как в РПГ». Если, конечно, не ставить целью овладение технологией ради технологии (а не ради решения бизнес-задачи).

                                                                                                                              +20
                                                                                                                              Быть «сорокалетним синьором одной технологии» — это тоже опасно, тк со временем начинает теряться кругозор (а так же отрастать борода и свитер). Опять же диверсификация важна как в финансах, так и в карьере. К тому же технологии имеют тенденцию наскучивать (мне по крайней мере) и редко кто, как мне кажется, хочет копаться 20 лет в одном и том же. Ну да, за 20 лет можно стать мегаджедаем Джавы или Оракла и затыкать всех за пояс на собесах, но в этом ли цель?
                                                                                                                                +11
                                                                                                                                Я fullstack, я могу построить систему от 0 до акта. Когда я вижу системы написанные «частичниками» — у меня волосы дыбом встают, сколько глупого кода, лишнего… То что можно сделать в субд, делается в коде языка софта бэка. Насколько это затратно и по коду и по времени выполнения… что можно эффективно сделать на языке софта бэка — перекладывается на язык клиента… Как минимум в команде должен быть руководитель fullstack, а лучшие — вся команда из fullstack. В такой команде всегда найдутся те, кому нравится больше фронт, кому бэк, кому субд. Но такая команда сможет грамотно организовать распределение задачи на нужную область выполнения.
                                                                                                                                  +26
                                                                                                                                  У вас тут подмена понятий происходит.

                                                                                                                                  Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.
                                                                                                                                  Нормальный фронтендер не затащит на фронт то, что нужно делать на бэке.

                                                                                                                                  Плохой разработчик сделает и то и то и другое вне зависимости от того, узкий он специалист или fullstack.
                                                                                                                                    –2
                                                                                                                                    Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.
                                                                                                                                    Ключевое слово — Нормальный. Но таких ужасающе мало, и к сожалению, я таких не встречал. Хотя в своей «частной» области сеньёры…
                                                                                                                                      +12
                                                                                                                                      Откуда вы такие беретесь? Умные, красивые, дартаньяны, все прям могут и при этом «нормальных» бэкендеров не встречали? Я конечно могу жестко заблуждаться, но что-то мне подсказывает, что если вы не работали с крутыми, умными коллегами и в том числе специалистами в узких областях — то вы врядли настолько офигенные, как вы о себе думаете.
                                                                                                                                        –4
                                                                                                                                        К сожалению — не встречал. Наверное такие есть, не отрицаю, но практика вещь серьёзная… На моей практике людей разбирающихся в субд — мало, зато остальные считают себя спецами и городят функции субд на языке софта системы… — да, в своей области они спецы, но они не понимают, что их труд по реализации функций субд полная фигня… Ладно бы они это признавали и просили о содействии, а то ведь считают себя в этом вопросе истиной в первой инстанции. Придумывают тысячу отговорок, чтоб не использовать возможности субд.
                                                                                                                                        Да и в своей области не всегда красиво выглядят. Есть примеры когда ругают код, а предлагают такое, что добавляет и кучу кода и время выполнения. Как яркий пример использование шаблонизации — да, чисто внешне вроде красиво, как копнёшь… нужно сделать то, сё, пятое, десятое… а в итоге за всем этим скрыто простое построение строки, которое можно сделать просто и наглядно в в несколько строк кода, а не в нескольких файлах. и будет работать а разы быстрее.
                                                                                                                                          0
                                                                                                                                          Можно уточнить, что подразумевается под «простым построением строки», конкатенация?
                                                                                                                                            –2
                                                                                                                                            по большому счёту — конкатенация, только в java это, если в лоб, очень затратная операция, поэтому используется StringBuilder. В любом случае, и серверный рендеринг, и json, и шаблонизация — это построение строки.
                                                                                                                                              +3
                                                                                                                                              Отлично, сегодня вы сделали конкатенацию строки в процедуре а завтра туда мигрирует вся логика. После этого саппорт подобного «солюшена» превращается в муки ада. Я не спорю что иногда лучше посчитать там где данные обитают чем гонять их по сети, но конкатенировать несколько строк возможностями бд это уже выше моего понимания.
                                                                                                                                            0
                                                                                                                                            Вот по каким критериям полная фигня? Эти критерии важны для кого? У этих кого нет более важных критериев?

                                                                                                                                            Если код работает, отвечает функциональным требованиям к системе — он уже не фигня объективно.
                                                                                                                                              0
                                                                                                                                              код может работать 1 мс, а может 1минуту — оба варианта отвечают требованиям.
                                                                                                                                              как правило один код может отличаться от другого на не большое время работы — но таких кусков кода может быть много — в итоге система может либо тормозить, либо быстро работать — выбор за тобой