Архитектору нужно понимать, какие решения вообще реализуемы и сколько они стоят в терминах времени и ресурсов. Без опыта разработки вы рискуете строить «воздушные замки»: красиво на схеме, но команда все равно обойдет это решение, потому что оно невыполнимо.
Эх, кабы так. У меня не очень большой опыт архитектуры: 4 года. Пришел в архитектуру из разработки (тут опыт уже немного больше: 20+). Купился на "масштабные проекты", "цифровую трансформацию" и прочий словесный мусор, полагающийся в таком случае. Оказалось, все не совсем так. Разработчики, действительно, не без успеха игнорировали и обходили достаточно много решений, заложенных в архитектуру. В частности, именно по причине того, что архитекторы (не все, конечно, но очень многие) совершенно не понимали и не хотели понимать как софт пишется. Более того, многие из архитекторов не только не стремились хоть что-то понять, но убежденно считали, что это им совершенно не нужно. По итогу - я сбежал обратно, в разработчики. Понимаю, мой опыт нетипичен. Но подозреваю, что такого отношения архитектуры к разработке много где еще.
Инженеры, как раз физику знали: золото было предусмотрено изначально. Но, как обычно, влезли "эффективные" менеджеры. Подозреваю, что инженеры возражали, но кто будет их слушать
Да, забыл. Было бы недурно не просто упомянуть Го, но и дать ссылки. Люди ленивы ) И позвольте в качестве дополнения порекомендовать хорошую книжку для чайников
Ну, хоть что-то конструктивное в вопросах работы с персоналом. А то одна вода. Правда, боюсь, Ваше предложение насчет Го будет недооценено (и это еще мягко сказано). Готовьтесь нахватать "минусов". Но я - плюсую.
Вы писали, что надо проходить фильтры эйчаров и собеседования с литкодом. В случае поиска на стороне - да. А своих - зачем пропускать через эту мясорубку? Поэтому и написал, что искать им никого не надо: из тех, кто есть вырастят
Да ерунда :) Пару месяцев на привыкание к синтаксису и в полный рост можно клепать круды, да джейсоны туда-сюда перекладывать. Тем более, примеров как это делается пруд пруди. А там, по ходу дела, постепенно догонят и остальное.
Вот для нагрузок, многопоточки, безопасности и прочих действительно сложных вещей, нужны сильные и опытные специалисты. Но немного. Их и правда, не один год "готовить" надо. Таких лучше нанять
В тоже видел в одном "зеленом" банчке. Правда, проект нишевый, для внутренних так сказать нужд. Те самые 7 уровней. Пока по цепочке классов и интерфейсов пройдешь - забываешь откуда начал. И, главное, непонятно для чего этот наворот был задуман. На сей счет ответа не было. Было только многозначительное "это же ООП". Вот так, из хорошего подхода, некоторые особи сооружают не пойми что. Хвала небесам удалось перейти в другой проект
С камерами при найме удаленщика - да, это разумно. Как-то раз нанял одного. Вроде ничего так парень, вроде работал первую неделю. Ну какая там работа - знакомился с проектом, командой и т.д. Потом получил первый таск, очень простой (для разминки, так сказать). Работы там было на пару часов (ну ладно, если сильно постараться, то на день). Делал неделю, стендапы пропускал. Что-то плел насчет поликлиники. Дальше хуже: пропадал на весь день. Причины стандартные: нет интернета, нет электричества. Причем в крупном городе с ГЭС неподалеку.
Все-таки, удалось взглянуть на него на видеоконференции. Все стало понятно: чувак бухает, причем конкретно. Лицо типичного алконавта. Пока как-то держится - более менее. Но максимум пару дней. А потом опять пропадает. Пришлось попрощаться. Жалко парня - явно не глупый, когда-то был хорошим разрабом, но в прошлом.
Так что смотрите сами - требовать видео или нет. Всякое бывает
Потому ну совершенно не удивляют ни минусы, ни отсутствие комментариев - тому, кто в теме, причины негатива очевидны
А тем, кто не в теме? Им-то что делать: верить или не верить материалу статьи? Если изложение плохое - пусть предложат альтернативы. Я бы, например, порекомендовал https://postgrespro.ru/education/books/dbguide Здесь все темы раскрыты достаточно подробно + книга свободна для загрузки.
Ну, нормальненький такой букварь для начинающих. Вот только не понял: те, кто минусил не оставили комментариев почему это сделали. Так невежливо, господа. Трусите объяснить и гадите втихаря?
Слушайте, ну это же очевидно. Чем меньше разработчика дергают на всякие встречи, созвоны, совещания и бог знает на что еще, тем разработчик продуктивней, качество кода однозначно растет, решения, принимаемые в процессе разработки, взвешеннее и логичнее. Сколько можно мусолить одно и то же. Главная задача менеджера не пальцы растопыривать, а обеспечивать спокойную рабочую обстановку. С техническими проблемами разработчики сами прекрасно разберутся.
Мне кажется, это потому, что нет разумных метрик оценки работы программиста. Количество строк кода? Да элементарно, сколько надо в день: 200/300/500/800? Скорость реализации? Давайте вспомним выбор между скоростью разработки (временем), качеством и стоимостью. Никак больше 2-х не выбирается. Качество? Как его оценить, по результатам тестирований? Пока код не попадет в прод - все это, по большому счету, некое приближение и надежды, что оно не слетит, не развалится под нагрузкой и т.д. А безопасность, устойчивость, пригодность к развитию? Вот честно, я не знаю. Как по мне, главное - качество, пусть за счет скорости реализации. Тогда не будет искушения вставлять пробелы на пару с подельником. Но система устроена так, что только успевай одни дыры латать другими и городить велосипеды. Видел проектик на java как-то. В одном классе было штук 5 методов по 3-4 тысячи строк достаточно плотного кода. Какой там SOLID )))
Эх, кабы так. У меня не очень большой опыт архитектуры: 4 года. Пришел в архитектуру из разработки (тут опыт уже немного больше: 20+). Купился на "масштабные проекты", "цифровую трансформацию" и прочий словесный мусор, полагающийся в таком случае. Оказалось, все не совсем так. Разработчики, действительно, не без успеха игнорировали и обходили достаточно много решений, заложенных в архитектуру. В частности, именно по причине того, что архитекторы (не все, конечно, но очень многие) совершенно не понимали и не хотели понимать как софт пишется. Более того, многие из архитекторов не только не стремились хоть что-то понять, но убежденно считали, что это им совершенно не нужно. По итогу - я сбежал обратно, в разработчики.
Понимаю, мой опыт нетипичен. Но подозреваю, что такого отношения архитектуры к разработке много где еще.
Дык куды ж без ихней мудрой отеческой заботы хрестьянину деваться )))
Инженеры, как раз физику знали: золото было предусмотрено изначально. Но, как обычно, влезли "эффективные" менеджеры. Подозреваю, что инженеры возражали, но кто будет их слушать
Не уверен. Го на порядки сложнее. Иной образ мышления. Надо думать не столько о материале, сколько о территории под контролем
Да, забыл. Было бы недурно не просто упомянуть Го, но и дать ссылки. Люди ленивы ) И позвольте в качестве дополнения порекомендовать хорошую книжку для чайников
Ну, хоть что-то конструктивное в вопросах работы с персоналом. А то одна вода. Правда, боюсь, Ваше предложение насчет Го будет недооценено (и это еще мягко сказано). Готовьтесь нахватать "минусов". Но я - плюсую.
Вроде в 3.14 запилили настоящую многопоточность и как-то gil обошли? Или я ошибаюсь?
Вы писали, что надо проходить фильтры эйчаров и собеседования с литкодом. В случае поиска на стороне - да. А своих - зачем пропускать через эту мясорубку? Поэтому и написал, что искать им никого не надо: из тех, кто есть вырастят
Так я понял из статьи, что разрабов им искать не надо: достаточно своих пхп-шников доучить
Да ерунда :) Пару месяцев на привыкание к синтаксису и в полный рост можно клепать круды, да джейсоны туда-сюда перекладывать. Тем более, примеров как это делается пруд пруди. А там, по ходу дела, постепенно догонят и остальное.
Вот для нагрузок, многопоточки, безопасности и прочих действительно сложных вещей, нужны сильные и опытные специалисты. Но немного. Их и правда, не один год "готовить" надо. Таких лучше нанять
В тоже видел в одном "зеленом" банчке. Правда, проект нишевый, для внутренних так сказать нужд. Те самые 7 уровней. Пока по цепочке классов и интерфейсов пройдешь - забываешь откуда начал. И, главное, непонятно для чего этот наворот был задуман. На сей счет ответа не было. Было только многозначительное "это же ООП". Вот так, из хорошего подхода, некоторые особи сооружают не пойми что. Хвала небесам удалось перейти в другой проект
С камерами при найме удаленщика - да, это разумно. Как-то раз нанял одного. Вроде ничего так парень, вроде работал первую неделю. Ну какая там работа - знакомился с проектом, командой и т.д. Потом получил первый таск, очень простой (для разминки, так сказать). Работы там было на пару часов (ну ладно, если сильно постараться, то на день). Делал неделю, стендапы пропускал. Что-то плел насчет поликлиники. Дальше хуже: пропадал на весь день. Причины стандартные: нет интернета, нет электричества. Причем в крупном городе с ГЭС неподалеку.
Все-таки, удалось взглянуть на него на видеоконференции. Все стало понятно: чувак бухает, причем конкретно. Лицо типичного алконавта. Пока как-то держится - более менее. Но максимум пару дней. А потом опять пропадает. Пришлось попрощаться. Жалко парня - явно не глупый, когда-то был хорошим разрабом, но в прошлом.
Так что смотрите сами - требовать видео или нет. Всякое бывает
А тем, кто не в теме? Им-то что делать: верить или не верить материалу статьи? Если изложение плохое - пусть предложат альтернативы. Я бы, например, порекомендовал https://postgrespro.ru/education/books/dbguide Здесь все темы раскрыты достаточно подробно + книга свободна для загрузки.
Ну, нормальненький такой букварь для начинающих. Вот только не понял: те, кто минусил не оставили комментариев почему это сделали. Так невежливо, господа. Трусите объяснить и гадите втихаря?
Эх, хтош так делает! Забыли святое: в пятницу деплой - в выходные геморрой )
Слушайте, ну это же очевидно. Чем меньше разработчика дергают на всякие встречи, созвоны, совещания и бог знает на что еще, тем разработчик продуктивней, качество кода однозначно растет, решения, принимаемые в процессе разработки, взвешеннее и логичнее. Сколько можно мусолить одно и то же. Главная задача менеджера не пальцы растопыривать, а обеспечивать спокойную рабочую обстановку. С техническими проблемами разработчики сами прекрасно разберутся.
Можно. Но за какой срок? ))) И из какого пункта отправления/прибытия?
Верно. И меня мой же руководитель зачпокает, поскольку его KPI тоже упадет. Со всеми вытекающими
Мне кажется, это потому, что нет разумных метрик оценки работы программиста. Количество строк кода? Да элементарно, сколько надо в день: 200/300/500/800? Скорость реализации? Давайте вспомним выбор между скоростью разработки (временем), качеством и стоимостью. Никак больше 2-х не выбирается. Качество? Как его оценить, по результатам тестирований? Пока код не попадет в прод - все это, по большому счету, некое приближение и надежды, что оно не слетит, не развалится под нагрузкой и т.д. А безопасность, устойчивость, пригодность к развитию? Вот честно, я не знаю. Как по мне, главное - качество, пусть за счет скорости реализации. Тогда не будет искушения вставлять пробелы на пару с подельником. Но система устроена так, что только успевай одни дыры латать другими и городить велосипеды. Видел проектик на java как-то. В одном классе было штук 5 методов по 3-4 тысячи строк достаточно плотного кода. Какой там SOLID )))
Получается, Докинз в своем "Эгоистичном гене" (1976) все-таки выдвигал достаточно здравое предположение о влиянии мемов :)