Здравствуйте, IB, Вы писали:
V>>Я жду пояснений, почему у студента, который работал совместно (в том числе) с аспиранткой над проектом, должны были появиться вредные навыки? IB>Потому, что ему ставят другие задачи, по другим требованиям в других условиях, что вырабатывает привычки, которые потом придется ломать.
Какие другие задачи?
Какие другие требования?
Насчёт "условий" промолчу — там можно наспекулировать целый короб.
Но ты уже в 3-й раз не можешь ответить, какие вредные привычки?
Какие полезные вырабатываются — я перечислял.
От тебя пока ничего вразумительного.
V>>Я сужу по твоим словам. IB>А не надо меня судить, не судим будешь )
Тогда давай конкретней.
V>>Прежде чем придираться к оценке твоих слов тебе следовало бы дать что-нибудь конкретное. IB>Прежде всего, не следует меня оценивать, мы здесь не меня обсуждаем.
Я не виноват в том, что ты оставляешь слишком много простора для додумывания.
V>>Как правило больше половины выпускников IT-специальностей по специальности не работают. V>>Будем распространять это правило на меньшую половину реально работающих? )) IB>На любую половину, какая больше нравится.
На тех, что трудятся в IT, итак?
V>>>>Ты свои представления откуда черпаешь, позвольте спросить? IB>>>Из практики. V>>Из своей? IB>Из практики работы со студентами, кандидатами, стажерами и т. д.
Характер практики какой?
Что делаете?
Как организована работа?
Какая приёмка?
Сколько вложено усилий в органиацию работ и сколько в саму работу?
Тут бесконечный список вопросов, давать заранее ответы бесполезно.
V>>Ткни меня в конкретные примеры, плиз. IB>Пример я уже приводил — недавно мы взяли нескольких ребят из Стенфорда на побочный проект. Ребята толковые, на недостаток вузовской практики тоже жаловаться не могут, но из попытки самостоятельной работы получились слезы.
Столько слов и ни одного конкретного.
IB>Причина проста — у выпускников нет навыка работы в команде
Странно, а мы работали именно в команде. ))
IB>нет навыков следования стандартам
Тут помолчу, бо в плане ГОСТ-ов у нас было совсем страшно.
После ГОСТ-ов ни один стандарт не кажется сложным, так, мелкотня.
IB>навыков разбираться в чужом коде, навыков писать не сколько оптимальный, сколько поддерживаемый код, нет навыков писать понятный код, нет навыков проектировать сложные, но понятные решения, которые потом можно будет сопровождать и расширять, нет навыков писать код, когда требования меняются, нет навыков даже просто писать код по формальным требованиям.
Звучит как отсутствие вообще какой-либо практики работы над большим совместным проектом.
А сколько надо лет, чтобы научиться?
IB>Все эти навыки зачастую противоречат тому, что дается в вузе
В разделе "системный подход" даётся именно то, на отсутствие чего ты жаловался.
Причём, даётся более чем хорошо.
Анализ задач, анализ путей решения, проектирование жизненного цикла изделия, проектирование надежности продукта, проектирование самого процесса разработки.
И да, я помню, что ты учился на чуть другой специальности, не на системотехника.
Инженеры-системотехники должны осуществлять исследовательскую, методическую и методологическую деятельности. Главное, чем должен владеть специалист, — умение применять все полученные знания для решения двух основных системотехнических задач: управления процессом создания сложной системы и обеспечение интеграции частей этой системы в единое целое.
Да, я прекрасно сам наблюдал беспомощность не-системотехников и тем более переученных на программеров с других специальностей.
Потому что сама методология разработки сложных в информационном смысле систем для них — это китайская грамота.
По-сути, они потом должны самостоятельно изучать то, что дают в ВУЗ-е на профильной специальности.
IB>как показывает практика — больше всего возни с олимпиадниками, они уже звезду схватили, но еще не понимают, что в практическом плане толку от них пока ноль.
Смотря по какой специальности олимпиада.
V>>Боюсь, одно от другого плохо отделяется, IB>Прекрасно отделяется. Навык — это рефлексы и привычки, а знания — это информация.
Боюсь, для моска одно от другого неотделимо. ))
Везде информация и навык оперировать ею.
V>> бо за навыками либо стоит понимание "почему так", либо эти навыки не закрепляются. IB>Вот именно. И вузе просто нет повода выработать эти навыки, они приходят с опытом работы на реальных задачах.
Собачачья чушь. ))
Пока что ты обрисовал до боли знакомую картину — в ВУЗ-е ребят учили на одну специальность, а работать приходится по другой.
Я когда с такими сталкиваюсь, даже с уже относительно опытными — тоже плачу крокодиловыми слезами.
При таких раскладах светошумовые эффекты могут быть произвольными, понятно, бо в наборе знаний об организации разработки зияет бездонная пропасть.
Особенно тяжело с теми, которые непрофильные, но уже "опытные", бо Мнение Имеют Хрен Оспоришь.
А ни до чего критического подпускать всё-равно нельзя.
Даже человек, который за 10+ лет научился неплохо проектировать ООП-системы в целом, его всё-равно можно допускать лишь до относительно узкого класса задач.
Чуть что шаг вправо-влево — паника, неумение выбрать решение, отсутствие ориентирования в трудоёмкости смежных областей, отсутствие понятия — как вообще эти смежные области окучиваются, в итоге зацикливание на чём-то одном еще на стадии предварительного обсуждения.
Собсно, вот одно из ранних обсуждений так и не состоявшейся разработки здесь на сайте: http://www.rsdn.org/forum/prj/365664.1
Когда на полном серьёзе для генератора отчётов предлагалось сделать сердцем "XSLT".
Примерно отсюда мне всё стало понятно, и я махнул рукой: http://www.rsdn.org/forum/prj/369802.1
Там народ поотлетал просто от самого взятого упоротого тона обсуждания, но автор такого тона этого даже не заметил, мамой клянусь. ))
Гибкости и развития в процессе обсуждения — ноль.
Упорость близорукостью погоняет.
Результат предсказуем.
Ты там что-то заикался об умении работать в команде?
Это умение начинается с умения вникать в то, что тебе говорят, для начала.
Это умение делиться опытом и умение его черпать в свою очередь.
Это умение быть конструктивным и максимально полезным.
Это умение иногда просто засунуть язык в ж-пу, уж прости мне прямую речь.
У некоторых с годами наблюдаю ровно обратное — деградацию перечисленных умений.
Т.е., годы опыта порой во вред. ))
И уровень "рассуждений" с тех пор особо не поменялся.
Всё вот так же — по верхам.
Прикладную обвязочку сделать? — да, можно, тут мы мега-архитекты и вообще уважаемые люди.
Самим платформенное что-то накатать — да ты шо? Как можно?
V>>Это в два раза ниже по рынку. IB>По какому рынку?
Здравствуйте, alexzzzz, Вы писали:
A>Ну принято считать и все (многие) постоянно говорят, что "нормальный" программист должен знать алгоритмы, а какие алгоритмы, не говорят. На одних только графах алгоритмов миллион на все случаи жизни, из них половина ищут кратчайшие пути. И непонятно, где проходит та черта, до которой знать надо, а после — не обязательно. Чем нужные отличаются от ненужных?
Должен знать не алгоритмы. А хотя бы куда копать, и направление должно быть правильным.
А то типичное собеседование. Предметная область связана с логистикой и частично с алгоритмами, в результате в требованиях стоит "базовые знания Computer Science":
— чем занимались?
Высокочастотный трейдинг, хайлоад, big data, кластеры, сеньер разработчик, фулстек и т.д. Начинается разговор про корабли бороздящие просторы вселенной
(по разговору про корабли видишь, что резюме не такое крутое и он занимался в основном саппортом космического корабля на деле. Технологии, которые указаны, на деле сам не использовал, они просто использовались в проекте. По синтаксису языка спрашивать не хочется, скучно, знаешь что можно и сильного завалить при желании, тем более что писать придется на другом языке. По разговору по общей культуре программирования понимаешь, что язык знать должен, уровень средний, про всякие CI GIT, тестирование и т.д к счастью слышал, вроде не случайный в ИТ человек. И теперь переходим собственно к проверке базовых знаний, есть ИТ образование или нет).
— как у вас с алгоритмами?
Нормально
— игру lines знаете?
нет
— ладно, рисую доску, объясняю правила. Говорю что нужно ткнуть в 2 точки, и далее программа должна нарисовать путь из точку А в Б и он должен показаться. Как будете делать, какие подходы примените. Решать не надо, просто навскидку что будете делать, по каким словам гуглить?
Ступор на несколько минут. Далее что то вроде идем в одну сторону, упираемся в препятствие, идем вниз на одну клеточку, идем снова пытаемся. Блин. Через 10 минут — ладно, нет идей, задача очень сложная.
— ладно. Есть директория, в жтой директории включены другие директории. Нужно найти в этой директории файл. Как будете решать задачу?
Ступор не несколько минут. Попробую циклом в первую попавшуюся. Блин, этож надо как то вернуться. Сдаюсь.
— ладно. Структура данных типа дерево знакома?
нет.
— ладно. Вы игтегритесь со сторонним сервером. Он возвращает JSON из ИД и ФИО. Но там ошибка, он возвращает дубликаты, и вам нужно на фронтэнде чтобы дубликаты не показывались. Как будете решать?
Ступор. Через 2 минуты — через вложенный цикл.
— Какая вычислительная сложность у этого алгоритма?
Не понял, что такое вычислительная сложность?
— Ладно. А вообще какой ВУЗ заканчивали?
Что то вроде ЛЭТИ или ИТМО или Бауманки, что то вроде прикладной математики.
— программирование было, у вас точно ИТ образование?
Было. Писали на Турбо паскале.
— ладно, а как с математикой?
Хорошо, был отличником, красный диплом.
— что такое синус гиперболический?
нет ответа
— чем занимались на дипломе. Что лучше всего знаете?
Теорию вероятностей.
— Что такое плотность вероятнорсти?
Ступор. Не помню.
— Сколько хотите денег
300 тысяч рублей на руки.
Приукрасил маленько, это один из самых запущенных случаев, но такое наблюдаю частенько. Наблюдается как у опытных, которым за 40 лет, так и у студентов.
Здравствуйте, LaptevVV, Вы писали:
S>>Проффессор если не секрет, а когда вы книжки читаете (в какое время) LVV>Ну, по-разному бывает. LVV>Сечас вот купил книжки по фронт-енду. LVV>Почитываю и пытаюсь выполнить то, что там написано...
LVV>>По какой теории? S>книги по теории алгоритмов и дискретной математике
По алгоритмам — Кормен, Сэджвик, Кнут, Вирт.
Ну и по мелочи их очень много.
А по дискретке — в первую очередь Новиков. Есть еще пара переводных.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Почему у тебя промышленная разработка, а у других кустарная? НС>Не у других, а у тебя. Как еще можно назвать, когда вчерашние студенты ваяют что то программно-аппаратное, основываясь на надыбанной где то коробке микроконтроллеров?
Я разве только об этом случае говорил?
И тот пример не про Пики, а про умение создать инфраструктуру для разработки.
Просто пример сочный.
Так-то организовывать инфраструктуру, писать кучи вспомогательных утилит/сервисов или изготавливать стендовое/тестовое оборудование приходилось постоянно.
И сейчас приходится — всевозможные эмуляции бирж, эмуляции гонок в алгоритмах, эмуляция сетки как таковой (сокетов и всего АПИ сверху, под низом эмулятор, которому можно задавать всякие "капризы" сети, бо от реальной сетки детерминированно всевозможных ситуаций не добъешься для целей тестирования) и т.д.
Собсно, когда по удалёнке разрабатывал в штатовской конторе авионику, на самом деле сходу подключили к разработке именно диагностического комплекса.
Ну у меня там в резюме как раз нормально описано было про разработку инфраструктуры и вспомогательных утилит в том числе.
И вот "пришёл" бывший студент, 4 года как ВУЗ закончил, за 5 недель выкинул нафик имеющийся код от 40-калетних опытных дядек, уложился в меньший объем кода, в большую его понятность, получил втрое большую вероятность обнаружения коллизий (т.е. даже самых кратковременных), еще и саму железку переразвёл для лучшей помехозащищённости. Всего полтора месяца и полугодовой (до меня) проект был закончен. Те офигели и доверили сходу разработку мажоритарного хаба, который от тройного резервирования принимает решение о достоверности сигнала, мониторит состояние самих линий и шлёт инфу центральному блоку о состоянии линий и датчиков. Я их тогда научил автоматному проектированию алгоритмов, что вместо 3-х процов оказалось достаточно одного и что физически невозможно "забыть обработать else или код ошибки", бо на выходе большая детерминированная таблица и возможность как угодно подробно проэмулировать работу всей этой кухни без железа.
Сам этот хаб считался самой ответственной частью проекта.
После моего опыта в институтской лаборатории — в зубах поковыряться.
Просто подработка по вечерам, которая в месяц приносит годовой оклад основной работы.
В общем, удалённо работал дофига.
Ездил в Штаты работать лично потом.
Везде повальное нубство.
Даже больше, чем у нас. ))
НС>И да, я сам точно так же поучаствовал в разработке системы захвата цели для Ми-28Н. И там мы даже не ориентировались на коробку с микросхемами, а честно покупали комплект разработчика для Xilinx, который десятки килобаксов в середине 90-х стоил.
У тебя не "мы", а государство, Xilinx — это про FPGA.
Официальный ассемблер от ПИК-ов я чуть позже видел, когда до нас интернет нормальный дошёл.
Работал медленнее моего.
Среды разработки НЕТ.
А у нас была почти сразу.
Т.е., от наличия официального ассемблера толком ничего не поменялось бы — сэкономил бы 2-3 недели, что не принципиально.
Ну и, "мы" — это уже после ВУЗ-а, просто несколько ребят, которые друг друга в той лаборатории нашли, а не сам ВУЗ.
На тех пиках делали системы телефонной транкинговой связи и рекламные бегущие огни.
Как бэ сравни вложения в Ми-28 и в рекламные огни. ))
Тем более, что вложения из наших же карманов.
Хотя время такое было — заводы гибли, мы за копейки натащили себе дохрена оборудования, местами даже высокоточного.
У меня гораздо большей головной болью было наладить мелкосерийный выпуск импульсников на 10-20 киловольт под неон.
Тоже центром "разработки" стала довольно-таки сложная утилита теплового расчёта импульсных трансформаторов.
Сравнительной утилиты я не видел до сих пор.
Отдельные аспекты обсчёта вижу, а в комплексе, чтобы автоматически-итеративно, на каждой итерации корректируя рабочую температуру и беря из БД уточнённые характеристики ферритов — нет.
Да я вообще не видел, чтобы народ с лёгкостью в одном проекте интегрировал Пролог, С++ и VB. ))
VB для "кнопок", Пролог для поиска решений, С++ для остального.
НС>И тем не менее ничего общего с современной промышленной разработкой софта это не имело, все было в определенных аспектах сильно проще.
Потому что тебе задачу узкую поставили.
Ты не занимался организацией процесса разработки, ты уже в процесс пришёл.
У тех, кто стоял повыше, информационная сложность была приличная, уверен, и вопросы организации самой разработки не на последнем месте.
Сейчас, скорее всего, занимаешься в первую очередь выделенным, верно?
Здравствуйте, vdimas, Вы писали:
V>Какие другие задачи?
Не прикладные.
V>Какие другие требования?
Не от продактов, а от научного руководителя.
V>Насчёт "условий" промолчу — там можно наспекулировать целый короб.
Вот и хорошо, не надо спекулировать )
V>От тебя пока ничего вразумительного.
То что тебе не нравится, это не значит что оно не вразумительное.
V>Я не виноват в том, что ты оставляешь слишком много простора для додумывания.
А ты не додумывай, мы же не меня обсуждаем.
V>На тех, что трудятся в IT, итак?
Что и так? Я выше все написал.
V>Характер практики какой? V>Что делаете? V>Как организована работа? V>Какая приёмка? V>Сколько вложено усилий в органиацию работ и сколько в саму работу? V>Тут бесконечный список вопросов, давать заранее ответы бесполезно.
На что ответы и к чему эти вопросы?
V>Столько слов и ни одного конкретного.
Да, кейс для тебя не удачный, но он очень конкретный.
V>Странно, а мы работали именно в команде. ))
Рад за вас, но это не значит, что у вас появился этот навык.
V>Тут помолчу, бо в плане ГОСТ-ов у нас было совсем страшно. V>После ГОСТ-ов ни один стандарт не кажется сложным, так, мелкотня.
Вот-вот, по ГОСТУ навык может и приобрелся бы, а по уму — нет.
V>Звучит как отсутствие вообще какой-либо практики работы над большим совместным проектом.
Именно так.
V>А сколько надо лет, чтобы научиться?
По разному, обычно около года постоянной работы и вправления мозга от старших товарищей.
V>В разделе "системный подход" даётся именно то, на отсутствие чего ты жаловался.
Ага, теоретически.
V>Анализ задач, анализ путей решения, проектирование жизненного цикла изделия, проектирование надежности продукта, проектирование самого процесса разработки.
И все это бесконечно далеко от того, что встречается в реальной жизни.
V>И да, я помню, что ты учился на чуть другой специальности, не на системотехника.
В последний раз напоминаю, что обсуждаем здесь не меня.
V>Да, я прекрасно сам наблюдал беспомощность не-системотехников и тем более переученных на программеров с других специальностей.
А я наблюдал беспомощность системотехников, особенно профильных специальностей, специалистов с корочками "программная инжинерия" и другими красивыми словами.
V>Пока что ты обрисовал до боли знакомую картину — в ВУЗ-е ребят учили на одну специальность, а работать приходится по другой.
Эта картина не зависит от специальности.
V>Это умение начинается с умения вникать в то, что тебе говорят, для начала. V>Это умение делиться опытом и умение его черпать в свою очередь. V>Это умение быть конструктивным и максимально полезным. V>Это умение иногда просто засунуть язык в ж-пу, уж прости мне прямую речь. V>У некоторых с годами наблюдаю ровно обратное — деградацию перечисленных умений. V>Т.е., годы опыта порой во вред. ))
Да! Вот сейчас все верно рассказал =)))
V>По доступному для проживающих в СНГ, ес-но.
Если бы в СНГ был доступен рынок, где среднему разработчику платили бы 300-360, то в мск платили бы уже больше )
Тут и так рынок перегрет, и явно переплачивают.
Здравствуйте, IB, Вы писали:
V>>Какие другие требования? IB>Не от продактов, а от научного руководителя.
Это у аспирантов научный руководитель.
А над инженерной разработкой конкретный руководитель проекта.
Научные руководители у него, считай, в подчинении, он им выдает т.н. "темы".
V>>От тебя пока ничего вразумительного. IB>То что тебе не нравится, это не значит что оно не вразумительное.
Т.е. ничего вразумительного можно не ждать?
V>>Я не виноват в том, что ты оставляешь слишком много простора для додумывания. IB>А ты не додумывай, мы же не меня обсуждаем.
Мы обсуждаем, что же именно ты сказал.
Простора для додумываний пока овердофига.
V>>Сколько вложено усилий в органиацию работ и сколько в саму работу? V>>Тут бесконечный список вопросов, давать заранее ответы бесполезно. IB>На что ответы и к чему эти вопросы?
Да вы тут абстрактно охаете, ахаете, а по факту распространяете известные городские легенды. ))
Да, упоротость в чистую академку с лютыми ГОСТ-ами и чудовищной информационной иерархией проекта или, наоборот, в совсем простой "полуинженерный" подход, где на верхнем уровне лишь формы, сверху кнопки, а вся макаронная логика сидит в OnClick — это два полюса, над которыми полно потешных историй.
Но работающая реальность всегда где-то посередине.
А потешные истории чаще исключения.
V>>Столько слов и ни одного конкретного. IB>Да, кейс для тебя не удачный, но он очень конкретный.
Какой кейз?
Ты с кем разговариваешь?
V>>Странно, а мы работали именно в команде. )) IB>Рад за вас, но это не значит, что у вас появился этот навык.
Как ты определил?
V>>После ГОСТ-ов ни один стандарт не кажется сложным, так, мелкотня. IB>Вот-вот, по ГОСТУ навык может и приобрелся бы, а по уму — нет.
Решил опять начать хамить? ))
V>>Звучит как отсутствие вообще какой-либо практики работы над большим совместным проектом. IB>Именно так.
Это у вас так, я уже понял.
Потому что ВУЗ не вёл реальных больших проектов.
Это был псевдо-ВУЗ.
Или ты был псевдо-студент, если тебя на такие проекты не брали.
Мои соболезнования.
V>>А сколько надо лет, чтобы научиться? IB>По разному, обычно около года постоянной работы и вправления мозга от старших товарищей.
Т.е. 3 года в ВУЗ-е практики мало, а года после ВУЗ-а достаточно.
Ты сам это сказал.
V>>В разделе "системный подход" даётся именно то, на отсутствие чего ты жаловался. IB>Ага, теоретически.
Нет в ВУЗ-е ничего чисто теоретического.
Обязательно практика сверху.
V>>Анализ задач, анализ путей решения, проектирование жизненного цикла изделия, проектирование надежности продукта, проектирование самого процесса разработки. IB>И все это бесконечно далеко от того, что встречается в реальной жизни.
Не повезло тебе.
V>>И да, я помню, что ты учился на чуть другой специальности, не на системотехника. IB>В последний раз напоминаю, что обсуждаем здесь не меня.
Мы обсуждаем твою точку зрения.
Она не из вакуума взялась, а от твоего субъективного опыта.
V>>Да, я прекрасно сам наблюдал беспомощность не-системотехников и тем более переученных на программеров с других специальностей. IB>А я наблюдал беспомощность системотехников, особенно профильных специальностей, специалистов с корочками "программная инжинерия" и другими красивыми словами.
"Программная инженерия" — это примерно твоя специальность, если что. ))
Моя — "инженер-системотехник".
М/у ними пропасть.
Ты с ними не встречался потому, что без смеха инженеры-системотехники твои статьи середины 2000-х читать не смогли бы.
Без обид.
Это разные непересекающиеся уровни реальности.
Ты обитаешь на своём, они на своём.
Они делают, ты потребляешь.
Я занимался учётными системами только по весьма замысловатому стечению обстоятельств — вокруг развал, а интернета еще не было.
А уже двое на руках.
И это единственная разновидность "чистого софта", который тогда можно было продавать в кач-ве "подработки".
Стоило дойти до нас интернету и получить спустя год после этого первую тыщщу долларов за месячную подработку — и всё резко поменялось.
Никакими продажами подобного софта столько в моей местности не заработаешь. ))
С тех пор пашу только на буржуев.
И по официальной работе и по периоду, когда много подрабатывал или фриланствовал.
V>>Пока что ты обрисовал до боли знакомую картину — в ВУЗ-е ребят учили на одну специальность, а работать приходится по другой. IB>Эта картина не зависит от специальности.
Это известное самооправдание.
V>>По доступному для проживающих в СНГ, ес-но. IB>Если бы в СНГ был доступен рынок, где среднему разработчику платили бы 300-360, то в мск платили бы уже больше ) IB>Тут и так рынок перегрет, и явно переплачивают.
Если ты сейчас меня не троллишь, то это натуральное ой.
Хотя, НС тут неоднократно утверждал обратное.
Кто из вас врёт?
Здравствуйте, vdimas, Вы писали:
V>>>Почему у тебя промышленная разработка, а у других кустарная? НС>>Не у других, а у тебя. Как еще можно назвать, когда вчерашние студенты ваяют что то программно-аппаратное, основываясь на надыбанной где то коробке микроконтроллеров? V>Я разве только об этом случае говорил?
Тем не менее пример отличный, хорошо демонстрирующий суть проблемы.
V>И вот "пришёл" бывший студент, 4 года как ВУЗ закончил, за 5 недель выкинул нафик имеющийся код от 40-калетних опытных дядек, уложился в меньший объем кода, в большую его понятность, получил втрое большую вероятность обнаружения коллизий (т.е. даже самых кратковременных), еще и саму железку переразвёл для лучшей помехозащищённости.
Ну значит такие рукожопе дядьки были. Вообще, качество софта железячников — притча воязыцех.
НС>>И да, я сам точно так же поучаствовал в разработке системы захвата цели для Ми-28Н. И там мы даже не ориентировались на коробку с микросхемами, а честно покупали комплект разработчика для Xilinx, который десятки килобаксов в середине 90-х стоил. V>У тебя не "мы", а государство, Xilinx — это про FPGA.
Да ты прям глаза мне открыл.
НС>>И тем не менее ничего общего с современной промышленной разработкой софта это не имело, все было в определенных аспектах сильно проще. V>Потому что тебе задачу узкую поставили.
Нет. Потому что разработка софтовой части была кустарной.
V>Ты не занимался организацией процесса разработки, ты уже в процесс пришёл.
Там не было никакой организации. Как не было у тебя с твоими пиками и датчиками.
V>У тех, кто стоял повыше, информационная сложность была приличная, уверен, и вопросы организации самой разработки не на последнем месте. V>Сейчас, скорее всего, занимаешься в первую очередь выделенным, верно?
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Ты не занимался организацией процесса разработки, ты уже в процесс пришёл. НС>Там не было никакой организации. Как не было у тебя с твоими пиками и датчиками.
Тебе не надоело ходить вокруг да около? ))
Я так и не смог добиться от вас формулировки отличия кустарщины от некустарщины.
Правильная организация разработки может быть даже у единичного разработчика.
Тем более у группы их.
Размер группы тут не определяющий.
Определяющим является степень методологической полноты процесса и, разумеется, соответствие этого процесса характеру конкретной разработки.
Под кустарщиной же понимается стадия лишь наивных экспериментов.
В этом смысле никакие дорогие купленные ср-ва разработки не являются признаком некустарщины.
У богатеньких могут быть свои причуды. ))
А на деле работает поговорка "без ума креститься" далее ты в курсе.
Определяющим является понимание процесса целиком.
Здравствуйте, vdimas, Вы писали:
V>Тебе не надоело ходить вокруг да около? )) V>Я так и не смог добиться от вас формулировки отличия кустарщины от некустарщины.
Очень плохо. У некустарщин есть процесс и есть какие то вещи типа SLA. У кустарщины всего этого нет.
V>Правильная организация разработки может быть даже у единичного разработчика.
Ты, опять же, по прежнему не понимаешь о чем разговор, потому и ответа не видишь. Организация это не распорядок дня и ритуальные танцы вокруг, это прежде всего способность команды раз за разом выдавать стабильный и качественный результат, без авралов и пинания балды, в условиях постоянно меняющихся требований. Когда речь про одного-двух разработчиков, просто нет проблемы, которую нужно решать.
V>Размер группы тут не определяющий.
Тогда смысла тебе объяснять просто нет. Ты все равно не поймешь.
Здравствуйте, elmal, Вы писали:
E>- ладно, рисую доску, объясняю правила. Говорю что нужно ткнуть в 2 точки, и далее программа должна нарисовать путь из точку А в Б и он должен показаться. E>- ладно. Есть директория, в жтой директории включены другие директории. Нужно найти в этой директории файл. Как будете решать задачу? E>- ладно. Структура данных типа дерево знакома? E>- ладно. Вы игтегритесь со сторонним сервером. Он возвращает JSON из ИД и ФИО. Но там ошибка, он возвращает дубликаты, и вам нужно на фронтэнде чтобы дубликаты не показывались. Как будете решать? E>- Какая вычислительная сложность у этого алгоритма? E>- что такое синус гиперболический? E>- Что такое плотность вероятнорсти?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>У некустарщин есть процесс
Верно.
НС>есть какие то вещи типа SLA.
Еще 15 лет назад значение этого термина было немного другое чем сегодня, в эпоху облаков и победившей жиры.
Сам по себе этот элемент опциональный, особенно для времён, когда все выч. ср-ва, располагаемые конторой, ею же и обслуживались, со всеми следствиями в плане разворачивания и администрирования.
НС>У кустарщины всего этого нет.
У кустарщины всё это есть, особенно в последние годы, т.е. набор доступных и там и там сервисов абсолютно идентичный.
Более того, эти сервисы ВСЕГДА развиваются в первую очередь для кустарщины (того же большинства опенсорса) и лишь потом, достигнув некоей зрелости, становятся интересны более-менее серьёзным коммерческим разработкам.
Т.е всё с точностью до наоборот пока. ))
V>>Правильная организация разработки может быть даже у единичного разработчика. НС>Ты, опять же, по прежнему не понимаешь о чем разговор, потому и ответа не видишь.
Я хорошо понимаю, что именно вы с IB пролетарским чутьём чуете, а сказать не можете.
Не вы первые, не вы последние.
Могу дать описательные формулировки по большинству аспектов некустарного производства.
Их довольно много, некоторые в базе весьма академичны, с теоремами/леммами, но они давно переведены для рабочего класса в т.н. "метрики", которые хорошо работают как в ПО, так и в железе.
=====================
В общем, ни один из вас еще в яблочко не попал.
Разумеется, ни покупная дорогая система, ни SLA не являются признаком некустарщины.
Это всё доступно любому любопытному, располагающему кое-какими ср-вами и свободным временем.
Ни кол-во человек (если брать просто число людей), ни даже само распределение их обязанностей, ни сердитый шеф, ни кофе с печеньками — всё не показатель.
Я более одного раза наблюдал симуляцию "настоящей работы" в условиях, когда никто не имеет ни малейшего представления, как эту работу организовать.
Но так-то все внешние признаки "настоящей работы" на лицо.
И даже что-то как-то делалось и даже продавалось.
Но в наше время слишком большой местами спрос на тот же заказной софт, поэтому кустарщина цветёт и пахнет, ес-но.
НС>Организация это не распорядок дня и ритуальные танцы вокруг, это прежде всего способность команды раз за разом выдавать стабильный и качественный результат, без авралов и пинания балды, в условиях постоянно меняющихся требований.
Угу.
Под какой-то неширокий круг задач такую команду можно "заточить" на интуитивном уровне, согласен.
Т.е. методом проб и ошибок нащупать нечто работающее.
Ну или кто-то опытный принесёт опыт с прошлого места работы.
Или даже с более чем одного прошлого места.
Но возможности нормального управления ресурсами тут не будет, бо будете держаться за однажды нащупанные подходы, которые на некоей разработке давали неплохой результат.
А если заметно изменился сам характер разработки, то "опыт предыдущей разработки будет вреден" (С) — аккурат по заветам IB. ))
(я ведь хорошо понимаю, что он там пытался сказать, а главное — почему он пытался сказать именно это)
В отсутствии на уровне мозжечка общей схемы, каждая частность будет казаться "слишком другой".
Да,я обратил своё внимание на вашу реакцию насчёт "акцентов" — примерно такая: "да ну, херня какая-то". (С)
Т.е. без малейшего понятия у обоих, т.е. вы оба, разумеется, чистейшей воды самоучки/самородки в области организации разработки (если заниматесь этим, конечно).
Вернее, даже не самоучки, нет. Самоучки хоть что-то учат.
Вы именно "самородки". ))
Сам факт того, что общая схема некустарной разработки всегда одна и та же для совершенно разных по характеру проектов — она же порвёт вам моск, верно?
Например, что для написания сайта-магазина 3-мя человеками, что разработка софта космической ракеты коллективом из 100 человек.
Я хорошо помню твою точку зрения, что ты считаешь кол-во информации на душу разработчика эдаким "водоразделом".
Мол, тут на два порядка больше информационный объем, чем там. ))
Огорчу — оно примерно одинаковое, коль люди одинаково не тупые или одинаково тупые.
Но характер этой информации разный.
А количество её всегда столько, чтобы ею был способен оперировать далеко не глупый человек среди хомо сапиенс — грамотный инженер.
Причём, в космосе на человека приходится намного больше информации, бо уделяется большое внимание её всевозможной каталогизации и навигации.
То бишь инфа хорошо "уплотняется", ей проще оперировать, отсюда можно эффективно оперировать большим её объёмом.
А в "обычной разработке" возможности современной выч.техники именно в плане организации проектной информации фактически не используются.
Дальше баг/фич-трекеров и пул-реквестов не ушли.
Это примерно 15-20% от требуемого, и то с натяжкой.
Невезде так, но это явный мейнстрим.
V>>Размер группы тут не определяющий. НС>Тогда смысла тебе объяснять просто нет. Ты все равно не поймешь.
Русским языком если оформить — понял бы любой, ес-но.
Но ты не сможешь вот так, с кондачка.
А попытался бы хотя бы раз (чиста для себя) сформулировать свои ощущения, потом несколько раз критически пройтись по написанному с исправлениями — и с вероятностю 99% удивишься, насколько записанное в конечном варианте станет не похожим на то, чем ты сейчас пытаешься оперировать сугубо через ощущения/эмоции.
Это я еще не стал с первой итерации придираться к самим формулировкам "всё-равно не поймёшь".
Одновременно и забавно, и хамство, и демонстрируемая слабость позиции в споре — всё в одном флаконе.
Я бы желал быть избавленным от всего этого набора.
Здравствуйте, vdimas, Вы писали:
V>Это у аспирантов научный руководитель. V>А над инженерной разработкой конкретный руководитель проекта. V>Научные руководители у него, считай, в подчинении, он им выдает т.н. "темы".
О чем и речь. Это бесконечно далеко от того, чем приходится заниматься в коммерческой разработке, цели другие.
Я больше скажу, разница между разработкой коробки, sdk и софта для интеграторов такая, что людей переучивать приходится, не говоря уже о внутренней разработке, а тут вообще другой мир.
Тебе правда нужно объяснять, в чем разница между разработкой софта за который будут готовы платить деньги и софта, который удовлетворит научного руководителя?
V>Т.е. ничего вразумительного можно не ждать?
Оно уже было, просто ты не заметил, слишком увлекся расписыванием того, какой ты был крутой в студенчестве )
V>Мы обсуждаем, что же именно ты сказал.
Вот именно, а тебя почему-то все время тянет меня обсудить, а не то что я сказал.
Сдерживай себя, иначе за тебя это сделают другие.
V>>>Странно, а мы работали именно в команде. )) IB>>Рад за вас, но это не значит, что у вас появился этот навык. V>Как ты определил?
Я ничего не определял, я сделал логический вывод о том, что из одного не обязятельно следует другое. Поскольку, повторюсь, работа в команде над научным проектом и работа над коммерческим это совершенно разный опыт, так как цели другие.
V>Это у вас так, я уже понял. V>Потому что ВУЗ не вёл реальных больших проектов. V>Это был псевдо-ВУЗ. V>Или ты был псевдо-студент, если тебя на такие проекты не брали. V>Мои соболезнования.
Вот в этом разница между моим опытом и твоим. Обовсем ты судишь исключительно по себе и проецируешь это на всех остальных, поэтому тебе так сложно удержаться от перехода на личности.
Я же, в данном случае, сужу не по собственному опыту, в студенчестве я тоже был круче брюс виллиса, и еще в школе лазал через забор в МИФИ, чтобы ковыряться вместе со студентами на их проектах, но сейчас это вызывает только умиление.
Я сужу по опыту уже наверное сотни студентов, которые прошли через меня, как с наших кафедр, так и нет, и сдается мне, выборка у меня по репрезентативнее будет.
V>Т.е. 3 года в ВУЗ-е практики мало, а года после ВУЗ-а достаточно. V>Ты сам это сказал.
Именно так, поскольку, как уже говорилось, вузовская практика имеет мало отношения к реальной работе.
За редким исключением, типа нас, когда мы берем студентов к себе на реальные коммерческие проекты, но тут опять же все проходит дольше, так как студент еще учится параллельно.
V>Моя — "инженер-системотехник". V>М/у ними пропасть. V>Ты с ними не встречался потому, что без смеха инженеры-системотехники твои статьи середины 2000-х читать не смогли бы. V>Без обид.
Да уж какие обиды, раз люди ко мне до сих пор по этим статьям приходят и просят проконсультировать, значит не зря писал. Хотя они, конечно, не для системотехников ))
V>Это разные непересекающиеся уровни реальности. V>Ты обитаешь на своём, они на своём.
Да, я уже понял, что настоящих системотехников готовят только в севастпольском политехе, и выпускники МГУ, Физтеха, МИФИ, Бауманки и НГУ им в подметки не годяться ) И вообще, они такие звери, что их оттуда даже не выпускают, чтобы они, упаси байт, индустрию не взорвали =))
V>Это известное самооправдание.
Мне себя оправдывать не надо, если я своей карьерой и детскими увлечениями не хвастаюсь, это не значит, что я ими не доволен и не горжусь )
IB>>Тут и так рынок перегрет, и явно переплачивают. V>Если ты сейчас меня не троллишь, то это натуральное ой.
Троллю немного конечно, но не очень понимаю что тут "ой".
V>Хотя, НС тут неоднократно утверждал обратное.
Я не знаю что ты там у него вычитал...
Здравствуйте, IB, Вы писали:
IB>Я больше скажу, разница между разработкой коробки, sdk и софта для интеграторов такая, что людей переучивать приходится, не говоря уже о внутренней разработке, а тут вообще другой мир.
ЧТД, я сразу кое-то заподозрил и ты здесь прямой речью об этом.
Спасибо.
IB>Тебе правда нужно объяснять, в чем разница между разработкой софта за который будут готовы платить деньги и софта, который удовлетворит научного руководителя?
Даже если в последнем случае тоже деньги платятся конторой-заказчиком? ))
Для научного руководителя не софт, а проработанная "тема".
Результат неких исследований.
Это необязательно софт даже в IT.
Это могут быть мат-модели какие-нить и соотв. исследование их св-в.
V>>Т.е. ничего вразумительного можно не ждать? IB>Оно уже было, просто ты не заметил, слишком увлекся расписыванием того, какой ты был крутой в студенчестве )
Не я, людей хватало.
Правда, абсолютно все разъехались по заграницам или в Москву/Питер еще очень давно, к концу 90-х.
Последний свалил в ЮК в начале 2000-х.
V>>Мы обсуждаем, что же именно ты сказал. IB>Вот именно, а тебя почему-то все время тянет меня обсудить, а не то что я сказал.
Я не вижу самодостаточных формулировок, считай, что это я тебя таким образом стимулировал на конкретику. ))
Здравствуйте, neFormal, Вы писали:
F>а что вы делаете с таким набором требований?
Блин, какие это к черту требования? Это первый курс, вообще то. Оптимизационные задачи, составление оптимальных расписаний. Всякие DSL для составления систем уравнений, всякие генетические алгоритмы, ибо задачи зачастую NP Complete, усложненный коммивояжер. Плюс всякий анализ данных, нужно на миллиардных таблицах делать в реалтайме агрегацию по произвольным выборкам и обратную запись с учетом кучи ограничений. Короче институтская программа не лишняя.
Здравствуйте, elmal, Вы писали:
F>>а что вы делаете с таким набором требований? E>Блин, какие это к черту требования? Это первый курс, вообще то. Оптимизационные задачи, составление оптимальных расписаний. Всякие DSL для составления систем уравнений, всякие генетические алгоритмы, ибо задачи зачастую NP Complete, усложненный коммивояжер. Плюс всякий анализ данных, нужно на миллиардных таблицах делать в реалтайме агрегацию по произвольным выборкам и обратную запись с учетом кучи ограничений. Короче институтская программа не лишняя.
на мой взгляд, там вопросы были сильно из разных сфер. например, поиск пути из lines я плохо представляю, где ещё можно применить, если рядом есть гиперболический синус и выборки из БД.
просто непонятно: ты ищешь человека, который выполнит тебе какую-то задачу, или успешно сдаст экзамен в универе. может, вы дипломы на заказ пишете, поэтому всё это нужно.
я почему интересуюсь, потому что многие популярные алгоритмы не помню, хоть и реализовывал их по нескольку раз. а к собеседованиям не готовлюсь, т.к. хз, к чему готовиться.
мне интересно, где у нас могут найтись точки соприкосновения.
Здравствуйте, IB, Вы писали:
IB>Я ничего не определял, я сделал логический вывод о том, что из одного не обязятельно следует другое. Поскольку, повторюсь, работа в команде над научным проектом и работа над коммерческим это совершенно разный опыт, так как цели другие.
Смотрю и молчание продолжается, и в плане формулировок на этой итерации еще сложности, продолжаются слова общего плана. ))
Что помешало в двух словах описать те тонкости "алгоритма промышленной разработки", про который намекаете ты и НС?
Что мешает мне описать ВАШИ алгоритмы — понятно, в случае чего, мол, это я за вас расписался и будет удобно обвинить меня в разговоре с голосами в голове.
Но так-то вы каждый уже в течении 3-х постов, хоть и туманно, но намекали, например, вот на такое вполне известное происходящее:
— от заказчика постоянно приходят хотелки, которые трансформируются в уточнения требований;
— разработка получается итеративной, версии выходят регулярно и не патамушта багфикс, а потому еще, что аж новые фичи и при этом крайне желательно, чтобы старые фичи не отвалились.
(4-й курс профильного ВУЗ-а по дисциплине "системы/комплексы" — описание одного из этапов жизненного цикла системы)
Я ХЗ почему НС дважды делал вид, что такой характер разработки зело уникальный, а его оппонент и вовсе "всё равно не поймёт". ))
Наша контора тоже выпускает обновления каждую неделю, обычно более чем для одного продукта (т.е. редкая неделя без обновлений) и в 99.9% это новые фичи, а не багфиксы.
Но фиг с ним.
Разумеется, тут упомянута лишь малая часть процесса, но коль вы намекали именно на эту часть, то пару слов о ней:
Это классика жанра. ТЧК.
Итерации, уточнение требований на каждой итерации, поддержка регрессией сверху, планирование итераций, организация условий их осуществления, контроль/верификация достигнутых результатов и т.д..
Такой характер работ прямо предписывается на всех этапах разработки сложных комплексов.
Т.е. даже начиная с эксизного проекта.
И даже со стадии постановки задачи.
Взять обсуждаемые рядом самолёты и движки.
Вот их разрабатывают по 10 лет.
Почему?
Казалось бы, нарисовал и готово.
Дудки.
Такая же точно итеративность и даже период итераций зачастую близок.
Рекомендуется длительность итерации от 2-х недель до 2-х месяцев.
Каждая команда в большом проекте реализует требования, выкатывает свою часть.
Иногда просто теоретическую или 3D (зависит от стадии проекта).
Далее продолжает работу над следующей итерацией, одновременно с этим на уровне интеграции или самого что ни есть академического матана/исследований гоняется текущий результат. К началу следующей итерации готовы уточнённые требования. И так по кругу несколько лет. Когда доходят до "железной" части — аналогично. Когда отлаживают технологию производства — тоже. Всегда происходит одно и то же.
в зависимости от условий создания АС возможны различные совмещения функций заказчика, разработчика, поставщика и других организаций, участвующих в работах по созданию АС
Но это же относится и к серийному продукту и к софтовой "коробке".
В разных по характеру проектах по-разному распределены роли, вот в чём отличие.
Ключевая роли — это роли источника функциональных и нефункциональных требований и роли контролирующего органа.
И назови ты их как хочешь, хоть даже исключтельно английскими аббревиатурами, смысл не поменяется. ))
Поэтому, вот всё, на что НС глубокомысленно намекал, но так и не сформулировал — это обязательная часть процесса разработки любых более-менее сложных систем.
Итого.
Какой бы аспект происходящего (из десятков их) вы бы не взяли из своей разработки — ничего уникального там нет.
Абсолютно любой происходящий у вас аспект разработки в нынешней ли её испостаси, или "как оно было 5 лет назад" — не важно, всё это хорошо известные и разобранные до уровня молекул вещи.
И это я еще не прошёлся по принципам проектирования сложных систем.
А то тоже порой слышу "в реальном продакшене всё по-другому".
Святая простота. ))
IB>Да, я уже понял, что настоящих системотехников готовят только в севастпольском политехе, и выпускники МГУ, Физтеха, МИФИ, Бауманки и НГУ им в подметки не годяться
Я говорил лишь, что конкретно ты не системотехник по образованию.
Других сюда не вплетай.
Что касается системотехников, то они вообще поголовно свалили из страны сразу же после ВУЗ-а, бо их отрывали тогда с руками и ногами.
Ты ж вспомни, времена тогда были не настолько софтовые-высокоуровневые как сегодня.
Тогда ЛЮБАЯ более-менее серьёзная разработка содержала в себе до 70% (минимум) объема "платформенного" или, если угодно, "ядерного" кода.
Сейчас весь такой код дан "откуда-то сверху" и почти всегда на сейчас даром.
Взять для примера 1С (работает там один из одногруппников, т.е. не "мальчик одинэсник", а именно разрабатывает её), в этом продукте хорошо заметно разделение на "ядро" и "остальное" — такое разделение прямо в конторе, и оно именно так и обзывается.
IB>ко мне до сих пор по этим статьям приходят и просят проконсультировать, значит не зря писал.
Боже упаси мне сказать, что зря писал.
Это направление нужное и важное, ес-но.
РЕчь о том, что ты опять как-то по-странному отметился по такому направлению, на которое не натаскивался.
Это бросается в глаза.
При этом малость не с той стороны зашёл, т.е. опять блокируешь, собсно, сам обмен опытом.
Так-то со стороны если, твоё желание участвовать в обсуждениях подобных тем выдаёт здоровое любопытство прожённого технаря и мне даже где-то странно, что у тебя случилась малость другая специализация по-жизни. Без сарказма.
Cтатьи твои, если начистоту, написаны в хорошо знакомом мне ключе.
Сплошное де жа вю.
По складу ума ты тот самый технарь, роющий самую суть вещей, из которого только и может получиться грамотный аналитик.
Из других не получается обычно, они всегда на пол-дороге где-то застревают. ))
Просто, блин, потрачена эта "манна" была на такую тему... это как микроскопом гвозди забивать.
Здравствуйте, vdimas, Вы писали:
V>Я ХЗ почему НС дважды делал вид, что такой характер разработки зело уникальный
Вот какой смысл тебе что то отвечать, если ты тупо перевираешь мои слова? Я ни слова не сказал про уникальность. Уникальность это как раз та самая кустарщина. А промышленная разработка, она как раз неуникальна обычно.
V>Наша контора тоже выпускает обновления каждую неделю, обычно более чем для одного продукта (т.е. редкая неделя без обновлений) и в 99.9% это новые фичи, а не багфиксы.
Тут важно не сколько раз в неделю, а ваша готовность сделать это в любой момент. Continuous Delivery/Deployment, слыхал про такое?
А теперь расскажи нам, как студент на практике может познакомится с CD и всем что для этого нужно? Какую задачу он этим решит? Или нафига был бы CD в ваших экзерсисах с датчиками, кораблями и коробкой пиков?
И это лишь один из маленьких кирпичиков, и их таких много. Чтобы понять всю специфику эволюции коммерческих продуктов, надо непосредственно и достаточно длительный срок во всем этом поварится, не просто тупо зазубрить модные слова, но на своей жопе прочувствовать нафига оно вообще нужно и почему без этого хуже.
Еще раз — дело не в том что вы не из того мяса сделаны, а в том что перед вами просто цели другие. Разработка под одного заказчика — да ради бога, я сам в таком участвовал. Но это никак не гарантирует, что та же команда умеет выпускать коробку или SaaS-продукт.
V>Я говорил лишь, что конкретно ты не системотехник по образованию.
Ну а конкретно у меня в дипломе тот самый инженер-системотехник написан. Однако я с ним согласен, а не с тобой. Можно на этом переход на личности закончить?
Здравствуйте, neFormal, Вы писали:
F>на мой взгляд, там вопросы были сильно из разных сфер. например, поиск пути из lines я плохо представляю, где ещё можно применить, если рядом есть гиперболический синус и выборки из БД.
Про гиперболический косинус речь заходит чтобы выяснить есть ли у кандидата хоть какие остаточные знания. И не подойдет ли он на вакансию математика, который еще и может программировать. То есть здесь речь идет не о том чтоб завалить, а чтоб нащупать чем кандитат может усилить команду.
F>я почему интересуюсь, потому что многие популярные алгоритмы не помню, хоть и реализовывал их по нескольку раз. а к собеседованиям не готовлюсь, т.к. хз, к чему готовиться. F>мне интересно, где у нас могут найтись точки соприкосновения.
А их не нужно помнить и не нужно к собеседованиям готовиться. Лично я смотрю только остаточные знания. То есть если будет проблема, мне интересно, вспомнит ли кандидат ключевые слова, по которым он будет гуглить. Время на собеседование то крайне ограничено, нужно как то за час управиться и без тестовых заданий, рабочего кода на бумажке и всей любимой многими фигни. Если в институте учился, хоть что то должно остаться.
Мы уже победили, просто это еще не так заметно...
