Возможно я нахватаю минусов, но... кажется, что нужность классических книги по программированию уходит в прошлое. Если что - я ещё Фигурнова в своё время покупал.
Потому что DeepSeek, СhatGPT и иже с ними. Рассказать про основные принципы - получается. Уточнить какое-то из понятий - пять секунд, и вполне толковый раздел готов. "Назови причины, по которым может не выполняться тест, над которым @Test" - назвала, и таки одна из них оказалось правдой (умудрился из 4 JUnit аннотацию взять, как - до сих пор понять не могу). Даже на ошибки компилятора можно получить развёрнутое описание.
С классической бумажной книгой так не получается, даже c PDF. Хотя наверно именно для новичка, чтобы получить последовательное связное изложение принципов, и не метаться туда-сюда - да, книга хороша. Особенно с заданиями на самопроверку, в стиле HeadFirst.
Вы будете смеяться... но некоторые автопроизводители уже почти дошли. Подшипник ступицы, обоймой является вся ступица. С соответствующим ценником на замену. Я уж не говорю про вариатор, где коробление пластиковой основы одного клапана управления в горячем масле приводит к нерасчётным режимам и прогрессирующему износу узла. Сайлент-блоки, меняющиеся только в сборе с рычагами. Ну и т.д. и т.п. В советское время это назвалось "вредительство", а теперь "запрограммированный износ". Когда инженеры хорошие - выходит из строя аккуратно в пределах +5% от гарантийного срока :)
Гм. Я бы назвал статью Junior of IntelliJ IDEA :) И вот почему:
Первое, что нужно сделать, после того как открыл IDEA - зайти в Help / Keyboard Shortcuts PDF. Распечатать, повесить на стенку и учить наизусть. Там всё, что приведено в статье, и ещё много интересного :)
Собственно второе, что нужно сделать - это отключить долбанное дефолтное переназначение F-кнопок на клавиатуре ноута со всяких "Открыть браузер", "Уменьшить громкость" и прочие "Почесать спинку" на нормальные F-xx и убрать руку от мышки. При профессиональной работе она нужна очень редко - либо потыкать в интерфейс, для которого нет shortcuts (ну как нет: значит просто лень настроить) либо повыделять что-то блоком на экране, т.е. тот самый мультикурсор. Главное меню тоже по shortcuts надо звать - Alt-H, K - и вот на экране тот самый PDF из предыдущего абзаца. Честно говоря, у меня есть круг задач, которые я стабильно делаю мышкой, но обычно они связаны с навигацией в каком-то из tool windows. Видимо просто лень придумывать shortcut-ы, они у меня кажется кончились, приходится делать многоуровневые. Мечтаю о клавиатуре с F12 - F24 или педали для переключения слоёв. Рояль не предлагать :)
Следующее, с чем надо разобраться и начать использовать - это Live Templates (File | Settings | Editor | Live Templates). Похоже на Postfix completion, плюс: определение переменных уровня шаблона и контекста, в котором шаблон доступен. С его использованием становится не нужным например file templates: определяешь новый live template и вставляешь в пустой файл (Alt+1, Alt+Ins) по мере необходимости.
Вот мой любимый (самодельный), лень каждый раз это всё печатать руками, вызывается по pat + Tab (PArametrized Test):
После применения аккуратно правишь аргументы в парадигме - подали на вход - ожидаем результат и соответственно параметры метода на 11 строке, и вот он - параметризованный тест во всей красе. Минуc размножение тестов copy-paste, что обычно и происходит.
Стоит поковырять VM оptions, дефолтные настройки это очень, очень мало. У нас были случаи креша с порчей открытых файлов. На 6GB получается держать пару открытых проектов среднего размера. Если у вас "альтернативно импортированное" решение - то файлик, в котором нужно править опции - он не тот, который в документации, он другой.
Постарайтесь не использовать local history и shelve как основное хранилище изменений. Оно блин ЛОКАЛЬНОЕ. И прекрасно дохнет вместе с локальным винтом, чисткой кешей, переустановкой и ещё по тысяче причин. Git наше всё, тем более, что его поддержка близка к идеальной (но сравнивать два документа Word или PowerPoint, или отрисовать дерево веток как TortoiseGIt - не умеет). При правильном разведении веток - все мысли и идеи хранятся там, особенно если не стесняться писать многострочные пояснения к коммитам - что сделано, что не сделано, что падает и как и про что ещё нужно не забыть. WIP - коммит (Work In Progress) в локальную ветку после завершения каждого "логического блока" (30 минут - два часа работы, не больше) - это нормально. Всё равно потом будет squash и все душевные метания пропадут.. Зато возвращаешься к ветке через две недели, читаешь собственную историю и вспоминаешь, что имелось в виду. Но это уже не про IDEA, это про процесс разработки.
Обязательно надо настраивать цветовую схему редактора кода. Дефолтная - мягко говоря не раскрывает всех возможностей среды по идентификации элементов, но тут целую статью надо писать.
На первый взгляд выглядит попугаисто, но каждый цвет показывает на тип элемента:
Пример цветовой схемы
белый - метод класса;
голубой - абстрактный метод
сиреневый - статический метод или интерфейс;
синий - класс;
зелёный - параметр;
салатовый - локальная переменная read-only;
желто-зелёный - параметр, захваченный из контекста;
Кстати - если у вас не слишком хорошо со зрением, то штатный шрифт среды разработки можно и нужно увеличить: у меня актуальный фаворит для самой IDEA Inter 15, для кода - Noto Sans Mono те же 15. Время от времени надоедают, меняю на аналоги из Google Fonts.
Главное меню пункты Code и Refactoring. Нужно протыкать каждый и понять, зачем он нужен и что делает. Избавляет от тысяч ручных правок файлов и экономит время. Но опять же - мышкой туда не набегаешься, поэтому учим клавиатурные комбинации. Мои фавориты - ну кроме очевидных рефакторингов, Extract/Introduce и Inline - Inspect Code, Analyze Data Flow from Here / to Here.
Кажется, комментарий начинает превращаться в статью. Поэтому заканчиваю на каждодневных Call Hierarchy (Сtrl-Alt-H под Windows) и просто Hierarchy (Ctrl-H), первое работает на сигнатуре метода, второе - где угодно в коде (и тогда показывает про текущий класс / интерфейс, или на конкретном типе - тогда рассказывает про него.
Не всех и не всегда :) Как не было возможности заполнить FK-столбец, выбрав из dropdown значение, так и нет. Я уж не говорю про то, чтобы дать возможность выбрать значение, когда WHERE пишешь.
SQL Workbench/J разумется, (недоступен из РФ). НА DG переходил с трудом, хотя возможность поработать с SQL из любого места, включая markdown и asciidoc - бесценна.
В SQLWB/J интересен не столько сам клиент, сколько его расширения Wbxxx, коим посвящена добрая треть руководства на 200+ страниц. Задачи получается решать... весьма специфические.
Местами это настолько отвратительно, что даже прекрасно :)
С челвеком-концом, когда он product owner или лид в той же кепке есть две проблемы:
а) иногда контекст перестаёт лезть в голову. И мало кто в таких случаях начинает его делить на куски. Потому что "и так понятно как делать" и что нужно получить в итоге. А это не работает для 80% коллег, только если рядом в команде не такие же сидят, и вы не обзавелись общим позитронным полем.
б) bus factor, который в такой схеме равен 1.
По остальным пунктам пройдусь:
То, что какой-то мудрец сделал статусную модель в IDEF0 - ну добра ему. За такую диаграмму надо убивать конечно. Но и управляемости без формального процесса фиг достигнешь, особенно с человеком "ну-я-делаю", который за 32 списанных рабочих часа не сделал ни одного коммита. И не отладкой занимался, вполне себе пилил фичу по разжёванной постановке. Но не пришёл вовремя сказать, что аналитик накосячил, и две части постановки противоречат друг другу.
О да. Логи, логи ещё не забудьте засунуть внутрь контейнера и прикрутить к ним кибану-логстеш-херню на верёвочке, чтобы не дай Бог кто-нибудь бы не пошёл грепать и не обнаружил проблему быстро. Особенно доставляет, когда контейнер виснет и не пишет вообще ничего. Happy Debug! А! забыл. Конфиги туда же, которые куда-то там запечены и перезаписывают тобой же сделанные изменения, ну чтобы нельзя было поправить, перезапустить и посмотреть, как там оно.
Хрен вам, а не push в devel. Да и MR не спасают иногда. Тут матом не ругаются. но очень хочется. Подход "да, я запушил херню которая O(n^2), и что?" потом неприятно удивляет на проде. Потому что тестеры, ****, тоже проверяли на таблице из пяти записей. Но если у вас общее позитронное поле - то ускоряет разработку 10x.
Если человек-конец олимпиадник и ёмкости мозга хватает - то да, тесты нафиг не нужны. А вот если заказчик намутил процесс с семью вариантами начала (передаю привет банковским продуктологам) и восьмью - конца, то без 56 тестов (ладно, шучу, достаточно 15 основных и ещё двух для случая, когда одна или две из семи перпендикулярных красных линий прозрачные) хрен убедишься, что вообще код обрабатывает все варианты. Я ещё и покрытие смотрю на чтении MR, а иногда и мутационное тестирование запускаю. Но я токсичный мудак, судя по реакции некоторых коллег на замечания к коду.
Плюс итерационности - когда вы понимаете, что сделать нужный функционал в указанное время не получается. Но надо, ибо бигбоссы уже что-то кому-то пообещали. Тогда сначала мы делаем, чтобы работал один хардкодед вариант из четырёх, на следующей итерации прикручиваем все четыре (выкидывая первый), а если доживём - редактор, который позволит аналитику на стороне клиента нафигачить ещё тридцать четыре.
Добавлю: если по результатам совещания не родилась задача / письма / статья в KB - оно вам нафиг было не нужно. И не говорите мне про "мы обсудили и разобрались". Всегда найдётся человек [1..*] из присутствующих, который понял не так и взялся с энтузиазмом делать, и ещё один, которому надо, но он не был на совещании, и нужно всё рассказывать заново.
И последнее. " - Дайте мне автомат Калашникова и магазин патронов, и я сделаю мир лучше. - Но ведь магазина не хватит. - Я и не говорю, что сделаю мир совершенным. Но он станет лучше"
Не могу. Ибо не HR. Да и по CMM мы болтались на уровне ~1.5. Обстановка была скорее семейная, что нужно - спрашивай, считаешь нужным - изучай, нужно на недельку уйти в сдачу сессии - предупреди только заранее. ДМС был, кофе-машина и печеньки на кухне :)). Слова onboarding никто не использовал.
Пишу с некоторой горечью: название статьи должно звучать "Почему джуны - это хорошая инвестиция для крупных и известных компаний". А вот если вы пусть и успешная, но маленькая и неизвестная компания - то будете работать фабрикой джунов для большой. Пробовали, знаем. Крайний случай - после чего стали с большой осторожностью подходить к - наняли двух джунов, под окончание института. Реально толковые парни. Повозились, поменторили, через пол-года они даже начали писать приемлемый код за предсказуемое время. И ушли. То ли в Яндекс, то ли в Сбер - тот как раз пылесосил рынок. Не помню уже.
Я вот реально не понимаю, как обеспечивать при такой конкуренции "лояльность". Внутри наверно там вообще - одна зарплата привлечённого по прохождении им испытательного.
Если задолбали кнопки и хочется поделать что-то руками - то станочные профессии. Токарь, фрезеровщик. Денег там (пока что) много. И даже можно попрограммировать, в G-code. Правда там не Exception в лог прилетит если что, а болванкой на сто килограмм в голову :)
Считают, только немножко по другому. Есть паттерн такой - если долго и уверенно транслировать любую дичь из каждого утюга и проводить политику, что все остальные с этим согласны и воспринимают как должное, то даже трезвомыслящий индивидуум начинает сомневаться в своей картинке мира. Ибо животные мы стадные, в своё время от этого зависело выживание.
Попробую посмотреть в зеркальный шар: by default хороший инженер != хороший руководитель. Просто нервная организация неподходящая: была бы подходящей, ещё в институте бы пошел по руководящему профилю. И не стал бы хорошим инженером. Нужна просто генетическая любовь к поруководить, организовать и всё такое. Плюс известный пофигизм в части реальных результатов: не важно, что сделано, важно что считает по этому поводу Большое Начальство.
А хороший инженер, ставший руководителем, он органически так не может. Он за результат, и чтобы оно реально работало. Он ночью садится доделывать. За весь отдел, ага. Сотрудники тем временем потихоньку расслабляются и садятся на шею: "ну максимум меня поругают на планёрке, ну сдам ещё раз эту же недоделку / забью на профилактику / потом как нибудь сделаю backup и будет норм. Пока же всё норм? Зарплату платят. Значит да".
Закономерный результат: руководитель несколько раз огребает сверху, пару (десятков) раз работает по четырнадцать часов на предмет закрыть косяки, потом начинает подозревать, что единственный способ не свихнуться - это ожидать от подчинённых ответственности и исполнительности. на уровне пятого класса школы. Ещё один шаг в разрушении картинки мира: мы же все инженеры! Как же так? Плюс отсутствие признания заслуг, с обеих сторон взаимодействия. Плюс необходимость участия в аппаратных играх. Плюс ещё много чего...
конкурсный управляющий подал иск об аннулировании выплат зарплат и соцпомощи бывшим сотрудникам.
Интересно то как... То есть работаешь ты официально в российской компании X с 2019 года, получаешь зарплату пять лет, налоги платишь, ипотеку взял, продукты вот каждый день покупаешь, куртку опять же к зиме. А потом раз - большие дяди и тёти поссорились, и ты резко должен родному государству пять годовых окладов? Которые взять разумеется неоткуда. И? Суд, имущество с молотка, банк отнял квартиру, детей в детский дом?
Что-то жёстко про артефакты ушедшей цивилизации. Многие вещи объясняются куда как более прозаичными экономическими причинами. В СССР правда ещё и помноженными на некоторый идиотизм, но всё таки.
Возьмём тот же сверхзвук, от которого отказались все, кроме военных. Лепили ли 144 с Конкорда, или всё-таки аэродинамика одинаковая для всех - сейчас не так уж и важно. Потенции сделать хватило у обоих лагерей (а это и расчёты, и проектирование, и материаловедение и... много чего ещё). Но. Топлива оно жрало как не в себя, пассажировместимость - небольшая (у них - относительно в то же время появившегося 747), дальность - ограничена (тут у нас эпичный отрицательный прирост дальности относительно ТЗ), итого у нас - дотационные рейсы и то в единственный город, у них - ценник не для среднего пассажира.
Дальше сценарии чуть расходятся - у нас вроде как довели до бесфорсажного сверзвука, надёжность наработать не успели, после чего проект закрыли росчерком пера. Ну и как водится - все заделы уничтожили, т.е. открыть росчерком пера не получилось бы ещё тогда, нужно всё собирать заново.
У них - долетали до первой катастрофы, а там и экологи подтянулись, и общественность, которой шумно. Как я подозреваю - окончательно добило это всё IT, отпала необходимость за три часа добираться до другого конца земли на предмет провести переговоры, и электронная почта стала за секунды ходить.
Что характерно - вояки до сих пор летают, а даже коммерческого сверхзвукового бизнес-джета нет. Значит - не нужно, т.е. слишком дорого получается.
С космосом рассуждения примерно такие же: шаттлы сделали и тут, и там.
Там: Оказалось, это получился не орбитальный самолёт, который сел, провели общий осмотр, заправили жидкостями и твёрдостями и пристегнули к следующему топливному баку, а достаточно сложная штука, которую между стартами нужно частично пересобирать. Ну и надёжность не очень, да. А задач по спуску чего-то крупного с орбиты на предмет починить на земле и отвезти на место - не так и много. Так что на одноразовых Союзах летать оказалось и дешевле, и безопаснее. А у Маска ещё и дешевле получилось, с учётом переиспользования.
Тут: Энергия - это полноценная ракета. Которая выкидывалась (сгорала) полностью при каждом запуске. И ценник относительно Союза там... большой. А задач, под которые нужна была бы функциональность возврата с орбиты чего-то большого - не оказалось. Хотя может быть они и были, денег на космос никто не считал, но тут неожиданно кончился СССР.
А дальше и там, и тут начала работать такая интересная штука, как "потеря общего знания". Т.е. если что-то перестать делать, то постепенно уходят люди, которые в этом разбирались, и, хорошо, если не уничтожена документация (про спецстанки, стенды и прочую оснастку и не говорю). Теперь домножим это на все звенья цепочек поставки. А новое поколение инженеров зачастую неспособно по документации восстановить производство - просто потому, что очевидные вещи никто не документирует (иначе документация станет совершенно нечитаемого объёма), а они становятся неочевидными спустя лет двадцать. Меняются стандарты индустрии, методики преподавания, стандарты безопасности и ещё 100500 вещей, неявным образом влияющих на производство. И, например, смежников, поставлявших кабель по стандарту A-B-123456-C-D уже давно нет в природе. Так что построить Сатурн 5 в США сейчас тоже нельзя. Не потому что нет инженеров - Старшип то построили. А потому что там всё - другое и по другим стандартам. А чтобы заменить на современное - R&D в не меньшем объёме нужно, а зачем?
Только не пытайтесь чрез него смотреть экраны. Особенно вёрстку. Это днище просто: 1) нет увеличения / уменьшения; 2) дикое мыло и артефакты сжатия; 3) это блин поделие само накладывает линейные градиенты сверху и снизу экрана, и ты видишь ни разу не то, что тебе показывает дизайнер
Возможно я нахватаю минусов, но... кажется, что нужность классических книги по программированию уходит в прошлое. Если что - я ещё Фигурнова в своё время покупал.
Потому что DeepSeek, СhatGPT и иже с ними. Рассказать про основные принципы - получается. Уточнить какое-то из понятий - пять секунд, и вполне толковый раздел готов. "Назови причины, по которым может не выполняться тест, над которым
@Test" - назвала, и таки одна из них оказалось правдой (умудрился из 4 JUnit аннотацию взять, как - до сих пор понять не могу). Даже на ошибки компилятора можно получить развёрнутое описание.С классической бумажной книгой так не получается, даже c PDF. Хотя наверно именно для новичка, чтобы получить последовательное связное изложение принципов, и не метаться туда-сюда - да, книга хороша. Особенно с заданиями на самопроверку, в стиле HeadFirst.
Вы будете смеяться... но некоторые автопроизводители уже почти дошли. Подшипник ступицы, обоймой является вся ступица. С соответствующим ценником на замену. Я уж не говорю про вариатор, где коробление пластиковой основы одного клапана управления в горячем масле приводит к нерасчётным режимам и прогрессирующему износу узла. Сайлент-блоки, меняющиеся только в сборе с рычагами. Ну и т.д. и т.п. В советское время это назвалось "вредительство", а теперь "запрограммированный износ". Когда инженеры хорошие - выходит из строя аккуратно в пределах +5% от гарантийного срока :)
Посмотрите где там наш любимый Spring. https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22&l=zik0vz-cn3 Возможно Вы сочтёте, что нужно выбрать другой вид нагрузки (тест), но в любом случае, Spring, при всех его достоинствах - не лидер в производительности.
Гм. Я бы назвал статью Junior of IntelliJ IDEA :) И вот почему:
Первое, что нужно сделать, после того как открыл IDEA - зайти в Help / Keyboard Shortcuts PDF. Распечатать, повесить на стенку и учить наизусть. Там всё, что приведено в статье, и ещё много интересного :)
Собственно второе, что нужно сделать - это отключить долбанное дефолтное переназначение F-кнопок на клавиатуре ноута со всяких "Открыть браузер", "Уменьшить громкость" и прочие "Почесать спинку" на нормальные F-xx и убрать руку от мышки. При профессиональной работе она нужна очень редко - либо потыкать в интерфейс, для которого нет shortcuts (ну как нет: значит просто лень настроить) либо повыделять что-то блоком на экране, т.е. тот самый мультикурсор. Главное меню тоже по shortcuts надо звать - Alt-H, K - и вот на экране тот самый PDF из предыдущего абзаца. Честно говоря, у меня есть круг задач, которые я стабильно делаю мышкой, но обычно они связаны с навигацией в каком-то из tool windows. Видимо просто лень придумывать shortcut-ы, они у меня кажется кончились, приходится делать многоуровневые. Мечтаю о клавиатуре с F12 - F24 или педали для переключения слоёв. Рояль не предлагать :)
Следующее, с чем надо разобраться и начать использовать - это Live Templates (File | Settings | Editor | Live Templates). Похоже на Postfix completion, плюс: определение переменных уровня шаблона и контекста, в котором шаблон доступен. С его использованием становится не нужным например file templates: определяешь новый live template и вставляешь в пустой файл (Alt+1, Alt+Ins) по мере необходимости.
Вот мой любимый (самодельный), лень каждый раз это всё печатать руками, вызывается по
pat+ Tab (PArametrized Test):После применения аккуратно правишь аргументы в парадигме - подали на вход - ожидаем результат и соответственно параметры метода на 11 строке, и вот он - параметризованный тест во всей красе. Минуc размножение тестов copy-paste, что обычно и происходит.
Стоит поковырять VM оptions, дефолтные настройки это очень, очень мало. У нас были случаи креша с порчей открытых файлов. На 6GB получается держать пару открытых проектов среднего размера. Если у вас "альтернативно импортированное" решение - то файлик, в котором нужно править опции - он не тот, который в документации, он другой.
Постарайтесь не использовать local history и shelve как основное хранилище изменений. Оно блин ЛОКАЛЬНОЕ. И прекрасно дохнет вместе с локальным винтом, чисткой кешей, переустановкой и ещё по тысяче причин. Git наше всё, тем более, что его поддержка близка к идеальной (но сравнивать два документа Word или PowerPoint, или отрисовать дерево веток как TortoiseGIt - не умеет). При правильном разведении веток - все мысли и идеи хранятся там, особенно если не стесняться писать многострочные пояснения к коммитам - что сделано, что не сделано, что падает и как и про что ещё нужно не забыть. WIP - коммит (Work In Progress) в локальную ветку после завершения каждого "логического блока" (30 минут - два часа работы, не больше) - это нормально. Всё равно потом будет squash и все душевные метания пропадут.. Зато возвращаешься к ветке через две недели, читаешь собственную историю и вспоминаешь, что имелось в виду. Но это уже не про IDEA, это про процесс разработки.
Обязательно надо настраивать цветовую схему редактора кода. Дефолтная - мягко говоря не раскрывает всех возможностей среды по идентификации элементов, но тут целую статью надо писать.
На первый взгляд выглядит попугаисто, но каждый цвет показывает на тип элемента:
белый - метод класса;
голубой - абстрактный метод
сиреневый - статический метод или интерфейс;
синий - класс;
зелёный - параметр;
салатовый - локальная переменная read-only;
желто-зелёный - параметр, захваченный из контекста;
Кстати - если у вас не слишком хорошо со зрением, то штатный шрифт среды разработки можно и нужно увеличить: у меня актуальный фаворит для самой IDEA Inter 15, для кода - Noto Sans Mono те же 15. Время от времени надоедают, меняю на аналоги из Google Fonts.
Главное меню пункты Code и Refactoring. Нужно протыкать каждый и понять, зачем он нужен и что делает. Избавляет от тысяч ручных правок файлов и экономит время. Но опять же - мышкой туда не набегаешься, поэтому учим клавиатурные комбинации. Мои фавориты - ну кроме очевидных рефакторингов, Extract/Introduce и Inline - Inspect Code, Analyze Data Flow from Here / to Here.
Кажется, комментарий начинает превращаться в статью. Поэтому заканчиваю на каждодневных Call Hierarchy (Сtrl-Alt-H под Windows) и просто Hierarchy (Ctrl-H), первое работает на сигнатуре метода, второе - где угодно в коде (и тогда показывает про текущий класс / интерфейс, или на конкретном типе - тогда рассказывает про него.
Удачи!
Не всех и не всегда :) Как не было возможности заполнить FK-столбец, выбрав из dropdown значение, так и нет. Я уж не говорю про то, чтобы дать возможность выбрать значение, когда WHERE пишешь.
SQL Workbench/J разумется, (недоступен из РФ). НА DG переходил с трудом, хотя возможность поработать с SQL из любого места, включая markdown и asciidoc - бесценна.
В SQLWB/J интересен не столько сам клиент, сколько его расширения Wbxxx, коим посвящена добрая треть руководства на 200+ страниц. Задачи получается решать... весьма специфические.
У нас в Java есть for(;;). Правда крайний раз на MR меня попросили так не писать :)
Я правильно понял, что задачи уровня "перевернуть строку штатными средствами языка" - теперь джуну предлагать моветон? Это уровень мидл+ ?
Не будьте столь категоричны. Есть метод триграмм, есть фонетические алгоритмы
Ну...это должна была бы быть столбиковая диаграмма. Как проценты вообще можно считать при мультиголосовании ?
Хабр прекрасен. Сделано программистами для программистов.
Местами это настолько отвратительно, что даже прекрасно :)
С челвеком-концом, когда он product owner или лид в той же кепке есть две проблемы:
а) иногда контекст перестаёт лезть в голову. И мало кто в таких случаях начинает его делить на куски. Потому что "и так понятно как делать" и что нужно получить в итоге. А это не работает для 80% коллег, только если рядом в команде не такие же сидят, и вы не обзавелись общим позитронным полем.
б) bus factor, который в такой схеме равен 1.
По остальным пунктам пройдусь:
То, что какой-то мудрец сделал статусную модель в IDEF0 - ну добра ему. За такую диаграмму надо убивать конечно. Но и управляемости без формального процесса фиг достигнешь, особенно с человеком "ну-я-делаю", который за 32 списанных рабочих часа не сделал ни одного коммита. И не отладкой занимался, вполне себе пилил фичу по разжёванной постановке. Но не пришёл вовремя сказать, что аналитик накосячил, и две части постановки противоречат друг другу.
О да. Логи, логи ещё не забудьте засунуть внутрь контейнера и прикрутить к ним кибану-логстеш-херню на верёвочке, чтобы не дай Бог кто-нибудь бы не пошёл грепать и не обнаружил проблему быстро. Особенно доставляет, когда контейнер виснет и не пишет вообще ничего. Happy Debug! А! забыл. Конфиги туда же, которые куда-то там запечены и перезаписывают тобой же сделанные изменения, ну чтобы нельзя было поправить, перезапустить и посмотреть, как там оно.
Хрен вам, а не push в devel. Да и MR не спасают иногда. Тут матом не ругаются. но очень хочется. Подход "да, я запушил херню которая O(n^2), и что?" потом неприятно удивляет на проде. Потому что тестеры, ****, тоже проверяли на таблице из пяти записей. Но если у вас общее позитронное поле - то ускоряет разработку 10x.
Если человек-конец олимпиадник и ёмкости мозга хватает - то да, тесты нафиг не нужны. А вот если заказчик намутил процесс с семью вариантами начала (передаю привет банковским продуктологам) и восьмью - конца, то без 56 тестов (ладно, шучу, достаточно 15 основных и ещё двух для случая, когда одна или две из семи перпендикулярных красных линий прозрачные) хрен убедишься, что вообще код обрабатывает все варианты. Я ещё и покрытие смотрю на чтении MR, а иногда и мутационное тестирование запускаю. Но я токсичный мудак, судя по реакции некоторых коллег на замечания к коду.
Плюс итерационности - когда вы понимаете, что сделать нужный функционал в указанное время не получается. Но надо, ибо бигбоссы уже что-то кому-то пообещали. Тогда сначала мы делаем, чтобы работал один хардкодед вариант из четырёх, на следующей итерации прикручиваем все четыре (выкидывая первый), а если доживём - редактор, который позволит аналитику на стороне клиента нафигачить ещё тридцать четыре.
Добавлю: если по результатам совещания не родилась задача / письма / статья в KB - оно вам нафиг было не нужно. И не говорите мне про "мы обсудили и разобрались". Всегда найдётся человек [1..*] из присутствующих, который понял не так и взялся с энтузиазмом делать, и ещё один, которому надо, но он не был на совещании, и нужно всё рассказывать заново.
И последнее. " - Дайте мне автомат Калашникова и магазин патронов, и я сделаю мир лучше. - Но ведь магазина не хватит. - Я и не говорю, что сделаю мир совершенным. Но он станет лучше"
Не могу. Ибо не HR. Да и по CMM мы болтались на уровне ~1.5. Обстановка была скорее семейная, что нужно - спрашивай, считаешь нужным - изучай, нужно на недельку уйти в сдачу сессии - предупреди только заранее. ДМС был, кофе-машина и печеньки на кухне :)). Слова onboarding никто не использовал.
Пишу с некоторой горечью: название статьи должно звучать "Почему джуны - это хорошая инвестиция для крупных и известных компаний". А вот если вы пусть и успешная, но маленькая и неизвестная компания - то будете работать фабрикой джунов для большой. Пробовали, знаем. Крайний случай - после чего стали с большой осторожностью подходить к - наняли двух джунов, под окончание института. Реально толковые парни. Повозились, поменторили, через пол-года они даже начали писать приемлемый код за предсказуемое время. И ушли. То ли в Яндекс, то ли в Сбер - тот как раз пылесосил рынок. Не помню уже.
Я вот реально не понимаю, как обеспечивать при такой конкуренции "лояльность". Внутри наверно там вообще - одна зарплата привлечённого по прохождении им испытательного.
Если задолбали кнопки и хочется поделать что-то руками - то станочные профессии. Токарь, фрезеровщик. Денег там (пока что) много. И даже можно попрограммировать, в G-code. Правда там не Exception в лог прилетит если что, а болванкой на сто килограмм в голову :)
Считают, только немножко по другому. Есть паттерн такой - если долго и уверенно транслировать любую дичь из каждого утюга и проводить политику, что все остальные с этим согласны и воспринимают как должное, то даже трезвомыслящий индивидуум начинает сомневаться в своей картинке мира. Ибо животные мы стадные, в своё время от этого зависело выживание.
Попробую посмотреть в зеркальный шар: by default хороший инженер != хороший руководитель. Просто нервная организация неподходящая: была бы подходящей, ещё в институте бы пошел по руководящему профилю. И не стал бы хорошим инженером. Нужна просто генетическая любовь к поруководить, организовать и всё такое. Плюс известный пофигизм в части реальных результатов: не важно, что сделано, важно что считает по этому поводу Большое Начальство.
А хороший инженер, ставший руководителем, он органически так не может. Он за результат, и чтобы оно реально работало. Он ночью садится доделывать. За весь отдел, ага. Сотрудники тем временем потихоньку расслабляются и садятся на шею: "ну максимум меня поругают на планёрке, ну сдам ещё раз эту же недоделку / забью на профилактику / потом как нибудь сделаю backup и будет норм. Пока же всё норм? Зарплату платят. Значит да".
Закономерный результат: руководитель несколько раз огребает сверху, пару (десятков) раз работает по четырнадцать часов на предмет закрыть косяки, потом начинает подозревать, что единственный способ не свихнуться - это ожидать от подчинённых ответственности и исполнительности. на уровне пятого класса школы. Ещё один шаг в разрушении картинки мира: мы же все инженеры! Как же так? Плюс отсутствие признания заслуг, с обеих сторон взаимодействия. Плюс необходимость участия в аппаратных играх. Плюс ещё много чего...
Интересно то как... То есть работаешь ты официально в российской компании X с 2019 года, получаешь зарплату пять лет, налоги платишь, ипотеку взял, продукты вот каждый день покупаешь, куртку опять же к зиме. А потом раз - большие дяди и тёти поссорились, и ты резко должен родному государству пять годовых окладов? Которые взять разумеется неоткуда. И? Суд, имущество с молотка, банк отнял квартиру, детей в детский дом?
Что-то жёстко про артефакты ушедшей цивилизации. Многие вещи объясняются куда как более прозаичными экономическими причинами. В СССР правда ещё и помноженными на некоторый идиотизм, но всё таки.
Возьмём тот же сверхзвук, от которого отказались все, кроме военных. Лепили ли 144 с Конкорда, или всё-таки аэродинамика одинаковая для всех - сейчас не так уж и важно. Потенции сделать хватило у обоих лагерей (а это и расчёты, и проектирование, и материаловедение и... много чего ещё). Но. Топлива оно жрало как не в себя, пассажировместимость - небольшая (у них - относительно в то же время появившегося 747), дальность - ограничена (тут у нас эпичный отрицательный прирост дальности относительно ТЗ), итого у нас - дотационные рейсы и то в единственный город, у них - ценник не для среднего пассажира.
Дальше сценарии чуть расходятся - у нас вроде как довели до бесфорсажного сверзвука, надёжность наработать не успели, после чего проект закрыли росчерком пера. Ну и как водится - все заделы уничтожили, т.е. открыть росчерком пера не получилось бы ещё тогда, нужно всё собирать заново.
У них - долетали до первой катастрофы, а там и экологи подтянулись, и общественность, которой шумно. Как я подозреваю - окончательно добило это всё IT, отпала необходимость за три часа добираться до другого конца земли на предмет провести переговоры, и электронная почта стала за секунды ходить.
Что характерно - вояки до сих пор летают, а даже коммерческого сверхзвукового бизнес-джета нет. Значит - не нужно, т.е. слишком дорого получается.
С космосом рассуждения примерно такие же: шаттлы сделали и тут, и там.
Там: Оказалось, это получился не орбитальный самолёт, который сел, провели общий осмотр, заправили жидкостями и твёрдостями и пристегнули к следующему топливному баку, а достаточно сложная штука, которую между стартами нужно частично пересобирать. Ну и надёжность не очень, да. А задач по спуску чего-то крупного с орбиты на предмет починить на земле и отвезти на место - не так и много. Так что на одноразовых Союзах летать оказалось и дешевле, и безопаснее. А у Маска ещё и дешевле получилось, с учётом переиспользования.
Тут: Энергия - это полноценная ракета. Которая выкидывалась (сгорала) полностью при каждом запуске. И ценник относительно Союза там... большой. А задач, под которые нужна была бы функциональность возврата с орбиты чего-то большого - не оказалось. Хотя может быть они и были, денег на космос никто не считал, но тут неожиданно кончился СССР.
А дальше и там, и тут начала работать такая интересная штука, как "потеря общего знания". Т.е. если что-то перестать делать, то постепенно уходят люди, которые в этом разбирались, и, хорошо, если не уничтожена документация (про спецстанки, стенды и прочую оснастку и не говорю). Теперь домножим это на все звенья цепочек поставки. А новое поколение инженеров зачастую неспособно по документации восстановить производство - просто потому, что очевидные вещи никто не документирует (иначе документация станет совершенно нечитаемого объёма), а они становятся неочевидными спустя лет двадцать. Меняются стандарты индустрии, методики преподавания, стандарты безопасности и ещё 100500 вещей, неявным образом влияющих на производство. И, например, смежников, поставлявших кабель по стандарту A-B-123456-C-D уже давно нет в природе. Так что построить Сатурн 5 в США сейчас тоже нельзя. Не потому что нет инженеров - Старшип то построили. А потому что там всё - другое и по другим стандартам. А чтобы заменить на современное - R&D в не меньшем объёме нужно, а зачем?
Только не пытайтесь чрез него смотреть экраны. Особенно вёрстку. Это днище просто: 1) нет увеличения / уменьшения; 2) дикое мыло и артефакты сжатия; 3) это блин поделие само накладывает линейные градиенты сверху и снизу экрана, и ты видишь ни разу не то, что тебе показывает дизайнер