Местами это настолько отвратительно, что даже прекрасно :)
С челвеком-концом, когда он 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) это блин поделие само накладывает линейные градиенты сверху и снизу экрана, и ты видишь ни разу не то, что тебе показывает дизайнер
Плагин GitToolbox вообще делает blame автоматически для выделенной строки, помимо всего остального.
А ещё из полезных вещей, которыми почему-то никто не пользуется - Call Hierarchy и Analyze Data Flow to here. Но с первым нужно быть аккуратным и обязательно настроить частный scope на файлы и либы проекта, иначе упёршись в какой-нибудь Thread.run эта штука попытается просканировать весь maven и подвиснет вместе с IDEA
:) Вы не использовали shortcut XYZ 7851 раз. И 7852-й раз не использую, потому что я долго и со вкусом перед эти ковырялся мышкой в run configuration, и кликнуть чуть быстрее, чем опять уходить на клавиатуру
Вынужден отметить, что многие вышеприведённые советы... не вполне эффективны. КМК профессиональный разработчик должен делать всё, что только можно не отрываясь от клавиатуры. Так тупо быстрее, и думать не нужно - только понадобилось, а руки уже сделали. И IDEA это всё поддерживает - достаточно сходить в Help - Keyboard Shortcuts PDF, распечатать, повесить на стену и выучить всё. Тот же Select opened file - под Win Alt-F1 и далее либо Enter сразу, либо куда хочешь... Обратно в окно редактора из дерева проекта - Esc. Ну и так далее, переписывать весь PDF в комментарий к статье (да их там три PDF, по одному на каждую из основных ОС) - дело неблагодарное.
А вот совет который явно отсутствует - научится пользоваться bookmarks, как окном и разными списками заметок, так и установкой именованных по горячим клавишам. Потому что найдя что-то, нужно ещё запомнить где оно и зачем вообще искали. Открывать 100500 файлов и помнить визуально где какая вкладка - можно, но неэффективно. А в этих списках ещё и комментарии можно писать к строке - что имели в виду, когда искали.
Вы не поверите... Если немного учесть, что подключение к конкретной БД - настраиваемый параметр, то есть такая штука как Edit - Find - Search structurally. Там же и replace. Ну или регулярками по тексту, тоже так неплохо работает.
Присоединяюсь к просьбе. Ну очень интересно. Потому что как это бывает на бывшей 1/6 части суши - примерно понятно (дядя - тётя - сват - брат в начальниках али совладельцах). А вот как из рядовых разработчиков / аналитиков в крупной американской конторе в менеджмент попадают - непонятно. Даже термин специальный придуман и не на пустом месте - "Стеклянный потолок". В общем просим ещё главу - "От кеш-линий в кеш-flow" :)
Vaadin? Не то чтобы no-code, но концепцию "щас повесим на on-click бизнес-логику" позволяет реализовать замечательно. А так да... для того, чтобы это вот всё завелось, нужна рядышком ролевая модель и метаданные, какие поля в какой таблице что означают на бизнес-языке, и куда по какой связи ходить можно ... и при каких условиях... и кому... и где и как создавать новые записи. Была такая SugarCRM, которая этот концепт неплохо так развила
Как же SOLID ещё никто не помянул то... А оно ведь работает. Просто не на уровне именования переменных и функций, а на уровне микроархитектуры приложения. Ну возможности распиливания монолита на микросервисы потом, да. PS:
Говорящие имена переменных бесполезны
А что касается выразительности... Зависит от языка конечно, но вот в Java к примеру, не завезли перегрузку операторов и кое-какое наследование, через что адски неудобно делать типы. Т.е. классов с интерфейсами хоть залейся, а вот определить два несовместимых Double, один для градусов цельсия, второй для кельвинов - примерно никак. Ну или городить вычисления словами, а инициализацию через фабрику. А не, это из 2016. Теперь через билдер. Но если он будет порождаться фабрикой, так будет энтерпрайзней, всё равно в половине кода сделано так, а в половине, которая писалась при другом архитекторе, этак. И единственный способ поймать косяк на review - это таки да, говорящие имена. У нас на проекте, если имя локальной переменной не говорит, зачем она тут - MR тут же заворачивается на доработку. Плюс JavaDoc по стандартам, и дополнительно следим, чтобы там было написано ЗАЧЕМ этот параметр, а не что он есть. Иначе получается Сепулька сепулька; //ссылка на сепульку.
ваш код не читают от нечего делать, в качестве развлечения. Ну почти никто. В него смотрят обычно намереваясь обнаруживать и чинить баги. Я могу заверить, исходя из собственного опыта: намного важнее выразительности понимание алгоритма
Есть области, где это не работает. Ну нет описания алгоритма, вот вообще. Есть БТ + Функциональные требования. Есть толковый разработчик, который с утра наливает кофе, открывает тикет, читает, матерится на аналитиков, которые это писали, открывает исходник и начинает соображать, в какое вообще место в коде (который писали три команды за последние семь лет) это можно присрать. И как. По дороге выясняется, что на двадцатой странице БТ написано про семь параллельных линий, на тридцать второй про то, как они должны пересекаться. Ещё через пол-года другой разработчик что-то там унаследует, чтобы одна из линий была в форме котёнка. А ещё через год - выяснится, что всё должно быть совсем не так, потому что Госдума. И очередной новый разработчик, после двух недель на "изучение существующего решения", таки осознает, что алгоритма - нет. То, что написано в ТЗ №1 - вообще не соответствует кодовой базе, потому что были доработки XX и XY, а постановка задачи на фикс с котёнком потонула в переписке двух эффективных менеджеров и РП. Ни один из которых в данный момент в конторе уже не работает. И единственный источник истины - код, потому как стоит в проде и функциональный заказчик почти не ругается. И вот тут говорящие имена переменных, выразительная структура классов и паттерны проектирования где надо, описания зачем так и ссылки на тикеты (хотя в Java сейчас хорошо - есть плагин для IDEA, который умеет показать это для каждой строки прямо в коде) - становятся ключевым фактором сроков выкатки фич. А это уже про чистые деньги.
Ну...это должна была бы быть столбиковая диаграмма. Как проценты вообще можно считать при мультиголосовании ?
Хабр прекрасен. Сделано программистами для программистов.
Местами это настолько отвратительно, что даже прекрасно :)
С челвеком-концом, когда он 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) это блин поделие само накладывает линейные градиенты сверху и снизу экрана, и ты видишь ни разу не то, что тебе показывает дизайнер
Я бы добавил в аналоги Visio - yEd. Местами он реально удобнее даже
Будете перевыкладывать - проверьте вёрстку на Samsung Internet, который в телефоне Galaxy по умолчанию браузер.
Как оно на телефоне
Плагин GitToolbox вообще делает blame автоматически для выделенной строки, помимо всего остального.
А ещё из полезных вещей, которыми почему-то никто не пользуется - Call Hierarchy и Analyze Data Flow to here. Но с первым нужно быть аккуратным и обязательно настроить частный scope на файлы и либы проекта, иначе упёршись в какой-нибудь Thread.run эта штука попытается просканировать весь maven и подвиснет вместе с IDEA
:) Вы не использовали shortcut XYZ 7851 раз. И 7852-й раз не использую, потому что я долго и со вкусом перед эти ковырялся мышкой в run configuration, и кликнуть чуть быстрее, чем опять уходить на клавиатуру
Вынужден отметить, что многие вышеприведённые советы... не вполне эффективны. КМК профессиональный разработчик должен делать всё, что только можно не отрываясь от клавиатуры. Так тупо быстрее, и думать не нужно - только понадобилось, а руки уже сделали. И IDEA это всё поддерживает - достаточно сходить в Help - Keyboard Shortcuts PDF, распечатать, повесить на стену и выучить всё. Тот же Select opened file - под Win Alt-F1 и далее либо Enter сразу, либо куда хочешь... Обратно в окно редактора из дерева проекта - Esc. Ну и так далее, переписывать весь PDF в комментарий к статье (да их там три PDF, по одному на каждую из основных ОС) - дело неблагодарное.
А вот совет который явно отсутствует - научится пользоваться bookmarks, как окном и разными списками заметок, так и установкой именованных по горячим клавишам. Потому что найдя что-то, нужно ещё запомнить где оно и зачем вообще искали. Открывать 100500 файлов и помнить визуально где какая вкладка - можно, но неэффективно. А в этих списках ещё и комментарии можно писать к строке - что имели в виду, когда искали.
Вы не поверите... Если немного учесть, что подключение к конкретной БД - настраиваемый параметр, то есть такая штука как Edit - Find - Search structurally. Там же и replace. Ну или регулярками по тексту, тоже так неплохо работает.
Присоединяюсь к просьбе. Ну очень интересно. Потому что как это бывает на бывшей 1/6 части суши - примерно понятно (дядя - тётя - сват - брат в начальниках али совладельцах). А вот как из рядовых разработчиков / аналитиков в крупной американской конторе в менеджмент попадают - непонятно. Даже термин специальный придуман и не на пустом месте - "Стеклянный потолок".
В общем просим ещё главу - "От кеш-линий в кеш-flow" :)
Vaadin? Не то чтобы no-code, но концепцию "щас повесим на on-click бизнес-логику" позволяет реализовать замечательно. А так да... для того, чтобы это вот всё завелось, нужна рядышком ролевая модель и метаданные, какие поля в какой таблице что означают на бизнес-языке, и куда по какой связи ходить можно ... и при каких условиях... и кому... и где и как создавать новые записи. Была такая SugarCRM, которая этот концепт неплохо так развила
Как же SOLID ещё никто не помянул то... А оно ведь работает. Просто не на уровне именования переменных и функций, а на уровне микроархитектуры приложения. Ну возможности распиливания монолита на микросервисы потом, да.
PS:
А что касается выразительности... Зависит от языка конечно, но вот в Java к примеру, не завезли перегрузку операторов и кое-какое наследование, через что адски неудобно делать типы. Т.е. классов с интерфейсами хоть залейся, а вот определить два несовместимых Double, один для градусов цельсия, второй для кельвинов - примерно никак. Ну или городить вычисления словами, а инициализацию через фабрику. А не, это из 2016. Теперь через билдер. Но если он будет порождаться фабрикой, так будет энтерпрайзней, всё равно в половине кода сделано так, а в половине, которая писалась при другом архитекторе, этак. И единственный способ поймать косяк на review - это таки да, говорящие имена. У нас на проекте, если имя локальной переменной не говорит, зачем она тут - MR тут же заворачивается на доработку. Плюс JavaDoc по стандартам, и дополнительно следим, чтобы там было написано ЗАЧЕМ этот параметр, а не что он есть. Иначе получается
Сепулька сепулька; //ссылка на сепульку.Есть области, где это не работает. Ну нет описания алгоритма, вот вообще. Есть БТ + Функциональные требования. Есть толковый разработчик, который с утра наливает кофе, открывает тикет, читает, матерится на аналитиков, которые это писали, открывает исходник и начинает соображать, в какое вообще место в коде (который писали три команды за последние семь лет) это можно присрать. И как. По дороге выясняется, что на двадцатой странице БТ написано про семь параллельных линий, на тридцать второй про то, как они должны пересекаться. Ещё через пол-года другой разработчик что-то там унаследует, чтобы одна из линий была в форме котёнка. А ещё через год - выяснится, что всё должно быть совсем не так, потому что Госдума. И очередной новый разработчик, после двух недель на "изучение существующего решения", таки осознает, что алгоритма - нет. То, что написано в ТЗ №1 - вообще не соответствует кодовой базе, потому что были доработки XX и XY, а постановка задачи на фикс с котёнком потонула в переписке двух эффективных менеджеров и РП. Ни один из которых в данный момент в конторе уже не работает. И единственный источник истины - код, потому как стоит в проде и функциональный заказчик почти не ругается. И вот тут говорящие имена переменных, выразительная структура классов и паттерны проектирования где надо, описания зачем так и ссылки на тикеты (хотя в Java сейчас хорошо - есть плагин для IDEA, который умеет показать это для каждой строки прямо в коде) - становятся ключевым фактором сроков выкатки фич. А это уже про чистые деньги.