Справка - Поиск - Участники - Войти - Регистрация
Полная версия: IT специалист кто это?
Частный клуб Алекса Экслера > Деловые вопросы
Страницы: 1, 2, 3, 4
chucha
24 июля 2015, 14:04

ПФУК написал: Подсказка, как создаётся и утверждается программа обучения в вузе?


"Печатаются учебники", в отношении обучения IT специалистов, звучит очень свежо.
Готовых учебных курсов от вендоров, вполне бесплатных для учебных заведений, пруд пруди. Вместе со всем необходимым софтом.



ПФУК написал: Честно говоря, совершенно не понимаю, как знание С помогает писать на SQLе.

Чуть более, чем никак. Зато поможет в освоении большинства процедурных языков, используемых в современной индустрии.
ПФУК
24 июля 2015, 14:18

chucha написал:
"Печатаются учебники", в отношении обучения IT специалистов, звучит очень свежо.
Готовых учебных курсов от вендоров, вполне бесплатных для учебных заведений, пруд пруди. Вместе со всем необходимым софтом.

"Печатаются учебники", это написание учебных материалов, утверждение их в соответствующих инстанциях, вёрстка и наверное что-то ещё.
Впрочем чего спорить, ввиду того, что редко происходит смена обучающего курса, я, очевидно прав.
chucha
24 июля 2015, 14:23

ПФУК написал:
"Печатаются учебники", это написание учебных материалов, утверждение их в соответствующих инстанциях, вёрстка и наверное что-то ещё.
Впрочем чего спорить, ввиду того, что редко происходит смена обучающего курса, я, очевидно прав.

Из этого следует, что единственная причина наличия Паскаля в учебной программе, это хреновая система образования.
Ночной полковник (забыл пароль)
24 июля 2015, 14:23

ПФУК написал:
ps.gif Я кстати не понимаю, какое проблемы писать на том же Оракле, если хорошо знаешь языки более низкого уровня?

Да никаких проблем, просто фигня получится biggrin.gif Надо знать кучу тонкостей, анализировать планы, индексы добавлять и так далее. В молодости я по необходимости занимался оптимизацией SQL-запросов, и небольшие вроде бы изменения (типа удалить "not" в условии, заменив на minus-объединение) приводили к ускорению работы где-то в 30-50 раз. Идея "всё равно на чем писать, главное - АЛГОРИТМЫ" идет из доисторических времен программирования, уже минимум лет 15 как ситуация совсем другая.
Ночной полковник (забыл пароль)
24 июля 2015, 14:30

chucha написал:
Ну хорошие технари тоже знают, как вишенку на тортик прилепить, для топов. Если новые технологии  хочеться потрогать. Так что тут всегда сложный компот. А пара лет для искушенного джедая не срок.

В мелких конторках - возможно. В монструозах типа Газпрома, Роснефти, Транснефти, ФСК, Лукойла никакие "вишенки" не помогут. Да и не добираются там с собственной инициативой технари до лиц, принимающих решения - их обычно приглашают для консультации уже по итогам появления идеи/потребности, обсудив возможность решения с CIO и пригласив пяток компаний-поставщиков с презентациями "как мы решим вашу проблему".
ПФУК
24 июля 2015, 14:31

Ночной полковник (забыл пароль) написал:
Да никаких проблем, просто фигня получится  biggrin.gif  Надо знать кучу тонкостей, анализировать планы, индексы добавлять и так далее. В молодости я по необходимости занимался оптимизацией SQL-запросов, и небольшие вроде бы изменения (типа удалить "not" в условии, заменив на minus-объединение) приводили к ускорению работы где-то в 30-50 раз. Идея "всё равно на чем писать, главное - АЛГОРИТМЫ" идет из доисторических времен программирования, уже минимум лет 15 как ситуация совсем другая.

По-моему ты не том говоришь.

А по поводу SQL да, я согласен.

Собственно это касается практически любого языка, если ты знаешь, как и что в нём реализовано.
chucha
24 июля 2015, 14:45

Ночной полковник (забыл пароль) написал: Да и не добираются там с собственной инициативой технари до лиц, принимающих решения

Это все же от специфики бизнеса сильно зависит. Если он сильно завязан на IT решения, то подобная ситуация не самое разумное решение, как по мне.
Под технарями я, разумеется, не имею в виду рядовых девелоперов.
anonym
24 июля 2015, 15:03
Сисадмин - это ведь классом ниже? (Но очень массово и вполне реально) Оплата за работу одного и того же содержания, интенсивности и уровня сложности может различаться хоть на порядок - в зависимости от работодателя. Банк или бюджетная контора с соответствующей убогой сеткой тарифов.
ПФУК
24 июля 2015, 15:06

anonym написал: Сисадмин - это ведь классом ниже? (Но очень массово и вполне реально) Оплата за работу одного и того же содержания, интенсивности и уровня сложности может различаться хоть на порядок - в зависимости от работодателя. Банк или бюджетная контора с соответствующей убогой сеткой тарифов.

Не обязательно.
Некоторые сисадмины, это директоры по инф. безопастности.

У меня один знакомый получает очень приличные деньги будучи сисадмином в посольстве wink.gif
Гата
24 июля 2015, 15:38

bilbo написал: Показательный пример конфликта поколений - старшее поколение воспринимает образование и жизнь как единое целое плавно перетекающее из одного в другое. Младое поколение принципиально не понимает как эти вещи можно вообще связывать. Образование оно вот как бы есть, лежит бамажкой в коробочке и особо не вспоминается, разве что на вечере выпускников "20 лет спустя" - а дальше собственно начинается сама жизнь - и это две разные вещи. Абсолютно.
Архаизм какой то право дело - работать в соответствии с полученной специальностью. Средневековое мракобесие.

На Хабре опубликовали статью, почему нужно учиться в университете:
http://m.habrahabr.ru/company/devrainsolutions/blog/160871/
   Спойлер!
Последнее время подобные обсуждения на околоайтишных ресурсах — не редкость. Мнения айтишников все больше и больше сводятся к тому, что учеба в университете — обычная трата времени, потому что они — [айтишники без диплома, бросили университет, купили диплом] — нужное подчеркнуть. Такая точка зрения понятна и имеет право на существование. Но хочу поговорить об этом вопросе с другого ракурса. Конечно же, в каждом конкретном случае все индивидуально, но некие общие выводы можно сделать.

Сам закончил университет и защитил кандидатскую диссертацию (кстати, она была очень тесно связана с тематикой работы в ИТ компании), поэтому может сложиться впечатление, что я буду оправдывать нашу образовательную систему. Это не так, но, в любом случае, постараюсь быть объективным.

Пока университеты будут думать как заплатить за коммунальные услуги, нормального образования в ЭтойСтране не будет.

Байки о том, как основатели Microsoft и Apple без высшего образования добились мирового успеха я трогать не буду, т.к. это не относится к основной теме. Многие нынешние политики и бизнесмены тоже не всегда учились в университете.

Первое, на что я хотел бы обратить внимание. Вы полетите на самолете, зная, что главный пилот не учился в летном училище, зато налетал тысячу часов на игровом симуляторе? Вы доверите делать операцию человеку, который анатомию не читал, но осуждает, но на 100% уверен, что резать нужно где-то здесь? Вы доверите защищать себя в суде человеку, который не учился в юридической академии, но прочитал на дому 3 книги по юриспруденции?

Скорее всего, нет. Но, если у вас насморк, то, наверное, совета аптекаря вам будет достаточно, а для понимания общего принципа работы упрощенной системы налогообложения вам будет достаточно совета «продвинутого» непрофиссионала или юриста-стажера.

Очень хорошо тема наличия/необходимости диплома раскрыта в сериале «Форс-мажоры» (Suites).

Если проводить аналогии с ИТ, то если вам необходимо сделать простую работу, например, написать пресс-релиз, сделать прототип на php или натянуть тему на вордпресс, то вам не нужен профессиональный специалист и, действительно, чтобы освоить то или иное ИТ-ремесло, университет де-факто не нужен. К счастью для наших айтишников 90% всей аутсорс работы — именно такая.

Но как только уровень сложности задачи повышается (а, соответственно, и уровень ответственности), то все уже не так гламурно, как кажется на первый взгляд. Кроме знания платформы, языка, инструмента нужно еще понимать доменную область и иметь исторический багаж знаний, который человек будет готов применить в критических ситуациях. В случае с юристами — это знакомство с базой прошлых дел и умение находить прецеденты, для управленца — это знание бизнес кейсов и fail stories, для разработчика — знание математики, алгоритмов и т.д.

Откройте любую вакансию, например, из health care. Вряд ли вы увидете много вакансий, где не будет требования быть bachelor или master. Или спросите любого, кто проходил собеседование в высокотехнологические компании — вряд ли на них задавали вопросы по C# или Java.

На самом деле ответ на вопрос «стоит ли учиться в университете» каждый может ответить достаточно просто. Для этого необходимо вопрос немного переформулировать в следующие:

вы поступили в вуз, потому что хотели туда поступить или потому что больше никуда не взяли?
вы поступили в вуз, потому что это нужно для карьеры?
вы поступили в вуз ради диплома?
вы планируете свою карьеру на ближайших 5 лет или 20?


Но и это не самая главная мысль, которую я хотел бы донести.

Главная ценность любой страны — ее интеллектуальный потенциал (ну еще нефть и газ). Он измеряется в количестве и качестве патентов (помните все патентные войны?), наличием передовых технологий и научных сотрудников. Каждая большая ИТ компания тратит миллионы долларов на исследования и проведение экспериментов. Благодаря этому они защищены на десять-двадцать лет вперед от дефолта и серьезных проблем.

У нас ситуация немного другая. Исследовательские институты практически утратили стратегическое значение, в университете остаются преподавать, в основном, те, кого не взяли на другую работу. Бюрократия пресекает на корню любые инициативы и успехи. Поэтому если говорить с точки зрения геополитики, наличие XXX тыс. аутсорсеров для страны — показатель достаточно бесполезный. На многомиллионные страны у нас мизерное количество офисов мировых компаний с R&D. СНГ по уровню проникновению больших компаний, думаю, проигрывает одному Тель-Авиву. Но в Израиле 27-летний джуниор девелопер — это норма.

Ну и в завершение скажу, что многие мои коллеги вполне успешно совмещали как учебу в университете, так и работу в ИТ компаниях. Более того, умение планировать свое время и умение расставить приоритеты очень сильно сейчас им помогают.

Кроме того, университет — отличное время для экспериментов и поиска того, что вам реально интересно. Часто люди, которые решили изучить все самостоятельно, берут, как правило, «что легче», «что друг посоветовал» или «куда брали», а через несколько лет не готовы бросить не любимую работу, т.к. нужно учить все заново.

Кстати, когда меня спрашивают, что учить и какой язык программирования использовать, я отвечаю таким образом: возьмите свое хобби и сделайте для него, например, сайт — сначала на C#, потом на Java и сравните свои ощущения, что вам больше понравилось. Если ни то, ни другое — ищите дальше. После нескольких экспериментов вы поймете, что вас реально заводит и нравится.

Спасибо за внимание!
bilbo
24 июля 2015, 16:11

Гата написал:
На Хабре опубликовали статью, почему нужно учиться в университете:



Первое, на что я хотел бы обратить внимание. Вы полетите на самолете, зная, что главный пилот не учился в летном училище, зато налетал тысячу часов на игровом симуляторе? Вы доверите делать операцию человеку, который анатомию не читал, но осуждает, но на 100% уверен, что резать нужно где-то здесь? Вы доверите защищать себя в суде человеку, который не учился в юридической академии, но прочитал на дому 3 книги по юриспруденции?

С одной стороны мне очень хочется подобные вопросы задать тем кто в ПЖ тусуются. Там каждый практически Черчиль как минимум. biggrin.gif
С другой - с юристами имеющих дипломы постоянно бодаюсь. Такую пургу несут - не описать. С пилотами пример вообще не корректен. Первым пилотом становятся не зависимо от диплома, в первую очередь там важен практический налет. Возможно удивишься, но по России летают пилоты у которых диплом о высшем образовании по специальности "штурман", а пилотом они стали после курсов повышения квалификации.
Да и уверенности в том что врач с дипломом действительно читал учебник анатомии у меня то же нет.biggrin.gif
Chief
24 июля 2015, 23:07

Ночной полковник (забыл пароль) : А потом, через пол-года разработки, придет вчерашний выпускник, залезет в код и спросит, нахрена такой огород было городить, если есть продукт А, делающий то же самое, но в десять раз эффективнее?

Ну да, я и говорю, теперь программеров нет, есть кодеры.
Chief
24 июля 2015, 23:12

anonym написал: Сисадмин - это ведь классом ниже?

Ниже чего? Не так редко сисадмин ниже только системного архитектора, до которого далеко не все могут дорасти.
wiklis
25 июля 2015, 16:55
Я благодарю всех форумчан, принявших участие в обсуждении моей проблемы. Не ожидал такого обвала постов. Тема обсосана от и до. Теперь можно предъявить ей мнение народа и сподвигнуть её на выбор более узкой конкретной цели.
Lynx082
26 июля 2015, 01:08
Офигеть, насколько я вообще теперь не в теме smile.gif можно сказать, что понимаю примерно 5% написанного. Круто. И ведь все практически на глазах создавалось.
Гата
5 ноября 2015, 18:12

bilbo написал: С одной стороны мне очень хочется подобные вопросы задать тем кто в ПЖ тусуются. Там каждый практически Черчиль как минимум.
С другой - с юристами имеющих дипломы постоянно бодаюсь. Такую пургу несут - не описать. С пилотами пример вообще не корректен. Первым пилотом становятся не зависимо от диплома, в первую очередь там важен практический налет. Возможно удивишься, но по России летают пилоты у которых диплом о высшем образовании по специальности "штурман", а пилотом они стали после курсов повышения квалификации.
Да и уверенности в том что врач с дипломом действительно читал учебник анатомии у меня то же нет.

На Хабре опубликовали еще аналогичную статью, почему стоит учиться в вузе на программиста. Во-первых, там дают теорию тех же баз данных и т.д. Во-вторых, студент должен постоянно кодить. Часто преподаватели дают идеи (пусть даже самые безумные) для собственных проектов. Часто студенты набивают руки на конкретных курсовых и дипломных проектах, на производственной практике (которая оплачивается), к концу обучения у них уже есть опыт, к тому же оплаченный стипендией.
Troubleshooter
6 ноября 2015, 01:37

Гата написал: Там еще непонятно по какой причине отсутствует многопоточное и параллельное программирование.

Этому, по моим наблюдениям, в университетах не учат. В лучшем случае упоминают. На интервью половина java программистов не знает что такое java memory model. Из тех кто хотя бы слышал о её существовании, единицы могут рассказать как это работает. Из тех кто смог рассказать ещё меньше знает как применять на практике (или хотя бы рассказать зачем нужен immutable об'ект и как его создать). Я уж не говорю о более высоких материях. На самом деле это очень серьёзная проблема.
Troubleshooter
6 ноября 2015, 01:58

Chief написал:
Ну да, я и говорю, теперь программеров нет, есть кодеры.

А фрезеровщик, если он настоящий фрезеровщик, должен вручную собрать станок на котором работает? smile.gif

Современный пограммист фокусируется на создание алгоритма для бизнеса применяя наиболее подходящие для этого инструменты, с учётом заданных ограничений. Чем дальше тем это сложнее т.к. спектр инструментов для решения какой то задачи увеличивается.
Chief
6 ноября 2015, 13:40

Troubleshooter написал: Современный пограммист фокусируется на создание алгоритма

О чем я и говорю. Программист - должен создать алгоритм. А сейчас больше кодеров, которые эти алгоритмы кодируют...
Мне вот сейчас слегка надо вникнуть в php, хотя я не программер и не кодер. Программером при этом - я не стану, хотя как раз алгоритмы меня и учили создавать. Просто я ушел в другую область.
Troubleshooter
6 ноября 2015, 15:12

Chief написал:
О чем я и говорю. Программист - должен создать алгоритм. А сейчас больше кодеров, которые эти алгоритмы кодируют...
Мне вот сейчас слегка надо вникнуть в php, хотя я не программер и не кодер. Программером при этом - я не стану, хотя как раз алгоритмы меня и учили создавать. Просто я ушел в другую область.

Как в твоём представлении происходит процесс разработки? Программист или кодер, назови как хочешь, создает программный код. Программный код всегда отражает какой то алгоритм. Понятно что этот алгоритм может быть оптимальным или нет. На оптимальность в большой степени влияет знание доступных инструментов, паттернов и т.п.
whitekiller
6 ноября 2015, 16:12

Troubleshooter написал:
На оптимальность в большой степени влияет знание доступных инструментов, паттернов и т.п.

Еще больше влияет наличие светлой головы.
Dead Knight
6 ноября 2015, 16:43

Troubleshooter написал:
Как в твоём представлении происходит процесс разработки? Программист или кодер, назови как хочешь, создает программный код. Программный код всегда отражает какой то алгоритм. Понятно что этот алгоритм может быть оптимальным или нет. На оптимальность в большой степени влияет знание доступных инструментов, паттернов и т.п.

Нет, он правильно говорит. Просто это в разных местах по разному называется. Деление может идти как у него: Программист vs Кодер, - или как принято у других: Инженер ПО vs Программист - и т.д.

Разница между Программистом и Кодером по Chief в том, что Кодеру ты дашь алгоритм и он его заимплементит на том языке, который он знает. А программисту ты скажешь, что хочешь, а его задача подобрать алгоритмы, определить архитектуру и уже по факту имплементировать.

В больших компаниях такие Кодерыв выступают в качестве джунов или мидлов (кем они по сути иявляются) иногда дорастая до сеньеров (по выслуге лет), в то время как те, кого Chief называет Программистами обычно уже в течении одного-двух проектов становятся синьорами или архитекторами/техлидами.
Dead Knight
6 ноября 2015, 16:47

Troubleshooter написал:
Как в твоём представлении происходит процесс разработки? Программист или кодер, назови как хочешь, создает программный код. Программный код всегда отражает какой то алгоритм. Понятно что этот алгоритм может быть оптимальным или нет. На оптимальность в большой степени влияет знание доступных инструментов, паттернов и т.п.

Моя практика показывает, что огромное количество людей легко учится писать код, и может заимплементить алгоритм, который им дали. Но вот заучивание паттернов или целых алгоритмов им ну никак не помогает эти самые паттерны использовать или самим выбирать какие алгоритмы нужно использовать и когда.

Скорее даже наоборот.
Fantomny
6 ноября 2015, 17:00

О чем я и говорю. Программист - должен создать алгоритм. А сейчас больше кодеров, которые эти алгоритмы кодируют..

Крайне редко программисту дается готовый алгоритм. Обычно это задачи, совместные с математиками....
Другое дело, что не всегда сложность в алгоритме. Где то сама логика - элементарна, а сложности "в другом".




Сисадмин - это ведь классом ниже?

Есть разные уровни.
Топовые сетевики - это достаточно дорогая позиция.
В среднем , они более низкой квалификации, но это именно "в среднем".
Troubleshooter
6 ноября 2015, 22:06

Dead Knight написал:
Разница между Программистом и Кодером по Chief в том, что Кодеру ты дашь алгоритм и он его заимплементит на том языке, который он знает. А программисту ты скажешь, что хочешь, а его задача подобрать алгоритмы, определить архитектуру и уже по факту имплементировать.

В Scrum, когда происходит груминг , разработчикам рассказазываются детали того что надо сделать. Затем каждый может задать вопросы если что то непонятно, после чего каждый оценивает сложность задачи. Новую задачу из спринта берёт свободный разрабртчик. Обычно никто заранее не знает над какой конкретной задачей из списка разработчик будет работать. Если этого не делать то тогда обычно разработчики начинают специализироваться в конкретной области. Т.е. различае между синиор, мидл и джуниор девелоперами не делается ( Мне не нужно чтобы синиор девелопер свалил в другую компанию и какие то задачи встали). Конечно есть и искоючения если что то надо сделаиь очень срочно. Если я неуверен в девелопере то я могу попросить его сначала написать псевдокод для задачи. Этот псевдокод или сам проверю или попрошу ведущих разработчиков. Если задача не тривиальная, то она обязательно начинается с создания и проверки интерфейса. Если что то из начинки имплементировано неправильно то это будет обнаружено во время проверки кода (код ревью), или тестов (юнит, компонент, интегрейшин, пользовательских, производительности). Идея в том что бы "начинка" была достаточно мала чтобы можно было легко поменять, если надо.

Возможно я говорю очевидные вещи, все это для того чтобы оь'яснитт почему я считаю неправильным подход где алгоритм создается целиком для молодых разработчиков, а они только кодируют. Для меня это выглядит ненужным микромэнэджментом. Должен быть определённый уровень доверия команде с которой ты работаешь. Должны быть средства которые отлавливают ошибки, должны быть стандарты принятые в конкретной команде. Вoбщем все то что обычно подразумевается под SDLC, Continuous Integration.
Troubleshooter
6 ноября 2015, 22:17

Dead Knight написал:
Моя практика показывает, что огромное количество людей легко учится писать код, и может заимплементить алгоритм, который им дали. Но вот заучивание паттернов или целых алгоритмов им ну никак не помогает эти самые паттерны использовать или самим выбирать какие алгоритмы нужно использовать и когда. .

Я не понимаю что подразумевается под " уметь писать код" и при этом не уметь применять алгоритмы и паттерны. Наверное мы вкладывает разный смысл в эти слова.

У меня был обратный случай. Разработчик среднего уровня производил ужасный код. Ок, напиши псевдокод для алгоритма который ты собираешься реализовать. Пишет, все нормально. Теперь реализуй его. Выходит ужас. Спрашиваю, ты же написал псевдокод почему ты кодируешь что то другие? Нет вразумительного ответа. Так продолжалось полгода. Потом расстались.
Chief
6 ноября 2015, 22:20

Troubleshooter написал: Я не понимаю что подразумевается под " уметь писать код" и при этом не уметь применять алгоритмы и паттерны.

Не применять. Программер должен САМ уметь создавать алгоритмы...
Troubleshooter
6 ноября 2015, 22:43

Chief написал:
Не применять. Программер должен САМ уметь создавать алгоритмы...

Создавать алгоритмы для решение своей конкретной задачи, да. Делается это с применением существующих паттернов (патерн это то же алгоритм) которые заведомо работают. Ну как можно серьёзно разговаривать с разработчиком, который для кэширования и репликации данных между приложениями стал использовать HashMap и низкоуровневый сетевой API в качестве альтернативы Oracle Coherence, из-за того что он не знает как Coherenсe работает Реальный случай из моей практики. Прошу прощения за java специфику
Chief
6 ноября 2015, 22:57

Troubleshooter написал:
Реальный случай из моей практики. Прошу прощения за java специфику

Я именно про таких и говорю. Именно их я кодерами и называю.
Один мой друг, очень ХОРОШИЙ программер, как то сказал: Мне плевать на каком языке кодить - синтаксис учится быстро (знает, в реале, много языков).
Его квалификацию может подтвердить не один форумчанин (он сам на форуме был почти с самого начала, просто ушел), при этом не один из форумчан именно программеров...smile.gif
Dead Knight
6 ноября 2015, 23:02

Troubleshooter написал:
В Scrum, когда происходит груминг , разработчикам рассказазываются детали того что надо сделать....


У скрама есть куча ограничений, из-за которых он даже близко не является серебрянной пулей. К примеру, сейчас я как дурак сижу в Мюнхене, потому что тут нужно спасать проект, к которому в том числе благодаря и этому самому скраму в гости наведался маленький сибирский зверек.

Огромное количество народа может писать код, но вот писать код так, чтобы потом его не нужно было выкидывать на помойку и переписывать полностью, по моему опыту может, дай бог, если хотя бы 30% программистов.


Troubleshooter [URL=http://club443.ru/t/192529
Возможно я говорю очевидные вещи, все это для того чтобы оь'яснитт почему я считаю неправильным подход где алгоритм создается целиком для молодых разработчиков, а они только кодируют.


Вопрос не в том, что кто-то должен создавать алгоритм, а кто-то его должен кодировать, а в том, что просто огромное количество народа тупо умеют только кодить. Мне по фиг, молодой передо мной программист или у него стаж 30 лет, но если ему говорят, что на данном проекте STL запрещен и нужно пользоваться специальными библиотеками, а он все равно пишет код с использованием STL, а потом удивляется, почему его код не собирается на билд сервере, то по моему у него с головой проблемы.

Кстати, я знал одного человека, который был шикарный алгоритмист, и ести нужно было придумать что-ибо для решения специфической задачи или проанализировать и найти прблему, он был прекрасен. Но писать код или рефакторить чужой код он не мог (не в смысле, что он мог программировать). К нему в свое время даже человека проставили, у которого была задача код потом переписывать.


Troubleshooter [URL=http://club443.ru/t/192529
Должен быть определённый уровень доверия команде с которой ты работаешь.

Доверие к команде, не на пустом месте возникает. Чтобы доверять другим людям в комманде, нужно знать, кто чего стоит, и кто в чем хорош. А в начале, когда собирают людей под новый проект, которые раньше друг с другом не работали, и половина из них вообще со стороны пришла, все что ты можешь, это надеяться, что они хотя бы в половину так хороши, как у них в CV написано.
Dead Knight
6 ноября 2015, 23:11

Troubleshooter написал:
Создавать алгоритмы для решение своей конкретной задачи, да. Делается это с  применением существующих паттернов (патерн это то же алгоритм) которые заведомо работают.  Ну как можно серьёзно разговаривать с разработчиком, который для кэширования и репликации данных между приложениями стал использовать HashMap и низкоуровневый сетевой API в качестве альтернативы  Oracle Coherence, из-за того что он не знает как Coherenсe работает  Реальный случай из моей практики. Прошу прощения за java специфику

Ба, так о чем же речь идет. Прослушать курс по паттернам и получить корочку разработчика ПО, проблем нет.

Проблема как раз в том, что когда ты на ревью спрашиваешь: "Почему тут у темя переменная цикла называется "nGhFt", а тело цикла занимает 7 экранов, и вообще, ты сможешь рассказать, что твой код делает через хотя бы 2-3 месяца?", - то в ответ начинается: "Ну, это что же, мне теперь все переписывать, и вообще, оно и так работает. Мамой клянусь, я тестировал..."
Troubleshooter
6 ноября 2015, 23:39

Chief написал:
Я именно про таких и говорю. Именно их я кодерами и называю.
Один мой друг, очень ХОРОШИЙ программер, как то сказал: Мне плевать на каком языке кодить - синтаксис учится быстро (знает, в реале, много языков).
Его квалификацию может подтвердить не один форумчанин (он сам на форуме был почти с самого начала, просто ушел), при этом не один из форумчан именно программеров...smile.gif

Опять же, мы наверно понимаем по-разному знание языка. Знание синтаксиса и базовой библиотеки учатся быстро, да. Хотя видел не мало неплохих java программистов, которым потребовалось время что бы понять scala. Но хорошее знание языка, в моём понимании, не ограничивается знанием синтаксиса и базовой библиотеки.
Troubleshooter
7 ноября 2015, 00:04

Dead Knight написал:

У скрама есть куча ограничений, из-за которых он даже близко не является серебрянной пулей. К примеру, сейчас я как дурак сижу в Мюнхене, потому что тут нужно спасать проект, к которому в том числе благодаря и этому самому скраму в гости наведался маленький сибирский зверек.


Ну, серебряной пулей наверно ни что не является, но многие из описанных здесь проблем решаются при правильном применении скрама. Как скрам завёл этот проект в такое состояние?



Огромное количество народа может писать код, но вот писать код так, чтобы потом его не нужно было выкидывать на помойку и переписывать полностью, по моему опыту может, дай бог, если хотя бы 30% программистов.


Я не видел ни одного водопроводчик, или плиточника, маляра который не раскритиковал бы работу своего предшественника smile.gif тоже самое с программными проектами, почти всегда можно что то улучшить. Иногда это действительно проблема, иногда естественный прцесс эволюции т.к. получен дополнительный опыт, предыдущая версия устраивала в тех, предыдущих условиях, и т.д.



Доверие к команде, не на пустом месте возникает. Чтобы доверять другим людям в комманде, нужно знать, кто чего стоит, и кто в чем хорош. А в начале, когда собирают людей под новый проект, которые раньше друг с другом не работали, и половина из них вообще со стороны пришла, все что ты можешь, это надеяться, что они хотя бы в половину так хороши, как у них в CV написано.

Скрам отлично справляется с этой проблемой. Двухнедельных спринтов, которые включают планирование в начале спринта, анализ проделанной работы и show&tell сессий, где народ демонстрирует что сделал более чем достаточно чтобы понять уровень каждого разработчика. Одна из основных проблем руководства проектом это понимание что ты не можешь быть везде. Иначе станешь сам "узким горлышком" (bottleneck) для своей команды. Скрам помагает организовать процесс где можно быстро понять сильные и слабые стороны команды , и позволяет команде организовывать себя самостоятельно.
bilbo
7 ноября 2015, 00:08
Кодер не кодер.
Мозги или есть или уже ни каким дипломом не спасёшься.
Troubleshooter
7 ноября 2015, 00:15

Dead Knight написал:
Ба, так о чем же речь идет. Прослушать курс по паттернам и получить корочку разработчика ПО, проблем нет.


Это неплохое начало, но естественно этим не ограничивается. Альтернатива когда разработчик изобретает велосипед меня не устраивает в такой же мере.



Проблема как раз в том, что когда ты на ревью спрашиваешь: "Почему тут у темя переменная цикла называется "nGhFt", а тело цикла занимает 7 экранов, и вообще, ты сможешь рассказать, что твой код делает через хотя бы 2-3 месяца?", - то в ответ начинается: "Ну, это что же, мне теперь все переписывать, и вообще, оно и так работает. Мамой клянусь, я тестировал..."

Понятно что это не ведущий разработчик. Но на ревью я ещё спрашиваю почему такой код был создан чтобы понять чего нехватает (общих знаний, опыт работы в предыдущей компании где это было принято, нехватка времени, частое переключение между контекстами). Что бы понять что было упущено в организации работы.
Dead Knight
7 ноября 2015, 01:05

Troubleshooter написал:
Ну, серебряной пулей наверно ни что не является, но многие из описанных здесь проблем решаются при правильном применении скрама. Как скрам завёл этот проект в такое состояние?


Скрам был одной из причин, коих там было и есть вагон и маленькая тележка. К примеру когда я впервые запустил отладчик и увидел порядка 90 потоков в приложении которое в силу своей архитектуры многопоточным не было, у меня был шок. Это в свою очередь оказалось результатом того, что каждый решил, что он сам себе архитектор и начал писать ко в лес, кто по дрова. В результате хаос и разруха. Или когда человек работает полтора месяца(!) над стейтмашиной, и в результате реализует ее при помощи божественного класса внутри которого неонка с отдельным потоком внутри, который каждые 2 секунды запускает метод с кучей if-ов.

А мы, это говорим о проекте, над которым работает наверное под 50-60 человек только программистов над одним компонентом проекта и стоимостью наверное в пару-тройку десятков миллионов евро, если не больше.


Troubleshooter написал:
Я не видел ни одного водопроводчик, или плиточника, маляра который не раскритиковал бы работу своего предшественника  smile.gif тоже самое с программными проектами, почти всегда можно что то улучшить.


Всегда есть что улучшать, проблема то не в этом. Проблема в том, что когда через год тебе дают код, который написан через одно место, названия методов даны от фонаря, а архитектуры нет, потому что писавший его человек считал себя гением, поэтому решил, что рисовать ЮМЛ диаграммы или покрывать свой код юнит тестами на данном этапе разработки не обязательно, т.к. это замедлит разработку, и вся комманда с ним согласилась, потому что они все такие, а потом он уволился - становится очень и очень неприятно.


Troubleshooter написал:
Иногда это действительно проблема, иногда естественный прцесс эволюции т.к. получен дополнительный опыт, предыдущая версия устраивала в тех, предыдущих условиях, и т.д.


Угу, 640кБ гватит на все copy.gif Что есть эти самые "предыдущие условия"? Когда компания А разрабатывает несколько лет что то для компании Б, и компанию Б все устраивает, потом что потребности у них маленькие. А потом эта компаня А продает свой продукт для компании В, которая точно знает, чего хочет, а хочет она всего и побольше. И вдруг оказывается, что адаптация продукта очень и очень сложна, потому что продукт именно что подгонялся под А. Т.е. многие вещи просто делались криво, потому что, и "так сойдет". "Ах, как это оказалось, что этот интерфейс может использовать больше чем один компонет. Мы когда его писали, думали что подписчик будет только один. Что, пользователь может подключить более одного монитора? Ну надо же, а мы думали что и один монитор у пользователя роскошь"


Troubleshooter написал:
Скрам отлично справляется с этой проблемой. Двухнедельных спринтов, которые включают планирование в начале спринта, анализ проделанной работы и show&tell сессий, где народ демонстрирует что сделал более чем достаточно чтобы понять уровень каждого разработчика. Одна из основных проблем руководства проектом это понимание что ты не можешь быть везде. Иначе станешь сам "узким горлышком" (bottleneck) для своей команды. Скрам помагает организовать процесс где можно быстро понять сильные и слабые стороны команды , и позволяет команде организовывать себя самостоятельно.


Да это так, и нет, жизнь штука тяжелая и не справедливая. Потому, что топ менеджеры часто живут в своем отдельном мирке и далеки от народа. При этом ни СПО ни скраммастер на рабочий процесс влиять не могут. В результате комманда делает что хочет, а менеджмент говорит, ну так там же скрам, оно все само образуется. И так до тех пор, пока не приходит заказчик, и не описывает менеджерам, в каких позах их будут иметь через два месяца, когда подойдет время СОПа. И тут менеджеры начинаею бегать, рассказывать что нужно напрячься. Да вот только напрягаться уж некому, ибо люди которые реально работали, не выдержали такого скрама, плюнули на все и уволились, а остались те, кого скрам этой самой "самоорганизацией" и устраивал.
Chief
7 ноября 2015, 11:34

Troubleshooter написал: Опять же, мы наверно понимаем по-разному знание языка.

Не языка. Я различаю кодеров (умение налапатить что угодно по созданному алгоритму на знакомом языке) и программеров - умение составить алгоритм и по нему написать код.
Один раз мне показали код индийского кодера из MS в силиконовой долине (да, нарушили безопасность, но мне и не весь код показывали - просто чтоб поржал).
Грубо говоря - вместо одного case - сотня вложенных if else...
Я понимаю, что второе таки отработает быстрее, но код увеличивается вдвое, как минимум...
Dead Knight
7 ноября 2015, 12:56

Chief написал:
Грубо говоря - вместо одного case - сотня вложенных if else...
Я понимаю, что второе таки отработает быстрее, но код увеличивается вдвое, как минимум...

А я не понимаю, потому, что если if в коде выполняет те же функции, что и switch, то в общем случае switch окажется быстрее.

Тем не менее, в большинстве случаев не это главное. Все это экономия на спичках. Само по себе то, что имеется большой разветвленный если-то в одном месте или человек пишет гиганский переключатель с логикой в разных значениях, то это уже проблема дизайна в целом.
Troubleshooter
7 ноября 2015, 13:56

Dead Knight написал:

Здесь описаны несколько проблем, говорящие о том что работа разработчиков неорганизована и потерен контроль над проектом.

Юнит тесты часть разработки. Когда разработчик показывает что он сделал за неделю первое что он демонстрирует это юнит тесты. Т.е. юнит тесты показывают что надо сделать и работает ли это. Нет юнит тестов работа не сделана. У нас вчера одна проблема была обнаружена только в интегрейшн тестах. В понедельник рано утром главный руководитель проекта ждёт пояснений от меня (отвечающего за технические вопросы) и от человека отвечающего за бизнес сторону почему проблема не была обнаружена на стадии юнит и компонент тестов. А также что будет сделано что бы улучшить качество.

Бизнес никогда не стоит на месте и всегда будет требовать чего то нового. Это разве новость для кого то? Если нет стратегии по адаптации изменяющихся требований то проект с самого начала обречён т.к. это ведёт к ситуации как в примере с компаниями А и Б.

И да, самоорганизация не имеет ничего общего с анархией. Одно из преимушеств скрама это фокус на команду, а не на отдельных гениальных разрабртчиков. Для больших проектов это особенно критично.
Troubleshooter
7 ноября 2015, 15:18

Chief написал:
Не языка. Я различаю кодеров (умение налапатить что угодно по созданному алгоритму на знакомом языке) и программеров - умение составить алгоритм и по нему написать код.
Один раз мне показали код индийского кодера из MS в силиконовой долине (да, нарушили безопасность, но мне и не весь код показывали - просто чтоб поржал).
Грубо говоря - вместо одного case - сотня вложенных if else...
Я понимаю, что второе таки отработает быстрее, но код увеличивается вдвое, как минимум...

На самом деле этот пример показателен. В одних языках switch эффективней в других if могут быть более эффективны( отвлечемся на секунду что это микро оптимизация которая имеет смысл только в определённых сценариях). Приверженцы чистого об'ектно ориентированном дизайна скажут что это решается наследованием (что может привести к yo-yo проблеме). Приверженцы функционального программирования скажут что if'ы это выражения, а не стейтменты. Большинство современных языков OOP поддерживают if/switch. Все больше делается упор на функциональное программирование. Теперь представим что программист с бэкграундом где if это наиболее эффективный способ ветвления создаёт алгоритм реализации для функционального языка. Сможет он это сделать? Да. Будет такой алгоритм эффективен? Врят ли.

Кстати, мне непонятны проблемы с большимт классами, сотнями вложенных if. Есть инструменты типа Jenkins, TeamCity и Sonar. Везде где я работал последние лет 8-10ть наверно, программист комитит код в sourece control ежедневно, возможно по несколько раз в день. Затем происходит автоматическая проверка кода. Сотня ifов просто не позволит создать приложение до тех пор пока код не будет изменён. Для этого даже ревью делать не надо. Все настолько прозрачно что для меня выглядит странным этот способ проверки кода еще где то не используется
Dead Knight
7 ноября 2015, 20:24

Troubleshooter написал: В понедельник рано утром главный руководитель проекта ждёт пояснений от меня (отвечающего за технические вопросы) и от человека отвечающего за бизнес сторону почему проблема не была обнаружена на стадии юнит и компонент тестов. А также что будет сделано что бы улучшить качество.

Ха.. у нас недавно митинг был, на котором топ менеджер рассказывал, как им (топам) будет больно, если программисты не напрягутся и не пооветаймят. И там была сказана гениальная фраза: "А еще мы подумали, что нужно включить систем-тесты"... Это за 2 месяца до СОП-а. При том, что им еще год назад говорилось, что нужны систем тесты, что нужна хорошая команда тестировщиков, что нужна нормальная организация работы.

А так, скрам, для меня это всего лишь инструмент, который имеет свою область применимости.
BigSister
7 ноября 2015, 21:26

Dead Knight написал: к которому в том числе благодаря и этому самому скраму в гости наведался маленький сибирский зверек.

В том, что ты описал ниже, скрам никоим образом не повинен.
Dead Knight
8 ноября 2015, 01:32

BigSister написала:
В том, что ты описал ниже, скрам никоим образом не повинен.

Он не повинен, в смысле как нож не повинен, что его использовали для ограбления магазина. Скрам - это инструмент, и сам по себе он ничего не решает, если им пользоваться правильно и к месту, получишь бонусы. Будешь пользоваться как попало - будет плохо.

Если ты почитаешь внимательно, то мои слова о скраме были конкретным ответом на слова Troubleshooter , что пользуйтесь скрам, и ваши волосы будут белые и пушистые.

Вот к примеру лично я предпочитаю V-model, при том что у нас в компании разрешено использовать хоть скрам хоть ватерфолл. При этом все эти процессы разработки у нас используются довольно успешно разными командами.
BigSister
8 ноября 2015, 01:54

Dead Knight написал: Он не повинен, в смысле как нож не повинен, что его использовали для ограбления магазина. Скрам - это инструмент, и сам по себе он ничего не решает, если им пользоваться правильно и к месту, получишь бонусы. Будешь пользоваться как попало - будет плохо.

Если ты почитаешь внимательно, то мои слова о скраме были конкретным ответом на слова Troubleshooter , что пользуйтесь скрам, и ваши волосы будут белые и пушистые.

Перечитала пост Траблшутера. "Белопушистости" скрама снова не обнаружила. А если ты понимаешь, что скрамом пользовались "неправильно", то должОн понимать, что ваши проблемы вовсе не из-за него.
Troubleshooter
8 ноября 2015, 02:32

Dead Knight написал:
Если ты почитаешь внимательно, то мои слова о скраме были конкретным ответом на слова Troubleshooter , что пользуйтесь скрам, и ваши волосы будут белые и пушистые.

Вот к примеру лично я предпочитаю V-model, при том что у нас в компании разрешено использовать хоть скрам хоть ватерфолл. При этом все эти процессы разработки у нас используются довольно успешно разными командами.

Я тоже не понял по поводу "белопушистости". Само собой Скрам не идеален и его нужно использовать правильно. Но с его помощью легче держать проект под контролем. Например тот же V-model по большому счёту waterfall. Принципиальная разница между скрамом и waterfall в том что в скраме, как и в любой agile методологии, стимулируется ранний feedback на всех этапах разработки. Соответственно гораздо легче исправлять ошибки и вносить изменения. В отличается от waterfall, где обнаруженная ошибка в дизайне на стадии имплементации может вызвать эффект домино. После чего начинаются героические усилия по спасению проекта.
Не Кролик
8 ноября 2015, 05:09

Troubleshooter написал: Само собой Скрам не идеален и его нужно использовать правильно.

Честно говоря, за всю свою карьеру мне не разу не довелось увидеть правильное использование Скрама. В во всех местах, где его применяли, единственный результат заключался в пустой трате времени и ресурсов.
А в тех случаях, когда процесс организовывал я (будучи R&D Manager старт-апа, например), то мы прекрасно обходились без Скрама.
MM
8 ноября 2015, 09:11

Ночной полковник (забыл пароль) написал:
Да никаких проблем, просто фигня получится  biggrin.gif  Надо знать кучу тонкостей, анализировать планы, индексы добавлять и так далее. В молодости я по необходимости занимался оптимизацией SQL-запросов, и небольшие вроде бы изменения (типа удалить "not" в условии, заменив на minus-объединение) приводили к ускорению работы где-то в 30-50 раз. Идея "всё равно на чем писать, главное - АЛГОРИТМЫ" идет из доисторических времен программирования, уже минимум лет 15 как ситуация совсем другая.

Не путай базы данных и просто программы.
whitekiller
8 ноября 2015, 09:28

Не Кролик написал:
Честно говоря, за всю свою карьеру мне не разу не довелось увидеть правильное использование Скрама. В во всех местах, где его применяли, единственный результат заключался в пустой трате времени и ресурсов.
А в тех случаях, когда процесс организовывал я (будучи R&D Manager старт-апа, например), то мы прекрасно обходились без Скрама.

У меня сейчас один проект идет под скрамом и довольно успешно. Главное преимущество - ежедневные, а иногда и 3-4 раза в день отчеты о проделанной работе. Мне хватает 5 минут в день, чтобы полностью быть в курсе дела. Надо добавить, что разработчики, аналисты и пользователи находятся в разных городах.
Dead Knight
8 ноября 2015, 13:55

Troubleshooter написал:
Я тоже не понял по поводу "белопушистости". Само собой Скрам не идеален и его нужно использовать правильно. Но с его помощью легче держать проект под контролем. Например тот же V-model по большому счёту waterfall. Принципиальная разница между скрамом и waterfall в том что в скраме, как и в любой agile методологии,  стимулируется ранний  feedback на всех этапах разработки. Соответственно гораздо легче исправлять ошибки и вносить изменения.  В отличается от waterfall, где обнаруженная ошибка в дизайне на стадии имплементации может вызвать эффект домино. После чего начинаются героические усилия по спасению проекта.

Это одновременно и правда и ложь. Правда, что ошибки в дизайне ватерфолла вылазят в конце, ложь в том, что когда об этом ты знаешь, ты начинаешь очень внимательно относится к этапам дизайна и планирования. В скраме, я чаще всего наблюдал обратную ситуацию, казалось бы, все правильно и система габкая, однако ошибки возникающие от недостаточного внимания к дизайну начинают складываться, и с какого-то момента система резко перестает быть стабильной.

Все что я говорю, я имею возможность наблюдать в реальной жизни.
Troubleshooter
8 ноября 2015, 14:12

Не Кролик написал:
Честно говоря, за всю свою карьеру мне не разу не довелось увидеть правильное использование Скрама. В во всех местах, где его применяли, единственный результат заключался в пустой трате времени и ресурсов.
А в тех случаях, когда процесс организовывал я (будучи R&D Manager старт-апа, например), то мы прекрасно обходились без Скрама.


Было бы интересно узнать в чем отличался успешный процесс в стартапе от скрама.
Дальше >>
Эта версия форума - с пониженной функциональностью. Для просмотра полной версии со всеми функциями, форматированием, картинками и т. п. нажмите сюда.
Invision Power Board © 2001-2017 Invision Power Services, Inc.
модификация - Яро & Серёга
Хостинг от «Зенон»Сервера компании «ETegro»