S>Проффесор подскажите пожалуйста, а что делать если S>жена вместо того что бы подносить патроны выносит мозги S>и потребляет все мои рессурсы — время, деньги и силу
Ты сам знаешь ответ. S>я понимаю что надо развестись, послать нах и вычеркнуть из жизни
Ну, сам жеж знаешь, что делать.
Послать надо не всех.
Жену, мож и послать, а детей — не посылать.
И не вычеркивать.
S>с другой стороны есть мысль — а другие как живут, они же как то женаты и при этом делают карьеру
Ты — не другие. Ты — это ты...
По секрету скажу, что и у меня было так же, как у тебя — сейчас дружим...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, ukrspecs, Вы писали:
U>Здравствуйте, RussianFellow, Вы писали:
RF>>ukrspecs, не могли бы Вы описать свои скиллы--знания, умения, опыт? Какими языками программирования владеете, какие библиотеки и технологии знаете?
U>Не мог бы.
Здравствуйте, ukrspecs, Вы писали:
U>Здравствуйте, RussianFellow, Вы писали:
RF>>ukrspecs, не могли бы Вы описать свои скиллы--знания, умения, опыт? Какими языками программирования владеете, какие библиотеки и технологии знаете?
U>Не мог бы.
Стесняешься? Специалисты с кучей сертификатов от крупных компаний и обширным портфолио успешно завершенных проектов — они такие
А можете рассказать подробнее про плотное код-ревью?
Это ревью всего кода или какой-то его части?
Для скольки человек одновременно получается его проводить? Или прововодите не всё вы, а команда друг у друга?
У меня личный опыт такой. Ко мне периодически приставляли джуна. И я делал ему код-ревью (настолько плотное, насколько сил хватало).
И как-то такое ощущение, что джун пишет код чуть ли не быстрее, чем я его читаю. То есть кода много. И код бывает получается сложный, что мозг сломаешь. И просто сказать человеку "что-то как-то сложно всё" неконструктивно. Я пытаюсь сообразить, как это можно переделать, при этом код не пиша. И это мне плохо даётся. Если я сам рефакторю код, то идея рефакторинга иногда разбивается об реализацию из-за неучтённых деталей. Может и хуже получиться. А говорить "Ну сделай так. Сделал? Не, снова фигня. Давай вот-так попробуй" тоже вроде не очень.
Может быть, конечно, я ещё не обобщил достаточно свой опыт (хотя вроде его уже 10+). Или просто нужно ещё больше код-ревью-практики.
RU>А можете рассказать подробнее про плотное код-ревью?
Не поставлен процесс документирования.
Требуйте с джуна так же исчерпывающую документацию к коду в нужном формате.
Производительность у него резко упадёт и Вы начнёте успевать.
Здравствуйте, ukrspecs, Вы писали:
U>Собственно сабж. Каково оно после 40? Больше зарабатываете чем в 30+? Приходится постоянно переучиваться, подстраиваться под тренды? Будь вы на 10-15 лет моложе, какой совет бы себе дали?
Следить за трендами и обновлять портфель навыков. Скорость соображалки тренировать алго задачками регулярно.
Здравствуйте, Эйнсток Файр, Вы писали:
RU>>А можете рассказать подробнее про плотное код-ревью?
ЭФ>Не поставлен процесс документирования. ЭФ>Требуйте с джуна так же исчерпывающую документацию к коду в нужном формате. ЭФ>Производительность у него резко упадёт и Вы начнёте успевать.
Способ интересный )
Но у нас не требуется такой подробной документации, только достаточно высокоуровневая типа API к модулю, параметров конфигов.
И, боюсь, начальство не поймёт инициативы загрузить человека ненужным делом.
Q>Мне 47 и я не развалина, предложения поступают постоянно.
Можно узнать какой стек технологий и домен? Это обычно энтерпрайс, аутсорс? На какую позицию?
Интересуюсь, потому что условный .NET 10 лет назад и сегодня — это разные вещи. Так сложилось изначально, что я вкладывался в разработку под десктоп. Сначала на С++/WinAPI/MFC, потом переехал на C#/WPF/WinForms. И за последние 3 года, мне сильно повезло, что попались 2 проекта под мобайл, и я смог поехать дальше на Xamarin/iOS/Android. Если бы остался на десктопе — то там ветхое и унылое легаси. Либо портировать еще более унылый софт, с Java/Obj-C на .NET. Но обычно — это уже 14-ая версия, которая прошла через все национальности и стили кодирования до меня, что есть боль.
Здравствуйте, RedUser, Вы писали:
RU>А можете рассказать подробнее про плотное код-ревью?
RU>Это ревью всего кода или какой-то его части? RU>Для скольки человек одновременно получается его проводить? Или прововодите не всё вы, а команда друг у друга?
RU>У меня личный опыт такой. Ко мне периодически приставляли джуна. И я делал ему код-ревью (настолько плотное, насколько сил хватало). RU>И как-то такое ощущение, что джун пишет код чуть ли не быстрее, чем я его читаю. То есть кода много. И код бывает получается сложный, что мозг сломаешь. И просто сказать человеку "что-то как-то сложно всё" неконструктивно. Я пытаюсь сообразить, как это можно переделать, при этом код не пиша. И это мне плохо даётся. Если я сам рефакторю код, то идея рефакторинга иногда разбивается об реализацию из-за неучтённых деталей. Может и хуже получиться. А говорить "Ну сделай так. Сделал? Не, снова фигня. Давай вот-так попробуй" тоже вроде не очень.
RU>Может быть, конечно, я ещё не обобщил достаточно свой опыт (хотя вроде его уже 10+). Или просто нужно ещё больше код-ревью-практики.
Требуй юнит-тестов, по ним можно и понять, что код делает и что не делает. Чем больше тестов, тем лучше.
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, ukrspecs, Вы писали:
U>>Я на .NET-e уже лет 10 сижу, переехал в свое время с плюсов. Сначала десктоп делал, теперь мобильные приложения на Xamarin. Облизываясь смотрю на Azure и highload/BigData. Хотел бы в чем-то таком масштабном поработать, но пока не подворачивалось вариантов. Да и опыта мало с Azure. Вот например — облачные технологии учить, потом применять — есть смысл? Есть смысл , идти из разработки в архитектора? SK>Я такое не учу принципиально, так как там и так все понятно, все учение заключается просто в запоминании какую комманду вбить и где конфигурацию поменять. Все остальное — те самые основы и здравый смысл.
Допустим вам поступает задача — сделать бекенд для шеринга фото миллионами пользователей, по типу инстаграмма. И тут уже нужны знания каждого винтика внутри Azure, как построить архитектуру, какие сервисы выбрать, чтобы снизить нагрузки и правильно распределять ресурсы. Как обеспечить безопасность, масштабируемость, сохранность данных итд. Это может быть больше про архитектуру, но и разработчику нужно знать как работают сервисы, особенно с опытом.
Разумеется Дональд Кнут об этом не пишет. И знание протоколов и модели OSI тут не первично. Чтобы решить такую задачу, нужно изучить трендовые технологии. Azure Functions, CDN, Redis (кеширование), Cosmos DB и еще пачку сервисов, аналогов которым не было 10 лет назад.
Вот хотел бы узнать, взялись бы за решение такой задачи, или не учили принципиально? Оффер от Microsoft на 200к$/год для примера
AG>Совет очень простой: AG>Переходить в тот сектор ИТ, где порог вхождения более высокий. AG>Там (в основном) будут люди за 35...40 — и тебе будет с ними комфортнее, нежели с 23-летними сеньорами
А на вскиду, какие это сектора?
Например у меня был год назад проект, с высоким порогом входа. NLP+Machine learning. Вокруг — сплошь молодежь, 30+-.
Здравствуйте, kaa.python, Вы писали:
KP>Стесняешься? Специалисты с кучей сертификатов от крупных компаний и обширным портфолио успешно завершенных проектов — они такие
Так а зачем?
Все описывать, копипастить — долго. А давать ссылки на свои блоги, сайты, портфолио — не хочу. Слишком много личного вам рассказал
Здравствуйте, ukrspecs, Вы писали:
U>Здравствуйте, Qulac, Вы писали:
Q>>Мне 47 и я не развалина, предложения поступают постоянно. U>Можно узнать какой стек технологий и домен? Это обычно энтерпрайс, аутсорс? На какую позицию?
U>Интересуюсь, потому что условный .NET 10 лет назад и сегодня — это разные вещи. Так сложилось изначально, что я вкладывался в разработку под десктоп. Сначала на С++/WinAPI/MFC, потом переехал на C#/WPF/WinForms. И за последние 3 года, мне сильно повезло, что попались 2 проекта под мобайл, и я смог поехать дальше на Xamarin/iOS/Android. Если бы остался на десктопе — то там ветхое и унылое легаси. Либо портировать еще более унылый софт, с Java/Obj-C на .NET. Но обычно — это уже 14-ая версия, которая прошла через все национальности и стили кодирования до меня, что есть боль.
Стек обычный: C#, sql, wpf, wcf. web — web api, angular. winforms забыл когда пользовался, но в некоторых местах требуется. В основном энтерпрайс, позиция в основном мидл. Так от себя добавлю, что для веба сейчас нужно знать какой ни будь spa Фреймворк, очень много где требуется.
Здравствуйте, RedUser, Вы писали:
RU>А можете рассказать подробнее про плотное код-ревью?
Под плотным я имею ввиду, что замечания могут касаться всех аспектов кода, от именования переменных до нарушения архитектурных гайдов, и первое время итерации по пулл-реквесту могут длиться 2-3 недели и включать сотни замечаний. Если код ревью ушло в затяг, то можно какие-то замечания опустить, или самому доделать, или завести тикет в техдолг на доработку.
RU>Это ревью всего кода или какой-то его части?
Это новый код, т.е. ревью пулл-реквестов (иногда, если при просмотре пулл-реквеста виден более старый код, он тоже подвергается анализу и замечаниям).
А для анализа существующего кода на предмет техдолга есть другой процесс: например анализ сонар-кубом, или заведение в бэклог отдельных тикетов на рефакторинг.
RU>Для скольки человек одновременно получается его проводить? Или прововодите не всё вы, а команда друг у друга?
У меня получается у 3-4 человек, это занимает 60-70% времени.
Друг у друга команда тоже ревьювит, если ревьювер сам того желает (даже если джун, но тогда обычно на пулл реквесте есть ещё второй более опытный ревьювер). Единственное требование, что ревью нужно делать адекватно и быть готовым обосновывать свои замечания (иногда это не так просто сделать, например доказывать "зачем нужен OCP если switch/if меньше кода занимает и не плодит классов?"). Чтобы такие обоснования не делать каждый раз заново, я например веду вики со списком наиболее распространенных замечаний, сейчас у меня в нём 70+ таких правил, многие с обоснованиями. Ещё такое вики является чек-листом для разрабов, чтобы сверяться с ним перед коммитом.
RU>У меня личный опыт такой. Ко мне периодически приставляли джуна. И я делал ему код-ревью (настолько плотное, насколько сил хватало). RU>И как-то такое ощущение, что джун пишет код чуть ли не быстрее, чем я его читаю. То есть кода много.
Ну да, есть такое. А если ещё людей учить горячим клавишам рефакторинга, то код пишут ещё быстрее, только успевай ревьювить.
RU> И код бывает получается сложный, что мозг сломаешь. И просто сказать человеку "что-то как-то сложно всё" неконструктивно. Я пытаюсь сообразить, как это можно переделать, при этом код не пиша. И это мне плохо даётся.
У меня такое тоже бывает. Некоторые решения таких проблем мы с разрабом совместно пытаемся отрефакторить или пофиксить, причем бывает, что вместе сделали некое решение, а на следующий день после мержа я понимаю, что решение некорректное — и тогда или переделываем если сроки позволяют, или заводим тикет на доработку в будущем. Это уже получается не просто код ревью, а "совместная работа над кодом", о чём надо постоянно заявлять, чтобы все понимали, что код ревью — это не надзор или способ самоутверждения, а совместная работа, результатом которой становится отчуждаемый код. Так что без твоего участия в написании кода сложных и проблемных мест такие проблемы не решить. Обязательно надо самому стянуть ветку, позапускать код в IDE и пробовать рефакторить его самому.
Но первое, что я делаю когда вижу объективно сложный код с высокой цикломатической сложностью — это прошу написать юнит-тест и назвать все классы, методы и переменные понятным образом (правильное именование само по себе отдельное искусство и это часто сложная задача). И только потом можно начинать код переделывать и упрощать. Иногда это упрощение занимает 2-3 недели, случаи действительно бывают сложными, особенно когда в коде метода сто вложенных ифов и итераций, и когда не понимаешь с какого края подступиться к упрощению кода.
RU> Если я сам рефакторю код, то идея рефакторинга иногда разбивается об реализацию из-за неучтённых деталей. Может и хуже получиться. А говорить "Ну сделай так. Сделал? Не, снова фигня. Давай вот-так попробуй" тоже вроде не очень.
Ну да. Поэтому при упрощении кода нужно иметь набор целевых показателей, сформулированных в виде общепризнанных принципов, которые явно перечислены на вашей вики и имеют обоснования, принимаемые всеми членами команды (чтобы в процессе ревью ты ещё не тратил силы на обоснования каждого замечания). Сами принципы — это например, DRY, KISS, принцип QSR, чистота функций, соблюдение инвариантов объектом, принципы OCP, SRP, известные паттерны вместо своих запутанных решений, ну и их ещё пара десятков, их наличие на вашей вики дает понимание к чему именно мы стремимся при упрощении кода и когда можно сказать что "стоп, теперь годится".
RU>Может быть, конечно, я ещё не обобщил достаточно свой опыт (хотя вроде его уже 10+). Или просто нужно ещё больше код-ревью-практики.
А ты свой опыт на вики формулируешь в виде чеклистов или сводов правил с пояснениями?
У меня опыта ревью лет 16, и приемлимо ревьювить я стал наверное только года 4 назад, до этого часто понимал что не до конца понимаю то что мне прислали в пул реквесте и пропускал многие проблемы.
При этом я считаю, что ревью не призван искать баги, для этого есть другие процессы (хотя код ревью частично эту задачу решает, особенно если вместе с кодом стаются и юнит или интеграционные тесты как часть пулл реквеста).
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, ukrspecs, Вы писали:
U>>Здравствуйте, RussianFellow, Вы писали:
RF>>>ukrspecs, не могли бы Вы описать свои скиллы--знания, умения, опыт? Какими языками программирования владеете, какие библиотеки и технологии знаете?
U>>Не мог бы.
Здравствуйте, ukrspecs, Вы писали:
U>>>Я на .NET-e уже лет 10 сижу, переехал в свое время с плюсов. Сначала десктоп делал, теперь мобильные приложения на Xamarin. Облизываясь смотрю на Azure и highload/BigData. Хотел бы в чем-то таком масштабном поработать, но пока не подворачивалось вариантов. Да и опыта мало с Azure. Вот например — облачные технологии учить, потом применять — есть смысл? Есть смысл , идти из разработки в архитектора? SK>>Я такое не учу принципиально, так как там и так все понятно, все учение заключается просто в запоминании какую комманду вбить и где конфигурацию поменять. Все остальное — те самые основы и здравый смысл.
U>Допустим вам поступает задача — сделать бекенд для шеринга фото миллионами пользователей, по типу инстаграмма. И тут уже нужны знания каждого винтика внутри Azure, как построить архитектуру, какие сервисы выбрать, чтобы снизить нагрузки и правильно распределять ресурсы. Как обеспечить безопасность, масштабируемость, сохранность данных итд. Это может быть больше про архитектуру, но и разработчику нужно знать как работают сервисы, особенно с опытом. U>И знание протоколов и модели OSI тут не первично. Чтобы решить такую задачу, нужно изучить трендовые технологии. Azure Functions, CDN, Redis (кеширование), Cosmos DB и еще пачку сервисов,
Винтики конкретного продукта надо знать только если вы собираетесь его использовать. Эти винтики учить не надо, надо просто сделать как написано в документации.
В первую же очередь надо понимать, что вы хотите от этих технологий и как фундаментально вы ожидаете они должны работать, а для этого не надо знать конкретную реализацию. Надо посмотреть на задачу и решить что для решения понадобится некий конкретных подход, потом уже под этот подход подбирать тулзы.
Например, есть сервис для расшаривания фоток, видно что доступ, в основном, по одному ключу — пользователю, значит key-value подойдет. Пользователей будут десятки миллионов, которые будут много качать, соответственно надо раскидать их на машины, которые могут более-менее независимо работать и, желательно, иметь независимые каналы, ну и так далее. Далее, допустим, возьмем то же редис, от которого мы точно знаем, что хотим и посмотрим как он работает и оправдывает ли ожидания, возможно, что он и нафиг тут не нужен.
Продуктовые "профессионалы" часто подходят к вопросу с обратной стороны, что выглядит довольно забавно для стороннего наблюдателя. Для тех же кто работает на таком проекте, это печаль и мучение.
U>Разумеется Дональд Кнут об этом не пишет.
Разумеется, "Кнут" (в кавычках!, это собирательный Кнут) как раз и пишет и том, как решать задачу, но не о том какой продукт для этого нужен.
U>аналогов которым не было 10 лет назад.
Не было конкретных названий и настолько широкого использования, но вы серьезно думаете, что не было технологий и фундаментальных подходов? Не смешите мои тапочки.
U>Вот хотел бы узнать, взялись бы за решение такой задачи, или не учили принципиально? Оффер от Microsoft на 200к$/год для примера
Вопроса не понял. Все учили. Не учили только флажки и галочки — такое надо учить когда надо пользоваться тулом, но не до того.
Здравствуйте, bnk, Вы писали:
bnk>Я правильно понимаю, что в С++ еще остались какие-то неоткрытые острова (в отличие от этой планеты)? bnk>То есть, народ все еще не знает как обрабатывать мультимедийные (аудио-видео) данные, или как строить карты, что ли?
Недавно пришлось работать с не публичным СДК (хоть и от топовой мировой компании), сборка там сильно через одно место. Гугл в принцепе ничего не знает об этом СДК. Не рокет сайенс, но вчерашний студент не разберется и гугл ему не поможет.
bnk>И в области C++ сейчас стало сильно лучше и интереснее, чем было 10-15 лет назад, когда многие (включая меня) оттуда свалили?
Разработка под всякие железки сильно оживилась. IoT и тому подобное. Условно в каждой лампочке код из boost.
Здравствуйте, StanislavK, Вы писали:
SK>Винтики конкретного продукта надо знать только если вы собираетесь его использовать. Эти винтики учить не надо, надо просто сделать как написано в документации.
Вряд ли вам доверят реализацию сервиса на миллион пользователей, если вы не знаете как работать с той же Azure или AWS. Именно в глубину, а не по загалям. А там поверьте, деталей не меньше чем в стандарте С++.
И если с наскока проектировать по докам, которые структурированы чтобы туда заглядывать и сверяться, а не решать задачи — то дела не будет. Опыт нужен, практика.
Я пытаюсь донести, что Cloud — это совсем другое, чем базовые знания о тех протоколах, сетях и алгоритмах. И это отдельный пласт специалистов, с которыми конкурировать чисто на опыте — не получиться.
SK>Например, есть сервис для расшаривания фоток, видно что доступ, в основном, по одному ключу — пользователю, значит key-value подойдет. Пользователей будут десятки миллионов, которые будут много качать, соответственно надо раскидать их на машины, которые могут более-менее независимо работать и, желательно, иметь независимые каналы, ну и так далее. Далее, допустим, возьмем то же редис, от которого мы точно знаем, что хотим и посмотрим как он работает и оправдывает ли ожидания, возможно, что он и нафиг тут не нужен.
У key-value и "раскидать по машинам", есть конкретные названия сервисов. И если их не знать — то и решения не будет. Т.е. скорее не зная из чего выбирать.
U>>аналогов которым не было 10 лет назад. SK>Не было конкретных названий и настолько широкого использования, но вы серьезно думаете, что не было технологий и фундаментальных подходов? Не смешите мои тапочки.
Не было тех же облачных технологий, которые я беру как яркий пример того, где наша с вами база — не является определяющим фактором. Если выучив алгоритмы потом С, мы могли прыгать и в C++, и в Java, потом в C#, и писать там что угодно. То в 2020, имея эти знания, мы не сможем с такой же легкостью запрыгнуть в MachineLearning, BigData, Cloud, AI.
U>>Вот хотел бы узнать, взялись бы за решение такой задачи, или не учили принципиально? Оффер от Microsoft на 200к$/год для примера SK>Вопроса не понял. Все учили. Не учили только флажки и галочки — такое надо учить когда надо пользоваться тулом, но не до того.
Выше вы писали, что не учите новые технологии принципиально. Я спросил, стали бы учить за крутой оффер?
RU>>Может быть, конечно, я ещё не обобщил достаточно свой опыт (хотя вроде его уже 10+). Или просто нужно ещё больше код-ревью-практики.
G>А ты свой опыт на вики формулируешь в виде чеклистов или сводов правил с пояснениями?
Нет. Я тут имел ввиду обобщение в голове, когда под куда больше ситуаций у меня сразу же будет формулироваться приемлемое готовое решение.
