Как говорится: сам себя не похвалишь - никто не похвалит. Дока - проект для самопиара, не более. Теперь каждый контрибьютор проекта может написать по бесполезной статье о проекте, в котором никто не нуждался, на хабре и прочих ресурсах, чтобы почувствовать себя важнее, так держать!
1. Если это простые компоненты по 15 строчек, то весь этот ритуал с какими то скриптами и туду зачем? Поправил сразу на месте и забыл. ИБД? Опять же не очень вообще понял в чем «рефакторинг» состоял? Обертки для тупых компонентов подправить во всем проекте?
2. У вас в статье написано, что вы были один на проекте. Откуда джуны взялись?
3. Ну то есть вы подтвердили мою мысль — заказчику знать об технических задачах не стоит, если он явно об этом не просит (например если ему не понятен почему выставлен такой большой естимейт по задаче и нужно детально расписать). Вы же не докладываете заказчику сколько компонентов за неделю создали или строчек css написали? Это чисто технические нюансы. Если для выполнения бизнес-задач требуется рефакторинг, то он должен быть заложен в эстимейты этих бизнес задач. Это утверждение конечно с оговоркой, оно не относится к большим проектам — когда появляются прослойки между заказчиком и разработчиками в виде ПМов, тимлидов, аналитиков, но даже в таком случае все технические задачи декомпозируются из бизнес-задач, просто для бизнеса они не существенны, а для ПМ\тимлида могут быть важны.
Есть ряд вопросов к автору:
1. Лезем в воду, не зная броду. На чужой код, который вы планировали рефакторить были написаны тесты? Вы не задумывались почему каждый новый разработчик создавал, свой новый компонент, а не переиспользовал старые? Может на то были причины, чтобы например изолировать свой код, который понятно на что влияет и в который можно предсказуемо вносить изменения, от чужого?
2. В статье описан процесс организации, но не описаны причины и результаты. Например что стало с проектом, через 3 месяца такого рефакторинга? Что стало лучше, что стало хуже, много ли было работы, не выгорели ли под гнётом миллиона ту-ду?
3. Заказчику как правило фиолетово на ваши технические задачи, ему важны только сроки по его бизнес-задачам, которые влияют на функциональность. Как в вашем случае заказчик оценивает эту работу? Нужен ли ему рефакторинг и не кажется ли ему, что вы создаете имитацию бурной деятельности? Может заказчику и не нужно знать об техдолге, а часы на него проще прятать в бизнес-задачи?
Если я в один прекрасный день допустим попаду к вам в квартиру, потому что вы не заперли дверь, сниму об этом ролик «Квартира Никиты Куприянова уже не в безопасности!!11» для видеоблога, а вы об этом узнаете из трендов ютуба, то как я буду выглядеть в ваших глазах? Как злоумышленник или как герой-блоггер, тестирующий безопасность чужих жилищ?
То, что вы не заперли дверь — глупость.
То, что я залез к вам в квартиру и не уведомил об этом вас, как хозяина, даже из лучших побуждений — тоже глупость.
Так обьясните мне, почему глупость РЖД должна как то оправдывать глупость автора (состоит в том, что он не уведомил хозяина системы)?
Гораздо вероятней банальное эксплуатирование оборудования в качестве майнеров крипты, чем какие то диверсии из видимо хулиганских побуждений.
Пришел дежурный, заметил перевод стрелок не по плану — перевел обратно.
Пришел админ, щелкнул ИБП, все снова заработало.
Факапы в ИТ случаются ежедневно и ежечасно даже без всяких хулиганов\террористов\шпионов\диверсантов\злых хакеров — это норма, даже гугл почта недавно падала например.
Автор получил доступ каким то подсетям, каким то камерам и устройствам, непонятно какого филиала РЖД, т.е. даже сам не разобрался к чему. Да даже квалифицированному админу без грамотной оставленной документации от предыдущего админа порой нужен не один месяц, чтобы разобраться что и за что отвечает в сети и где находится, а вы тут фантазируете о каких то маловероятных сценариях, где злобный хакер нажатием одной кнопки парализует работу всего РЖД. И самый главный вопрос — зачем это все хакеру, какая выгода? Гипотетически можно защищать вообще всё от вообще всего, но в жизни обычно все прагматичнее — защищают только самое важное и на что хватает ресурсов.
Тогда тем более к автору еще больше претензий — ни в коем случае не нужно было раскрывать эти уязвимости публично. Теперь каждый второй мамкин хакер полез пробивать рубежи, как выяснилось слабо подготовленной, инфраструктуры РЖД. Но зато автор себе побыстрее плюсиков в карму нахватал, произвел так сказать ИБ-открытие года, собственная значимость ведь действительно важнее судьбы огромного предприятия!
В больших организациях горизонт планирования бюджетов минимум — полугодие, а то и год. А если это по каким то критериям покадает в капитальные инвестиции — то может быть и три года. Так что в лучшем случае конкурс на аудит они начнут отыгрывать во втором полугодии. Никто там метаться кабанчиком и продавливать какие то оперативные решения на уровне финдиректоров не будет из за того, что какой то аноним решил прославиться на хабре. Провели служебную проверку, поменяли пароли по её решению, позакрывали порты и всё (может быть даже премию кто то получил по итогам этих действий). Статья опять же на манер желтой прессы, чтобы попугать обывателя — не понятно к насколько большой и важной части инфраструктуры можно было получить доступ через эти микротики и что с этим сделать. Видеокамеры, роутеры уровня SOHO — это неприятно, да, но не критично
Автор пошел по пути самопиара, потому что очевидно, написать вкратце об узвимости на десяток публичных email и подождать неделю реакции РЖД требует меньше усилий и времени, чем расписать такую статью с замазыванием скриншотов и историческими ликбезами о факапах ИТ в РЖД в прошлом
Не искажайте смысл. Так в данном случае по аналогии об осталенной открытой двери рассказали не Вам (хозяину), а всем вокруг. Почему вообще подобные действия должны поощряться? Это какая то медвежья услуга — сообщать об уязвимостях публично.
Почему автор не написал об уязвимости в РЖД, но не поленился расписать статью со скриншотами и маркдауном на хабр?
Героев нынче судят не по поступкам, а по тому насколько громче эти «герои» кукарекают. Синдром BLM и СЖВ в действии.
Я нисколько не оправдываю головотяпство ИТ-сотрудников (или их ИТ-подрядчиков) РЖД, но обьясните — что такого ужасного «взломал» автор? Пару роутеров SOHO-класса и несколько китайских камер видеонаблюдения? Я бы еще понял беспокойство, если бы он получил доступ к каким то БД, серверам или сетевому ядру ЦОД, но в данном контексте статья выглядит как «Мам, смотри, я взломал РЖД!!11»
Не хотелось бы злорадствовать, но какую ценность или опыт несёт данная статья? Выглядит как пустая декларация намерений ради социального одобрения. Человек ещё ничего не добился, но уже громко на публику заявляет что хочет вкатИТься. В любом случае желаю автору успехов в начинаниях и побольше акцентировать внимание на том что сделано, а не на том, что якобы будет сделано.
Спасибо за статью, но очень интересны юридические нюансы. Каким образом ваша компания оформляет "стажировку" и как она оплачивается? Ведь формально если стажёр решает рабочие задачи джуна и его код уезжает в прод, то по ТК РФ это можно признать трудовым отношениями, и все эти "стажировки" очень сильно заинтересуют трудовую инспекцию в случае жалоб со стороны "стажёра". Есть ли у вашей компании лицензия на образовательную деятельность, если это по бумагам оформляется как обучение и какие документы получает стажёр после окончания стажировки?
Если говорить про частично примененный синус от какого то стейта, то почему бы и не написать getSinOfExecutionTime, не понимаю на чем экономить. Для ФВП есть вполне устоявшееся withSomething. Я говорил в контексте прикладного программирования, а не системного, где возможно разумно использовать другие рассуждения — тут не берусь судить конечно
Не соглашусь. Результат выполнения функций — не всегда действие, а сама функция всегда выполняет какое то действие, вернуть что либо — это тоже действие.
Такой нейминг примеров из статьи на мой взгляд более удачный: defaultCollection > getDefaultCollection arifmeticalProgression > getArifmeticalProgression
Глагол явно указывает на то, что в переменной функция и её можно вызвать
Девочка потратила полтора года и деньги на курсы фронтенда, потому что кто то ей внушил, что у неё талант к программированию и по итогу не смогла устроится ни фронтенд-разработчиком, ни верстальщиком. Звучит совсем не как история успеха
Мне показалось что ноги у всех описанных случаев факапов растут из того, что инженерная культура 1С сильно отстаёт от мировых стандартов. Что я имею в виду под инженерной культурой? Разработка с использованием систем контроля версий, автотесты, ci/cd, мониторинг. Зачастую типовой проект 1С лишён вообще любого из вышеперечисленных пунктов. И в целом ситуация в мире 1С выглядит так, что нет ни инструментов для внедрения этих практик, ни желания и понимания у разработчиков зачем это вообще необходимо. Почему так происходит и стоит ли ожидать перемен в будущем?
Можно ещё из самого нодовского приложения zabbix-sender'ом(есть реализация под js) посылать нужные статусы при ошибках например или метрики какие нибудь (количество активных пользователей… ) — думали об этом?
Отлично, а Вы собственно кто, чтобы так авторитетно заявлять свое видение и какие результаты были с таким подходом ко вкату в ИТ?
Как говорится: сам себя не похвалишь - никто не похвалит. Дока - проект для самопиара, не более. Теперь каждый контрибьютор проекта может написать по бесполезной статье о проекте, в котором никто не нуждался, на хабре и прочих ресурсах, чтобы почувствовать себя важнее, так держать!
2. У вас в статье написано, что вы были один на проекте. Откуда джуны взялись?
3. Ну то есть вы подтвердили мою мысль — заказчику знать об технических задачах не стоит, если он явно об этом не просит (например если ему не понятен почему выставлен такой большой естимейт по задаче и нужно детально расписать). Вы же не докладываете заказчику сколько компонентов за неделю создали или строчек css написали? Это чисто технические нюансы. Если для выполнения бизнес-задач требуется рефакторинг, то он должен быть заложен в эстимейты этих бизнес задач. Это утверждение конечно с оговоркой, оно не относится к большим проектам — когда появляются прослойки между заказчиком и разработчиками в виде ПМов, тимлидов, аналитиков, но даже в таком случае все технические задачи декомпозируются из бизнес-задач, просто для бизнеса они не существенны, а для ПМ\тимлида могут быть важны.
1. Лезем в воду, не зная броду. На чужой код, который вы планировали рефакторить были написаны тесты? Вы не задумывались почему каждый новый разработчик создавал, свой новый компонент, а не переиспользовал старые? Может на то были причины, чтобы например изолировать свой код, который понятно на что влияет и в который можно предсказуемо вносить изменения, от чужого?
2. В статье описан процесс организации, но не описаны причины и результаты. Например что стало с проектом, через 3 месяца такого рефакторинга? Что стало лучше, что стало хуже, много ли было работы, не выгорели ли под гнётом миллиона ту-ду?
3. Заказчику как правило фиолетово на ваши технические задачи, ему важны только сроки по его бизнес-задачам, которые влияют на функциональность. Как в вашем случае заказчик оценивает эту работу? Нужен ли ему рефакторинг и не кажется ли ему, что вы создаете имитацию бурной деятельности? Может заказчику и не нужно знать об техдолге, а часы на него проще прятать в бизнес-задачи?
То, что вы не заперли дверь — глупость.
То, что я залез к вам в квартиру и не уведомил об этом вас, как хозяина, даже из лучших побуждений — тоже глупость.
Так обьясните мне, почему глупость РЖД должна как то оправдывать глупость автора (состоит в том, что он не уведомил хозяина системы)?
Пришел дежурный, заметил перевод стрелок не по плану — перевел обратно.
Пришел админ, щелкнул ИБП, все снова заработало.
Факапы в ИТ случаются ежедневно и ежечасно даже без всяких хулиганов\террористов\шпионов\диверсантов\злых хакеров — это норма, даже гугл почта недавно падала например.
Автор получил доступ каким то подсетям, каким то камерам и устройствам, непонятно какого филиала РЖД, т.е. даже сам не разобрался к чему. Да даже квалифицированному админу без грамотной оставленной документации от предыдущего админа порой нужен не один месяц, чтобы разобраться что и за что отвечает в сети и где находится, а вы тут фантазируете о каких то маловероятных сценариях, где злобный хакер нажатием одной кнопки парализует работу всего РЖД. И самый главный вопрос — зачем это все хакеру, какая выгода? Гипотетически можно защищать вообще всё от вообще всего, но в жизни обычно все прагматичнее — защищают только самое важное и на что хватает ресурсов.
Не искажайте смысл. Так в данном случае по аналогии об осталенной открытой двери рассказали не Вам (хозяину), а всем вокруг. Почему вообще подобные действия должны поощряться? Это какая то медвежья услуга — сообщать об уязвимостях публично.
Героев нынче судят не по поступкам, а по тому насколько громче эти «герои» кукарекают. Синдром BLM и СЖВ в действии.
Я нисколько не оправдываю головотяпство ИТ-сотрудников (или их ИТ-подрядчиков) РЖД, но обьясните — что такого ужасного «взломал» автор? Пару роутеров SOHO-класса и несколько китайских камер видеонаблюдения? Я бы еще понял беспокойство, если бы он получил доступ к каким то БД, серверам или сетевому ядру ЦОД, но в данном контексте статья выглядит как «Мам, смотри, я взломал РЖД!!11»
Не хотелось бы злорадствовать, но какую ценность или опыт несёт данная статья? Выглядит как пустая декларация намерений ради социального одобрения. Человек ещё ничего не добился, но уже громко на публику заявляет что хочет вкатИТься. В любом случае желаю автору успехов в начинаниях и побольше акцентировать внимание на том что сделано, а не на том, что якобы будет сделано.
Спасибо за статью, но очень интересны юридические нюансы. Каким образом ваша компания оформляет "стажировку" и как она оплачивается? Ведь формально если стажёр решает рабочие задачи джуна и его код уезжает в прод, то по ТК РФ это можно признать трудовым отношениями, и все эти "стажировки" очень сильно заинтересуют трудовую инспекцию в случае жалоб со стороны "стажёра". Есть ли у вашей компании лицензия на образовательную деятельность, если это по бумагам оформляется как обучение и какие документы получает стажёр после окончания стажировки?
Не соглашусь. Результат выполнения функций — не всегда действие, а сама функция всегда выполняет какое то действие, вернуть что либо — это тоже действие.
Такой нейминг примеров из статьи на мой взгляд более удачный:
defaultCollection>getDefaultCollectionarifmeticalProgression>getArifmeticalProgressionГлагол явно указывает на то, что в переменной функция и её можно вызвать
Девочка потратила полтора года и деньги на курсы фронтенда, потому что кто то ей внушил, что у неё талант к программированию и по итогу не смогла устроится ни фронтенд-разработчиком, ни верстальщиком. Звучит совсем не как история успеха
Когда уже появится адаптивный дизайн и верстка у сайта? Ну очень неудобно с мобилы пользоваться
Мне показалось что ноги у всех описанных случаев факапов растут из того, что инженерная культура 1С сильно отстаёт от мировых стандартов. Что я имею в виду под инженерной культурой? Разработка с использованием систем контроля версий, автотесты, ci/cd, мониторинг. Зачастую типовой проект 1С лишён вообще любого из вышеперечисленных пунктов. И в целом ситуация в мире 1С выглядит так, что нет ни инструментов для внедрения этих практик, ни желания и понимания у разработчиков зачем это вообще необходимо. Почему так происходит и стоит ли ожидать перемен в будущем?
Можно ещё из самого нодовского приложения zabbix-sender'ом(есть реализация под js) посылать нужные статусы при ошибках например или метрики какие нибудь (количество активных пользователей… ) — думали об этом?