Где-то проскакивала такая идея: разработка это творчество, а творчеству нужно ставить цели а не ограничения, как их достичь оно найдет само.
Суть в том, что у разработчика множество инструментов для достижения цели: он взаимодействует непосредственно с кодом и всеми его особенностями, большинство из которых нигде не описаны, и поэтому не могут использоваться для проектирования кем-то кроме разработчика, также он имеет какой-то индивидуальный опыт и знания, которые могут выстрелить и серьезно сократить/упростить/ускорить/улучшить код, и опять же никто кроме разработчика такое предусмотреть не в состоянии. Творчество как оно есть.
Так что в идеале просто требуется максимально наглядно донести до разработчика конечный результат. Для фронта - макеты и описание/скриншоты состояний. Для бека - диаграммы, дающие понимание что должно происходить в системе на высоких уровнях.
В реальности же в крупных фирмах многие разработчики - многостаночники: они не погружены в конкретный проект. Обычно есть ведущий разработчик, ответственный за проект, имеющий с ним много опыта, и "мускулы" - разработчики, которых привлекают по потребности к разным проектам, нередко сразу к нескольким. Так что у большинства из них нет никакой информации о проекте, кроме той, что есть в задаче и в описании проекта. Именно поэтому в задаче важно описать все так, чтобы было понятно новичку: разработчик придет с другого проекта на поддержку, он не знает какие механики есть на проекте и как интерпретировать скудное ТЗ, у него нет контекста. Есть конечно ведущий разработчик, и он частично это может компенсировать, но только частично: если все так плохо огганизовано, ему придется и за аналитика и за продакта работать. Разовый затуп он может разгрести, но если на постоянку так - просто уволится. Поэтому все это должно быть организовано заранее.
Но чтобы реализовать этот творческий потенциал, разработчики должны привлекаться к процессу проработки ТЗ на уровне технических консультантов.
Это не редактор, а IDE, так что вполне естественно что процесс разработки должен поддерживаться от и до, и максимально бесшовно.
Веб-сервисы и БД для локальной разработки у многих в докере сейчас, так что интеграция с ним нужна - нужно же взаимодействовать с этими сервисами, вот оно и взаимодействует. Аналогично и все остальное.
А то БД вроде тоже не нужно по такой логике, но на практике оказывается очень нужно: почти любая разработка так или иначе завязана на те или иные СУБД, а тут схема БД синхронизируется с кодом, пишешь SQL и сразу получаешь актуальные подсказки по реальной БД, а не вслепую как в аналогах, и тут же можешь отладить запрос на реальных данных, выполнить его, поменять, оптимизировать. Удобно. А еще в целом помогает решать проблемы, которые сложно решить иначе - можно быстро поменять схему, диагностировать ошибку запроса, поискать фрагмент во всех табличках и всех полях сразу, загрузить/выгрузить данные, и т.п. Получается интеграция с БД от и до, не отрываясь от процесса разработки, ни на что лишнее отвлекаться не нужно.
Интеграция с git вообще выше похвал: большинство проблем можно отследить за секунды без bisect, просто по тесной связи кода в редакторе с историей, а по истории можно ходить рекурсивно и по фильтрам - задаешь критерии и видишь когда, кто, и что делал, нередко видно и почему, когда был внесен баг, и как его исправить. Тут же можно перейти в gitlab/github или поделиться ссылкой на коммит или фрагмент кода в истории.
Веб-сервер помогает как минимум при верстке и ее правке - результат почти в реальном времени видно, без внешних зависимостей, удобно. Там же можно отладить простые приложения.
Отладчик шикарен: в каждом узле трейса видно актуальное состояние окружения, есть условия, вычисляемые значения и отслеживаемые переменные, можно писать проходы фрагментов кода в лог без остановки выполнения, и выпадать в отладчик по конкретному условию или по выбранным исключениям. В общем сильная штука.
Профилировщик жаль не везде работает - в задачах оптимизации просто на порядки ускоряет работу: вместо поиска и анализа сразу видишь наиболее горячие участки, и быстро можешь сравнить эффект от их изменения. Но всегда можно прикрутить внешний профилировщик, если встроенный не поддерживает конкретный язык.
Ежедневник тоже штука нужная, но ненадежная - один раз потерял заметки. Но там есть scratch'es и закладки, вот эти в сочетании очень хороши. Позволяют хранить свои заметки по каждой задаче или событии, планы, наброски - это нужно когда работаешь больше чем над одной задачей и вынужден выгружать все из головы: открыл заметку и сразу видно на каком ты этапе и что делать дальше. А также там можно хранить списки апи-вызовов для отладки/тестирования апишек всяких, тоже иногда нужно по-быстрому что-то проверить, не ломаешь голову - просто открыл заметку по апи, подставил данные и выполнил запрос.
Таск-трекер отслеживает состояние IDE и позволяет быстро переключаться между несколькими задачами, в каждой уже будут открыты актуальные для нее участки кода. Удобно. А в сочетании с интеграцией с тайм-трекерами еще и отслеживает время работы над каждой задачей, и в некоторые тайм-трекеры может автоматически выгружать статистику.
Кстати, встроенная система статистики и связанная с ней помощь и обучение тоже мощные штуки - позволяют отследить насколько полно ты знаешь/пользуешься возможностями IDE, и потренить их.
Все это по-отдельности вроде бы мелочи и можно использовать отдельно, но все вместе и дает тот самый эффект, о котором тут пишут, и заставляет людей нести деньги - оно того просто стоит.
Безусловно хотелось бы видеть близких по возможностям конкурентов, чтобы иметь выбор и не зависеть от единственной фирмы. Но конкурентов со схожими возможностями пока что-то не видно, и это странно - компания далеко не монополист, конкурентов не пожирает, казалось бы поле непаханое возможностей для конкуренции.
Нормально выглядит. Просто в одном случае сравнивается производительность одиночной операции в одном вычислительном блоке, а в другом - полная производительность всех вычислительных блоков.
У двух процессоров может быть одинаковая производительность по операциям, например одна частота и одна скорость выполнения в тактах, но при этом совершенно разная производительность: один имеет один alu, а другой десятки, и ещё всякие avx-расширения, так что способен через себя за тоже время пропускать огромные потоки.
Бенчмарки естественно сравнивают полную противоположность - именно то, что будет использовать оптимизированный прикладной софт. А одиночная линейная операция покажет совершенно другие цифры - всё таки процессоры растут больше вширь, а не вглубь, поэтому оптимизации под железо сейчас так важны - нужно нагружать все исполнительные блоки железа по-максимуму чтобы код был действительно быстрый.
Для своих задач сравниваю производительность в архиваторах, и рост за десятилетие там тоже впечатляет.
Вот например мои тесты:
WinRAR
Armv7 Neon (2012) 2c/2t 1GHz 300kb/s
Intel HT (2005) 1c/2t 3GHz 300kb/s
Amd APU (2012) 2c/4t 4GHz 3000kb/s
Amd Ryzen 7 (2020) 8c/16t 5GHz 32000kb/s (3300kb/s single thread)
Все первые тесты в многопотоке были. Рост за 15 лет впечатляет, 2 порядка.
Половина современного ядра по вычислительной мощности превосходит совокупно все ядра прошлых поколений, работающие вместе.
Если правильно понял, такой конфиг принимает соединения точечно, для всех остальных сервак остается безмолвным черным ящиком, который нет смысла атаковать. Шикарное решение.
Да, работа с ast-деревом доступна уже сейчас. Сейчас большое количество софта именно на этом уровне с кодом и работает.
Но на горизонте 10 лет недостижимо даже адекватное понимание этих двух фраз-приказов: в текущем виде нейронки не мыслят, они статичны. А для понимания приказов нужно много работы: перевести в промежуточный язык, выделить сущности и связать их с кодовой базой, сформировать очередность команд, и т.п. Много абстрактной работы с контекстами. Это целый ворох технологий будущего, которых пока просто нет.
Даже у человека дойти до уровня этих приказов займет 3-5 лет.
10 лет - это типичное время развития одной не особо сложной технологии. А не букета сложнейших технологий.
Смотря что за SSD. Если смотреть на современные флагманы типа Самсунга, то контроллеры там перемалывают огромные потоки данных (читай - работают с огромными частотами) и хорошо греются, крупные техпроцессы малоприменимы.
Отдельный элемент - прошивка, в которую отлиты секреты, ноу-хау и опыт по практической эксплуатации миллионов изделий прошлых поколений, всё для достижения высокой производительности и долговечности. Это тоже не так просто получить.
А прошивку дополняет сервисный софт: диски же нужно обслуживать, ремонтировать, обновлять прошивку.
Отдельный момент: клиентские утилиты. Они дают преимущество: там где у конкурентов клиент будет недоволен походом в сервисцентр, у того же Самсунга клиент сам обновит прошивку в авторежиме через софт, легко избавившись от возможных багов прошивки. Но эти утилиты должны поддерживаться, должны быть красивы и удобны - считай нужно много ресурсов на софт и поддержку, напрямую к продукту отношения не имеющему.
А ведь ещё есть сеть сервисцентров, документация, оборудование...
И это абсолютно не говорим о таких мелочах как маркетинг и реклама, что тоже требует сотни специалистов.
Вот и получается, что чип спроектировать и произвести - это конечно большая работа, но капля в море того, что требуется для успешного выхода на рынок.
Но есть также другой, не менее важный аспект в сфере безопасности: пока страна имеет доступ к внешним поставкам какой-либо технологии, очень сложно, на всех уровнях причем, заставить полностью импортозаместить эту технологию. Всегда кто-то где-то захочет сэкономить, и так или иначе закупит чужое, а это, в случае разрыва внешних поставок, поставит страну в очень уязвимое положение. Так что китайцы сделали правильный вывод из этой ситуации: хочешь что-то своё - сделай это несовместимым с чужим, и тогда всем волей-неволей придется сосредоточиться именно на своем, потому что такое же чужое найти просто невозможно.
Грубо говоря они начинают разработку и производство risc-x, а потом ставят требование, что железо в таких-то областях должно быть исключительно risc-x, и все, заказы пошли, машина заработала: никаких уязвимых технологий снаружи никто импортировать не может физически, risc-x можно заказать только у внутренних поставщиков
Экономия места - она за счёт сжатия. Отсюда быстрая установка и обновление, но медленный старт и работа. И по-моему основное - это как раз работа.
Мы берём современные nvme не для того, чтобы экономить место, а чтобы софт максимально быстро работал с файлами. И с этой точки зрения сжатие - не самая умная идея: оно тормозит работу с ФС, и дополнительно нагружает процессор.
На HDD сжатие имело смысл - там шины были узкие, процессор простаивал, выгоднее было нагрузить процессор и разгрузить шины. Но на nvme, ИМХО, доступ к тысячам файлов, он быстрее будет напрямую.
От тысяч файлов никуда не уйти - IDE так или иначе с ними работает. Просто в одном случае она один раз чуть дольше устанавливается, зато быстро может обращаться к файлам в любой момент, а в другом случае она чуть быстрее устанавливается, зато дополнительно тормозит и при запуске и при обращении к файлам, потому что вынуждена продираться через дополнительные слои распаковки.
К тому же нативно для IDE ещё и работает родной toolbox, через который проходит синхронизация, обновления, управление интеграцией в систему, очистка временных файлов, и там же небольшой аналог машины времени встроен: если новая версия не зашла, можно за секунду откатиться к предыдущей, гарантировано рабочей версии IDE. Не думаю что все это будет корректно работать со snap.
Ты не учитываешь, что программист ни за что не отвечает, потому что ему никто этой ответственности не даёт - всё решают за него, и до него, ответственность у вышестоящих лиц, сам он лишь мелкий винтик в современной индустрии. Ему дают задачу и время, и главное - уложиться в отведенный срок, а результат не особо важен.
Собственно это последствия мира команд и менеджмента.
Одиночка имеет больше ответственности, более целеустремлён, имеет контроль над кодом. В командах ответственность размазывается, контроль удержать сложно, как итог в код начинает проникать мусор и ошибки, и ресурсов этого избежать часто нет. Особенно плохо, если в команде есть слабые коллеги: за них их часть работы никто не сделает, ресурсов на это не дают, а их код ужасен, но так навсегда в проекте и останется, будет кое-как работать, порождать сотни ошибок.
С учётом того что современная разработка построена на максимальной экономии и руководит процессом менеджер, который в этом ничего не понимает, приходим к фичегонке: оказывается для проекта важнее наклепать тысячу ненужных фич, чем остановиться и привести в порядок хотя бы одну из уже сделанных. Та же ситуация с техдолгом и качеством кода: на это никогда нет времени, вечное завтра.
Вот и получается, что на выходе у одиночки компактный рабочий код - он его сам писал, один, сам за все в ответе, сам все проверил, и результат прямо соответствует ему опыту: у новичков он плохой, у опытных хороший.
А на выходе у компании - урод, внутрь которого лучше не заглядывать: раздутая смесь из грязного кода, ошибок и костылей, которая каким-то чудом но частично работает. Там тысячи фич, но работает из них лишь часть, и работает не особо хорошо.
Особенно таким грешат крупные компании, где софт для галочки: его просто нужно выпустить, а как - не важно. Менеджер на менеджере сидит и менеджером погоняет, важны только отчёты и расходы, а главное, сам результат, никого не интересует.
Чтобы результат был хорош, нужно давать разработчикам свободу. А это в основном некоторые продуктовые компании, которые сосредоточены на результате, где можно взять и пилить одну фичу до тех пор, пока она действительно не будет готова, или где если заметил ошибку или неоптимальный алгоритм, ты можешь его взять и поправить.
Так то да, но все же стремиться к этому стоит. В первую очередь такое полезно для себя любимого.
Например если ты не зациклен на одном языке - у тебя больше возможностей для поиска работы, выше мобильность. Это касается кстати не только языков программирования, но и человеческих - некоторые рынки требуют своих специфичных языков.
С другой стороны распыляться тоже нехорошо - все имеет свою цену: за одно и тоже время ты освоишь хорошо один язык или средне два.
На начальном этапе это будет тормозить развитие и нежелательно. Но после - почему бы и нет?
Начинается такое обычно для себя, из интереса - пощупать новое. Потом постепенно твои возможности растут, и становится доступна миграция между языками, можешь +/- эффективно что-то делать и там и там. А там недалеко и до смены сферы на более комфортную или параллельная работа на два лагеря.
Это уже каждый сам решает куда двигаться. Тут важно, что развитие в принципе дает такую возможность, позволяет не застаиваться в своем болоте.
С ЯП низкого уровня согласен - знать нужно, не обязательно хорошо, но пощупать стоит, и желательно вглубь: "Code: The Hidden Language of Computer Hardware and Software" дает неплохую базу, как и старые советские детские книжки времен dos. Ну а если удалось "пощупать" cpu изнутри, например писали что-то под микроконтроллеры - это вообще замечательно: многие из "железных" проблем и абстракций становятся ближе и понятнее, как и уникальные возможности, которые на уровне прикладного софта просто недоступны.
Понимание ООП+ФП тоже нужно. В новых курсах некоторые уже начинают сразу оба подхода параллельно давать: где-то применим один, где-то другой. А заодно рассказывают и о других, уже устаревших, подходах - для целостной картины мира.
Все это начинает играть где-то со 2-3 года опыта, когда рефакторинг выходит на значимое место.
Что касается остального - оно часто опционально, и зависит от области деятельности. Многие могут за всю практику так никогда и не столкнуться с тем же html. У каждого на рынке сейчас своя специализация: то-то пишет драйвера, кто-то прошивки, кто-то сайты, кто-то приложения, а кто-то вообще какие-нибудь внутренние модули абстрактной большой системы, которые никакого интерфейса наружу вообще в принципе не имеют.
Там, где нужна интерфейсная часть, везде своя специфика: где-то достаточно cli, где-то требуется gui, ну а где-то web-интерфейс или какое-либо апи.
По БД тоже самое - кто-то хранит данные в текстовых файлах, кто-то пользуется sqlite, кто-то взрослыми СУБД, кто-то работает через апи другой системы, кто-то даже в памяти все хранит (и, что странно, вполне успешно - недавно такая статья тут уже была), а кто-то вообще ничего не хранит. Отсюда и соответствующие потребности.
Но в целом SQL хотя бы в общем виде знать нужно - это наиболее распространенное решение для хранения данных. Хотя бы на уровне "не пугаться незнакомых слов". Как минимум это поможет сэкономить силы и время, когда и если потребность в БД придет - тот же sqlite можно куда угодно подпихнуть при необходимости, готовое и доступное решение в любом случае лучше попыток изобрести что-то свое.
А что касается web-интерфейсов - основы html еще можно по-быстрому освоить, а вот углубляться в верстку и фронт думаю не стоит, это отдельная большая область знаний, ее лучше оставить соответствующим специалистам. Эта область слишком динамичная, без постоянной практики не удержаться. Ради разовой потребности смысла погружаться мало, под разовую задачу лучше найти специалиста конкретно по фронту - будет быстрее и качественнее, чем самому что-то изобретать.
Сейчас такое время, когда важно даже не столько что-то уметь, сколько знать о существовании какой-либо возможности или технологии. Такие знания расширяют твой инструментальный набор: если ты слышал о какой-либо технологии, у тебя уже больше возможностей, чем у того, кто о ней не слышал - если потребуется, найти документацию и освоить технологию всегда можно, а вот заранее узнать что такое вообще в принципе существует и возможно - это уже не так просто, нужно постоянно расширять профессиональный кругозор. Те, кто не слышал про технологию, вынуждены будут изобретать свой велосипед, фактически делающий тоже самое, но хуже, к тому же еще и дольше/сложнее/дороже, чем воспользоваться готовым.
Как-то на время подключили на один маленький проект, который единолично вел такой вот Сережа.
Первое что насторожило - подход Серёжи: по любой мелочи часовой созвон, на котором всячески изображается готовность помочь, но в итоге просто по нескольку раз повторяется то что ты скажешь, и по сути ничего обсудить не удается. Человек изображает бурную деятельность, и клиентам это нравится, но по факту впустую тратит время. От практики созвонов с Серёжей естественно пришлось отказаться, ввиду их абсолютной неэффективности.
Второе что привлекло внимание - отсутствие автозагрузки классов на проекте: обычно это означает что идёт жёсткая борьба за быстродействие. Но код проекта как-то не показывал, что стремится быть быстрым - кеширование почти не используется, море говнокода и лишней работы в коде, все тормозит. В коде настолько много лишнего, что после рефакторинга в своей небольшой зоне ответственности код сокращался в разы, почти полностью заменяясь библиотечным функционалом, и наконец то становился более-менее понятен с первого взгляда. Стал разбираться как же так вышло, что за несколько лет жизни проект не обзавелся автозагрузкой - это же 15 минут работы, элементарный функционал. В итоге нашел: задача на оптимизацию проекта была, пару лет назад, там в том числе затрагивался вопрос автозагрузки, но Сережа просто не понял что от него хотят, и в итоге все эти годы тщательно складывал каждый новый класс в огромную таблицу статической загрузки классов. Терпение конечно впечатляющее у человека, но это сизифов труд.
И вот примерно в таком стиле был построен весь проект. Но опыт был интересным, конечно: как в кунсткамеру сходил - столько необычных решений и абсурда редко где встретишь.
Такие идеи о "своем детище" на практике быстро разваливаются, т.к. точка зрения на развитие продукта у бизнеса и техлида отличаются, и решение не за техлидом, и в данной ситуации каждый считает продукт "своим детищем" и тянет одеяло на себя. В такой ситуации у техлида получается позиция "прокладки", номинального управляющего - он отвечает за техническую часть и желает ее максимально улучшить, но фактически никаких реальных полномочий на это повлиять не имеет, желания диктует исключительно бизнес, потому что бизнес все и оплачивает.
Роль техлида - наилучшим образом удовлетворить потребности бизнеса с помощью своей технической экспертизы. И с этой точки зрения это просто рутинная должность: переводить требования с языка бизнеса на язык технологий. Придумать как наилучшим образом реализовать запрошенное, с учётом потребностей бизнеса по стоимости, времени и функционалу - требуется найти некий компромисс, чтобы решение было функционально и финансово доступно, и в тоже время не ломало существующие процессы и было поддерживаемо.
Понимание базовых истин и принципов приходит с опытом, через боль и страдания.
Новичкам естественно проще и понятнее более простая процедурная архитектура - они ещё не сталкивались с отладкой чего-то сложнее калькулятора и неуловимыми ошибками. Донести до них опыт можно, но вот понять его многие из них не смогут, только запомнить. Исключения - те, кто сталкивались с чем-то похожим на прошлом опыте.
Когда человек убьет день на глупый досадный баг, который можно было бы легко избежать, следуя очевидным истинам и простым принципам, он постарается в будущем не повторять такой ошибки.
В идеале такое надо сразу вносить в программу обучения, чтобы сразу на личном опыте новички ощутили не только плюсы, но и минусы того или иного подхода.
К сожалению в большинстве случаев этого не делается, возможно из соображений упрощения и снижения нагрузки: если новичкам с первых шагов расставлять грабли, путь сможет пройти меньше людей, тех кто сдался поприбавится. Как минимум той модели курсов, что эксплуатируется сейчас, выгодна именно массовость, а не качество.
В любом случае, по наблюдениям, первые 6-18 месяцев человек упорно пытается придерживаться процедурного подхода, генерируя страшный код. Потом обычно начинается прогресс - начинает приходить понимание, накапливается опыт. Но не у всех, к сожалению.
Серьезный бустер тут - обмен опытом с более опытными коллегами: ревью и рефакторинг чужого кода, обсуждения. Что-то постигается самостоятельно, что-то подсматривается в коде более опытных коллег, что-то выносится из обсуждений/проблем, свидетелем или участником которых был. Этого к сожалению типичные курсы тоже не дают - даже если есть группы, они одного уровня.
При этом если человека что-то неустраивает, об этом он не скажет - обратной связи по деструктивной деятельности руководства нет. Поэтому такая глупость вдвойне опасна: недовольство будет только накапливаться, а потом сорвется лавиной и снесет руководителя, нередко вместе с фирмой.
С точки зрения самого человека обратную связь давать нет никакого смысла: ждать положительных изменений в конкретной фирме бессмысленно, если это и будет, то донести их будет тяжело, и займет годы - проще, быстрее и выгоднее просто уйти в другую, еще и с повышением в зарплате. Процессы в фирме либо налажены, либо нет, и налаживать их - задача совсем не линейного рабочего.
Всякие модные анонимные опросники не работают. Кто реально занят работой, не тратят время на очередной бесполезный опросник, хотя их мнение наиболее важно для фирмы, но никак не учитывается. Те кто чем-то недоволен, по большей счасти тоже проигнорирует опросник, из-за опасений что он не совсем анонимный и будут последствия за высказанное недовольство, нередко обоснованные, сам такое уже видел: даже если нет технического способа выяснить отправителя - недовольные руководители с горящей попой устраивают чистки. Ну а кому делать нечего и их все устраивает - именно они и будут проходить опросники, только вот это полностью дискредитирует саму идею: мнение наиболее полезных членов рабочего коллектива, а также мнение наиболее недовольных, никак не охвачено, а значит любые изменения по итогам опроса не будут учитывать эти две категории и положительным образом на них не отразятся. В результате все изменения по итогам результатов опроса сведутся к очередному никому не нужному игровому автомату или чему-то подобному, и ресурсы вроде потрачены, галочка о проведении работе с коллективом проставлена, а результата нет: люди уходят. Эффективность как она есть.
Так что внутри коллектива либо доверие, либо противостояние.
Где-то проскакивала такая идея: разработка это творчество, а творчеству нужно ставить цели а не ограничения, как их достичь оно найдет само.
Суть в том, что у разработчика множество инструментов для достижения цели: он взаимодействует непосредственно с кодом и всеми его особенностями, большинство из которых нигде не описаны, и поэтому не могут использоваться для проектирования кем-то кроме разработчика, также он имеет какой-то индивидуальный опыт и знания, которые могут выстрелить и серьезно сократить/упростить/ускорить/улучшить код, и опять же никто кроме разработчика такое предусмотреть не в состоянии. Творчество как оно есть.
Так что в идеале просто требуется максимально наглядно донести до разработчика конечный результат. Для фронта - макеты и описание/скриншоты состояний. Для бека - диаграммы, дающие понимание что должно происходить в системе на высоких уровнях.
В реальности же в крупных фирмах многие разработчики - многостаночники: они не погружены в конкретный проект. Обычно есть ведущий разработчик, ответственный за проект, имеющий с ним много опыта, и "мускулы" - разработчики, которых привлекают по потребности к разным проектам, нередко сразу к нескольким. Так что у большинства из них нет никакой информации о проекте, кроме той, что есть в задаче и в описании проекта. Именно поэтому в задаче важно описать все так, чтобы было понятно новичку: разработчик придет с другого проекта на поддержку, он не знает какие механики есть на проекте и как интерпретировать скудное ТЗ, у него нет контекста. Есть конечно ведущий разработчик, и он частично это может компенсировать, но только частично: если все так плохо огганизовано, ему придется и за аналитика и за продакта работать. Разовый затуп он может разгрести, но если на постоянку так - просто уволится. Поэтому все это должно быть организовано заранее.
Но чтобы реализовать этот творческий потенциал, разработчики должны привлекаться к процессу проработки ТЗ на уровне технических консультантов.
Это не редактор, а IDE, так что вполне естественно что процесс разработки должен поддерживаться от и до, и максимально бесшовно.
Веб-сервисы и БД для локальной разработки у многих в докере сейчас, так что интеграция с ним нужна - нужно же взаимодействовать с этими сервисами, вот оно и взаимодействует. Аналогично и все остальное.
А то БД вроде тоже не нужно по такой логике, но на практике оказывается очень нужно: почти любая разработка так или иначе завязана на те или иные СУБД, а тут схема БД синхронизируется с кодом, пишешь SQL и сразу получаешь актуальные подсказки по реальной БД, а не вслепую как в аналогах, и тут же можешь отладить запрос на реальных данных, выполнить его, поменять, оптимизировать. Удобно. А еще в целом помогает решать проблемы, которые сложно решить иначе - можно быстро поменять схему, диагностировать ошибку запроса, поискать фрагмент во всех табличках и всех полях сразу, загрузить/выгрузить данные, и т.п. Получается интеграция с БД от и до, не отрываясь от процесса разработки, ни на что лишнее отвлекаться не нужно.
Интеграция с git вообще выше похвал: большинство проблем можно отследить за секунды без bisect, просто по тесной связи кода в редакторе с историей, а по истории можно ходить рекурсивно и по фильтрам - задаешь критерии и видишь когда, кто, и что делал, нередко видно и почему, когда был внесен баг, и как его исправить. Тут же можно перейти в gitlab/github или поделиться ссылкой на коммит или фрагмент кода в истории.
Веб-сервер помогает как минимум при верстке и ее правке - результат почти в реальном времени видно, без внешних зависимостей, удобно. Там же можно отладить простые приложения.
Отладчик шикарен: в каждом узле трейса видно актуальное состояние окружения, есть условия, вычисляемые значения и отслеживаемые переменные, можно писать проходы фрагментов кода в лог без остановки выполнения, и выпадать в отладчик по конкретному условию или по выбранным исключениям. В общем сильная штука.
Профилировщик жаль не везде работает - в задачах оптимизации просто на порядки ускоряет работу: вместо поиска и анализа сразу видишь наиболее горячие участки, и быстро можешь сравнить эффект от их изменения. Но всегда можно прикрутить внешний профилировщик, если встроенный не поддерживает конкретный язык.
Ежедневник тоже штука нужная, но ненадежная - один раз потерял заметки. Но там есть scratch'es и закладки, вот эти в сочетании очень хороши. Позволяют хранить свои заметки по каждой задаче или событии, планы, наброски - это нужно когда работаешь больше чем над одной задачей и вынужден выгружать все из головы: открыл заметку и сразу видно на каком ты этапе и что делать дальше. А также там можно хранить списки апи-вызовов для отладки/тестирования апишек всяких, тоже иногда нужно по-быстрому что-то проверить, не ломаешь голову - просто открыл заметку по апи, подставил данные и выполнил запрос.
Таск-трекер отслеживает состояние IDE и позволяет быстро переключаться между несколькими задачами, в каждой уже будут открыты актуальные для нее участки кода. Удобно. А в сочетании с интеграцией с тайм-трекерами еще и отслеживает время работы над каждой задачей, и в некоторые тайм-трекеры может автоматически выгружать статистику.
Кстати, встроенная система статистики и связанная с ней помощь и обучение тоже мощные штуки - позволяют отследить насколько полно ты знаешь/пользуешься возможностями IDE, и потренить их.
Все это по-отдельности вроде бы мелочи и можно использовать отдельно, но все вместе и дает тот самый эффект, о котором тут пишут, и заставляет людей нести деньги - оно того просто стоит.
Безусловно хотелось бы видеть близких по возможностям конкурентов, чтобы иметь выбор и не зависеть от единственной фирмы. Но конкурентов со схожими возможностями пока что-то не видно, и это странно - компания далеко не монополист, конкурентов не пожирает, казалось бы поле непаханое возможностей для конкуренции.
Нормально выглядит. Просто в одном случае сравнивается производительность одиночной операции в одном вычислительном блоке, а в другом - полная производительность всех вычислительных блоков.
У двух процессоров может быть одинаковая производительность по операциям, например одна частота и одна скорость выполнения в тактах, но при этом совершенно разная производительность: один имеет один alu, а другой десятки, и ещё всякие avx-расширения, так что способен через себя за тоже время пропускать огромные потоки.
Бенчмарки естественно сравнивают полную противоположность - именно то, что будет использовать оптимизированный прикладной софт. А одиночная линейная операция покажет совершенно другие цифры - всё таки процессоры растут больше вширь, а не вглубь, поэтому оптимизации под железо сейчас так важны - нужно нагружать все исполнительные блоки железа по-максимуму чтобы код был действительно быстрый.
Для своих задач сравниваю производительность в архиваторах, и рост за десятилетие там тоже впечатляет.
Вот например мои тесты:
WinRAR
Armv7 Neon (2012) 2c/2t 1GHz 300kb/s
Intel HT (2005) 1c/2t 3GHz 300kb/s
Amd APU (2012) 2c/4t 4GHz 3000kb/s
Amd Ryzen 7 (2020) 8c/16t 5GHz 32000kb/s (3300kb/s single thread)
Все первые тесты в многопотоке были. Рост за 15 лет впечатляет, 2 порядка.
Половина современного ядра по вычислительной мощности превосходит совокупно все ядра прошлых поколений, работающие вместе.
Если правильно понял, такой конфиг принимает соединения точечно, для всех остальных сервак остается безмолвным черным ящиком, который нет смысла атаковать. Шикарное решение.
Нет, в течении десяти лет такое недостижимо.
Да, работа с ast-деревом доступна уже сейчас. Сейчас большое количество софта именно на этом уровне с кодом и работает.
Но на горизонте 10 лет недостижимо даже адекватное понимание этих двух фраз-приказов: в текущем виде нейронки не мыслят, они статичны. А для понимания приказов нужно много работы: перевести в промежуточный язык, выделить сущности и связать их с кодовой базой, сформировать очередность команд, и т.п. Много абстрактной работы с контекстами. Это целый ворох технологий будущего, которых пока просто нет.
Даже у человека дойти до уровня этих приказов займет 3-5 лет.
10 лет - это типичное время развития одной не особо сложной технологии. А не букета сложнейших технологий.
Так это не ИИ, оно само ничего не пишет
Смотря что за SSD. Если смотреть на современные флагманы типа Самсунга, то контроллеры там перемалывают огромные потоки данных (читай - работают с огромными частотами) и хорошо греются, крупные техпроцессы малоприменимы.
Отдельный элемент - прошивка, в которую отлиты секреты, ноу-хау и опыт по практической эксплуатации миллионов изделий прошлых поколений, всё для достижения высокой производительности и долговечности. Это тоже не так просто получить.
А прошивку дополняет сервисный софт: диски же нужно обслуживать, ремонтировать, обновлять прошивку.
Отдельный момент: клиентские утилиты. Они дают преимущество: там где у конкурентов клиент будет недоволен походом в сервисцентр, у того же Самсунга клиент сам обновит прошивку в авторежиме через софт, легко избавившись от возможных багов прошивки. Но эти утилиты должны поддерживаться, должны быть красивы и удобны - считай нужно много ресурсов на софт и поддержку, напрямую к продукту отношения не имеющему.
А ведь ещё есть сеть сервисцентров, документация, оборудование...
И это абсолютно не говорим о таких мелочах как маркетинг и реклама, что тоже требует сотни специалистов.
Вот и получается, что чип спроектировать и произвести - это конечно большая работа, но капля в море того, что требуется для успешного выхода на рынок.
Странный способ встречать прогресс с дубиной
Так все это и так в открытом доступе. В чем проблема?
Про контроль выше уже отписались.
Но есть также другой, не менее важный аспект в сфере безопасности: пока страна имеет доступ к внешним поставкам какой-либо технологии, очень сложно, на всех уровнях причем, заставить полностью импортозаместить эту технологию. Всегда кто-то где-то захочет сэкономить, и так или иначе закупит чужое, а это, в случае разрыва внешних поставок, поставит страну в очень уязвимое положение. Так что китайцы сделали правильный вывод из этой ситуации: хочешь что-то своё - сделай это несовместимым с чужим, и тогда всем волей-неволей придется сосредоточиться именно на своем, потому что такое же чужое найти просто невозможно.
Грубо говоря они начинают разработку и производство risc-x, а потом ставят требование, что железо в таких-то областях должно быть исключительно risc-x, и все, заказы пошли, машина заработала: никаких уязвимых технологий снаружи никто импортировать не может физически, risc-x можно заказать только у внутренних поставщиков
Nix кстати на ubuntu пользуюсь, там бывают пакеты, которые сложно найти в других местах.
Экономия места - она за счёт сжатия. Отсюда быстрая установка и обновление, но медленный старт и работа. И по-моему основное - это как раз работа.
Мы берём современные nvme не для того, чтобы экономить место, а чтобы софт максимально быстро работал с файлами. И с этой точки зрения сжатие - не самая умная идея: оно тормозит работу с ФС, и дополнительно нагружает процессор.
На HDD сжатие имело смысл - там шины были узкие, процессор простаивал, выгоднее было нагрузить процессор и разгрузить шины. Но на nvme, ИМХО, доступ к тысячам файлов, он быстрее будет напрямую.
От тысяч файлов никуда не уйти - IDE так или иначе с ними работает. Просто в одном случае она один раз чуть дольше устанавливается, зато быстро может обращаться к файлам в любой момент, а в другом случае она чуть быстрее устанавливается, зато дополнительно тормозит и при запуске и при обращении к файлам, потому что вынуждена продираться через дополнительные слои распаковки.
К тому же нативно для IDE ещё и работает родной toolbox, через который проходит синхронизация, обновления, управление интеграцией в систему, очистка временных файлов, и там же небольшой аналог машины времени встроен: если новая версия не зашла, можно за секунду откатиться к предыдущей, гарантировано рабочей версии IDE. Не думаю что все это будет корректно работать со snap.
Ты не учитываешь, что программист ни за что не отвечает, потому что ему никто этой ответственности не даёт - всё решают за него, и до него, ответственность у вышестоящих лиц, сам он лишь мелкий винтик в современной индустрии. Ему дают задачу и время, и главное - уложиться в отведенный срок, а результат не особо важен.
Собственно это последствия мира команд и менеджмента.
Одиночка имеет больше ответственности, более целеустремлён, имеет контроль над кодом. В командах ответственность размазывается, контроль удержать сложно, как итог в код начинает проникать мусор и ошибки, и ресурсов этого избежать часто нет. Особенно плохо, если в команде есть слабые коллеги: за них их часть работы никто не сделает, ресурсов на это не дают, а их код ужасен, но так навсегда в проекте и останется, будет кое-как работать, порождать сотни ошибок.
С учётом того что современная разработка построена на максимальной экономии и руководит процессом менеджер, который в этом ничего не понимает, приходим к фичегонке: оказывается для проекта важнее наклепать тысячу ненужных фич, чем остановиться и привести в порядок хотя бы одну из уже сделанных. Та же ситуация с техдолгом и качеством кода: на это никогда нет времени, вечное завтра.
Вот и получается, что на выходе у одиночки компактный рабочий код - он его сам писал, один, сам за все в ответе, сам все проверил, и результат прямо соответствует ему опыту: у новичков он плохой, у опытных хороший.
А на выходе у компании - урод, внутрь которого лучше не заглядывать: раздутая смесь из грязного кода, ошибок и костылей, которая каким-то чудом но частично работает. Там тысячи фич, но работает из них лишь часть, и работает не особо хорошо.
Особенно таким грешат крупные компании, где софт для галочки: его просто нужно выпустить, а как - не важно. Менеджер на менеджере сидит и менеджером погоняет, важны только отчёты и расходы, а главное, сам результат, никого не интересует.
Чтобы результат был хорош, нужно давать разработчикам свободу. А это в основном некоторые продуктовые компании, которые сосредоточены на результате, где можно взять и пилить одну фичу до тех пор, пока она действительно не будет готова, или где если заметил ошибку или неоптимальный алгоритм, ты можешь его взять и поправить.
Так то да, но все же стремиться к этому стоит. В первую очередь такое полезно для себя любимого.
Например если ты не зациклен на одном языке - у тебя больше возможностей для поиска работы, выше мобильность. Это касается кстати не только языков программирования, но и человеческих - некоторые рынки требуют своих специфичных языков.
С другой стороны распыляться тоже нехорошо - все имеет свою цену: за одно и тоже время ты освоишь хорошо один язык или средне два.
На начальном этапе это будет тормозить развитие и нежелательно. Но после - почему бы и нет?
Начинается такое обычно для себя, из интереса - пощупать новое. Потом постепенно твои возможности растут, и становится доступна миграция между языками, можешь +/- эффективно что-то делать и там и там. А там недалеко и до смены сферы на более комфортную или параллельная работа на два лагеря.
Это уже каждый сам решает куда двигаться. Тут важно, что развитие в принципе дает такую возможность, позволяет не застаиваться в своем болоте.
С ЯП низкого уровня согласен - знать нужно, не обязательно хорошо, но пощупать стоит, и желательно вглубь: "Code: The Hidden Language of Computer Hardware and Software" дает неплохую базу, как и старые советские детские книжки времен dos. Ну а если удалось "пощупать" cpu изнутри, например писали что-то под микроконтроллеры - это вообще замечательно: многие из "железных" проблем и абстракций становятся ближе и понятнее, как и уникальные возможности, которые на уровне прикладного софта просто недоступны.
Понимание ООП+ФП тоже нужно. В новых курсах некоторые уже начинают сразу оба подхода параллельно давать: где-то применим один, где-то другой. А заодно рассказывают и о других, уже устаревших, подходах - для целостной картины мира.
Все это начинает играть где-то со 2-3 года опыта, когда рефакторинг выходит на значимое место.
Что касается остального - оно часто опционально, и зависит от области деятельности. Многие могут за всю практику так никогда и не столкнуться с тем же html. У каждого на рынке сейчас своя специализация: то-то пишет драйвера, кто-то прошивки, кто-то сайты, кто-то приложения, а кто-то вообще какие-нибудь внутренние модули абстрактной большой системы, которые никакого интерфейса наружу вообще в принципе не имеют.
Там, где нужна интерфейсная часть, везде своя специфика: где-то достаточно cli, где-то требуется gui, ну а где-то web-интерфейс или какое-либо апи.
По БД тоже самое - кто-то хранит данные в текстовых файлах, кто-то пользуется sqlite, кто-то взрослыми СУБД, кто-то работает через апи другой системы, кто-то даже в памяти все хранит (и, что странно, вполне успешно - недавно такая статья тут уже была), а кто-то вообще ничего не хранит. Отсюда и соответствующие потребности.
Но в целом SQL хотя бы в общем виде знать нужно - это наиболее распространенное решение для хранения данных. Хотя бы на уровне "не пугаться незнакомых слов". Как минимум это поможет сэкономить силы и время, когда и если потребность в БД придет - тот же sqlite можно куда угодно подпихнуть при необходимости, готовое и доступное решение в любом случае лучше попыток изобрести что-то свое.
А что касается web-интерфейсов - основы html еще можно по-быстрому освоить, а вот углубляться в верстку и фронт думаю не стоит, это отдельная большая область знаний, ее лучше оставить соответствующим специалистам. Эта область слишком динамичная, без постоянной практики не удержаться. Ради разовой потребности смысла погружаться мало, под разовую задачу лучше найти специалиста конкретно по фронту - будет быстрее и качественнее, чем самому что-то изобретать.
Сейчас такое время, когда важно даже не столько что-то уметь, сколько знать о существовании какой-либо возможности или технологии. Такие знания расширяют твой инструментальный набор: если ты слышал о какой-либо технологии, у тебя уже больше возможностей, чем у того, кто о ней не слышал - если потребуется, найти документацию и освоить технологию всегда можно, а вот заранее узнать что такое вообще в принципе существует и возможно - это уже не так просто, нужно постоянно расширять профессиональный кругозор. Те, кто не слышал про технологию, вынуждены будут изобретать свой велосипед, фактически делающий тоже самое, но хуже, к тому же еще и дольше/сложнее/дороже, чем воспользоваться готовым.
Знавал таких Серёжей.
Как-то на время подключили на один маленький проект, который единолично вел такой вот Сережа.
Первое что насторожило - подход Серёжи: по любой мелочи часовой созвон, на котором всячески изображается готовность помочь, но в итоге просто по нескольку раз повторяется то что ты скажешь, и по сути ничего обсудить не удается. Человек изображает бурную деятельность, и клиентам это нравится, но по факту впустую тратит время. От практики созвонов с Серёжей естественно пришлось отказаться, ввиду их абсолютной неэффективности.
Второе что привлекло внимание - отсутствие автозагрузки классов на проекте: обычно это означает что идёт жёсткая борьба за быстродействие. Но код проекта как-то не показывал, что стремится быть быстрым - кеширование почти не используется, море говнокода и лишней работы в коде, все тормозит. В коде настолько много лишнего, что после рефакторинга в своей небольшой зоне ответственности код сокращался в разы, почти полностью заменяясь библиотечным функционалом, и наконец то становился более-менее понятен с первого взгляда. Стал разбираться как же так вышло, что за несколько лет жизни проект не обзавелся автозагрузкой - это же 15 минут работы, элементарный функционал. В итоге нашел: задача на оптимизацию проекта была, пару лет назад, там в том числе затрагивался вопрос автозагрузки, но Сережа просто не понял что от него хотят, и в итоге все эти годы тщательно складывал каждый новый класс в огромную таблицу статической загрузки классов. Терпение конечно впечатляющее у человека, но это сизифов труд.
И вот примерно в таком стиле был построен весь проект. Но опыт был интересным, конечно: как в кунсткамеру сходил - столько необычных решений и абсурда редко где встретишь.
Такие идеи о "своем детище" на практике быстро разваливаются, т.к. точка зрения на развитие продукта у бизнеса и техлида отличаются, и решение не за техлидом, и в данной ситуации каждый считает продукт "своим детищем" и тянет одеяло на себя. В такой ситуации у техлида получается позиция "прокладки", номинального управляющего - он отвечает за техническую часть и желает ее максимально улучшить, но фактически никаких реальных полномочий на это повлиять не имеет, желания диктует исключительно бизнес, потому что бизнес все и оплачивает.
Роль техлида - наилучшим образом удовлетворить потребности бизнеса с помощью своей технической экспертизы. И с этой точки зрения это просто рутинная должность: переводить требования с языка бизнеса на язык технологий. Придумать как наилучшим образом реализовать запрошенное, с учётом потребностей бизнеса по стоимости, времени и функционалу - требуется найти некий компромисс, чтобы решение было функционально и финансово доступно, и в тоже время не ломало существующие процессы и было поддерживаемо.
Понимание базовых истин и принципов приходит с опытом, через боль и страдания.
Новичкам естественно проще и понятнее более простая процедурная архитектура - они ещё не сталкивались с отладкой чего-то сложнее калькулятора и неуловимыми ошибками. Донести до них опыт можно, но вот понять его многие из них не смогут, только запомнить. Исключения - те, кто сталкивались с чем-то похожим на прошлом опыте.
Когда человек убьет день на глупый досадный баг, который можно было бы легко избежать, следуя очевидным истинам и простым принципам, он постарается в будущем не повторять такой ошибки.
В идеале такое надо сразу вносить в программу обучения, чтобы сразу на личном опыте новички ощутили не только плюсы, но и минусы того или иного подхода.
К сожалению в большинстве случаев этого не делается, возможно из соображений упрощения и снижения нагрузки: если новичкам с первых шагов расставлять грабли, путь сможет пройти меньше людей, тех кто сдался поприбавится. Как минимум той модели курсов, что эксплуатируется сейчас, выгодна именно массовость, а не качество.
В любом случае, по наблюдениям, первые 6-18 месяцев человек упорно пытается придерживаться процедурного подхода, генерируя страшный код. Потом обычно начинается прогресс - начинает приходить понимание, накапливается опыт. Но не у всех, к сожалению.
Серьезный бустер тут - обмен опытом с более опытными коллегами: ревью и рефакторинг чужого кода, обсуждения. Что-то постигается самостоятельно, что-то подсматривается в коде более опытных коллег, что-то выносится из обсуждений/проблем, свидетелем или участником которых был. Этого к сожалению типичные курсы тоже не дают - даже если есть группы, они одного уровня.
При этом если человека что-то неустраивает, об этом он не скажет - обратной связи по деструктивной деятельности руководства нет. Поэтому такая глупость вдвойне опасна: недовольство будет только накапливаться, а потом сорвется лавиной и снесет руководителя, нередко вместе с фирмой.
С точки зрения самого человека обратную связь давать нет никакого смысла: ждать положительных изменений в конкретной фирме бессмысленно, если это и будет, то донести их будет тяжело, и займет годы - проще, быстрее и выгоднее просто уйти в другую, еще и с повышением в зарплате. Процессы в фирме либо налажены, либо нет, и налаживать их - задача совсем не линейного рабочего.
Всякие модные анонимные опросники не работают. Кто реально занят работой, не тратят время на очередной бесполезный опросник, хотя их мнение наиболее важно для фирмы, но никак не учитывается. Те кто чем-то недоволен, по большей счасти тоже проигнорирует опросник, из-за опасений что он не совсем анонимный и будут последствия за высказанное недовольство, нередко обоснованные, сам такое уже видел: даже если нет технического способа выяснить отправителя - недовольные руководители с горящей попой устраивают чистки. Ну а кому делать нечего и их все устраивает - именно они и будут проходить опросники, только вот это полностью дискредитирует саму идею: мнение наиболее полезных членов рабочего коллектива, а также мнение наиболее недовольных, никак не охвачено, а значит любые изменения по итогам опроса не будут учитывать эти две категории и положительным образом на них не отразятся. В результате все изменения по итогам результатов опроса сведутся к очередному никому не нужному игровому автомату или чему-то подобному, и ресурсы вроде потрачены, галочка о проведении работе с коллективом проставлена, а результата нет: люди уходят. Эффективность как она есть.
Так что внутри коллектива либо доверие, либо противостояние.