Розробка · 14 липня 2010, 9:30 1595

Sergii Voloshyn, Product Manager в DOU.ua

Синьоры и лиды не знают элементарных вещей

Serzh-GT

За последний месяц я провел около 10 собеседований по.NET. Взяли только 2-ух или 3-ех. Собеседовал людей с опытом по 4–7 лет. В прошлом синьоры и лиды. Так не знают элементарных вещей. Например, разницу между массивом и списком. Также вводят в ступор слова — «это никто не использует», «лучше всегда использовать классы вместо структур», «GC сделает все сам и мне не нужно беспокоится о мемори ликах», «зачем вы меня по теории грузите, спросите лучше по практике» и т.д. Ребята, Вас же не на джуниора собеседуют. Вы возможные кандидаты на синьор и лид позиции. На Ваши плечи в будущем ляжет оптимизация, дебаг и повышение перфоманса приложения.

—

kievbs

2 Serzh-GT

Не согласен. Имея 4–7 летний опыт, теорию можно подогнать за неделю другую, если чего-то будет не хватать для конкретного проекта. Научиться тот же профайлер запускать и ловить мемори лики, если раньше не приходилось. А вот теория опыта не заменит. Личное наблюдение, народ который хорошо рассказывал теорию на собеседованиях частенько на практике оказывался довольно бесполезными. Так что лично я против собеседований по теории, гораздо эффективнее подбирать людей с опытом по тематике проекта.

—

volf

2 Serzh-GT

Простите, но вы действительно «оптимизируете» заменой списков на массивы???

Был сам на «таком» собеседовании (Java dev), когда по «массивом» имеют ввиду «ArrayList», а под «списком» — «LinkedList»...

Или например «внутренний клас, обьявленный внутри метода, НЕ МОЖЕТ ИМЕТЬ ИМЕНИ и поэтому называется анонимным».

З.Ы. может это мне конечно так повезло, но был на 2 собеседованиях в оной компании, и оба раза был неприятно удивлен отношением со стороны собеседователей.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Алексей Лукьянов 08.12.2010 13:00

Специалист специалисту рознь...
Элементарные примеры отбора разработчиков: — Часто на синьёров аутсурсинга берут переводчиков с английского, а не специалистов с опытом C++/Java, потом спустя время не знают куда его деть, и его английский как таковой не очень нужен и джаву/С++ не осиливает вовсе.
или — Берем того, кто мля умеет на C++ завернуть абстрактно код. Типа, завернул так что бы сразу не было даже спецу понятно — БЕРЕМ, иначе в сад...
или — Смотрят мол, на основы, типа расскажи мне ООП. И их не гребет что у человека 6−8 лет опыта программирования большущих систем. Потом найдя какой то «недовыговор» по заданному вопросу, и сразу же делают вывод — нет, не потянет. Да я за 10 минут подтяну всю необходимую теорию, если есть необходимость!...
Люди мы разные, по разному смотрим на жизнь, взгляды пересекаются, но это не значит, что все разработчики будут как один.
Просто на рынке труда IT у нас, мало кто смотрит на потенциал и уровень самообучаемости.

У многих контор одно и тоже: вот от сюда и до обеда...а не? значит нет!...

Відповісти

Підтримати

св Антоний 05.12.2010 16:53

По сути сказано ноль

Повторюсь: ИМХО, специализация — это разработка приложений с использованием конкретной технологии. Дальнейшее расщепление градации, или нахождение своей ниши в разработке, и заниматься в пределах сугубо этой ниши, и дальше не высовываться — признак ущербности.

Відповісти

Підтримати

anonymous 05.12.2010 15:45

Отличие хирурга от знатока инструментов в том, что хирург лечит, а знаток инструменты точит.

Відповісти

Підтримати

anonymous 05.12.2010 15:42

-

Відповісти

Підтримати

anonymous 05.12.2010 15:06

To Вовка: не совсем так. Хирург людей оперирует. Диагноз ему ставит другой врач или даже несколько, еси он консультируется сразу у нескольких. Сдает анализы и т.п. И кахдый вчачь знет свой «зажим». Хируг знает свои инструменты, знает как решать свои задачи (оперировать определенные органы и системы).

Відповісти

Підтримати

anonymous 05.12.2010 15:02

To @HT0x@: ок, зажим из 2-х деталей. На станке 5 зажима и кнопка вкл/выкл. Чувак знает тока как включить, выключить и читал про то, как пользоваться 3-мя из 5 зажимами. 1-м зажимом пытался пользоваться сам. Так понятней?

Відповісти

Підтримати

anonymous 05.12.2010 14:59

To @HT0x@: Спасибо Кэп (про эргономику). Какая разница как это называется. Я про суть и смысл, а не про название. По сути сказано ноль.

Відповісти

Підтримати

св Антоний 05.12.2010 07:02

что зажим состоит из пару сотен деталей, имеет кучу насадок, переходников, режимов и так далее.

Джуниор санитар детектед?:) Зажим, по-русски говоря, это как ножницы, но с концами различной формы, только они фиксируются в одном положении. Деталей там не пара сотен, а как у ножниц, так что аналогия неуместна.

Потом, после неудачной операции, пациент попадает в морг. Сначала его встречает санитар без опыта, на испытательном сроке, который просто его разденет и правильно положит на стол, чтобы другим специалистам было удобно его разделывать. А если он трупы будет укладывать неправильно (рука свесится, или нога, а то и сам труп соскользнет во время вскрытия и упадет на пол) — его карьера на этом и закончится. Потом подходит джуниор разметчик, который фломастером на теле рисует линии разрезов. Рисует он везде, кроме головы (опыта маловато). По нарисованным линиям ~~специалист по базам данных~~ один санитар делает скальпелем разрез на груди, и большими клещами вскрывает грудную клетку. Мастерски и профессионально, одним движением руки. Ну может двумя — он на этом деле собаку сьел. Потом работает второй санитар — он вскрывает брюшную полость, вынимает и шинкует все внутренности. Потом приходит сениор разметчик, и начинает размечать для вскрытия череп. Потому что если не там разметит — черепушка криво откроется, поэтому джуниор разметчик эту ответственную работу и не выполняет. Хотя и интересуется, читает книжки, наблюдает за работой своего старшего товарища. Вот, а потом приходит тим-лид, и делает вынос моска: накернил долотом по разметкам на черепе, сделал несколько надрезов, и потом ЧПОК! — черепушка открылась, всем спасибо, проект закончен

Відповісти

Підтримати

св Антоний 05.12.2010 06:32

Не просто так в современных авто делают управление магнитолой, круизом и т.п. на руле

Да блин, все это называется одним словом — эргономика, я ж писал. Загляни в педивикию что это такое. Если б кнопки управления магнитолой были бы возле педалей — да, это было бы странно.

Відповісти

Підтримати

anonymous 05.12.2010 00:44

Хирург, это не специалист по использованию зажимов — это специалист по лечению людей. Аналогия понятна?

Відповісти

Підтримати

anonymous 05.12.2010 00:34

TO: можно и такое сравнение привести. Только в таком случае не нужно забыть упомянуть, что зажим состоит из пару сотен деталей, имеет кучу насадок, переходников, режимов и так далее. И это круто, если человек его досконально знает. Я думаю, что никто не хочет, чтобы хирург слабо знал каким инструментом ( «зажимом» ) работать в конкретной ситуации. И вместо лучшего вырианта лечения выбрал «шото среднее», которое все знают, но дороже, больнее, опасней и т.п.

Відповісти

Підтримати

anonymous 05.12.2010 00:13

профессионал в какой-то своей области (база данных, язык программирования, фреймворк)?

Язык программирования это инструмент, примерно такой как станок? Тогда специалист по фреймворку есть специалист по определенному зажиму, левому снизу:)

Відповісти

Підтримати

anonymous 04.12.2010 23:03

TO @HT0x@: ты меня явно не понял.
1. про отупение — никто не мешает чиать книги и развиваться. Я про специализацию. Про то, что специалистом ты не будешь везде и сразу. Это невозможно. Можно знать что-то хорошо. Что-то неплохо, а что-то на базовом уровне.
А теперь вопрос — что лучше, человек, который все знает на базовом уровне, типо «кодю на всем, что горит» или человек, который профессионал в какой-то своей области (база данных, язык программирования, фреймворк)?
Мое мнение — 2-й человек. Потому что, такие человеки делают BMW M5, а первые человеки делают Ладу Калину, Таврию и Чери Амулет. Разница есть?
И может 2-й товариищ, который специалит по ходовой про систему фаз газораспределения мало слышал, но зато управляемость и баланс бехи он сделал много лучше оного в китаском тазике.
А про мотор позаботится его товарищ.
Про устаревание знаний — так это не секрет. Любому ИТшнику нужно постоянно учиться, каким бы умным он не был, чтобы не оказаться ненужным. Это относится ко всем, а только к тем, кто крутит гайки М. Это вопрос элементарной адекватности.
2. про «p.s. скажу по секрету — автоматика в самолете работает только на автопилоте. 99%». Не понял при чем тут автопилот и аварии. Я про автоматизацию, про увеличение эффективности работы пилота, про его разгрузку от рутинной, сложной и автоматизируемой компом работы, про подготовку данных для наиболее быстрого восприятия.

Советую погуглить термины «авионика», HOTAS, HUD. Не просто так в современных авто делают управление магнитолой, круизом и т.п. на руле. Эти «новшества» пошли от последних 2-х понятий, проверенных на боевой технике. И это все увеличивает эффективность и безопасность.

Відповісти

Підтримати

Sergius von Bielersee 04.12.2010 17:17

После штрафа он ходил со значком рыбы — капли, приколотым к пиджаку. И просто светился от счастья.

На символ первых христиан похоже. Видно знак того, что он подставил правую щеку...

Відповісти

Підтримати

Anton P Software Engineer в Roku 04.12.2010 17:12

Сначала он был в шоке и истерично смеялся, но сейчас все (и он в том числе) с улыбкой вспоминают этот штраф...

начальник, к стати, не менее уныл, но себя не оштрафовал ни разу — вот они двойные стандарты в действии...

Відповісти

Підтримати

anonymous 03.12.2010 22:51

да в Булате... мы тоже гордимся его штрафом...

А справку ему выдали?

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

Вот дятлы — можно подумать, если человека штрафануть — он будет сиять от радости. Небось, после штрафа у него лицо стало еще более унылым. Может он был просто эмо:)

После штрафа он ходил со значком рыбы — капли, приколотым к пиджаку. И просто светился от счастья.

Відповісти

Підтримати

св Антоний 03.12.2010 20:01

\
одного художника оштрафовали за унылое лицо, хотя лицо начальника было не менее унылым

Вот дятлы — можно подумать, если человека штрафануть — он будет сиять от радости. Небось, после штрафа у него лицо стало еще более унылым. Может он был просто эмо:)

Відповісти

Підтримати

Anton P Software Engineer в Roku 03.12.2010 19:20

да в Булате... мы тоже гордимся его штрафом...

Відповісти

Підтримати

anonymous 03.12.2010 18:13

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

В булате было дело такое, как я слыхал, не? Очень гордо. Лично я бы гордился таким штрафом.

Відповісти

Підтримати

Anton P Software Engineer в Roku 03.12.2010 17:59

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

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

Відповісти

Підтримати

anonymous 03.12.2010 17:45

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

А жаль, что не карточная игра. Не пройти собеседование, т.к. не умеешь играть в карты — это уровень. Я бы у них попросил себе сертификат даже, удостоверяющий, что я не прошел собеседование по этой причине и крайне бы им гордился. На стену повесил.

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

Для багфикса (в терминах аутсорса) это- крупный проект, как по мне. ЗА год не справидца с багами и надстройкой функциональности небольшой — это надо уметь. Полная переработка — займет уже больше, но полной переработки в нашей промышленности не бывает. Только надстройки, которые — аналог багфикса и дописывания индусокода в аутсорсе.

просто пару месяцев назад пришло предложение, где крупным проектом назвали проект длинной 6 месяцев...

Ну, ты ж не знаешь, сколько там человек на проекте на 6 месяцев, не? Может, там 200 челвоек арт отдела и 50 проггеров. В итоге, не такой уж и маленький проект, не?

Відповісти

Підтримати

Anton P Software Engineer в Roku 03.12.2010 17:36

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

просто пару месяцев назад пришло предложение, где крупным проектом назвали проект длинной 6 месяцев...

Відповісти

Підтримати

anonymous 03.12.2010 16:54

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

А куда собеседовался? Бридж — это ты о паттерне или об игре карточной?
Не помню, в какой теме ты писал о человеко-годах в ембеддеде и ентерпрайзе, отвечу здесь. Человеко-столетия — это весьма малый термин в полноценой встраиваемой или промышленной деятельности, когда идет разработка с нуля, а не переработка или доработка. Простой пример — черновая клеть блюминга и визулизация. Срок выполнения системы автоматики — 2 года четырьмя людьми + система визуализации + отладка система и мониторинг во время эксплуатации — еще пару лет. Но, это сравнимо с доработкой системы (багфиксингом) в аутсорсе, т.к. идет простая переработка предыдущей система управления.
А теперь, давай рассмотрим разработку с нуля такого устройства, принимая, что софт, САПРы, и производство железа не идет в зачет челвоекочасов, т.к. производится сторонними конторами (сервера и софт от сторонних в интерпрайзе тож не относят обычно к челвоекочасам).

Так вот, проектирование стана — пара лет работы инженерно — техническим отделом из 30 человек. ПРоектирование первоначальной системы автоматики — около 3х лет десятком челвоек. Сбор шкафов управления, дублирующих систем, систем визуализации — около года 30ю спецами. Монтаж, установка, строительство, проведение коммуникаций, пусконаладка — около 150 человек в течении года. Смотрим дальше, это я рассказал про один стан, а их на линии 15 + печи и клещевые краны, системы сортировки, системы взвешивания, системы порезки и т.п. ТУт уж интерпрайз тихонько курит в сторонке. Просто, стоит учитывать, что таки доработка систем автоматики — это не создание продукта с нуля, а простой багфиксинг и доработка в терминах софтостроителей, не?

Відповісти

Підтримати

Anton P Software Engineer в Roku 03.12.2010 16:39

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

но зато знаю, на что нужно обратить внимание в дальнейшем развитии...

Відповісти

Підтримати

anonymous 03.12.2010 15:26

Очень запомнился один гордый lead который очень удивился когда я сказал о том что процессы инертны, и еще один очень интересный PM который меня собеседовал и доказывал что System.String — на этапе компиляции преобразовывается в ValueType... А какой он к... В общем в таких конторах и денег обычно предлагают мало:)

А Саттера и Александреску для.Netчиков никто и не отменял. Как впрочем и Кнута.; -)

Відповісти

Підтримати

anonymous 03.12.2010 14:33

а слабо взять в руки рефлектор? если мы о.Net говорим, то
public class List< T>: IList< T>, ICollection< T>, IEnumerable< T>, IList, ICollection, IEnumerable
{
// Fields
private const int _defaultCapacity = 4;
private static T [] _emptyArray;
private T [] _items;
private int _size; ...}

Ну и так далее...

Відповісти

Підтримати

anonymous 03.12.2010 11:37

Це ви тіпа дотепник?

Шутка юмора.

Ще можу проти «разжижением мозга» порекомендувати матан читати на ніч.

Відповісти

Підтримати

Sergius von Bielersee 03.12.2010 11:30

А ще є класика «Труд сделал із обєзяни чєловєка».
Ао коні скільки в полі не пахали, щось не видно у них росту навіть до рівня неардентальців.

Це у вас наслідки радянської освіти. Не праця, а мова і мовлення зробили з бібізяни людину.

Мля, а как насчёт ефєкта взрива моска от таго шо многа думаєш?

Це ви тіпа дотепник?

Відповісти

Підтримати

BONUS 03.12.2010 10:53

Разумеется, если List< T> во фреймфорке не реализован с помощью массива.

Как раз как массив и реализован:) Список это LinkedList< T>.

А когда просят сравнить список и массив, обычно имеют ввиду классическую теорию структур и алгоритмов, а не прямой перевод (List в.Net c массивом в.Net)

Відповісти

Підтримати

anonymous 03.12.2010 10:49

@HT0x@
Чем больше знаний — тем более самодостаточен и независим.

може хватить слоганів,

он ГЛ пишуть, що

Но искренне убежден, что в долгосрочной перспективе, хорошо зарабатывает тот, кто «пашет», т.е. тяжело работает.

А ще є класика «Труд сделал із обєзяни чєловєка».

Ао коні скільки в полі не пахали, щось не видно у них росту навіть до рівня неардентальців.

После второго курса, 6.5 лет назад я как-то месяцок мотал дросселя. Называл этот эффект «разжижением мозга» и очень ему сопротивлялся.

Мля, а как насчёт ефєкта взрива моска от таго шо многа думаєш?

Відповісти

Підтримати

anonymous 03.12.2010 10:38

Напиши предметно, список — это List< T>, или ArrayList ()? А массив — это < T> []?

И шо, никакой разницы?
Ты не указал, из какого языка сии выдержки.
Но могу предположить, что List< T> и < T> [] — далеко не одно и то же.

Разумеется, если List< T> во фреймфорке не реализован с помощью массива.

Индекса в смысле по ключу:)

В смысле по порядковому номеру.:)

Відповісти

Підтримати

anonymous 03.12.2010 10:33

— список — структура, в якій елемент має значення та адресу наступного елементу, теоретично може рости до нескінченності, щоб добратись до Н-го елементу, тре перебрати всі попередні. — масив — структура фіксованого розміру, доступ до елементів відбувається по індексу

А что вообще подразумевается под эпическим “список vs массив”? Напиши предметно, список — это List< T>, или ArrayList ()? А массив — это < T> []? Или как? Если да — вопрос-г0вно, потому что у них всех есть итератор, да и разницы особой в производительности не будет. И индексов ни у списка, ни у массива нет (если я правильно понял вопрос) — это ж не dictionary или hashtable

кагбе сінйор дотнет детектед?

Відповісти

Підтримати

Sergius von Bielersee 03.12.2010 10:32

Антоха всю правду о конвеере сказал:)

После второго курса, 6.5 лет назад я как-то месяцок мотал дросселя. Называл этот эффект «разжижением мозга» и очень ему сопротивлялся. Мне, конечно, это не грозило всего за месяц, впереди было ещё три года универа, через полгода работа программиста.

Відповісти

Підтримати

св Антоний 03.12.2010 10:15

Индекса в смысле по ключу:)

Відповісти

Підтримати

св Антоний 03.12.2010 10:10

А что вообще подразумевается под эпическим «список vs массив»? Напиши предметно, список — это List< T>, или ArrayList ()? А массив — это < T> []? Или как? Если да — вопрос-г0вно, потому что у них всех есть итератор, да и разницы особой в производительности не будет. И индексов ни у списка, ни у массива нет (если я правильно понял вопрос) — это ж не dictionary или hashtable

Відповісти

Підтримати

anonymous 03.12.2010 09:49

2Юрий

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

Это был не ответ?

Відповісти

Підтримати

anonymous 03.12.2010 09:31

-

Відповісти

Підтримати

anonymous 03.12.2010 09:08

я встречал, что некоторых ребят называли тимлидами за «выслугу лет». программировать они видимо никогда и не умели, но вот сливать ветки и раздавать задания у них получалось хорошо.

Відповісти

Підтримати

anonymous 03.12.2010 08:41

ушел читать в чем разница между списками и массивами. Я тоже хочу быть тимлидером.

Только это тимлидом тебя не сделает.

А вот если ты этого не знаешь, а уже тимлид — то интересно узнать, кто тебя нанял.

Відповісти

Підтримати

anonymous 03.12.2010 07:28

Спасибо, я всегда путаюсь, думаю что конец этой проблеме все еще не положен, через месяц опять забуду как правильно; -)

главное список с массивом не путать;)

Відповісти

Підтримати

crypto5 03.12.2010 07:21

Граммар наци: Нет слова проЭкт. Есть слово проЕкт.

Спасибо, я всегда путаюсь, думаю что конец этой проблеме все еще не положен, через месяц опять забуду как правильно; -)

Відповісти

Підтримати

Александр Маненко 03.12.2010 06:59

Граммар наци: Нет слова проЭкт. Есть слово проЕкт.

Відповісти

Підтримати

anonymous 03.12.2010 05:19

ушел читать в чем разница между списками и массивами. Я тоже хочу быть тимлидером.

Відповісти

Підтримати

crypto5 03.12.2010 01:29

Я выводы делаю на основании вашего отстаивания методологий и прочей чепухи, а не того, где вы сидите.

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

Это зависит от отношения в компании — если все с 8 до 5 — то тогда временные зоны — это плохо. У нас же все были гибкие — и график более-менее сместился. Когда жена в декрет ушла, обнаружили что ходить утром в кино — очень классно. И свобода распоряжаться своим временем — это одна из самых больших ценнностей (мдя, с понедельника прийдётся отказаться: ()

Сидя в Украине можно с определенным уровнем комфорта работать и с штатами и с индией, хотя на одной из моих прошлых работ достаточно большой процент народа решал что это не для них в конце концов, а вот штаты с индией это другой расклад,

Відповісти

Підтримати

Євген Остроухов 02.12.2010 23:44

У меня похожая история, так что не нужно делать лишних выводов.

Я выводы делаю на основании вашего отстаивания методологий и прочей чепухи, а не того, где вы сидите.

Тебе проще, а когда в Калифорнии начинается рабочий день Индусы как раз идут спать и наоборот.

Это зависит от отношения в компании — если все с 8 до 5 — то тогда временные зоны — это плохо. У нас же все были гибкие — и график более-менее сместился. Когда жена в декрет ушла, обнаружили что ходить утром в кино — очень классно. И свобода распоряжаться своим временем — это одна из самых больших ценнностей (мдя, с понедельника прийдётся отказаться: ()

Відповісти

Підтримати

crypto5 02.12.2010 22:30

Ни малейшей проблемы за несколько лет. Потому что не было «процесса разработки» в понимании офисных хомячков — с ежедневными сборами всех. Все вопросы отлично решались P2P -, а двум людям пересечься нетрудно.

Тебе проще, а когда в Калифорнии начинается рабочий день Индусы как раз идут спать и наоборот.

Відповісти

Підтримати

св Антоний 02.12.2010 22:24

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

Кагбэ, Генри Форд изобрел конвейер, если знаете. Это дало сумашедший прирост производительности труда. Потому что действия всех работников, участвовавших в процессе, были быстрыми, точными, и доведены до автоматизма. Но было одно НО — у людей снижался IQ, и они тупели. Ну вот ты знаешь, что тебе нужно прикрутить вот там, там и там гайку М5. А потом нажать на кнопку. А потом снова прикрутить эти гайки там, там и там. И снова нажать на кнопку. И так 8 часов в день, 5 дней в неделю, на протяжении нескольких лет. Ты вообще не думаешь. И ты тупеешь. А потом окажется, что эта модель автомобиля снимается с производства, и тебя могут списать в связи с этим, потому что никому и нафиг не нужен квалифицированный, с многолетним опытом, специалист по вкручиванию гаек М5, даже если ты работал на заводе самого Генри Форда. Так что ну его на икс специализацию. ИМХО, нужно стремиться быть самодостаточным. Вот как в эпоху Возрождения — люди стремились стать универсалами, постичь все науки (благо, знаний тогда было мало, даже Парацельс знал мне кажется даже меньше первокурсника мед. института). А фреймворк нужно знать весь, ну может процентов 90, а остальное понадкусывать. А фуле тогда делать? Про базы данных и SQL я вообще молчу. И вообще — волка ноги кормят. Чем больше знаний — тем более самодостаточен и независим.

p.s. скажу по секрету — автоматика в самолете работает только на автопилоте. 99% — человеческий фактор. И эргономика. Вот даже, когда под Пермью несколько лет назад разбился Боинг, основная версия — неумение пилота управлять, из-за отключения автоматики (они оказывается прошли краткое обучение вождение Боингами). А в 2006 году, ТУ-154 упал под Константиновкой, так это ж была не автоматика, а плоский штопор — ручное пилотирование, недопустимый угол подьема при наборе высоты, вес задней половины самолета у этой модели превышает переднюю, плоский штопор, и кирдык. А вы говорите — автоматика...:)

Відповісти

Підтримати

crypto5 02.12.2010 22:20

Был комманда-из-одного-человека в организации (совсем проект непрофильный) — с понедельника подамся в офисные хомячки, за визу продался...

У меня похожая история, так что не нужно делать лишних выводов.

Відповісти

Підтримати

Євген Остроухов 02.12.2010 22:15

А ты сейчас принципал архитектор в маленьком стартапе, или все таки офисный хомячек?

Был комманда-из-одного-человека в организации (совсем проект непрофильный) — с понедельника подамся в офисные хомячки, за визу продался...

Для динамичного стартапа команда из 6 человек в трех отдаленных часовых поясах — это совсем не круто

Ни малейшей проблемы за несколько лет. Потому что не было «процесса разработки» в понимании офисных хомячков — с ежедневными сборами всех. Все вопросы отлично решались P2P -, а двум людям пересечься нетрудно.

Відповісти

Підтримати

crypto5 02.12.2010 19:38

распределённая комманда — это круто)

Для динамичного стартапа команда из 6 человек в трех отдаленных часовых поясах — это совсем не круто.

Відповісти

Підтримати

crypto5 02.12.2010 19:33

Я говорил что компании _начинаются_ с 2−3 человек.

Ты говорил что _продукты_ _пишутся_.

Поэтому они и работают в большой корпорации (Гугл, правильно?) рядовым винтиком.

А ты сейчас принципал архитектор в маленьком стартапе, или все таки офисный хомячек?

А кто сказал что были дырки?

Кто-то сказал что продукт был кривой, и пользователи недовольны?

Відповісти

Підтримати

crypto5 02.12.2010 19:30

офисным хомячкам

Не употребил это слово, день прожит зря?

Відповісти

Підтримати

Євген Остроухов 02.12.2010 19:14

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

Команда распределённая. И я не говорил что нас было 3 человека — нас было 5−6 человек (я на Украине, 1−2 в Индии, 3 человека в Штатах — распределённая комманда — это круто). Я говорил что компании _начинаются_ с 2−3 человек.

И да, я считаю непрофессионализмом манеру менеджмента, при которой дырки затыкаются переработками.

А кто сказал что были дырки? Был энтузиазм. Были горящие глаза. А менедмент как мог — так и остужал (хотя сами местами не лучше — они были и разработчиками). Просто проект был реально больше чем могла потянуть комманда. Но — увы — расширить комманду не получалось (регулярно появлялся кто-то новый -, но обычно у него был менталитет офисного хомячка и он не мог прижится).
В общем — перед релизом было желание «а ещё это проверю». «А ещё это исправлю». И т.д.

Но — как я сказал — офисным хомячкам не понять. Поэтому они и работают в большой корпорации (Гугл, правильно?) рядовым винтиком.

Відповісти

Підтримати

anonymous 02.12.2010 18:58

Прочел с интересом много страниц. Борьба злобных теоретиков с не менее ярыми практиками.:)
Лично мне кажется, что, как обычно, истина где-то посередке. Но не согласен с тем, что сениор должен знать все и сразу. Вы забываете, что:
1 — все в мире относительно. В одной конторе сеньор это одно, в другой — другое.
В реальном мире, в котором мы все живем нет ничего абсолютного. Что для русского хорошо, то для немца смерть.
2-е по поводу.нет, джавы и ФРЕЙМВОРКОВ. Делается все для упрощения, автоматизации, оптимизации. Для уменьшения стоимости разработки и для снижения порога, требуемого для владения инструментами, чтобы можно было привлечь больше ресурсов (людей) и получить больше отдачи за меньшие затраты (времени и денег).
Неужели не видно параллелей с реальным миром? Простой пример — авиация. Чем больше ручной работы у пилота и меньше автоматики, тем дольше и сложнее подготовить новых пилотов. Тем сложнее управление и больше риск катастрофы из-за ошибки человека.
Если же часть работы заберает автоматика — дешевле и быстрее готовить летчиков, меньше нагрузка на пилота. Для боевых самолетов это значит больше шансов сбить, а не быть сбитым, а значит выполнить свою роль, быть эффективным и экономически оправданым.
Та же фигня с коробкой передач автомобиля — 2 руки на руле, больше внимания на дороге, нет риска втыкнуть не ту передачу и заглохнуть/перекрутить двиг, лучше экономиться топливо за счет минимально возможных оборотов (актуально для современных КПП)
Та же фигня с компьютерами. Именно благодаря окошкам и простым ГУЯм непрогеры смогли сесть за тазики и фигачить в них отчеты, документы, и т.п. Без надобность юзать медленную почту, писать вручную и т.п.
Колличество знаний постоянно растет. Не может быть человек профессионалом во всем. Специалист знает свою область и за нее отвечает. Он решает свои задачи. А требовать от.НЕТтчика знать все алгоритмы, их временную сложность, структуры данных, кучу теории да еще и фреймворк, к нему веб сервисы, к нему знание базы данных, к этому кучу библиотек компонентов, библиотек «бест практик» типа ентерпрайз либрери, CAB, SCSF как-то дофига, не кажется ли?
Все равно, что требовать от врача делать операции, лечить народной медициной, делать анализы в лаборатории, специализироваться на всех органах и системах человека, вести психотерапию и т.п.
В таком случа врач, ИТшник, да кто угодно ничего толком знать не будет. Не зря есть специализация. Для того одни клепают окошки, другие пишут алгоритмически оптимальных код, третий проэктирует базу, четвертый проэктирует модель приложения.

И так далее — в мире рыночной экономики важно, чтобы то, во что вкладывается бабло — приносило прибыль. Именно поэтому есть и Индия с ее г@внокодом, и Украина с аутсорсом.

Відповісти

Підтримати

crypto5 02.12.2010 18:38

Вся комманда работала в таком ритме — и начальство и Индия. Просто потому что все хотели выпустить максимально качественный продукт и вовремя.

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

Ну и высокие рейты при почасовой олпате — это мифическая серебрянная пуля, если человеку платить в два раза больше это совсем не значит что он будет работать в два раза лучше, а в случае переработок, как раз наоборт.

Відповісти

Підтримати

crypto5 02.12.2010 18:29

Значит платят почасово и с высоким рейтом. Офисному планктонцу сего не понять, не?

Приступы телепатии?

Відповісти

Підтримати

crypto5 02.12.2010 18:26

Кока-кола и макдональдс — точно такие же стартапы.

Не такие же конечно.

Эппл начали и МС с гаража.

И?

Ну так правильно инвестиции = доход = бабло. Они заработали бабло, когда были в гараже, не? И заработали они его не засчет основания компании, а за счет своего гаражного продукта.

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

Відповісти

Підтримати

Євген Остроухов 02.12.2010 16:25

Поэтому в начале всех книг и докладов говорят: «Нам помогло то-то и то-то, а что нужно вам это вам решать»

Банальный отказ от ответственности. Т.е. учить-учим -, а за результат не ручаемся. Я же говорю — как всякие НЛП.

Вот тут я полностью согласен, если перед релизом ночь не спали, то у менеджера определенно есть талант развода лохов-программистов мотивации сотрудников; -)

Вся комманда работала в таком ритме — и начальство и Индия. Просто потому что все хотели выпустить максимально качественный продукт и вовремя.

Відповісти

Підтримати

anonymous 02.12.2010 14:56

«Кот в наушниках» — проект пишется через «е», и никак не через «э».

Відповісти

Підтримати

св Антоний 02.12.2010 11:58

Чукча не читатель, чукча писатель?:)

Відповісти

Підтримати

anonymous 02.12.2010 10:54

Хех. В нормальных странах министр здравоохранения предварительно проктологом таки поработал, не?

Таки не всегда, министр здравоохранения это не врач, министр здарвоохранения это чиновник. Лечить людей и управлять теми кто лечит — это разные вещи.

Відповісти

Підтримати

св Антоний 02.12.2010 10:12

Ну дык все-таки колупание в г0внокоде — это всего — лишь ступенька в карьере:)

Відповісти

Підтримати

anonymous 02.12.2010 10:06

Хех. В нормальных странах министр здравоохранения предварительно проктологом таки поработал, не?

Відповісти

Підтримати

св Антоний 02.12.2010 09:59

Ну это как кому повезет — то ли работать проктологом, и бомжей принимать, то ли работать министром здравоохранения:)

Відповісти

Підтримати

anonymous 02.12.2010 09:51

Ну дык я сразу и сказал, что надо читать код, а не рассказывать о паттернах и прочей теории, не?

Відповісти

Підтримати

св Антоний 02.12.2010 09:37

Та тут все правы:) Каким бы ты не был умным — вот посадят на проект, у которого гуй на сторонних контролах — и даже черный пояс по методологиям разработки не поможет — будешь в интеллисенсе и обджект броузере лазить, изучать:)

Відповісти

Підтримати

anonymous 02.12.2010 09:28

«Квалификация» — это расплывчато. Заучки под этим понимают количество прочитаных книг, я — опыт на реальных проектах.

Вы оба не правы! Знания можно извлекать и из книг и из проектов, но количество ни книг, ни проектов не о чем не говорит. Я знаю людей которые прочитали много книг и участвовали в десятках законченных проектов, но их код гуано (и это не только мое мнение).

«Чтобы продать что-то ненужное, нужно вначале купить что-то ненужное»

Вы торгаш или инженер? Кстати вспомните Билли, который сначала продал дос, а потом его купил.

Буквальное следование книгам (особенно по XP) — гарантия провала проекта.

Поэтому в начале всех книг и докладов говорят: «Нам помогло то-то и то-то, а что нужно вам это вам решать»

Відповісти

Підтримати

anonymous 02.12.2010 08:49

Вот тут я полностью согласен, если перед релизом ночь не спали, то у менеджера определенно есть талант развода лохов-программистов мотивации сотрудников; -)

Значит платят почасово и с высоким рейтом. Офисному планктонцу сего не понять, не?

Відповісти

Підтримати

anonymous 02.12.2010 08:48

Если говорим о терминологии, то в конце концов мне вообще не ясно:
как человек может хорошо разбираться в предметной области, и совершенно не знать ее терминологии.
Хоть в русском, хоть в английском варианте, в зависимости он языка документации.

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

Эпл и Майкрософт — это компании, у которых большинство успешным проэктов/продуктов сделано командами в больше чем 3 человека.
Кока-кола, макдональдс — я не в курсе, мы обсжудали индустрию ПО, или уже на металургию перейдем?
Бабло — это сколько? Бабка торгующая семками — это успешный проэкт?
Почему ты ушел от моего ворпоса про гугл? Тебя не смущает что adwords, на котором гугл начал колотить деньги появился только в 2000-ом, а получать инвестиции и нанимать они начали в 1998-ом? Тебя не смущает что фейсбук вышел на самоокупаемость только в прошлом году? Тебя не смущает что ютуб до сих пор был мегаубыточным?
У тебя в списке куча компаний которые развивались по пути:
1. Сделали прототип.
2. Получили денег от инвестора.
3. Наняли людей, которые довели все до успешного продукта.
И без пунктов 2 и 3 не было бы ни гугла ни фейсбука и многих других.
Если вопрос упрается в терминологию — основать компанию vs разработать успешный продукт, то тут уж я пас, такой ерундой не страдаю.

Кока-кола и макдональдс — точно такие же стартапы.
Эппл начали и МС с гаража.

Ну так правильно инвестиции = доход = бабло. Они заработали бабло, когда были в гараже, не? И заработали они его не засчет основания компании, а за счет своего гаражного продукта.

Відповісти

Підтримати

crypto5 02.12.2010 07:26

С опытом ( «сеньёрностью» ) приходит способность более адекватно воспринимать реальность — и не говорить догмами («если перед релизом неделю не спали — то менеджер — идиoт»)

Вот тут я полностью согласен, если перед релизом ночь не спали, то у менеджера определенно есть талант ~~развода лохов-программистов~~ мотивации сотрудников; -)

Відповісти

Підтримати

Євген Остроухов 02.12.2010 07:18

синьор — это уровень квалификации программиста.

«Квалификация» — это расплывчато. Заучки под этим понимают количество прочитаных книг, я — опыт на реальных проектах.

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

«Чтобы продать что-то ненужное, нужно вначале купить что-то ненужное»

Никакие навыки «торгаша» не дадут продать то, чего нет. Я и утверждаю что главное в проекте — его довести до конца. Буквальное следование книгам (особенно по XP) — гарантия провала проекта. С опытом ( «сеньёрностью» ) приходит способность более адекватно воспринимать реальность — и не говорить догмами («если перед релизом неделю не спали — то менеджер — идиoт»)

Відповісти

Підтримати

anonymous 02.12.2010 06:00

Чтобы запустить любой проект в момент “когда просто не оказалось конкурентов” — надо его уметь написать быстрее конкурентов. Что никогда не сможет сделать комманда заучек.

ну да, э така фраза, щоб бути успішним не тре бути розумніше за інших, тре хоча б на один день швидше

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 02.12.2010 03:31

zzhou, синьор — это уровень квалификации программиста. Начинают проекты, зачастую, далеко не синьоры, но особенность в том, что в начале требуется не столько инженерные навыки сколько «уменее продавать». Билли добился успеха не потому что написал интерпретатор бейсика, а потому что смог продать дос. И винду писали не 3 человека. И когда на Гугл пошла нагрузка там было тоже более 3 человек. И иОС также как и Мак ОС Х пишут более 3 человек.

Когда говорят «знать паттерны», подразумевают «уметь их использовать», а не тыкать лиш бы написать «у нас использовано 147 паттернов». Паттерны — это просто стандартные решения, от знания которых хуже не будет (джуну), а синьор должен знать (или вы предлагаете «изобретать велосипед»?).

Мы все — «программирующие дельцы» (пишем ради денег). Точнее — не все, некоторые просто офисные хомячки — которые занимаются программированием только потому что они ничего больше не умеют (да и программировать они особо не умеют).

У вас проблемы с логическими связями. Навыки программирования и то чем именно мотивирует себя человек ничем не связаны. Не все хотят «захватить мир».

Відповісти

Підтримати

Євген Остроухов 02.12.2010 03:15

Но я всё к тому, что в прорыве Гейтса нет программистского гения, просто он уже тогда был программирующим дельцом (только не надо говорить, что интерпретатор они написали для своего удовольствия, а потом уже это случайно дало денег).

Мы все — «программирующие дельцы» (пишем ради денег). Точнее — не все, некоторые просто офисные хомячки — которые занимаются программированием только потому что они ничего больше не умеют (да и программировать они особо не умеют).

у него на тот момент просто не оказалось конкурентов.

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

Відповісти

Підтримати

Sergius von Bielersee 02.12.2010 00:43

Зжу, вам лавры кэпа покоя не дают или лень дочитывать до конца?
Ещё раз, для самых маленьких — ничего новаторского в их разработке не было, они прочувствовали потребность рынка в данном интерпретаторе и выдали его на гора. Если вы так же прочувствуете, чего не хватает рынку, вам не придётся загадочно улыбаться и обещать оппоненту бесспорное поражение в фаллометрии — всё будет налицо без лишних объяснений.

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

Відповісти

Підтримати

Євген Остроухов 01.12.2010 23:33

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

Они сделали — вы нет.

Відповісти

Підтримати

Sergius von Bielersee 01.12.2010 22:54

Все компании начинаются с пары человек. Что потом — это уже куда кривая вывезет. Но если бы Пол и Билл делали перекрёстное кодревью и писали юниттесты — то кто-то другой успел бы до них продать Альтаиру Бейсик.

Я вас умоляю: -)

Это было точное попадание в коммерческом смысле. Ничего революционного они не сделали, не было в языкописании в то время уже никакого новаторства, а литературы хватало. А вот в нужное время в нужном месте прочувствовать, где можно взять денег... "Потому он Король, а вы держите фигу в кармане! "© И. Бабель про Беню ~~Гейца~~Крика.

Відповісти

Підтримати

proger 01.12.2010 21:17

Например XP.

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

так вот, про хп — много лет потом, «неожиданно» мы узнали про хп и очень удивились:)

Відповісти

Підтримати

anonymous 01.12.2010 20:00

Чи потрібна на проекті докуменація і яка документація — ЗАЛЕЖИТЬ ВІД ПРОЕКТА (складність, величина, стратегія розвитку) І ВІД ТОГО ХТО ЙОГО РОБИТЬ І В ЯКИХ УМОВАХ (бюджет, терміни і тд)
і оцінювати що і як документувати повинен керівник проекта (ЛЮДИНА ВІДПОВІДАЛЬНА ЗА РЕАЛІЗАЦІЮ ПРЕКТА) котра в рахі невдачі буде хоч чимось та відповідати (хоча б авторитет).

Все інше не більш чим набір рекомендацій на зразок: повітрям треба дихати чистим (проте мільйони живуть в загазованих мегаполісах), спати по 8 годин на день (хоча мільйони не досипають) і тд

Відповісти

Підтримати

Євген Остроухов 01.12.2010 19:51

Вообще люблю XP — сидели бездельники в громадной корпорации и плевали в потолок (книги писали). Проект в результате провалился.

Что характерно — кто такой сейчас Кент Бек? Например, Эрих Гамма (который писал намного менее завирательные «шаблоны» ) сейчас в IBM, занимается большими проектами (Jazz, Eclipse JDT). А Кент Бек — занимается проповедованием своего учения — ездит с лекциями. После того как наруководил проектом в Крайслере.

Відповісти

Підтримати

anonymous 01.12.2010 19:50

З свого досвіду можу сказати, що в мене також викликають роздратування питання на зразок в чому різниця між списком і масивом.
Так сталося що в індустріїї знаходиться велика кількість людей, котрі поверхнево нахватались всіляких термінів, окремих понятть, іншого флуду
і в розмові починають тобі цей флуд виливати...
На одній з конференцій по скраму лектор що кидався всякими «спрінтами», «мастерами» і тд, просто був не в стані сформулювати основні ідеї скраму кількома реченнями...
Тому знов таки з свого досвіду після отримання подібних питань необхідно просто попросити співрозмовника українською (російською)
мовою просто і лаконічно пояснити що він питається і для чого це йому, і взагалі для чого це питання.
В цій дискусіїї знов таки ми бачимо «юніттести», «діаграми», «еджайли» і тд...той самий флуд.
Давайте просто візьмемо юніттест — нехай хтось чітко лаконічно опише що це таке, для чого, своє бачення застосування і тд після цього буде хоча б предмет дискусії.
Знов з свого досвіду так юніттест дуже часто корисний і є ситуації коли він дуже потрібний, а є коли він НЕ ПОТРІБНИЙ, ось і все.
І мені на спвбесіді вистачає 30 хв щоб зрозуміти хто сидить навпроти. Саме тому що той, що говорить вже з першої хвилини розуміє, що треба буде пояснювати

те імена (терміни) чого він промовляє. І повірте розмова змінюється ну дуже відчутно...

Відповісти

Підтримати

crypto5 01.12.2010 19:46

Я же сказал что начинаются все проекты парой людей. Два Стива сделали в гараже компьютер и стали его продавать в разобраном виде — вот и Apple.
Билл с другом написали Basic для Альтаира — вот и будущий MS.

Тут спекуляция на терминах, говорим «проэкты», а примеры приводим «компаний», выше говорим «пишется», а теперь уже только «начинается», про «большинство» видимо тоже голословное утверждение, так как очевидно что Bing, Windows, MS SQL Server начинались делаться сразу большой командой людей, и статистики про удельную часть обоих случаев ни у кого под рукой нету.

Все компании начинаются с пары человек. Что потом — это уже куда кривая вывезет. Но если бы Пол и Билл делали перекрёстное кодревью и писали юниттесты — то кто-то другой успел бы до них продать Альтаиру Бейсик.

Все правильно, но как я уже говорил несколько раз выше, у продукта наступает момент, когда уже дальше без взрослого процесса разработки двигаться труднее.

Відповісти

Підтримати

Євген Остроухов 01.12.2010 19:45

Например XP. При использовании парного программирование, TDD, Continuous refactoring и т.д. необходимо чтобы все знали паттерны, весь стек используемых технологий и т.д. Все эти инженерные практики появились эволюционно как средство борьбы с багами/сложностью и другими проблемами в разработке ПО.

Люблю когда XP вспоминают. Секта вроде НЛП/пикаперов — придумана исключительно ради проведения тренингов, продажи книг и прочего развода лохов. Не слышал ни об одном успешном проекте, написанном согласно XP (т.е. с pair programming, TDD и т.д.)
«Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. [6] Beck became the C3 project leader in March 1996 and began to refine the development method used in the project and wrote a book on the method (in October 1999, Extreme Programming Explained was published). [6] Chrysler cancelled the C3 project in February 2000»

Т.е. кроме книги, ничего и не получилось у Бека.

Відповісти

Підтримати

Євген Остроухов 01.12.2010 19:28

У тебя в списке куча компаний которые развивались по пути:
1. Сделали прототип.
2. Получили денег от инвестора.
3. Наняли людей, которые довели все до успешного продукта.
И без пунктов 2 и 3 не было бы ни гугла ни фейсбука и многих других.
Если вопрос упрается в терминологию — основать компанию vs разработать успешный продукт, то тут уж я пас, такой ерундой не страдаю.

«Инвестору» нужен результат — двести диаграмм и пять гигабайтов «тест-фёст» юниттестов — не результат.

Кроме этого, большинство софта (мелкие приложения — в т.ч. всякие iPhone) пишется маленькими компаниями на свои деньги.

Відповісти

Підтримати

Євген Остроухов 01.12.2010 19:26

Эпл и Майкрософт — это компании, у которых большинство успешным проэктов/продуктов сделано командами в больше чем 3 человека.

Я же сказал что начинаются все проекты парой людей. Два Стива сделали в гараже компьютер и стали его продавать в разобраном виде — вот и Apple.
Билл с другом написали Basic для Альтаира — вот и будущий MS.

Все компании начинаются с пары человек. Что потом — это уже куда кривая вывезет. Но если бы Пол и Билл делали перекрёстное кодревью и писали юниттесты — то кто-то другой успел бы до них продать Альтаиру Бейсик.

Відповісти

Підтримати

crypto5 01.12.2010 17:02

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

Эпл и Майкрософт — это компании, у которых большинство успешным проэктов/продуктов сделано командами в больше чем 3 человека.
Кока-кола, макдональдс — я не в курсе, мы обсжудали индустрию ПО, или уже на металургию перейдем?
Бабло — это сколько? Бабка торгующая семками — это успешный проэкт?
Почему ты ушел от моего ворпоса про гугл? Тебя не смущает что adwords, на котором гугл начал колотить деньги появился только в 2000-ом, а получать инвестиции и нанимать они начали в 1998-ом? Тебя не смущает что фейсбук вышел на самоокупаемость только в прошлом году? Тебя не смущает что ютуб до сих пор был мегаубыточным?
У тебя в списке куча компаний которые развивались по пути:
1. Сделали прототип.
2. Получили денег от инвестора.
3. Наняли людей, которые довели все до успешного продукта.
И без пунктов 2 и 3 не было бы ни гугла ни фейсбука и многих других.

Если вопрос упрается в терминологию — основать компанию vs разработать успешный продукт, то тут уж я пас, такой ерундой не страдаю.

Відповісти

Підтримати

anonymous 01.12.2010 16:47

Моё последнее

Відповісти

Підтримати

anonymous 01.12.2010 16:43

последнее сообщение моё

Відповісти

Підтримати

anonymous 01.12.2010 16:36

2trimm
Спор на тему надо\не надо можно продолжать до бесконечности.
Если говорим о терминологии, то в конце концов мне вообще не ясно:
как человек может хорошо разбираться в предметной области, и совершенно не знать ее терминологии.

Хоть в русском, хоть в английском варианте, в зависимости он языка документации.

Відповісти

Підтримати

anonymous 01.12.2010 16:26

Глухонемой синьор нада?
Даже если он хорошо код строчить умеет, он ведь должен как-то общаться с коллективом.

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

Відповісти

Підтримати

anonymous 01.12.2010 16:04

Ну вот я ж и грю, что теоретики зохавали мир, не?

Глухонемой синьор нада?

Даже если он хорошо код строчить умеет, он ведь должен как-то общаться с коллективом.

Відповісти

Підтримати

anonymous 01.12.2010 16:01

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

Ну вот я ж и грю, что теоретики зохавали мир, не? И это, несмотря на то, что теория — это ничто. ТЕм более, теория на русском/украинском.

Відповісти

Підтримати

anonymous 01.12.2010 16:00

Ну от в мене на повному серйозі питали щось на подобі реалізації антікрешстеку

Може вже є які шаблони, патерни, а не в курсі.

Відповісти

Підтримати

anonymous 01.12.2010 15:56

Мене от недавно спитали що таке “крешстек” і як з ним боротись?

Думаю, здесь не структура данных имеется в виду:)

Відповісти

Підтримати

anonymous 01.12.2010 15:54

«Хеш таблиця» або «loop-up table» що то таке взнав теж пару років тому, хоча таблиці швидкого розрахунку синуса — косинуса ще 10 років тому використовував, тільки не знав як то по модному називається.
Чесно кажучи, що таке список не знав до 2008 року, бо не стикався, поки не прийшлось малювати полілінії.
Що таке atoi, навіть зара не знаю.
Про дерева, ну знаю, що існують, і що, і до даного часу не було потреби його пробігати, так що?
Мене от недавно спитали що таке «крешстек» і як з ним боротись?
Що людина мала на увазі. Я так і не зрозумів. Може тому, що не приходилось таку структуру даних реалізовувати.
У мене підхід один — може людина поставлені задачі розв"язувати (тобто чи може підівчити прогалини), чи профнепригодний зовсім.

Якщо то сенйор, то повинен вміти менеджити модших, заміняти старших, і помогати тим та іншим, і працювати без особливого нагляду збоку.

Відповісти

Підтримати

anonymous 01.12.2010 15:41

Я так зрозумів, ми пішли по другому колу.

Hello Kitty 4 мес. назад
== anonymous
== LOL. Назови плз десяток основных структур данных.
Стек, очередь, список, дерево, граф, хеш-таблица,...
Пока это вспомнил

Відповісти

Підтримати

anonymous 01.12.2010 15:41

Путь учит матчасть.

Відповісти

Підтримати

anonymous 01.12.2010 15:39

что челвоек просто может не знать терминологии

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

Відповісти

Підтримати

anonymous 01.12.2010 15:37

-

Відповісти

Підтримати

anonymous 01.12.2010 15:25

Юрий, эт вы мне или 2trimm’у?

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

А если он не знает, как оно на русском называедца? Я ведь об этом и веду спор, что спрашивать и задавать наводящие вопросы — нерезонно в контексте того, что челвоек просто может не знать терминологии (а в век общей интернетизации и распространенности иностранных языков, это весьма вероятно). ЗАчем спрашивать, а не дать простое тестовое на структуры данных?

Скільки людей із кола знайомих прогерів може розказати, що то за структури FIFO, LIFO, RAB, CB,

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

чергу, стек, циклічний буфер і буфер із довільним доступом.

Очередь и стек — любой из знакомых. Циклический буфер — это круговой буфер (circular buffer)? Если да, то не сможет написать пара злостных похапешников. Еще пара не учтет особенностей и не вставит проверок на переполнение. Буфер с произвольным доступом — это что? Буфер в котором можно получить любой из его элементов? Если да, тогда все.

Відповісти

Підтримати

anonymous 01.12.2010 15:17

Скільки людей із кола знайомих прогерів може розказати, що то за структури FIFO, LIFO, RAB, CB,

Очередь от стека тоже вообще то отличать не мешает. Особенно синьору.

Відповісти

Підтримати

anonymous 01.12.2010 15:01

Ту алл,
Скільки людей із кола знайомих прогерів може розказати, що то за структури FIFO, LIFO, RAB, CB,

дати визначення і по ходу спрівбесіди реалізувати: чергу, стек, циклічний буфер і буфер із довільним доступом.

Відповісти

Підтримати

anonymous 01.12.2010 14:50

Как ты определишь, знает ли человек, что такое список, если ты его спрашиваешь: «Что такое список? »,

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

Відповісти

Підтримати

anonymous 01.12.2010 14:49

-

Відповісти

Підтримати

anonymous 01.12.2010 14:43

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

И тут мы приходим к тому, с чего я начал свою песнь. Как ты определишь, знает ли человек, что такое список, если ты его спрашиваешь: «Что такое список? », а он не знает, как это на русском называедца. Посему и надо давать тестовые на структуры данных и смотреть, как и что человек применяет, а не спрашивать теорию (что такое список? Как реализовать и т.п.).

Відповісти

Підтримати

anonymous 01.12.2010 14:34

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

Браво! Какой тонкий психоанализ по аватарке, особенно, в части комплексов. Однако, есть неувязочка. Я очень молодой пень. Мне 24 недавно исполнилось. Или ты считаешь, что только старперы могут занимадца проектами, которыми занимался я?

Личные оскорбления? А таковых не было в сиим треде. Ну, а если мы непрямые оскорбления считаем, то свой вопрос тебе надо было адресовать Антоше:

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

Відповісти

Підтримати

anonymous 01.12.2010 14:25

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

Відповісти

Підтримати

anonymous 01.12.2010 14:21

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

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

Назвать массив эррэем никто не запрещает.

Відповісти

Підтримати

anonymous 01.12.2010 14:11

Це появилось тому, що в програмування пішло море людей інтелектом трохи вище за мавпу, і щоб хоч якось забезпечити прийнятнуякість кінцевого продукту у масовому кодінгу.

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

Відповісти

Підтримати

anonymous 01.12.2010 14:09

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

Читаем мое прошлое сообщение:

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

И что же мы там видим? А мы видим, что я вполне четко указал, что я нигде не говорю, что не надо знать структур данных, я говорю что не нужна терминология, которая и есть теория, в отличии от умения применять (которое я и предлагал тестить на собеседовании), которой так любят похвастадца теоретики, типа Антоши Мартыненко, которые успели хорошо протереть себе штаны, являясь офисным планктоном, зато нахватались умных слов и теперь этим кичадца, хотя, кроме умных слов, ни на что не способны. ХОтя, у таковых вообще с пониманием проблемы, даже не смогли понять по моим постам, что я программер из других областей, а не из CS, и, как типичная люмпенота, и сразу начали рассказывать о том, что я — неуч, даже не представляя, насколько они в своем формошлепстве жалки.
Давай я тебе другой пример приведу, чтобы было понятнее. Я по системам автоматики и ЦОС вообще не владею теорией на русском. Ну не знаю я терминологии и все, т.к. источников на русском по моей теме почти нет, все статьи на английском. Посему, моя защита, скажем, выглядела весьма забавно, когда я объяснял русскоязычным преподам, что же я такого наворотил в своей адаптивной системе со скользящим регулятором. Тем не менее, несмотря на полное незнание терминологии, я вполне смог объяснить им все, используя английскую теорию и объяснения на пальцах, за что получил свою оценку. Так вот, теперь вопрос, при полном незнании теории, но умении ее применять, являюсь ли я плохим специалистом? Пока, как я вижу, овтет — нет, ибо работодатели ни разу не ныли, что я не могу им что-то пояснить.

Посему, я настаиваю, что теоретики не нужны, и один человек, умеющий применять знания будет сильнее ста человек, которые знают названия.

Відповісти

Підтримати

anonymous 01.12.2010 14:04

Антон, от чому як збити навіть собачу будку, бажано мати креслення, я не кажу про те що на дачний будинок тре проект, а

в програмуванні виходить, що може збіштись шобла і аджайлом нагородити чудо програму.

Все эти инженерные практики появились эволюционно как средство борьбы с багами/сложностью и другими проблемами в разработке ПО

Це появилось тому, що в програмування пішло море людей інтелектом трохи вище за мавпу, і щоб хоч якось забезпечити прийнятнуякість кінцевого продукту у масовому кодінгу.

Відповісти

Підтримати

anonymous 01.12.2010 13:43

Это значит, что теория не должна быть основополагающей, нет?

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

Так як патерни прийшли від ти же будівельників, то давайте їх залишим архатекторам.

Почему? Паттерны — вполне нормальная практика.
И крайне полезна и правильном применении.

То, что кто-то там, впервые прочитав книжку гаммы, начинает строить замки из паттернов, где это надо, и где нет — это не вполне корректный аргумент против.

Відповісти

Підтримати

am am 01.12.2010 13:25

Але якщо в програмістів у тімі кожен сам собі архітектор — то клініка з точки зору будівництва.
І нафіга рядовому прогеру знати много умних слов і пробувати ліпити архітектуру кода, коли тре тупо робити по тому як написано в специфікації або доведено до відома старшими?

Ну не совсем. Есть такие методологии разработки, которые предполагают наличие навыков “архитектора” у всех. Например XP. При использовании парного программирование, TDD, Continuous refactoring и т.д. необходимо чтобы все знали паттерны, весь стек используемых технологий и т.д. Все эти инженерные практики появились эволюционно как средство борьбы с багами/сложностью и другими проблемами в разработке ПО.
Я не думаю, что в ембеддед у вас есть крупные проекты на сотни человеко-лет работы и с объемами исходников в сотни метров. В маленьких проектах совсем другие приоритеты.

В энтерпрайзе часто бывают действительно крупные проекты, и в них без тестов и паттернов дорога только одна — закрыть проект.

Відповісти

Підтримати

anonymous 01.12.2010 13:02

О патернах.
Так як патерни прийшли від ти же будівельників, то давайте їх залишим архатекторам.
Але якщо в програмістів у тімі кожен сам собі архітектор — то клініка з точки зору будівництва.

І нафіга рядовому прогеру знати много умних слов і пробувати ліпити архітектуру кода, коли тре тупо робити по тому як написано в специфікації або доведено до відома старшими?

Відповісти

Підтримати

anonymous 01.12.2010 12:55

И что? Это значит, что знать теорию — вредно?

Это значит, что теория не должна быть основополагающей, нет?

Да будь у тебя хоть 20 лет опыта в ковырянии гoвна — ничему, кроме ковыряния в гoвне, ты не научишься.

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

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

Ой поржал. Что еще скажешь умного? Хотя нет, вопрос задан неверно, верно так: «Ты вообще хоть что-то умное сказать можешь? »

Відповісти

Підтримати

anonymous 01.12.2010 12:48

по-моєму, пацани, ви страдаєте фігньою
хто такий сінйор?
хто такий лід?
почнем з ліда — людина яка може вести інших за собою, тобто лідер
да будь 5 7 пядєй во лбу, якщо нема лідерський якостий лідом не бути
сінйор — головний.
Його задача — помогати меншим і середшим, і бути на поготові замінити ліда.
Я уже ніби приводив приклад, про соціальні структури.
Тобто щоб тім був успішний, тре щоб був, альфа-самєц (він же лід), і хоть один сінйор, щоб комогав-кункурував із лідом, що той не розслабляв булки і але й не перенапрягався.
Решта народу для окучування і мішання г-кода.
Якщо в кого настає ступор — сінйор розрібає.
Лід — задає общий тон і пріоритети.
А забули про ПМа. Цей такий собі абстрактний клас-інтерфейс, із поліморфізмом, який змінює поведінку в залежності
від лінків: клієнт, адміністрація і тім. Через які тім спілкується і кієнтом і адміністрацією.
Якщо тім спілкується з топами або клієнтом напряму — тут уже або модель або реалізація ПМства кульгає.
Візьмем приклад. Будова -
Прораб (ПМ).
Бригадир — ТЛ.
Сінйор — майстер, може бути і не один. Коли бригадир забухав, може виконувати його фунції.
І подавани і замішувачі бетону/розчину підмайстєр"є і т.д.
Вопрос, чи повинен майстер знати, як патерни як правильно бовтати розчин у кориті?
Конєшно приклад прикладний до девелопмента.
Ясний перець що в багфіксингу організовано всьо по другому.
Так кагде надо прилизати після бригади постройку до прілічного вида, щоб комісія могла прийнять з откритими глазами (пофіксать баги до нужного уровня).
Вопрос звучить так — чи можна на фіксанні багов (замазуванні дир і щєлєй і установкє подпорок) стать майстром-укладчіком?

Отієт — нє, сначало надо научіться дєлать багі, що знати їх природу.

Відповісти

Підтримати

maxdz 01.12.2010 12:17

> если он будет выбирать структуры данных, опираять на интуицию

Какой-то минимум все знают. Скажем, массив, сортировка «пузырьком», наследование, передача параметра по значению, итп — таким минимум и будет пользоваться. Другое дело, достаточно ли этого для проекта? (для многих, наверное, даже достаточно):)

Відповісти

Підтримати

anonymous 01.12.2010 12:03

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

Может быть и хуже, если он будет выбирать структуры данных, опираять на интуицию.

Відповісти

Підтримати

am am 01.12.2010 12:01

С опытом понимаешь, что юнит-тесты до задницы, ибо ни они, ни что-либо еще не являюдца панацеей от плохого кода, которого пруд пруди.

Да будь у тебя хоть 20 лет опыта в ковырянии гoвна — ничему, кроме ковыряния в гoвне, ты не научишься.

Я же привел личный пример, что до того, как попасть в сию тему, я не знал термина «список», хотя с успехом применял списки там, где они были необходимы. И да, мое образование с CS связано весьма отдаленно.

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

Відповісти

Підтримати

anonymous 01.12.2010 11:57

С чего вообще спор?
Один написал, что взял на работу кадра с хорошей теорподготовкой, но который оказался ноль на практике.
И что? Это значит, что знать теорию — вредно?
Согласен, знание теории — это не достаточно для хорошего специалиста.

Но в большинстве случаев — это необходимо.

Відповісти

Підтримати

maxdz 01.12.2010 11:46

> Паттерны — это к теоретикам. Также, именно теоретики все поголовно знают, что такое список, а что такое массив. Я же привел личный пример, что до того, как попасть в сию тему, я не знал термина «список», хотя с успехом применял списки там, где они были необходимы.
Тут фишка в том, что если чел знает, что такое список или там, стэк, может описать тот или иной паттерн — есть бОльшая вероятность, что он сумеет им воспользоваться, чем если он не знает/не может описать. В наиболее клинических случаях, незнание матчасти может вылиться в то, что чел будет тратить время на самостоятельное написание функций, которые уже реализованы в АПИ, но чел о них не знал.

Понятно, что нет смысла требовать знания реализации/интерфейса в деталях (для этого есть хелп), но знать о существовании, общее устройство и пользу применения чел должен.

Відповісти

Підтримати

anonymous 01.12.2010 11:41

Причем тут теоритики и паттерны?
Речи идет о базе, которую должны знать все, кто закончил хотя бы один курс института.

Паттерны — это к теоретикам. Также, именно теоретики все поголовно знают, что такое список, а что такое массив. Я же привел личный пример, что до того, как попасть в сию тему, я не знал термина «список», хотя с успехом применял списки там, где они были необходимы. И да, мое образование с CS связано весьма отдаленно. Посему я и сказал, что надо не копать, знает ли челвоек терминологию (теоретик), а дать два тестовых и посмотреть, использует ли человек список и массив, когда в них есть необходимость.

Відповісти

Підтримати

anonymous 01.12.2010 11:35

Извините, но мы говорим о реальных людях в реальных проектах. Они есть, работают и будут работать.

Потому и существует такая масса говняного ПО.
По твоему, для программиста незнание простейших структур данных — это норма.

Ты бы захотел жить в доме, который проектировал инженер, не имеющий элементарных знаний по физике?

Відповісти

Підтримати

anonymous 01.12.2010 11:26

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

Причем тут теоритики и паттерны?

Речи идет о базе, которую должны знать все, кто закончил хотя бы один курс института.

Извини, но сложность выполнения операций — дело тонкое вообще-то. И да, человек вполне может не знать теорию, но пользовадца и тем, и другим.

Не обязан знать, какое О () у какой операции списка или массива. К практике это действительно мало имеет отношение.

Но должен знать когда пользоваться одим, а когда — другим, и понимать почему так.

Відповісти

Підтримати

maxdz 01.12.2010 11:22

> юнит и другие тесты — это must have для любого проекта, который не надо завтра выкинуть в сад
Требования к проектам (даже промышленным, встраиваемым в продукты, выпускаемые концернами) настолько часто меняются, что юнит-тесты, зачастую, будут устаревать к моменту окончания их написания.

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

Відповісти

Підтримати

anonymous 01.12.2010 11:11

Извините, но прогер, не знающий разницу между списком и массивом, это как писатель, не знающий букв. Или математик, не знающий цифр.

Извините, но мы говорим о реальных людях в реальных проектах. Они есть, работают и будут работать.

и все же хотел ось бы дождаться ответа Сергея, а то набросить на вентилятор получилось, а разобраться — нет. Хотя, who cares?

Відповісти

Підтримати

anonymous 01.12.2010 10:58

Это настолько базовые вещи, как ref & value types в дотнете, или наследование/полиморфизм/инкапсуляция в ооп, что знать их просто нужно, вне зависимости от длины прибора. Алгоритмы/нормальные формы и пр. — это уже потребности по профилю, согласен.себя оцениваю как хорошего мидла, переходящего в сеньера, хотя по офф.должности — тим лид. так то.

Проходите в сад, уважаемый полу-синьор, полу-тимлид юнит-тестер. Не знать, что наследование вообще не являедца базовой вещью ООП — это надо уметь. Идите дальше читать книжечки по юнит-тестам и Страуструпа. Вот уж дийсно синьоры и лиды не знают элементарных вещей: userpage.fu-berlin.de/.../doc_kay_oop_en
Зато рассказывают тут, как без тестиков нельзя писать и что все вокруг — «не „сеньёр-разработчик“ и даже не мидл, ага. Гонора у вас реально на тим-лида, это да.»

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

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

Извини, но сложность выполнения операций — дело тонкое вообще-то. И да, человек вполне может не знать теорию, но пользовадца и тем, и другим. Скажем, до прихода в эту тему я не знал, что есть такая штука, как список, хотя использовал их до этого постоянно. Знание терминологии в принципе не являедца столпом, особенно, если люди из других областей программеры. Намного лучше — просто спросить пример и увидеть, умеет ли челвоек пользовать в нужные моменты времени массивы, а в нужное — списки. А то, в итоге, так и наймете себе теоретика, типа таковых, пхающих паттерна на паттерне и паттерном погоняющий, которые сверху еще будут присыпан тестами от недосиньоров, которые не в курсе о том, что же такое ООП.

Відповісти

Підтримати

anonymous 01.12.2010 10:40

Это подавляющее большинство успешных проэктов? Каков критерий успешности? Сколько времени прошло между тем как гугл стал успешным и они наняли 4-го сотрудника?

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

Відповісти

Підтримати

anonymous 01.12.2010 10:30

вы все время носитесь с этим вопросом.

Почему все время? Просто конкретный пример приведен был.

К тому же это то, что так или иначе используется в 99.999 программ.

А собственно, что вы вкладываете в разницу? интересен ваш ответ на этот вопрос.

Программист должен понимать организацию структур данных и сложность выполнения операций с ними.

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

Відповісти

Підтримати

anonymous 01.12.2010 10:13

Извините, но прогер, не знающий разницу между списком и массивом, это как писатель, не знающий букв. Или математик, не знающий цифр.

вы все время носитесь с этим вопросом. А собственно, что вы вкладываете в разницу? интересен ваш ответ на этот вопрос.

Відповісти

Підтримати

anonymous 01.12.2010 09:54

3. Можете пару примеров написать? (на уровне, «Я сделал то и то, и даже ВОТ ЭТО! А вот разницу между массивом и списком не знаю, потому что их никто не использует и за меня все делает JVM, и хватит меня теорией грузить! »:)).

Извините, но прогер, не знающий разницу между списком и массивом, это как писатель, не знающий букв. Или математик, не знающий цифр.

Відповісти

Підтримати

anonymous 01.12.2010 09:54

>> вы не «сеньёр-разработчик» и даже не мидл,

вы тут сначала определитесь что такое синиор/мидл/джун, а то похоже каждый по своему (под себя) это понимает.

Відповісти

Підтримати

anonymous 01.12.2010 09:34

zzhou
А я сеньёр-разработчик. Разрабатываю IDE... бла-бла-бла...
Отличие сеньёра от несеньёра — это более практичные знания. Несеньёр — пионер, у которого не хватает ума что-то делать не по учебнику. Он заучивает умные слова, а в реальном проекте — начинает плакать что юниттестов маловато.
Глупо говорить что юниттесты и т.д. ничего не дают. Но бред требовать написание юниттестов во всех проектах и говорить догмами

увы, у меня для вас плохая новость — вы не «сеньёр-разработчик» и даже не мидл, ага. Гонора у вас реально на тим-лида, это да. Потому как только с опытом понимаешь, что юнит и другие тесты — это must have для любого проекта, который не надо завтра выкинуть в сад. Это настолько базовые вещи, как ref & value types в дотнете, или наследование/полиморфизм/инкапсуляция в ооп, что знать их просто нужно, вне зависимости от длины прибора. Алгоритмы/нормальные формы и пр. — это уже потребности по профилю, согласен.
Ибо приходят потом «сеньёры» и начинают педалить или рефакторить код без тестов, но зато с опытом. Первые недели успешно, а вот через месяц-другой получаем тот самый горячелюбимый говонокод, которые и поддерживать уже не возможно, ибо все разваливается при любом мелком чихе и выбросить жалко и дорого.
Странно что вы пишете о таком, работая над IDE. Хотя и notepad можно считать IDE... тогда да.

зы: у самого опыта 10+ очень интенсивных лет в больших и маленьких проектах, себя оцениваю как хорошего мидла, переходящего в сеньера, хотя по офф.должности — тим лид. так то.

Відповісти

Підтримати

crypto5 01.12.2010 06:27

И так разговор перешёл на личности...

Однако, сколько тебе понадобилось времени, что бы это заметить.

Відповісти

Підтримати

Євген Остроухов 01.12.2010 06:23

Ты считаешь это единственным чего ты мог бы стыдиться?

И так разговор перешёл на личности...

Відповісти

Підтримати

crypto5 01.12.2010 06:19

Я не стыжусь что люблю комедии Кевина Смита.

Ты считаешь это единственным чего ты мог бы стыдиться?

Відповісти

Підтримати

anonymous 01.12.2010 03:19

по теме,

Собеседовал людей с опытом по 4−7 лет.
В прошлом синьоры и лиды.
Так не знают разницу между массивом и списком.

Сергей, Вам вопрос.
7 лет опыта реальных проектов — не малый период для получения хорошей, не то что базы, а основательных знаний в тех или иных технологиях. Не говоря про программирование как таковое.
Я думаю, Ваши вопросы на собеседовании не ограничивались «разницей между массивом и списком».
Наверное, кандидаты всячески пытались рассказать и показать свой опыт, знания и примеры решения каких-то реальных задач и проблем в проектах.
1. Насколько значительны были успехи этих людей? Не перекрывают ли они (успехи) проблем с базовыми вещами?
2. Мог ли фактор переживания, внутреннего беспокойства повлиять на устные ответы? (для многих людей собеседование морально не простая вещь, даже для зубров свернувших технические горы).

3. Можете пару примеров написать? (на уровне, «Я сделал то и то, и даже ВОТ ЭТО! А вот разницу между массивом и списком не знаю, потому что их никто не использует и за меня все делает JVM, и хватит меня теорией грузить! »:)).

Відповісти

Підтримати

Євген Остроухов 01.12.2010 02:10

Я уже понял что у тебя широкий кругозор в плане увлечений.

Я не стыжусь что люблю комедии Кевина Смита.

Відповісти

Підтримати

crypto5 01.12.2010 00:58

См. термин Dutch Rudder.

Я уже понял что у тебя широкий кругозор в плане увлечений.

Відповісти

Підтримати

Євген Остроухов 01.12.2010 00:19

Нет нормальных программ на белом свете, как дальше жить...

Ровные программы до релиза не доживают.

Что конкретно плохого в код ревью? То что тыкают носом балаболов в их гавнокод, и они потом уходят на другие «интересные» проэкты?

См. термин Dutch Rudder.

Відповісти

Підтримати

св Антоний 30.11.2010 22:10

Да фигня все это — Ableton с эксепшеном в cpp модуле третий раз щас упал, куда мир катится? Нет нормальных программ на белом свете, как дальше жить...

Відповісти

Підтримати

crypto5 30.11.2010 22:06

Common sense.

Ну что же, очередной пример когда твой common sense расходится с реальностью.

Этот проект убил во мне слепую веру в учебник. И это бесценный урок, которого так не хватает офисным хомячкам.

бла бла бла.

Посмотри на свой компьютер — на все программы. DOS (основанный на CP/M) — написал один человек, потом уже до Windows доросло. Excel (в виде Lotus 1−2−3) написал один человек. Всевозможные сайты и т.д. — всё это создаётся маленькими командами, которые понимают что бессонная неделя перед релизом — это не признак глупости, а просто работа программиста.

Те версии, которые писались одним человеком, и то что стоит у меня на компьютере — несколько разного поля ягоды.

А потом приходит инфантильный офисный хомячёк и начинает рассказывать про перекрёстные кодревью.

Что конкретно плохого в код ревью? То что тыкают носом балаболов в их гавнокод, и они потом уходят на другие «интересные» проэкты?

Офисный хомячёк за это время только откроет пустую диаграмму в Розе и пойдёт чай пить.

Опять за всех расписываешься? Может хватит дартаньянствовать?

Відповісти

Підтримати

anonymous 30.11.2010 21:58

Зав’язалась цікава дискусія, моя точка зору наступна — на все потрібно в першу чергу розуміння.
Кваліфікований програміст тим і відрізняється від не кваліфікованого, ЩО РОЗУМІЄ ЩО ВІН РОБИТЬ причому розуміє глибоко.
Базових ідей ООП не так і багато (та і ніякі то не ідеї ООП — тим ідеям «100 лет в обед»),
людина котра дійсно їх глибоко пропустила через себе сприймає патерни
не більше як зразки застосувань певних ідей до певних умов, причому розуміє де в межах патерна закінчується одна ідея
і розпочинається інша і для чого була перша і для чого інша...
Тому в загальному код хороший якщо за ним проглядаєть чітка, струнка МОДЕЛЬ, котра відображає адекватне розуміння поставленої задачі, ,

а не велика кількість «мудрих» слів з посиланнями на «мудрі» книжки...

Відповісти

Підтримати

Євген Остроухов 30.11.2010 21:25

Можно посмотреть источники этой информации?

Common sense.

То есть вы поучаствовали в создании одного кривого продукта с оборотом в пару млн баксов в год, и это позволило вам считать себя мегазвездой?

Этот проект убил во мне слепую веру в учебник. И это бесценный урок, которого так не хватает офисным хомячкам.

Это подавляющее большинство успешных проэктов? Каков критерий успешности? Сколько времени прошло между тем как гугл стал успешным и они наняли 4-го сотрудника?

Посмотри на свой компьютер — на все программы. DOS (основанный на CP/M) — написал один человек, потом уже до Windows доросло. Excel (в виде Lotus 1−2−3) написал один человек. Всевозможные сайты и т.д. — всё это создаётся маленькими командами, которые понимают что бессонная неделя перед релизом — это не признак глупости, а просто работа программиста.
А потом приходит инфантильный офисный хомячёк и начинает рассказывать про перекрёстные кодревью.

У меня были другие проекты — и я знаю что я за 1−2 недели могу сделать нечто, что можно показать заказчику и успокоить его, убедить что всё получится. Офисный хомячёк за это время только откроет пустую диаграмму в Розе и пойдёт чай пить.

Відповісти

Підтримати

crypto5 30.11.2010 21:08

Можно я за него отвечу? Гугл, фейсбук, твиттер, ютуб, чатрулет, групон. Продолжать?

Это подавляющее большинство успешных проэктов? Каков критерий успешности? Сколько времени прошло между тем как гугл стал успешным и они наняли 4-го сотрудника?

Відповісти

Підтримати

anonymous 30.11.2010 20:54

Можно посмотреть источники этой информации?

Можно я за него отвечу? Гугл, фейсбук, твиттер, ютуб, чатрулет, групон. Продолжать?

Відповісти

Підтримати

crypto5 30.11.2010 20:46

Мне приходил сталкиваться с специалистами, которых я так характеризую. Поводов себя уважать в проф. сфере они не давали.

И вас все тяготить необходимость постоянно упоминать это спорное мнение на этом форуме?

Я критикую слепое следование учебнику. И утверждаю что сеньёр — он тем и ценен, что не занимается ерундой. Глупо говорить что юниттесты и т.д. ничего не дают. Но бред требовать написание юниттестов во всех проектах и говорить догмами (менеджер-идиoт потому что релиз был напрягом).

Вы тут кучу всего понаписывали, у вас и патерны и нормальные формы БД и документация — все фигня.

Подавляющее большинство успешных проектов пишется очень маленькими коммандами (макс 3 человека)

Можно посмотреть источники этой информации?

это они потом в бегемотов разростаются.

Они разрастаются когда переходят из стадии полусырого прототипа в стадию взрослого продукта, так как monkey patching дальше не проходит.

Имел. В большом проекте. В котором сорцы были натасканы из кучи опен-сорсных проектов. У которого не получилось единой архитектуры. У которого не было юниттестов. Который работал с внешними системами, у которых не всегда были внятные интерфейсы для взаимодействия -, а когда и были то были или глючными или очень плохо документированными. Но у этого проекта несколько сотен тысяч пользователей, которые раз в год платят за подписку. Они недовольны его качеством — и сами разработчики недовольны его качеством -, но у него всё равно очень ощутимая доля рынка.

То есть вы поучаствовали в создании одного кривого продукта с оборотом в пару млн баксов в год, и это позволило вам считать себя мегазвездой?

Самая страшная проблема у разработчика в банке — обед остыл. Это я знаю.

Я же говорю — балабол.

Відповісти

Підтримати

Євген Остроухов 30.11.2010 19:34

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

Мне приходил сталкиваться с специалистами, которых я так характеризую. Поводов себя уважать в проф. сфере они не давали.

критикуете подходы, которые имеют место быть в индустрии

Я критикую слепое следование учебнику. И утверждаю что сеньёр — он тем и ценен, что не занимается ерундой. Глупо говорить что юниттесты и т.д. ничего не дают. Но бред требовать написание юниттестов во всех проектах и говорить догмами (менеджер-идиoт потому что релиз был напрягом). Подавляющее большинство успешных проектов пишется очень маленькими коммандами (макс 3 человека) — это они потом в бегемотов разростаются. Я не видел ни одного успешного проекта написанного по всем этим методикам.

имели ли опыт работы в больших проэктах

Имел. В большом проекте. В котором сорцы были натасканы из кучи опен-сорсных проектов. У которого не получилось единой архитектуры. У которого не было юниттестов. Который работал с внешними системами, у которых не всегда были внятные интерфейсы для взаимодействия -, а когда и были то были или глючными или очень плохо документированными. Но у этого проекта несколько сотен тысяч пользователей, которые раз в год платят за подписку. Они недовольны его качеством — и сами разработчики недовольны его качеством -, но у него всё равно очень ощутимая доля рынка.

Главное отличие взрослого от ребёнка — умение понимать что не всё делится на «белое» и «чёрное». В этом же и отличие сеньёра от юниора — юниор считает что следование догмам — главное, и будет сухо и комфортно. Меня больше удивляет такое же отношение — что иначе чем инфантильностью я это назвать не могу — у сотрудников банков.

понимаете ли какие там проблемы бывают непонятно

Самая страшная проблема у разработчика в банке — обед остыл. Это я знаю.

поэтому и возникает подозрение, что вы, уж извините — балабол.

Ну подозревайте.

Відповісти

Підтримати

crypto5 30.11.2010 18:54

Я же так понял — вы развиртуализации хотите?

Ваша развиртуализация! = меряние письками со мной. Вы здесь часто употребляете разные слова, типа — пионеры, хомячки и т.д., критикуете подходы, которые имеют место быть в индустрии, но что сами из себя представляете, имели ли опыт работы в больших проэктах, и понимаете ли какие там проблемы бывают непонятно, поэтому и возникает подозрение, что вы, уж извините — балабол.

Відповісти

Підтримати

Євген Остроухов 30.11.2010 18:49

А я предлагал?

Я же так понял — вы развиртуализации хотите?

Відповісти

Підтримати

crypto5 30.11.2010 18:42

Письками мерятся не хочу — всё равно проиграете.

А я предлагал?

Відповісти

Підтримати

Євген Остроухов 30.11.2010 18:37

Или балаболы, никто ж не знает кто скрывается за личиной анонимного дартаньяна.

Письками мерятся не хочу — всё равно проиграете.

Відповісти

Підтримати

crypto5 30.11.2010 18:04

настоящие закалённые в боях ветераны!

Или балаболы, никто ж не знает кто скрывается за личиной анонимного дартаньяна.

Відповісти

Підтримати

Євген Остроухов 30.11.2010 16:57

Неделя неспанья перед релиз означает несколько вещей:
а) Менеджер проекта идиoт. Он не смог организовать нормальный процесс разработки с нормальными техниками программирования (парное программирование, код рекью, TDD, функциональное тестирование, UAT и т.д.)
б) Программисты, которые сие чудо писали — гoвнокод копипастеры. Ибо нормальный человек рано или поздно уходит с проекта, в котором «неделя неспанья» и неадекват менеджер, который не понимает зачем нужен код ревью, рефакторинг и TDD

Вот они — пионеры. У них есть даже паттерны определения идиoтизма менеджмента. Ни шагу от книги!
Проект просто рос спонтанно (сначала никто не ожидал что он так приживётся), количество разработчиков всегда отставало от потребностей проекта (достаточно специфичные умения были нужны)

«Гoвнoкoд-копипастеры» после этого проекта нарасхват — документально подтверждённый опыт, возможность увидеть код (немало стало опенсорсом), здоровый прагматизм. Это не безликие офисные хомячки — настоящие закалённые в боях ветераны!

Відповісти

Підтримати

anonymous 30.11.2010 14:06

Код ревью есть на крупных проектах. А на мелком ширпотребе, типа ифона, его редко кто делает. Скажем, мне проекты доставались от прошлых программеров, которые не справились, т.е. ревью уже до задницы, когда прошлого программера уволили.

на фрилансе код ревью наверно редко где встретишь.,
а вообще, — дело нужное. даже очень.
кстати, а может кто слышал — есть спрос на такого рода работы на фрилансе?

А на мелком ширпотребе, типа ифона

на мелком ширпотребе типа Блекберри- Андроид, там Джава и все порой непросто... — why not?

Відповісти

Підтримати

anonymous 30.11.2010 13:46

Какая прелесть.
Антон, вы — профессионал везде. В экономике, автомобилях, программировании...

Вы забыли про правоведение.

Відповісти

Підтримати

anonymous 30.11.2010 13:31

А код ревью слабо делать перед комитом? Теоретики блин...

Какая прелесть.

Антон, вы — профессионал везде. В экономике, автомобилях, программировании...

Відповісти

Підтримати

anonymous 30.11.2010 13:07

Если тимлид алень, может стоит поменять проект/компанию?

Поменяли тим лида =).

Відповісти

Підтримати

anonymous 30.11.2010 12:43

А код ревью слабо делать перед комитом? Теоретики блин...

Код ревью есть на крупных проектах. А на мелком ширпотребе, типа ифона, его редко кто делает. Скажем, мне проекты доставались от прошлых программеров, которые не справились, т.е. ревью уже до задницы, когда прошлого программера уволили.

Відповісти

Підтримати

anonymous 30.11.2010 12:39

А код ревью слабо делать перед комитом? Теоретики блин...

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

Если тимлид алень, может стоит поменять проект/компанию?

Відповісти

Підтримати

anonymous 30.11.2010 12:25

У меня нет линкедина. В моей сфере он не особо популярен, а созадвать его ради ифона не имеет смысла, т.к. недостаточное портфолио. Если хочешь, пиши мне в ЛС www.developers.org.ua/m/trimm/ Я вряд ли смогу прямо сейчас занядца предложением, т.к. на следующий месяц-два уже есть обязательства, но может смогу посоветовать кого-нить.

Відповісти

Підтримати

anonymous 30.11.2010 12:21

хотите серьезно? вы действительно считаете что ПП редко необходимы? вы тим-лид? расскажите о своих проектах.

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

Відповісти

Підтримати

anonymous 30.11.2010 12:19

список впечатляет. кинь линк на свой LinkedIn, есть хорошее предложение

Відповісти

Підтримати

anonymous 30.11.2010 12:12

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

Я не совсем правильно видать пояснил, т.к. мыслю я все-таки на некстстеповских возможностях. Метакласс — это полноценная сущность, а не метаданные. Ты ее по протоколу можешь дергать как хочешь (хоть инициализировать, статические методы вызывать, хоть еще что), в т.ч. и инстанциировать. Мне не нужно ничего порождать. В том — то и дело. Мне надо создать приспособленца, скормить ему метакласс, чтобы затем приспособленец инстанциировал внутри себя метакласс, выполнил запрос этого метакласса, обработал через делегата выхлоп инстанса и выдал на гора результат через соответствующую нотификацию, чтобы каждый заинтересованный объект мог получить эти данные. Сам сей приспособленец по сути выступает, как прокси смешанный с делегатом. Ну, а метакласс передаедца простым свитчем в классе — хозяине (фабричный метод, если я правильно помню — это и есть приближение). Зачем кучу абстрактных фабрик кидать я не понимаю до сих пор. Просто заново запилил класс, получил кода раза в три меньше, при этом большую гибкость.

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

Опять я неправильно объяснил. Классы полностью независимы, выхлопы их независимы. На простом примере: скачана картинка, об этом событии создаедца сигнал, который идет в приложение. Есть куча обхектов, которые хавают картинку. Инстансы некоторых могут существовать на данный момент, другие не существуют. Так вот, по сигналу никакие объекты не инстанциируются, но все те, которые заинтересованы в картинке и инстанциированы, получают ее. Предположим, один инстанс ее умнеьшает, а другой, который являедца кнопкой, отрисовывает ее на себе, третий матаданные картинки в базу. Так что тут наблюдатель в тему, а посредником отдаленно можно назвать объект, который отослал нотификацию всем заинтересованным объектам. Цепочка ответственности — это слегка не то, хотя они в ифоне есть на уровне реализации объектной модели (если я правильно понимаю, что это). Сигналы — это нотификации, которые получает наблюдатель. Тяжко с терминологией, т.к. я опять же привычен к некстстеповской.

ИМХО, знать шаблоны не означает их правильно применять. Много спорных вопросов.

Это факт. Но пхать их всюду поряд — тоже моветон, нет?

Відповісти

Підтримати

anonymous 30.11.2010 11:54

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

На данный момент не тим-лид, а самозанятый. Тим-лидом бывал. Нате вам 3: система обработки и фильтрации одно-, дву- и трехмерных сигналов, система управления нестабильным балансирующим объектом (аналог сегвея, загнулся, т.к. заказчиков в колчья порвал кризис им пришлось отпустить народ на волю, т.к. денег не было даже на прототип), система управления и учета порезки металла на маятниковых и летучих ножницах (проект без внедрения). Это из крупных. Из мелких — разный ширпотреб на ифон.

Відповісти

Підтримати

св Антоний 30.11.2010 11:54

отдавать делегату тупо метакласс для внутреннего конструирования необходимого класса с унифицированным протоколом и работы с оным через выполнение запроса и обработки выхлопа в делегате, который и являедца потебителем метакласса

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

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

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

ИМХО, знать шаблоны не означает их правильно применять. Много спорных вопросов.

Відповісти

Підтримати

anonymous 30.11.2010 11:42

хотите серьезно? вы действительно считаете что ПП редко необходимы? вы тим-лид? расскажите о своих проектах.

Відповісти

Підтримати

anonymous 30.11.2010 11:21

в мемориз!

Стебадца изволите?

Відповісти

Підтримати

anonymous 30.11.2010 11:17

применять паттерны только когда они дийсно необходимы (что на самом — то деле бывает редко).

в мемориз!

Відповісти

Підтримати

anonymous 30.11.2010 10:42

Ну не знаю... Фабрики тем хороши, что порождающие классы имеют абстракцию, и тебе переписывать ничего не нужно в основном — расширяй базовые классы, и наращивай функциональность, сохраняя при этом предыдущую (у класса А есть абстрактный класс, у класса БЭ тоже, и у фабрики). Фабричный метод тот вообще заменяет тупое создание инстанса на инкапсулированное создание инстанса с его инициализацией... Можно, конечно, доказывать, что class a = new class a (); лучше, чем фабричный метод, потому что всего одна строчка кода, и читается лучше, но... в месяце — 30 дней, базовых паттернов — 23, сделай себе «День паттерна» — каждый день глубоко бури новый, и через месяц ты преобразишься:)

Паттерны тем плохи, что пионерия их лепит всюду, куда ни плюнь. Пример из недавно виденного: есть группка классов, работающих с запросами в инет. Есть контроллирующий класс — делегат. Делегирование я принимаю тут, но кроме этого есть еще столько же фабрик, сколько типов запросов (абсолютно разнородные с разными интерфейсами, с базовыми классами и прочим, упомянуты тобой). Целесообразно? Нет. А целесообразнее было бы вообще сделать запросы с унифицированным интерфейсом (протоколом) и отдавать делегату тупо метакласс для внутреннего конструирования необходимого класса с унифицированным протоколом и работы с оным через выполнение запроса и обработки выхлопа в делегате, который и являедца потебителем метакласса. Или еще пример, есть куча взаимонесвязанных классов, которые должны получать при обработке сигналы извне и по ним обрабатывать внешние данные. Пионерия пхает всюду делегаты, которых наложено куча и которые проникают друг в друга иногда даже нарушая иерархию. В то же время, резонным было бы использование наблюдателя и сигналов (уже не помню, как это называедца у банды четырех).
Именно поэтому, массовое пхание пионерией паттернов приводит к тормозам системы с бешенными оверхедами и абсолютной нечитаемостью и неподдерживаемостью кода. ЭТо происходит из-за того, что апологеты паттернов забывают о очень простой вещи — разделяемости на решения на блоки, чему должны способствовать вообще-то паттерны с полиморфизмом и чему на практике мешают, т.к. системы получаюдца в итоге абсолютно неразделяемыми и крепко завязанными.

И именно по этой причине, код надо писать не с тоннами паттернов, а руководствуясь здравым смыслом и принципом разделяемости кода, а применять паттерны только когда они дийсно необходимы (что на самом — то деле бывает редко).

Відповісти

Підтримати

св Антоний 30.11.2010 09:59

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

Ну не знаю... Фабрики тем хороши, что порождающие классы имеют абстракцию, и тебе переписывать ничего не нужно в основном — расширяй базовые классы, и наращивай функциональность, сохраняя при этом предыдущую (у класса А есть абстрактный класс, у класса БЭ тоже, и у фабрики). Фабричный метод тот вообще заменяет тупое создание инстанса на инкапсулированное создание инстанса с его инициализацией... Можно, конечно, доказывать, что class a = new class a (); лучше, чем фабричный метод, потому что всего одна строчка кода, и читается лучше, но... в месяце — 30 дней, базовых паттернов — 23, сделай себе «День паттерна» — каждый день глубоко бури новый, и через месяц ты преобразишься:)

Відповісти

Підтримати

anonymous 30.11.2010 09:28

Наивный падаван zzhou просто не понимает особенностей больших систем, типа банковских.
Постулат № 1, который сильно отличает банк от стартапа: система уже работает, она уже кому-то нужна, поэтому новые ошибки в системе по определению делают её менее нужной. Это — не стартап, где «ай, да блин, потом исправим, всё равно сейчас ещё ни хрена не работает». Что подразумевает намного большее включение мозгов при написании нового кода. И да, если систему загнать в угол, то разгонят нафиг весь отдел. Поэтому юнит тесты.
Постулат № 2, который сильно отличает банковские системы: система по определению уже устаревшая и завтра будет ещё более устаревшей. Поэтому все новые изменения нужно вносить с прицелом на то, что завтра вам этот код придётся переписывать. То есть придётся переписывать полностью, и хорошо, если вам, а не Пете, который придёт через три года на ваше место — и даже если вам на это плевать, то на это не плевать вашему начальнику. Поэтому документация.
Постулат № 3, который сильно отличает банковские системы: требования к новому функционалу рождают люди, далёкие от программирования. Им глубоко пофиг на то, как вы элегантно нарезали классы и таблицы в своей системе; им нужно, чтобы воооот здесь появилась воооот эта кнопочка, которая делала воооот это — и им плевать на то, что из-за этой мелкой фичи вам придётся переписывать половину кода. Причём эти люди правы, потому что именно они платят вашу зарплату. Поэтому модулярность, избыточность кода, наличие «точек врезки» для потенциально нового кода, наличие write once кода для задач, которые непонятно, как будут сериализировать, и вообще бизнес-подход к программированию.

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

Відповісти

Підтримати

anonymous 30.11.2010 09:13

2Антон Мартыненко:

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

Значит это также говорит и о качестве сертификатов Майкрософт. К сожалению на собеседованиях мы проверяли только теорию и результат был крайне положительный. Как проверить практику на собеседовании с общим лимитом в 1 час я не знаю. Кстати, знаком еще с одним человеком, который очень сильно подкован теоретически, часто ходит по IT мероприятиям и в курсе всех новых технологий. НО! Код писать он не умеет, в результате что-то получается, но это просто мрак. И это тим лид! И может быть обратная ситуация: человек толком ничего сказать не может, но может хорошо сделать! Может у Вас, Антон, такой талант, что видите человека насквозь, но насколько я ориентируюсь в пространстве, есть такие персоны, которые проскочат все ваши тесты, собеседования и т.д. и в результате окажутся негодными работниками. Иначе никто бы не устраивал испытательные сроки.

Відповісти

Підтримати

anonymous 30.11.2010 09:04

Eclipse конечно популярное решение, сам им пользуюсь, но по прожорливости к ресурсам и умению упасть в самый ответсвенный момент ему нет равных.

А как же вижуал студия? =)

В общем — сеньёр vs. несеньёр — это банальное «да вы пороху не нюхали». После недели неспанья (перед релизом) всю ночь фиксить баг, который вылазит у реальных пользователей (просто из-за их обьёмов данных), с полным ребилдом и поинт-релизом — тут не до шаблонов проектирования.

Неделя неспанья перед релиз означает несколько вещей:
а) Менеджер проекта идиoт. Он не смог организовать нормальный процесс разработки с нормальными техниками программирования (парное программирование, код рекью, TDD, функциональное тестирование, UAT и т.д.)

б) Программисты, которые сие чудо писали — гoвнокод копипастеры. Ибо нормальный человек рано или поздно уходит с проекта, в котором «неделя неспанья» и неадекват менеджер, который не понимает зачем нужен код ревью, рефакторинг и TDD

Відповісти

Підтримати

anonymous 30.11.2010 08:18

Теперь ответьте, какова моя ценность как разработчика при переходе на новый проект, если я забью на «дизайн-паттерны, книги по ОО проектированию и буду тупо читать код»? Т.е. он дает некую краткосрочную выгоду за счет того, что писать код неправильно быстрее, чем правильно.

Неоднократно видел код, где паттернами заполнено все от начала и до конца. Код абсолютно нечитабелен, поддерживать тяжело, переписывать — еще тяжелее. Пхать надо по уму и там, где необходимо, а не с горящими глазами пионера делать фабрики на каждый класс с мыслью, тчо потом может появидца надобность в другом классе с тем же интерфейсом и фабрика станет у нагоди. Мне очень нравидца следующий принцип ХР в данном контексте: «Не делай то, что не являедца необходимым на данный момент.»

И да, лично я предпочитаю читать код, а не документацию на живом проекте. И рефакторить почаще.

пятимониторные конфигурации (меня всегда поражала любовь у ламеров к мульти-мониторным конфигурациям — хорошо же известно что они больше мешают

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

Eclipse конечно популярное решение, сам им пользуюсь, но по прожорливости к ресурсам и умению упасть в самый ответсвенный момент ему нет равных.

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

Відповісти

Підтримати

Євген Остроухов 30.11.2010 06:29

Шеф, я бы на вашем месте не очень бы и размахивал флагом. Eclipse конечно популярное решение, сам им пользуюсь, но по прожорливости к ресурсам и умению упасть в самый ответсвенный момент ему нет равных.

В смысле? Я ничем не размахиваю. И одна из прелестей опыта — я не подвязан на конкретные технологии.

Відповісти

Підтримати

anonymous 30.11.2010 06:12

Когда компания живёт с уже готового продукта, который практически не развивается и вся исходная комманда «фанатов своего дела» сбежала. Несколько лет можно и дурака повалять — пока деньги не начнут кончатся. Я обычно «фанат своего дела» — ухожу когда интересное заканчивается.

zzhou++

валяние дурака в саппорте — ловушка для дураков.

Відповісти

Підтримати

anonymous 30.11.2010 05:34

2 zzhou

Шеф, я бы на вашем месте не очень бы и размахивал флагом. Eclipse конечно популярное решение, сам им пользуюсь, но по прожорливости к ресурсам и умению упасть в самый ответсвенный момент ему нет равных.

Відповісти

Підтримати

anonymous 30.11.2010 04:55

Ещё раз. Не уходит крупный клиент от программерской ошибки. Или у вас есть примеры?

550 Кбагзов/год — это большой клиент? Клиент увидел данные другого пользователя и свалил, испугавшись что кто-то получит доступ к его данным.

Відповісти

Підтримати

crypto5 30.11.2010 04:41

Вот опять — теоретики начинают приводить надуманные аргументы.

Чья бы корова мычала.

Відповісти

Підтримати

Євген Остроухов 30.11.2010 03:24

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

Ещё раз. Не уходит крупный клиент от программерской ошибки. Или у вас есть примеры?

Вот опять — теоретики начинают приводить надуманные аргументы.

Есть еще функциональные тесты.

В нормальных компаниях есть тестеры. А не программисты ерундой занимаются.

Відповісти

Підтримати

crypto5 30.11.2010 02:34

ак показывает богатый жизненный опыт — подобные лажи (на реальных данных) не ловятся юниттестами и могут пролезть при любом методе разработке — или юниттесты уже 100% гарантия безбажности?

Есть еще функциональные тесты. Никто не говорит про 100%, но качество автоматическое тестирование обычно поднимает.

Банк разберётся -, но программист ничего и не почувствует. Разве что — без бонуса оставят. Если смогут чётко выяснить чья вина.

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

Это когда — на следующее утро после корпоратива?

Очевидно что я не это имел в виду.

Відповісти

Підтримати

Євген Остроухов 30.11.2010 02:22

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

Как показывает богатый жизненный опыт — подобные лажи (на реальных данных) не ловятся юниттестами и могут пролезть при любом методе разработке — или юниттесты уже 100% гарантия безбажности?

Кривущий — подразумевает множество ошибок, а у банка могут быть проблемы уже из за одной.

Банк разберётся -, но программист ничего и не почувствует. Разве что — без бонуса оставят. Если смогут чётко выяснить чья вина.

Разные ситуации бывают, и в маленьких компаниях можно балду пинать

Угу. Когда компания живёт с уже готового продукта, который практически не развивается и вся исходная комманда «фанатов своего дела» сбежала. Несколько лет можно и дурака повалять — пока деньги не начнут кончатся. Я обычно «фанат своего дела» — ухожу когда интересное заканчивается.

больших могут выжимать как лимон

Это когда — на следующее утро после корпоратива?

Відповісти

Підтримати

crypto5 30.11.2010 01:54

Не бывает таких ошибок. Там многоуровневый контроль — и при необходимости транзакции откатываются.

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

Конкуренты выпустили свой продукт раньше — все на улице. Продукт кривущий — пользователи разбежались — все на улице.

Кривущий — подразумевает множество ошибок, а у банка могут быть проблемы уже из за одной.

Для программиста — работа в большой компании — это ноль ответственности.

Разные ситуации бывают, и в маленьких компаниях можно балду пинать, и в больших могут выжимать как лимон.

Відповісти

Підтримати

св Антоний 30.11.2010 01:47

тут не до шаблонов проектирования

Поздно, батенька, пить боржоми, если печень посажена:)

Відповісти

Підтримати

Євген Остроухов 30.11.2010 01:26

В больших банках где крутятся большие бабки и сервис заказывают большие клиенты — если в продакшне возникает ошибка из за которой уходит большой клиент

Не бывает таких ошибок. Там многоуровневый контроль — и при необходимости транзакции откатываются.

Опять же ИМХО, но в маленьких компаниях — стартапах цена ошибки часто меньше

Конкуренты выпустили свой продукт раньше — все на улице. Продукт кривущий — пользователи разбежались — все на улице.

Для программиста — работа в большой компании — это ноль ответственности. От этого и разжижение мозгов начинается, от скуки шизоидные идеи появляются — всякие перекрёстные код-ревью и пятимониторные конфигурации (меня всегда поражала любовь у ламеров к мульти-мониторным конфигурациям — хорошо же известно что они больше мешают (lifehacker.com/...boost-a-myth))

Відповісти

Підтримати

св Антоний 30.11.2010 01:20

Статья правильная. И заучкам (а иначе любителей паттернов и прочей чепухи назвать нельзя) не понять — что такое создавать успешный продукт.

Вот не надо ля-ля, как говорится. Я лично тоже был когда-то г0внокодером, и писал г0внокод, и считал, что вся сила — в знании фреймворка, а на собеседовании на вопрос о дизайн паттернах ответил, что да, дизайнил в Фотошопе. Паттерны — это, конечно, не панацея, но каждый паттерн служит для выполнения определенной узкой задачи. Которую до тебя успешно решали. И тебе предоставляется возможность не изобретать велосипед (например, как сделать undo / redo, бляха муха, а его почти никто не делает, не нужно городить свои километры г0внокода, для этого есть memento — все просто до безобразия) и тратить время на его изобретение. Потом, стоимость. А как насчет стоимости сопровождения? Если придерживаться парадигмы г0внокода, то стоимость его будет велика, и дебажить будешь довольно долго, зафикся один баг, и наплодив другие. А есть проекты, в которых гуй сделан на UI application block и соотв. библиотеки инфраструктуры от майкрософта. И ты рискуешь его просто поломать, если будешь программить не по правилам. Просто, паттерны — это чисто шаблоны для выполнения конкретной «миниатюрной» задачи, в рамках всей инфраструктуры (если она может быть в г0внокоде), которые тебе конкретно облегчают разработку и сопровождение. Лично у меня получилось достичь такого дзена, когда внесенные изменения даже дебажить не нужно — все работает на ура, с первого раза. И не надо искать по всему солюшну, а где ж блин у меня используется такая-то переменная, и что оно будет, если ее выкосить.

Відповісти

Підтримати

crypto5 30.11.2010 01:10

Цена ошибки в маленькой компании — все оказываются на улице.

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

Опять же ИМХО, но в маленьких компаниях — стартапах цена ошибки часто меньше, поэтому и экономят на ресурсах что бы побыстрее выкатить полусырой продукт.

Відповісти

Підтримати

Євген Остроухов 30.11.2010 00:57

Тесты и прочие красивости в банке важны потому что цена ошибки может быть намного выше чем в маленькой компании,

Цена ошибки в маленькой компании — все оказываются на улице. Цена ошибки программиста в банке — для программиста — нулевая. Ну, скажут «Ц-ц-ц — ай-ай-ай». Никто не будет увольнять, особо даже виновных искать не будут.

В общем — сеньёр vs. несеньёр — это банальное «да вы пороху не нюхали». После недели неспанья (перед релизом) всю ночь фиксить баг, который вылазит у реальных пользователей (просто из-за их обьёмов данных), с полным ребилдом и поинт-релизом — тут не до шаблонов проектирования.

Відповісти

Підтримати

crypto5 30.11.2010 00:30

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

Тесты и прочие красивости в банке важны потому что цена ошибки может быть намного выше чем в маленькой компании,

Відповісти

Підтримати

Євген Остроухов 30.11.2010 00:21

Т.е. получается, что нужно разучивать код наизусть. Теперь ответьте, какова моя ценность как разработчика при переходе на новый проект, если я забью на «дизайн-паттерны, книги по ОО проектированию и буду тупо читать код»? Скорее всего нулевая. Да, я буду знать наизусть текущий проект, но не смогу написать ничего нового — у меня не будет ответов на вопросы почему сделано так, а не иначе. Не забываем, что далеко не все проекты написаны наилучшим образом. Получается, с точки зрения работника данный подход тупиковый.

Статья правильная. И заучкам (а иначе любителей паттернов и прочей чепухи назвать нельзя) не понять — что такое создавать успешный продукт.
Я был в ситуации подобной автору статьи. И я провёл почти 5 лет работая над успешным -, но жутко кривым — продуктом. Это был самый полезный опыт в моей жизни — я это понял уже на новом месте. Потому что меня научили добиваться результата — и на новом месте были поражены когда я за пару недель сделал нечто, что уже выглядит как продукт.
Тесты и прочие красоты — это круто. Когда сидишь в банке и никому результат не важен. А когда это маленькая компания (или стартап) — то важны два показателя:
1. Стоимость
2. ТТМ (time-to-market)

И в таких условиях не до парного программирования, тестов, группового онанизма и прочих студиозных изысков.

Відповісти

Підтримати

crypto5 29.11.2010 23:47

ИМХО задача собеседивания кандидата не имеет формального решения, то есть есть разные подходы которые имеют право на жизнь: одни тестируют умение решать алгоритмические задачи, другие знания апи фреймворков, третьи умение задизайнить архитектуру, еще тестируют умение писать SQL на доске.

Мой подход — задать вопросы кандидату в разных областях и оценить его по сово_купности (автомодератор увидел здесь слово — с_о_в_о_к; -)) критериев. Ну и конечно нужно ориентироваться на область в которой будет работать кандидат, очевидно что разработчику ИДЕ знать нормальные формы БД необязательно.

Відповісти

Підтримати

anonymous 29.11.2010 22:10

Хорошая статья. Достаточно часто приходилось ковыряться в новом/незнакомом коде разных (в т.ч. очень больших) размеров.

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

Основная мысль автора такова"документация не нужна, читайте код«. Юниттесты, шаблоны проектирования тоже не столь важны, вот цитата.

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

Т.е. получается, что нужно разучивать код наизусть. Теперь ответьте, какова моя ценность как разработчика при переходе на новый проект, если я забью на «дизайн-паттерны, книги по ОО проектированию и буду тупо читать код»? Скорее всего нулевая. Да, я буду знать наизусть текущий проект, но не смогу написать ничего нового — у меня не будет ответов на вопросы почему сделано так, а не иначе. Не забываем, что далеко не все проекты написаны наилучшим образом. Получается, с точки зрения работника данный подход тупиковый.

Может он выгоден с точки зрения работодателя — нет, не выгоден. Т.е. он дает некую краткосрочную выгоду за счет того, что писать код неправильно быстрее, чем правильно. Но люди увольняются, болеют, переходят на другую работу, в конце — концов смерть никто не отменял. И если код не документировать, буквально через год разработки получится монстр который будет совершенно невозможно поддерживать. Я такое видел на нескольких проектах: тонны монструозного кода, люди которые его писали в разное время давно поувольнялись (крепостное право отменено), в результате исправление одного бага оборачивается тремя новыми. Набрать новых сотрудников на такой проект, на рыночный уровень зарплат тоже невозможно. А нафик нужно такое счастье, вместо нормальной работы сидеть над глупыми багами с утра и до забора? Значит приходится переплачивать и во много раз. И это все для того, чтоб закончить пилотную версию на месяц раньше, стоит — ли оно того?

Відповісти

Підтримати

Євген Остроухов 29.11.2010 21:07

А я сеньёр-разработчик. Разрабатываю IDE. Много лет. Не помню нормальные формы БД, не знаю алгоритмы и прочую чепуху. Зато могу показать работодателю результаты своей работы в прошлых проектах и умею заранее сказать что не стоит делать (и иногда обьяснить почему).

Есть очень много умений, которые приходят только с опытом — например, умение разбираться в незнакомом кривом коде или плохо документированных системах (я когда-то делал инструменты для удалённого деплоя на WAS — это было весело). Отличие сеньёра от несеньёра — это более практичные знания. Несеньёр — пионер, у которого не хватает ума что-то делать не по учебнику. Он заучивает умные слова, а в реальном проекте — начинает плакать что юниттестов маловато.

Відповісти

Підтримати

anonymous 29.11.2010 17:07

Ну дык и хорошо. Значит, оне себе таковых и хотят.

Відповісти

Підтримати

anonymous 29.11.2010 16:22

Пускай не знают. Зато у них есть СТАТУС. А это важнее.

Получить знания можно и за год, можно даже за меньший срок, если есть способности и огромное желание их получить. Но практически в каждом резюме стандартное требование — от 2−3 лет работы, участие в проектах. Т.е. налицо требования к статусу, а не знаниям.

Відповісти

Підтримати

anonymous 29.11.2010 16:03

Braindump-ы рулят:)

Відповісти

Підтримати

anonymous 29.11.2010 14:26

2anemad

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

Відповісти

Підтримати

anonymous 29.11.2010 14:15

Вот как-то взяли человека дважды сертифицированного Майкрософт, теоретически он ответил лучше всех кандидатов. Не верили своей удаче! Через несколько месяцев пришлось нам расставаться — как практик оказался очень слабым и поломал все что только мог. Чинили после него долго. Вот вам и теория...

Відповісти

Підтримати

anonymous 03.08.2010 12:03

ну может кому то будет важно мое мнение:)

Відповісти

Підтримати

anonymous 03.08.2010 11:57

Капец. Еще упомяни квартирный вопрос и право на работу за бугром и эта тема соберет снова всех флудеров форума.

Відповісти

Підтримати

anonymous 03.08.2010 11:51

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

Відповісти

Підтримати

Roman Luchyshyn Senior C/C++ Developer в Brightgrove 26.07.2010 10:48

З приводу теми. Так от, колись давніше коли сеньором ще не був, тімлід сказа що з 10ти людей яких він інтервювив на сеньорів, лише 2 змогли написали рекурсивну функцію.

Тепер коли самому приходиться інтервювивити, бачу що ситуація така є. Про те які недоліки сінглтона, можна вже не говорити.

Відповісти

Підтримати

maxdz 22.07.2010 18:40

> Читай код© gaperton.livejournal.com/32772.html
Хорошая статья. Достаточно часто приходилось ковыряться в новом/незнакомом коде разных (в т.ч. очень больших) размеров. На мой взгляд, в статье опущен существенный нюанс — чтобы прийти в состояние «дзен» и начать ориентироваться в коде, походить по коду отладчиком (с параллельным чтением проходимого кода и функций вокруг), куда эффективнее одного лишь чтения. По крайней мере, для меня.

Что же касается организации кода — тут, обычно, есть внутрифирменные стандарты на кодирование (шапки модулей/функций, нотация, итд). Считаю необходимым: — дополнительно описывать функциональность сложных функций (которые нелегко читаются, в виде кода из-за размера или сложности алгоритма) — разбивать длинные функции на несколько или выделять вспомогательные классы, чтобы не получать функций, длинее пары-тройки экранов — стараюсь размещать определения классов в персональных хидерах (1 хидер = 1 класс), названных, по имени класса без заглавного «С» — отдельные нэймспейсы (пространства имён), для отдельных предметных областей — избыточно расставлять по всему коду ассерты (помогает и, как средство автодокументирования кода — показывая ограничения на принимаемые переменной значения) — осмысленное именование классов/функций/переменных, по принципу «чем больше область видимости — тем длинее название» — расставление комментариев с отметокой «TODO: » для вещей, которые должны быть изменены/исправлены/добавлены — стараюсь избегать дублирования кода. Если есть возможность реиспользовать существующий код — реиспользую — стараюсь использовать шаблоны проектирования, если возможно

Відповісти

Підтримати

Slava Zemlianskyi Software Engineering Manager 22.07.2010 14:46

anonymous 18 час. назад!
Зачем артикль в параметре?
Зачем метод не с прописной буквы?
Это все стандартные код гайдлайны для ОбжЦ кода, почему товарищь их в ЦРешетке применяет меня не спрашивай.

Исторически сложилось с тех времен, когда команда одновременно работала на С#, Java, Delphi. (в придачу три сервера БД — MySql, Oracle, MS Sql Server). Пришлось как-то сближать стандарты кодирования. Многие моменты потом прижились.

BE.Article

BE — неймспейс, Article — класс.
а — используется как префикс для обозначения аргумента метода
_ — для внутренней переменной

f — для приват поля в классе

Відповісти

Підтримати

anonymous 22.07.2010 07:25

Конечный автомат

Відповісти

Підтримати

anonymous 22.07.2010 07:18

2silverwolf — представте себе обработчик сообщений операционной системы — там их может быть куда больше чем 30−50

Согласен, такое возможно, скорее всего в некоторых случаях особого выбора и нет, но:
1) Это скорее исключение, особенно для ненавистного многим здесь «интерпрайза».
2) Если не надо бороться за каждый тик проца, то я бы разбил такой метод на логические блоки (если это возможно)

Вопрос ведь немного другой:

Иногда имеет смысл сделать метод подлиннее

Ключевое слово именно «сделать», то есть существуют способы разбить на небольшие методы, но программист сознательно пишет метод на 100−150 строк и получает выгоду.

Интересен именно такой пример.

Відповісти

Підтримати

anonymous 22.07.2010 07:03

Господи, спаси и сохрани наивных программистов, ибо не ведают, что творят.

Вы не боитесь летать на Боингах, там используется этот код в управлении полётом?

Відповісти

Підтримати

anonymous 22.07.2010 06:59

2 junior_dev

Спецификацию Вам микрософт забыл подарить, а вам надо её вызвать в своём коде из их библиотеки, причём завтра библиотека будет новой версии, с залатанными дырами, но при

a = 3.141516

будет блюскринчик

Відповісти

Підтримати

anonymous 22.07.2010 06:56

Зависит от ее спецификации, если она должна выполнять что-то типа return a > 10? 0: 1...
то пишем 2 boundary cases типа инфинити, потом проверяем спорный момент 10, 9.9, 10.1 и потом можно еще 2 с произвольными числами rand (> 10) & rand (< 10)
то есть всего 7 в сумме, но как это соотноситься к фабире или дипатчеру?

примеру у вас есть 200 разных сообщений и нужно проверить коректность вызова обработчиков, тут будет достаточно 200 + пара off range тестов что бы это валидировать...

Відповісти

Підтримати

anonymous 22.07.2010 06:51

Сколько тестов надо написать в общем случае для проверки функции

float f(float a);

Відповісти

Підтримати

anonymous 22.07.2010 06:50

Да, но это покрываеться линейным количествои тест кейсов у вас UT_Bla1 зафейлиться... в этом случае

так как количество ожидаемых состояний by design = N (3) поэтому и нужно 3 тест кейса что бы их валидировать...

Відповісти

Підтримати

anonymous 22.07.2010 06:47

switch (int i)
{
case 1: bla1 (arg1);
case 2: bla2 (arg2); break;
case 3: bla3 (arg3); break; }

когда исполняется bla1 (arg1); arg2, arg3 могут измениться, заметтьте нет break; в первом кейсе

Відповісти

Підтримати

anonymous 22.07.2010 06:40

А почему это порождает экпоненцйиальное поле случаев, а не линейное?
к примеру
switch (int i)
{
case 1: bla1; break;
case 2: bla2; break;
case 3: bla3; break; }

порадит 3 случая + 2 баундари кейса, а не 8?

Відповісти

Підтримати

anonymous 22.07.2010 06:36

100 — это сто веток switch

Відповісти

Підтримати

anonymous 22.07.2010 06:34

2silverwolf — представте себе обработчик сообщений операционной системы — там их может быть куда больше чем 30−50... к примеру так реализован диспатчер в VCL насколько я помню, и такой паттерн часто встречал в Win API приложениях...

Відповісти

Підтримати

anonymous 22.07.2010 06:31

2xaxa -

Вам надо проверить 2 в степени 100 вариантов

почему такое число? и почему это означает что они не могу существовать?

в случае диспатчера где бывает критично время исполнения switch иногда работает быстрее чем подписка или регистрация обработчиков в каких-то структурах данных.

Відповісти

Підтримати

anonymous 22.07.2010 06:30

2junior_dev

первое что пришло на ум, один из вариантов реализации диспатчера или фабрики на С++ через switch

А можно поподробнее. Если я вас правильно понял, то для того что бы метод был 100 строк в switch должно бить 30−50 case?

Відповісти

Підтримати

anonymous 22.07.2010 06:30

первое что пришло на ум, один из вариантов реализации диспатчера или фабрики на С++ через switch

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

Відповісти

Підтримати

anonymous 22.07.2010 06:24

2 junior_dev

первое что пришло на ум, один из вариантов реализации диспатчера или фабрики на С++ через switch

Такие конструкции невозможно отладить тестами полностью из-за ограничения времени проверки. Вам надо проверить 2 в степени 100 вариантов

Відповісти

Підтримати

anonymous 22.07.2010 06:18

Иногда имеет смысл сделать метод подлиннее — так что 2 экрана допустимы.

У вас там были проблемы с переполнением стека что ли?:)

Відповісти

Підтримати

anonymous 22.07.2010 05:42

Вячеслав Землянский, тем что вы тут написали вы себя дискредитировали. Тут не было б ничего плохого (всегда можно восполнить недостающие знания, да и можно быть хорошим менеджером даже с плавающими знаниями), если б не два момента: 1) слепая уверенность в своей крутости, 2) вы собеседуете людей. И вот это все уже печально.

Відповісти

Підтримати

anonymous 22.07.2010 05:02

Абсолютно согласен. НО подзадача которая выражается в 100−150 строках кода и ее нельзя разбить на более мелкие — это уже проблема.

первое что пришло на ум, один из вариантов реализации диспатчера или фабрики на С++ через switch

Відповісти

Підтримати

anonymous 22.07.2010 04:58

А мне вот кажется что основной критерий разбиения на методы — это декомпозиция задачи на под-задачи.

Абсолютно согласен. НО подзадача которая выражается в 100−150 строках кода и ее нельзя разбить на более мелкие — это уже проблема.
2Вячеслав Землянский

Хотелось бы увидеть пример такой задачи (подзадачи). У меня есть пару примеров, но все они достигают 100 строк, только за счет форматирования.

Відповісти

Підтримати

crypto5 21.07.2010 20:51

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

Відповісти

Підтримати

anonymous 21.07.2010 20:37

Зачем артикль в параметре?
Зачем метод не с прописной буквы?

Это все стандартные код гайдлайны для ОбжЦ кода, почему товарищь их в ЦРешетке применяет меня не спрашивай.

Відповісти

Підтримати

anonymous 21.07.2010 18:15

Или на 40 дюймовом ТВ будет строк больше чем на 17 при одинаковом разрешении?

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

Відповісти

Підтримати

anonymous 21.07.2010 18:10

public BE.Article selectLast (int aCategoryId)

Это C#?
Зачем артикль в параметре?
Зачем метод не с прописной буквы?

Что за чудо BE.Article? Nested public class?

Відповісти

Підтримати

anonymous 21.07.2010 18:07

Какие дюймы??? Вы что, домохозяйки? Или на 40 дюймовом ТВ будет строк больше чем на 17 при одинаковом разрешении?

Відповісти

Підтримати

anonymous 21.07.2010 16:38

Мониторы можно поставить один над другим, да и еще в портретной ориентации.

Відповісти

Підтримати

gorik gorik 21.07.2010 16:34

Иногда имеет смысл сделать метод подлиннее — так что 2 экрана допустимы.
У нас стандартная конфигурация рабочего места — два по 22 либо два по 23 дюймовых монитора.

Я уже представил этот ~~говно~~код с функциями на 2 22-дюймовых монитора:)

Відповісти

Підтримати

anonymous 21.07.2010 16:31

Определять допустимую длину метода не понятностью кода, а количеством «экранов» это какой то клинический кретинизм...

Відповісти

Підтримати

anonymous 21.07.2010 16:26

Оптимальной считается длина метода не более чем на один экран компьютера, чтобы можно было прочесть не листая.

у меня другой критерий оптимальности — метод должен быть легким для понимания., а понять легче тот метод, который короче. 6−7 строк — в самый раз. 10 — если не повезло

Відповісти

Підтримати

Александр Маненко 21.07.2010 15:59

Вячеслав, здесь народ интересуется о типах полиморфизма от Вашего знакомого Жеки

1. Стандартный способ используя наследование
2. С помощью интерфейсов
3. С помощью рефлексии
4. С помощью аттрибутов (да-да аттрибуты не имеют никакого отношения к рефлексии)

о которых, по его словам

поведал г-н Землянский на собеседовании

Собственно интересует пункт 4 с неотносящимися к рефлексии атрибутами:)

Відповісти

Підтримати

anonymous 21.07.2010 15:57

Иногда имеет смысл сделать метод подлиннее — так что 2 экрана допустимы.

Можно пример. Когда есть смысл такое делать? Или вы экономите на вызове методов?

Відповісти

Підтримати

Slava Zemlianskyi Software Engineering Manager 21.07.2010 15:55

Иногда имеет смысл сделать метод подлиннее — так что 2 экрана допустимы.

У нас стандартная конфигурация рабочего места — два по 22 либо два по 23 дюймовых монитора.

Відповісти

Підтримати

anonymous 21.07.2010 15:49

Оптимальной считается длина метода не более чем на один экран компьютера, чтобы можно было прочесть не листая.

Відповісти

Підтримати

anonymous 21.07.2010 15:29

2. Короткие методы в один-два экрана

фигасе. я думал что короткие это до 6−7 строк, длинные — 10.

Відповісти

Підтримати

anonymous 21.07.2010 15:21

Короткие методы в один-два экрана

экрана смартфона?

Відповісти

Підтримати

Slava Zemlianskyi Software Engineering Manager 21.07.2010 15:13

Читай код© gaperton.livejournal.com/32772.html

Мы тоже редко пишем комментарии в коде. Только, когда что-то неочевидное.
Но есть пару моментов, которые соблюдаются:
1. Осмысленные название ВСЕХ методов, параметров и переменных, таблиц и полей, кроме общепринятных (типа i, j в цикле), которые ОТРАЖАЮТ суть происходящего на АНГЛИЙСКОМ языке. Никаких русских слов в транслите, никаких сокращение типа svExtInf (опять таки, кроме общепринятых типа SOAP, TCP).

Пример:

public BE.Article selectLast(int aCategoryId)



2. Короткие методы в один-два экрана

3. Продуманная структура классов ядра и типовых шаблонов реализации той или иной функциональности.

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

Відповісти

Підтримати

anonymous 21.07.2010 07:36

Читай код — новая идеология запущенных проектов, где менеджеры стали выставлять часы на написание документации и тестов, а заказчик отказалася что ли?:)

Відповісти

Підтримати

Александр Маненко 21.07.2010 07:17

fprog.ru/2009/issue3

Спасибо

Відповісти

Підтримати

Maksym Stepanenko Technical Lead 21.07.2010 07:00

А можно поподробнее, я в этом (ФЯ) пока новичёк, в Эрланге с таким понятием не сталкивался.

fprog.ru/2009/issue3

Відповісти

Підтримати

anonymous 21.07.2010 06:15

Правильно!

И комментарии писать не надо, все-равно их потом никто не читает.

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 21.07.2010 06:15

Читай код© gaperton.livejournal.com/32772.html

Відповісти

Підтримати

anonymous 21.07.2010 05:39

Спрашиваю как работает метод? отвечают поищи поиском в коде, найдешь пример, так и используй.

это вполне адекватный ответ на, кстати, странный вопрос.

Відповісти

Підтримати

anonymous 21.07.2010 02:17

2gonzo,
а ти, очевидно, інтерв"ювером був.

попалив сам себе.

Відповісти

Підтримати

anonymous 20.07.2010 21:36

-

Відповісти

Підтримати

anonymous 20.07.2010 21:26

Был на таком собеседовании, спрашивали такой бред, кое что наверно дочитывали как раз перед собеседованием. Ну доказали мне что они гуру, мне то что. Предложили скосить 300 у.е. от запрашиваемого, отказался. Позвонили через 3−4 дня, говорят приходи на зп которую указал в резюме. Ну пришел, думал там проект вершина инженерной мысли, а там только заказчик жирный, а код использует либы написанные американскими индусами, ни junit, ни javadoc. Спрашиваю как работает метод? отвечают поищи поиском в коде, найдешь пример, так и используй. Вообщем ушел через 2 дня, а вакансию надо называть не senior java developer, а senior java debugger.

Відповісти

Підтримати

Александр Маненко 20.07.2010 18:44

Наверное так утверждают те, кто считает серебряной пулей ООП вообще и ООП-синтаксический сахар в частности.

Відповісти

Підтримати

anonymous 20.07.2010 18:32

И после этого кто-то еще пытается утверждать что Си убог

Відповісти

Підтримати

anonymous 20.07.2010 18:16

1. Стандартный способ используя наследование

следует сказать, что не просто наследование, а переопределение виртуальных методов в классе-наследнике.

похоже начальство глючит

Відповісти

Підтримати

anonymous 20.07.2010 18:11

А что такое полиморфизм? Вызов различной реализации через одну сигнатуру метода. И все.

Відповісти

Підтримати

anonymous 20.07.2010 17:46

1. Стандартный способ используя наследование
2. С помощью интерфейсов
3. С помощью рефлексии
4. С помощью аттрибутов (да-да аттрибуты не имеют никакого отношения к рефлексии)

Піпець, а в якій мудрій книжці таке пише?)) А наслідування від абстрактного класу чи реалізація методів які є оголошені і можуть бути реалізовані в «частковому» класів, що є новою фітчою.NET 4, або ж використання «extensions», тоже окремий поліморфізм?) Мені особисто здається, що є такі сеньйори (що співбесідують), які завчили мудрі слова — «цікавинки» на яких тупо можна ловити майже всіх і тим показувати який він модний перець, а по нормальному можна просто перефразовувати попростіше питання.

Відповісти

Підтримати

Александр Маненко 20.07.2010 17:40

— duck typing (в Python это тоже разновидность полиморфизма)

Надо сказать, что это та штука которой мне лично дико не хватает в C#, куда как элегантнее получаются некоторые решения на Python, нежели на решётках. Впрочем:) статическая/динамическая типизация это известный холивар.

есть градации полиморфизма в ФЯ (ad hoc)

А можно поподробнее, я в этом (ФЯ) пока новичёк, в Эрланге с таким понятием не сталкивался.

Відповісти

Підтримати

anonymous 20.07.2010 17:37

Ну смысл хотя бы в том, что в одном случае тебя возьмут на работу, в другом — нет...

Відповісти

Підтримати

Александр Маненко 20.07.2010 17:37

Ну там по си-шарпу вопрос был. Хотя вот у меня лично подозрение в адекватности (ну или если хотите академической точности) определения полиморфизма через рефлексию и аттрибуты. Само собой возможно я не так понял ответ сэя Евгения:)

Відповісти

Підтримати

anonymous 20.07.2010 17:18

Очевидно, что смысл в поднятии ЧСВ господина Землянского...

Відповісти

Підтримати

anonymous 20.07.2010 17:16

BTW: знание всех видов полиморфизма — это конечно не лишнее, но лично я в этом не вижу огромного смысла

Відповісти

Підтримати

anonymous 20.07.2010 17:14

Забыли — параметрический полиморфизм — duck typing (в Python это тоже разновидность полиморфизма)

+ есть градации полиморфизма в ФЯ (ad hoc), которые отличаются от ООП языков:)

Відповісти

Підтримати

anonymous 20.07.2010 16:39

Тогда еще 5: с помощью реализации абстрактных методов. Гы.

Відповісти

Підтримати

crypto5 20.07.2010 15:19

Да, про полиморфизм очень некачественный вопрос получился — чем принципиально отличается 1 и 2? Очевидно что такая класификация специфична для конкретного ЯП, так как в Ц++ никакой рефлексии нету, а в джаваскрипте все делается через рефлексию...

Відповісти

Підтримати

Александр Маненко 20.07.2010 15:08

да-да аттрибуты не имеют никакого отношения к рефлексии

Совсем никакого? А к чему они тогда имеют отношение?:)

Відповісти

Підтримати

anonymous 20.07.2010 15:02

3. С помощью рефлексии
4. С помощью аттрибутов (да-да аттрибуты не имеют никакого отношения к рефлексии)

примеры можно?

Відповісти

Підтримати

Жека 20.07.2010 14:52

расскажу про 4 типа полиморфизма, о которых мне поведал г-н Землянский на собеседовании (он меня собеседовал), надеюсь он не будет против.
1. Стандартный способ используя наследование
2. С помощью интерфейсов
3. С помощью рефлексии
4. С помощью аттрибутов (да-да аттрибуты не имеют никакого отношения к рефлексии)
Каюсь, что определение 3-й НФ я уже забыл (все же после института кое-какое время прошло), но что лучше — незнание определения или незнание способа использования, вопрос спорный.
По теме топика:

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

Відповісти

Підтримати

anonymous 20.07.2010 12:35

а кладут

Відповісти

Підтримати

anonymous 20.07.2010 11:32

отлично он будет работать. 3я нф интуитивно понятна и ее достаточно.

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

Відповісти

Підтримати

anonymous 20.07.2010 11:12

славик заходи чаще.
меня тоже очень интересует 4 способа. кроме того интересно как рядовой начальник формошлепа, регулярно использует полиморфизм.
славик, скажи
есть библиотека из 100 контролов. они отвечают на какие-то встроенные gestures (типа ховер там или придумай что-то еще).
и есть аппликейшн, который использует все контролы. тут внезапно кодерок решил добавить парочку контролов и новый gesture better_hover.
вопрос: как ты бы все это организовал, чтоб библиотечные контролы могли отвечать на новые пользовательские gestures (не меняя пользовательский код который уже использует контрол. КО). и как это лучше сделать на статик и дайнамик тайпед языках и что бы ты выбрал.
> чем отличается 2 от 3, то как он будет работать с такой базой?

отлично он будет работать. 3я нф интуитивно понятна и ее достаточно.

Відповісти

Підтримати

anonymous 20.07.2010 09:48

о 4 способах?

Відповісти

Підтримати

Slava Zemlianskyi Software Engineering Manager 20.07.2010 09:20

славик, а что для тебя полиморфизм в свете перечисленных тобой в профайле статик тайпд языков?

Это базовое понятие для любых ОО языков програмирование. Не понимаешь сути полиморфизма — не используешь значительную часть возможностей языка. К примеру, в С# есть минимум 4 способа реализации полиморфизма — и все имеют свою область применения.

А по поводу нормальных форм — при проектировании реальных баз данных обычно используются 2 и 3, причем в некотором миксе и в сочетании с нестандартными конструкциями. И если человек на собеседование не может внятно объяснить, чем отличается 2 от 3, то как он будет работать с такой базой?

Відповісти

Підтримати

anonymous 16.07.2010 13:51

Что пристали к человеку? Ну, не знает он ответа.

Відповісти

Підтримати

anonymous 16.07.2010 13:49

-

anonymous 16.07.2010 13:49

-

anonymous 16.07.2010 13:49

-

anonymous 16.07.2010 13:49

-

anonymous 16.07.2010 13:49

-

anonymous 16.07.2010 13:49

-

anonymous 16.07.2010 13:49

-

anonymous 16.07.2010 13:49

-

anonymous 16.07.2010 13:49

-

anonymous 16.07.2010 13:49

-

Bogdan Shyiak SE or Dev 16.07.2010 13:38

2down by the water

это как-то отвечает на мой вопрос?

А вы задавали какой-то вопрос?

Відповісти

Підтримати

anonymous 16.07.2010 11:50

это как-то отвечает на мой вопрос?

Відповісти

Підтримати

anonymous 16.07.2010 10:35

Полиморфизм это не динамическая типизация

Відповісти

Підтримати

maxdz 16.07.2010 10:17

.

Відповісти

Підтримати

anonymous 16.07.2010 10:15

какая глупость. не обязательно знать их по номерам. главное понимать суть.

славик, а что для тебя полиморфизм в свете перечисленных тобой в профайле статик тайпд языков?

Відповісти

Підтримати

Slava Zemlianskyi Software Engineering Manager 16.07.2010 09:26

Таки да, найти хорошего сеньора или техникал лида серъезная проблема. Многие из претендентов не могут внятно объяснить, что такое полиморфизм или третья нормальная форма БД.

Відповісти

Підтримати

anonymous 16.07.2010 06:39

У Нейгела точно є, а також звичайно в MSDN: msdn.microsoft.com/...y/he2s3bh7.aspx

Відповісти

Підтримати

anonymous 16.07.2010 06:33

По моему даже в Рихтере (у меня бумажная по 2.0) есть поверхностный обзор коллекций.

Відповісти

Підтримати

anonymous 16.07.2010 06:22

>> 2PomAH4uK

сішарпний List< T>, то я вас мабуть дуже здивую що насправді це трохи продвинутий масив (аналог std: vector< T> з C++). А списком насправді є LinkedList.

Ха, справді здивували, я так думав)). Ну от прочитав по самому.NET 5 книжок, і жодного згадування про LinkedList. До такого мабуть практика приводить. Чи є специфічна літературка якась хороша, кромі Ріхтера (читав, по GC не всьо поняв:)), де про цікавинки дотНета згадуються?

Відповісти

Підтримати

anonymous 16.07.2010 05:56

думки що краще використати список чи масив взагалі не виникає, завжди список — так легше:)

Якщо під списком малось на увазі сішарпний List< T>, то я вас мабуть дуже здивую що насправді це трохи продвинутий масив (аналог std: vector< T> з C++). А списком насправді є LinkedList. Ось тому і важливо питати такі питання.

Відповісти

Підтримати

anonymous 16.07.2010 00:22

единственного ответа здесь нет, но обе структуры используют разные подходы для организации данных, и поэтому в зависимости от ситуации может быть по разному, для Sorted... есть прямая зависимость на организацию порядка, а для просто Dictionary важна возможность получения ключа с равномерной вероятностью... в зависимости от типа и даже распределения данных они себя будут вести по разному... и нужно понимать как структуры устроены и уметь принимать решения...
Фреймворки это решение для всех... решение для всех, никогда не будет лучше решения только для вашей задачи (всегда есть ограничения изветные вам by design которые могут оптимизировать общее решение с разных точек зрения), а синьер это один из людей который начинает отвечать за решение (solution) и принимать решения (decisions) для развития проекта, этому в его же интересах знать как устроен фреймворк что бы знать что из него можно выжать, а что нужно будет подпилять...

а смотреть как утроен фреймворк тож не зазорно для синьера, если не он то кто? когда остальная команда не знает что делать?

Відповісти

Підтримати

anonymous 15.07.2010 23:37

Незнаю з чого ви взяли що я вважав що не треба знати деталі.NET, якраз я вважаю це головним для.NET senior. Просто часто чую що не важливо яка платформа, головне знати загальні речі.

По поводу питання, ніколи не юзав. Понятно що для першого варіанту додавання обєкту буде швидшим в простому Дікшенері, пошук обєкта буде швидшим для Сортованого, тобто якщо дікшенері більше для читання, то СортедДікшенері, якщо часто міняється то просто дікшенері. З другим затрудняюсь (тому і не сеньйор:), можливо СортедДікшенарі для класу має сенс коли клас реалізує інтерфейс IComparer (якось так)?

Відповісти

Підтримати

anonymous 15.07.2010 22:36

-

anonymous 15.07.2010 22:14

2PomAH4uK — если вы считаете что в дот-нете не нужно знать внутрености, то расскажите когда выгодно использовать SortedDictionary< string, int>, а когда Dictionary< string, int>?

и например для случаев SortedDictionary< MyClass, int> VS Dictionary< MyClass, int>?

Відповісти

Підтримати

anonymous 15.07.2010 21:35

самописними структурами, чесно кажучи неясно де це може бути корисним в.NET

Уточнення, окрім коли вам потрібна спеціальна колекція, як SortedList etc.

Відповісти

Підтримати

anonymous 15.07.2010 21:31

Для того что бы не выжирало память и не тормозило все и вся. Необходимо знать и понимать когда и как хебернейт пишет и читает в базу, как и когда происходит флаш, как он рабает с кэшем, как происходит инициализация коллекций, какие есть особенности при работе с хибернейтовыми проксями, как работает HQL, и как его писать что бы он не делал по стопицот запросов в базу, более узкие вопросы типа “в какой версии можна получить доступ к внутреннему представлению прокси, а начиная с какой уже нельзя? ”

Интересная логика. Джун должен знать структуры данных, а синьор нет? У джуна можно спросить чем LinkedList отличается от ArrayList, для чего нужны Map. А вот синьора можно попросить реализовать мапу (хоть чтение/запись), поспрашевать про хеш коды и икуалсы (хотя можно найти и вопросы поинтереснее).

Гг, матьоро ви хочете щоб сеньйор кожного фреймворку знав деталі і щоб алгоритми знав на память. Я не сеньйор, пока думаю до мідла доріс, але ніколи не доводилось працювати з самописними структурами, чесно кажучи неясно де це може бути корисним в.NET. Я думаю в.NET є більш важливим знання особливості технологій, там найбільше можна оптимізувати швидкість, використання ресурсів (LINQ запити, конфігурація WCF, багатопоточність, GC), а також знання паттернів/ооп. Нераз жертував швидкістю заради простоти коду, небачу в цьому проблему, хіба що б прийшлось писати високонагружений сервіс який не можна розприділити, думки що краще використати список чи масив взагалі не виникає, завжди список — так легше:). Тим не менш різницю цього на мій погляд сеньйорові треба знати. Взагалі думаю для складних алгоритмів мають використовуватись математики, а для написання сторед процедур розробники баз даних, а не майстер Вася, що на всі руки герой.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 15.07.2010 14:36

Вот откуда у вас эта привычка — equals, multy threading — икуалсы, МАЛТИ ТРИДИНГ

Прошу прощения, просто было впадло переключать раскладку, обычно я таки использую англ написание

Відповісти

Підтримати

anonymous 15.07.2010 14:32

Вот откуда у вас эта привычка — equals, multy threading — икуалсы, МАЛТИ ТРИДИНГ (первый раз вижу такое обозначение)?

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 15.07.2010 14:25

Править его сорцы при каждом случае — плохая идея.

Никто и не предлагает их править.

Зачем для этого внутренность хибернейта знать — непонятно.

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

Я джуниоров на собеседованиях например спрашивал как бы они реализовали меп.

Интересная логика. Джун должен знать структуры данных, а синьор нет? У джуна можно спросить чем LinkedList отличается от ArrayList, для чего нужны Map. А вот синьора можно попросить реализовать мапу (хоть чтение/запись), поспрашевать про хеш коды и икуалсы (хотя можно найти и вопросы поинтереснее).

Сеньйоров, имхо нужно по малти тридингу гонять. (речь идет о жабе)

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

Відповісти

Підтримати

anonymous 15.07.2010 13:26

Начиная с некоторого уровня личностные качества начинают перевешивать чисто технические (профессиональные). И человек, который способен «доставить письмо Гарсии», становится не менее (иногда и более) важным для компании, чем узкоспециализированный профессионал. Что, впрочем, не отменяет цености последних.

p.s. Кстати, название топа несколько провокационно. Как минимум до тех пор, пока не будет дано определение того, что в ходит в круг ответственности сеньора/лида. Слишком широкое обобщение.

Відповісти

Підтримати

Grez 15.07.2010 13:11

Я джуниоров на собеседованиях например спрашивал как бы они реализовали меп.
Сеньйоров, имхо нужно по малти тридингу гонять. (речь идет о жабе)
2 silverwolf
Я например не понимаю зачем мне понадобилось бы знать вунтренее строение хибернейта. Имхо, синйор в этом плане должен знать что это такое, как им пользоваться, какой перформанс геп, как тюнить, какие альтернативы и как пользоваться плеин ждбц. Зачем для этого внутренность хибернейта знать — непонятно. Править его сорцы при каждом случае — плохая идея. И если таки вдруг прижмет перформанс именно в хибернейте, а уйти от хибернейта нельзя — то невижу проблемы таки заглянуть внутрь сорцов.

Касательно того чем отличаеться сеньйор от мидла — то тут зависит от контор. У нас например это степень доверия.

Відповісти

Підтримати

anonymous 15.07.2010 12:41

Это был сарказм?

Это была суровая правда жизни...: (

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 15.07.2010 12:28

2eugene_n

Это был сарказм?

Відповісти

Підтримати

anonymous 15.07.2010 12:18

1) Тогда кто это должен знать? Кто должен принимать решение использовать кукую придлуду и использовать ли?

Кто-нибудь другой. Неясно кто, но определенно не такая важная птица, как сеньор на Люксе-Глобале-Эпаме.

2) Что входит в обязанности синьора (кроме получения 2500 Кбагза)?

Целый день висеть на ДОУ-ВКунтакте-Фишках-Youtube.

Чем он отличается от мидла и/или джуна (кроме ЗП)?

Размером ЧСВ.

Відповісти

Підтримати

anonymous 15.07.2010 12:08

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

2. ЧСВ больше еще.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 15.07.2010 12:07

2eugene_n

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

Два вопроса:
1) Тогда кто это должен знать? Кто должен принимать решение использовать кукую придлуду и использовать ли?
2) Что входит в обязанности синьора (кроме получения 2500 Кбагза)? Чем он отличается от мидла и/или джуна (кроме ЗП)?

По поводу трех плюсов абсолютно согласен.

Відповісти

Підтримати

anonymous 15.07.2010 11:53

-

anonymous 15.07.2010 11:53

-

anonymous 15.07.2010 11:53

-

anonymous 15.07.2010 11:53

-

anonymous 15.07.2010 11:53

-

anonymous 15.07.2010 11:53

-

anonymous 15.07.2010 11:53

-

anonymous 15.07.2010 11:53

-

anonymous 15.07.2010 11:53

-

anonymous 15.07.2010 11:52

(например се=делать так что бы код который использует хибернейт не выедал гиг памяти)

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

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

Відповісти

Підтримати

anonymous 15.07.2010 11:51

-

Bogdan Shyiak SE or Dev 15.07.2010 11:00

А вы поспрашивайте этих синьйоров как насетапить ЖЕЕ с спрингом, гибернейтом и прочей фигней.

То есть Java-синьоры занимаются тем что постоянно ~~настраиваю~~ сетаплят фреймворки? Я не синьор, спринг насетапил менее чем за час (насколько оптимально не скажу, проект «домашний» ), с хибернейтом было сложнее поскольку там где я работаю на него уже написана оболочка, которая значительно упрощает использование.

Синьор (Джава) должен, кроме алгоритмов, понимать как работают те же спринг и хибернейт (для этого кстати надо понимать структуры данных:)), и уметь их их использование оптимизировать (например се=делать так что бы код который использует хибернейт не выедал гиг памяти)

Відповісти

Підтримати

anonymous 15.07.2010 10:59

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

Вариант для соискателя нигде больше не работающего. Человек с работой сможет засесть за твое задание только ближе к выходным.

Відповісти

Підтримати

anonymous 15.07.2010 10:58

Я вот подумал, что то, насколько нужно спрашивать «конкретные фреймворки», а насколько — «теоретические алгоритмы», сильно зависит от проекта. ИМХО, при новой разработке фреймворки важнее, но при поддержке legacy проектов (если не нужно проводить рефакторинга в конкретном направлении) важнее что-то более теоретическое, так как сам проект является фреймворком.
Думаю, что в зависимости от того, каким конкретным образом складывалась карьера каждого конкретного программиста, мы получим совершенно разные ответы от разных людей.

Да, в общем-то, даже тот же перевод числа в пропись можно реализовать сильно по-разному стилистически, в зависимости от того, какие задачи были до этого у разработчика. Можно сделать очень эффективный алгоритм, можно сделать алгоритм с очень большим оверхедом, ну и все градации посредине.

Відповісти

Підтримати

anonymous 15.07.2010 10:53

Сеньор — это тот, кто может «насетапить... и прочую фигню»?

Відповісти

Підтримати

anonymous 15.07.2010 10:51

2maxdz
А где вы видели безработных сеньоров?... Покажите плз, у нас в компании за них бонусы 500−1000 баксов.
Я думаю на собеседовании стоит использовать смешанный подход. Вопросы по алгоритмам это хорошо, но реально их почти никто не использует. Вот те же паттерны куда важнее для дотнетчика/джависта.

Можно часик поспрашивать по теории, потом дать относительно простое задание (но не примитивное!) и посмотреть как человек его реализует (например, в Карговайзе было: написать программу, которая переводит сумму денег в цифрах в сумму прописью). Можно уложиться в 3−4 часа и дать ответ в кратчайший срок.

Відповісти

Підтримати

anonymous 15.07.2010 10:48

Grez, ИМХО, человек, которого вы описываете — это джуниор. Ну или человек из другой области, который её меняет.

Відповісти

Підтримати

maxdz 15.07.2010 10:41

> а что рассказывать на текущем месте работы?

Речь идёт о безработных, ищущих работу. С работающими, обычно, всё несколько проще (в смысле квалификации) -, но сложнее, в смысле зарплат.

Відповісти

Підтримати

Grez 15.07.2010 10:40

А вы поспрашивайте этих синьйоров как насетапить ЖЕЕ с спрингом, гибернейтом и прочей фигней.

То на что у человека концентрируемого на алгоритмах уйдет неделя времени, у такого синьйора займет пол часа.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 15.07.2010 10:39

Своего рода «испытательный минисрок».

Для того что бы проверить кандидата существует обыкновенный «испытательный строк». Собеседование нужно для того что бы узнать стоит ли тратить ресурсы компании на «испытание» кандидата. Если кандидат-синьор не знает основ программирования (алгоритмы/структуры и тд), то на мой взгляд тратить на него ресурсы не имеет смысла (по крайней мере расценивая его как синьора), ИМХО.

Відповісти

Підтримати

anonymous 15.07.2010 10:38

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

Відповісти

Підтримати

maxdz 15.07.2010 10:24

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

Відповісти

Підтримати

anonymous 15.07.2010 10:16

Майкрософт и Гугл, кстати не дают таких заданий

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

А на тему украинских реалий это не проканает еще потому, что у нас очень непрозрачная процедура приема. Интервьюер как партизан молчит про вилку ЗП и пытается всеми силами вытянуть из тебя на сколько ты согласен. И заодно присматривается блефует кандидат или нет. В результате далеко не каждому хочется писать 2 дня задание для какого нибудь Самсунга что бы в результате узнать что тебе с барского плеча согласны предложить аж целые 1700 долларов.

Відповісти

Підтримати

gorik gorik 15.07.2010 10:04

Ага, только далеко не каждый уважающий себя кандидат будет сидеть на шару двое суток задание Вам делать.

+100, я даже больше скажу, почти никто не будет.

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

Відповісти

Підтримати

anonymous 15.07.2010 09:53

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

Ага, только далеко не каждый уважающий себя кандидат будет сидеть на шару двое суток задание Вам делать. Если Вы конечно не в Гугль или МС собеседуете...

Відповісти

Підтримати

anonymous 15.07.2010 09:31

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

Ну, например, я исключаю вариант дать задачу на месте и пусть решает. Во-первых потому, что в таком случае задача должна быть тривиальна, чтоб кандидат не сидел день в офисе, так как это скорее всего пугает человека (сужу по своему опыту). Либо какая-то специфическая, с чем кандидат вполне мог и не работать никогда. Получаеться, реально оценить знания таким способом нельзя. Как и теоретический подход, тоже бред ИМХО, конечно.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 15.07.2010 09:15

гер Антон Мартыненко правильно заметил — не получаешь 2500 значит не синьор, а все вот эти знания алгоритмов это как-бы вторичный признак.

Контекст переключайте!
Приходит человек на собеседование и говорит «у меня была ЗП 2500» по вашей логике его надо брать, ибо синьор, а тот факт что он на мидла может и не тянуть и его предыдущий работодатель лох не рассматривается?

Знание «алгоритмов» и правду вторично, главное как человек сможет выполнять свои обязанности (программиста). Каким образом вы предлагаете проверить умения кандидата за пару часов собеседования?

Відповісти

Підтримати

from_luxoft 15.07.2010 07:59

гер Антон Мартыненко правильно заметил

класс!

Відповісти

Підтримати

anonymous 15.07.2010 06:15

гер Антон Мартыненко правильно заметил — не получаешь 2500 значит не синьор, а все вот эти знания алгоритмов это как-бы вторичный признак.

В точку! Ну не зря же пословица такая есть: «Дурак думкою багатiє». Если кто-то не сеньор, то по крайнер мере он может себя самоуспокоить поначитавшисть алгоритмов:).

Відповісти

Підтримати

anonymous 14.07.2010 22:48

А я когда то наблюдал как один синьйор нашел невиданную доселе конструкцию new в коде и испросил другого, а чем же она отличается от override за чем последовало обсуждение где-то на полчаса, а что оно такое те два слова и с чем их едят.

А вобще тут когда гер Антон Мартыненко правильно заметил — не получаешь 2500 значит не синьор, а все вот эти знания алгоритмов это как-бы вторичный признак.

Відповісти

Підтримати

anonymous 14.07.2010 16:56

neuropunk

Однозначно. Если код сложный и/или нужен узкоспециализированный анализ — то «кодеревьюверов» может быть и больше одного.

Відповісти

Підтримати

anonymous 14.07.2010 15:53

neuropunk
Это вопрос баланса технической (специализация в некоторых предметных областях) составляющей и управленческой. В разных ролях в разных организациях пропорции этих составляющих могут существенно отличаться.
Если рассматривать «начальника» как надпись на визитке и прибавку к зарплате — это одно. Если же это лицо, которое реально организует работу коллектива, принимает решения, обеспечивает достижение целей организации в рамках имеющихся ограничений (бюджет, сроки, требования) — то это совершенно другая история.
И для последнего типа сотрудников с сильным перекосом в организационную составляющую ключевую роль играют совершенно другие знания и умения. Что, впрочем, не исключает того, что кое-кто при этом будет разбираться и в деталях ООП, и особенностях классических алгоритмов.

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

Відповісти

Підтримати

anonymous 14.07.2010 14:44

Ребятки! Может хватит выборочной модерации, да?

Відповісти

Підтримати

anonymous 14.07.2010 14:43

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

Відповісти

Підтримати

anonymous 14.07.2010 14:36

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

Відповісти

Підтримати

anonymous 14.07.2010 14:18

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

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 14:10

Антон Мартыненко 4 мин. назад
Ембеддеры, сиплюсплюсники и прочие унылые. Хватит завидовать джавистам и точканетчикам за их высокую зп и успокаивать себя что они «Не знают что такое О (n) ».

Валите в бухи и юристы. С новым НК это станет архивостребованно.

Відповісти

Підтримати

anonymous 14.07.2010 14:08

А еще у вас нету паяльников и осциллографов, лузеры!

Відповісти

Підтримати

anonymous 14.07.2010 14:04

Ембеддеры, сиплюсплюсники и прочие унылые. Хватит завидовать джавистам и точканетчикам за их высокую зп и успокаивать себя что они «Не знают что такое О (n) ».

Відповісти

Підтримати

anonymous 14.07.2010 13:53

neuropunk
Это вопрос баланса технической (специализация в некоторых предметных областях) составляющей и управленческой. В разных ролях в разных организациях пропорции этих составляющих могут существенно отличаться.
Если рассматривать «начальника» как надпись на визитке и прибавку к зарплате — это одно. Если же это лицо, которое реально организует работу коллектива, принимает решения, обеспечивает достижение целей организации в рамках имеющихся ограничений (бюджет, сроки, требования) — то это совершенно другая история.

И для последнего типа сотрудников с сильным перекосом в организационную составляющую ключевую роль играют совершенно другие знания и умения. Что, впрочем, не исключает того, что кое-кто при этом будет разбираться и в деталях ООП, и особенностях классических алгоритмов.

Відповісти

Підтримати

anonymous 14.07.2010 13:39

начальник тот = программист + некоторые функции, которыми занимается только он

Если бы я был начальником — специально бы обратился к гипнотезерам, чтобы навсегда забыть всю эту кодерскую муть.

Відповісти

Підтримати

anonymous 14.07.2010 13:30

начальник тот = программист + некоторые функции, которыми занимается только он

Відповісти

Підтримати

anonymous 14.07.2010 13:29

Дійсно чому гордість виникає в сеніора за те що зміг імлементнути розроблений років 30 (а то і більше) тому алгоритм?
Зрозуміло що програміст повинен вміти думати і не знати що таке інкапсуляція, а розуміти. аналогічно з структурами даних 5, 10 чи 3 — яка різниця — головне щоб розумів що то за структура, для чого, міг на прикладі 2 чи трьох структур порівняльно охарактеризувати.
І дійсно в окремих випадках буває необхідність в власній реалізації необхідної структури (приклад — великі обєми даних, специфічний тип звязку між даними,

специфічний спосіб (поведінка) в обміні даними між структурою і споживачем).

Відповісти

Підтримати

anonymous 14.07.2010 13:25

Смотря что вкладывать в роль «начальника». Это может прозвучать немного странно для разработчиков, но у руководителей выше некоторого условного уровня несколько другие задачи, приоритеты и ключевые области знаний/умений.

Відповісти

Підтримати

anonymous 14.07.2010 13:11

я встречал начальника, который не знает что такое инкапсуляция

Відповісти

Підтримати

greench Microsoft DAX developer 14.07.2010 13:05

Прикольно. Модеры сами заинтресованы в разжиге срача?

Відповісти

Підтримати

anonymous 14.07.2010 13:02

Почему вы решили что к вам приходили сениоры и лиды? Так написано в вашем объявлении о работе? Или так написано в их резюме? На заборе тоже написано, а там дрова лежат... Переманить настоящего сениора или лида, врядли у вы такую зп платите:)

Відповісти

Підтримати

anonymous 14.07.2010 13:00

А исходники с прошлой работы никто ж не понесет:)

Не, ну я например носил, ибо ОпенСорц (ну типа), только их никто не спрашивал.

Відповісти

Підтримати

greench Microsoft DAX developer 14.07.2010 12:49

2 Serzh-GT:, а может там просто люди уважают друг друга?

Відповісти

Підтримати

Sergey Gavriliuk Team Lead, Solution Architect, Senior .NET Backend Developer в Kuadriga 14.07.2010 12:47

IT сообщество, IT сообщество.Курятник какой-то, а не сообщество. Все наровят клюнуть ближнего. Интересно, насколько часто подобные темы возникают на буржуйских форумах?

там модеры более жесткие))

Відповісти

Підтримати

greench Microsoft DAX developer 14.07.2010 12:45

IT сообщество, IT сообщество.Курятник какой-то, а не сообщество. Все наровят клюнуть ближнего. Интересно, насколько часто подобные темы возникают на буржуйских форумах?

Відповісти

Підтримати

BONUS 14.07.2010 12:31

2 Soft

Тяжело за 1 час на практике оценить знания человека. Так что срез знаний будет очень ограниченный. А исходники с прошлой работы никто ж не понесет:)

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 12:23

Самый правильный способ теста на сеньора — два задания
1. реальное (посмотреть код)

2. нереальное, типа нерешаемого математического алгоритма или задачи ИИ. А потом разобрать как пытался решить.

Відповісти

Підтримати

anonymous 14.07.2010 12:20

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

аааааа, Гы испортил ржачную ветку (((

Відповісти

Підтримати

anonymous 14.07.2010 12:19

Интересна природа человека, все желают опустить другого, чтобы стать выше и не двигаясь.

На фоне дурака всегда выглядишь умнее.

Відповісти

Підтримати

anonymous 14.07.2010 12:18

Я никого не пытаюсь опустить. Я сам по себе умный.

Відповісти

Підтримати

anonymous 14.07.2010 12:18

Возможно из-за своего скудноумия тут все этого еще не поняли, но думать надо всегда. Просто не всегда готовы платить за то, что ты будешь думать. Банальная экономическая целесообразность решает в итоге. И если бы существовали тренированные обезьянки, способные писать код безвоздмездо и хотя бы на уровне сегодняшних Жаверов и Дотнетчиков, жаберы и дотнетчики уже давным бы давно искали для себя новое занятия для зарабатывания денег...

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

Відповісти

Підтримати

anonymous 14.07.2010 12:17

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

Интересна природа человека, все желают опустить другого, чтобы стать выше и не двигаясь.

Відповісти

Підтримати

anonymous 14.07.2010 12:08

Ну да, ну да, зачем нам думать, если все придумали за нас?

Возможно из-за своего скудноумия тут все этого еще не поняли, но думать надо всегда. Просто не всегда готовы платить за то, что ты будешь думать. Банальная экономическая целесообразность решает в итоге. И если бы существовали тренированные обезьянки, способные писать код безвоздмездо и хотя бы на уровне сегодняшних Жаверов и Дотнетчиков, жаберы и дотнетчики уже давным бы давно искали для себя новое занятия для зарабатывания денег...

Відповісти

Підтримати

anonymous 14.07.2010 12:07

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

Ну, значит так писали...

Відповісти

Підтримати

BONUS 14.07.2010 12:06

Господа, не надо гипербол. Банальную разницу между списком и массивом любой, кто претендует на синьора все же должен знать. Не говоря уже о том, что попадаются программисты с опытом 4−5 лет, которые тяжело различают интерфейсы и абстрактные классы, убеждены что если объявлен конструктор, то конструктор базового класса в жизни не вызовется и тд

Відповісти

Підтримати

anonymous 14.07.2010 12:03

ведь это наверняка писал кто-то из МИТа и наверняка с научной степенью, а не Вася из аутсорса.

Ну да, ну да, зачем нам думать, если все придумали за нас?

Відповісти

Підтримати

Sergey Gavriliuk Team Lead, Solution Architect, Senior .NET Backend Developer в Kuadriga 14.07.2010 12:03

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

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

Відповісти

Підтримати

anonymous 14.07.2010 12:02

Умный вы наш. Тогда ответьте на простой вопрос — для каких структур данных наиболее важна рекурсия и почему?

наиболее важна для тех которые образуют дерево.

Правильно. Но большинство сеньеров C#/Java на этот вопрос не ответят. Так как всегда есть готовый фреймворк.

не встречал таких поэтому не могу согласиться, если такие и есть то ’ошейники’ синьоров они выменяли у манагеров за взятки.

а вообще C# или Java программеры могут и не знать о том что такое стек, для них это нормально. этого может и нету в книгах по данным языкам.

Відповісти

Підтримати

anonymous 14.07.2010 12:00

вы вообще смотрели исходники таких фреймворов?

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

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 11:59

Serzh-GT 38 сек. назад
2 Soft
GetType не виртуальный))

Он виртуальный в смысле «магии фреймворка», так как ведёт себя как виртуальный. Ну по сути берёт данные из внутренних структур метаданных, куда напрямую нед доступа разработчику.

Відповісти

Підтримати

Sergey Gavriliuk Team Lead, Solution Architect, Senior .NET Backend Developer в Kuadriga 14.07.2010 11:58

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

вы вообще смотрели исходники таких фреймворов? посмотрите исходники некоторых алгоритмов в.NET с помощью рефлектора. вас они приятно удивят.

Відповісти

Підтримати

anonymous 14.07.2010 11:57

потому что СТЛ не вписывался в тесные ограничения железа?

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

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 11:56

LOL2 2 мин. назад
Умный вы наш. Тогда ответьте на простой вопрос — для каких структур данных наиболее важна рекурсия и почему?
наиболее важна для тех которые образуют дерево.

Правильно. Но большинство сеньеров C#/Java на этот вопрос не ответят. Так как всегда есть готовый фреймворк.

Відповісти

Підтримати

Sergey Gavriliuk Team Lead, Solution Architect, Senior .NET Backend Developer в Kuadriga 14.07.2010 11:56

2 Soft

GetType не виртуальный))

Відповісти

Підтримати

anonymous 14.07.2010 11:54

Если все так печально, то почему бы Вас не уволить, и не взять на Ваше место тренированную обезьяну?

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

ИТ инженерия с самого своего становления стремится к сокращению расходов, любыми средствами.

Відповісти

Підтримати

anonymous 14.07.2010 11:53

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

Я понимаю что большинство кодеров в Украине меряют только по своему унылоынтырпрайзу и веб-деву, но что если у меня в проекте написанные ручками реализации структур данных и некоторых алгоритмов потому что СТЛ не вписывался в тесные ограничения железа?

Відповісти

Підтримати

anonymous 14.07.2010 11:52

LOL2 2 мин. назад
ааааа, Soft ещё сильнее лажанул:)
Умный вы наш. Тогда ответьте на простой вопрос — для каких структур данных наиболее важна рекурсия и почему?

наиболее важна для тех которые образуют дерево.
почитайте книги чем вообще важна рекурсия или вам на форум в ветку ’для новичков’.

да и вообще к чему вы всё это?

Відповісти

Підтримати

ducoze 14.07.2010 11:50

На сегодняшний день все это уже написано до вас. Нужно лишь знать примерно что это и уметь грамотно им пользоваться.

Если все так печально, то почему бы Вас не уволить, и не взять на Ваше место тренированную обезьяну?

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 11:49

Serzh-GT 3 мин. назад
вы о чем? о_О какой еще виртуальный метод?

Тем что такие задачи на собеседовании решаются на автомате. Смотрят на метод, а не на содержимое. В данном случае в обычном методе вызывается по сути виртуальный GetType ();

public Type Get () {
return GetType (); }

Відповісти

Підтримати

ducoze 14.07.2010 11:49

ИМХО, сейчас все не знают элементарных вещей.
Спросите любого явиста или шарписта нафига в этих языках понадобился базовый класс Object. Из человек 15ти, ни один еще не ответил более-менее вразумительно.

Я не говорю уже про механизм работы вирутальных функций. Один товарищ мне заявил, что за него все делает JVM, и ему глубоко пофиг как оно работает:)

Відповісти

Підтримати

anonymous 14.07.2010 11:48

Анонимуса, вот, удручает, когда на собеседовании человек высокой квалификации не может на доске написать простенький алгоритм хеширования или объяснить, как работает какой-нибудь MD5 или SHA-1. Но Анонимус, скорее всего, попросту придирчив, но не погонять человека по приведению типов, мат. множествам и структурам данных не может. Хотя зачастую конец немного предсказуем.

Тут правильно написали: в аутсорсинге подобные вещи зачастую никому не нужны. Есть же FRAMEWORKS! Но, как писал Блох, одними из основных качеств хорошего программиста являются высокая самообучаемость по собственной иннициативе, желание разобраться и понять «как оно работает» и написание кода дома just for fun. Посему любители FRAMEWORKS!, слепо исповедующие принцип «подключил и забыл», у Анонимуса зачастую идут лесом.

Відповісти

Підтримати

anonymous 14.07.2010 11:47

для каких структур данных наиболее важна рекурсия и почему?

Во задроты то. Вы еще способы обхода деревьев вспомните. Задроты такие задроты. И лучше скажите вы всем этим муссором пользовались хоть раз на практике? Всмысле приходилось ли это вам реализовывать?
На сегодняшний день все это уже написано до вас. Нужно лишь знать примерно что это и уметь грамотно им пользоваться. А реализовывать это все будут высокооплачиваемые буржую в классных конторах и с нормальными сроками на задачи. Как то читал, что на написание генератора рандомных чисел для Java высококлассные спецы потратили не один месяц работы. В аутсорсе никто не будет ждать даже недели, пока какойто Вася пишет классные структуры данных. Аутсорс на это банально не расчитан.

Потому хватит играться в высококлассных инженеров, а элементарно давайте спускайтесь на грешную землю ко своему говнокоду.

Відповісти

Підтримати

anonymous 14.07.2010 11:46

Тем что все эти структуры можно описать через все эти три определения.

Это как то отменяет необходимость знания на память сложности поиска элемента в хэш-таблице или рб-три? (даже если Вас разбудили с таким вопросом в 3 часа ночи с бадуна)

Відповісти

Підтримати

Sergey Gavriliuk Team Lead, Solution Architect, Senior .NET Backend Developer в Kuadriga 14.07.2010 11:43

Так это тест не на знание C#, а на внимательность. Вы бы еще картинки с дельфинами — найди 10 различий давали. Тоже сперва глянул на то что метод не виртуальный.

вы о чем? о_О какой еще виртуальный метод?

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 11:41

anonymous 50 сек. назад
Я счастлив услышать такое многозначительное заявление от столь авторитетного источника.
Что Вы этим хотели сообщать миру?

Тем что все эти структуры можно описать через все эти три определения.
ru.wikipedia.org/...структур_данных

С деревом ошибся. Правильнее граф. Так как дерево по сути ациклический направленный граф.

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 11:38

LOL2 2 мин. назад
ааааа, Soft ещё сильнее лажанул:)

Умный вы наш. Тогда ответьте на простой вопрос — для каких структур данных наиболее важна рекурсия и почему?

Відповісти

Підтримати

anonymous 14.07.2010 11:37

Так структур данных всего 3: — массив; — список; — дерево.
Остальное модификации от них. Например то же самое октодерево и бинарное дерево по сути обычное дерево с разным числом ветвей.

Я счастлив услышать такое многозначительное заявление от столь авторитетного источника.

Что Вы этим хотели сообщать миру?

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 11:36

замыкание.

Под этим словом много смыслов. Вы что имеете конкретно в виду?

А дерево — список списков.

Не согласен. Дерево это самостоятельная структура. А вот матрица и вектор это массив массивов и обычный массив соответственно.

Відповісти

Підтримати

anonymous 14.07.2010 11:36

Обычно все умные пока им не приходиться самим отвечать на вопросы, я про анонимусов...

Відповісти

Підтримати

anonymous 14.07.2010 11:34

ааааа, Soft ещё сильнее лажанул:)

Відповісти

Підтримати

anonymous 14.07.2010 11:32

Тогда вообще: массив, список, замыкание.

А дерево — список списков.

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 11:30

anonymous 1 мин. назад
Тоесть ты не только не можешь назвать 10 структур данных и сортировок, но и даже не особо умеешь читать?

Так структур данных всего 3: — массив; — список; — дерево.

Остальное модификации от них. Например то же самое октодерево и бинарное дерево по сути обычное дерево с разным числом ветвей.

Відповісти

Підтримати

anonymous 14.07.2010 11:28

ааааа, Дмитриц Ковтун лажанул:)

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 11:26

Serzh-GT 15 мин. назад
2 Дмитрий Ковтун
будет true, так как GetType возвращает тип созданного обьекта независимо в каком из родителей он был вызван

Так это тест не на знание C#, а на внимательность. Вы бы еще картинки с дельфинами — найди 10 различий давали. Тоже сперва глянул на то что метод не виртуальный.

Відповісти

Підтримати

anonymous 14.07.2010 11:25

Тоесть ты не только не можешь назвать 10 структур данных и сортировок, но и даже не особо умеешь читать? Так ты не потянешь на лида по СРешетке, максимум синиора.

Відповісти

Підтримати

Sergey Gavriliuk Team Lead, Solution Architect, Senior .NET Backend Developer в Kuadriga 14.07.2010 11:08

2 Дмитрий Ковтун

будет true, так как GetType возвращает тип созданного обьекта независимо в каком из родителей он был вызван

Відповісти

Підтримати

svini 14.07.2010 11:06

@Дмитрий Ковтун

двойка тебе

Відповісти

Підтримати

anonymous 14.07.2010 11:05

Дмитрий Ковтун

Для одно и того же инстанса вызывается виртуальный метод GetType, и независимо от стека вызова вызовется реализация метода для класса B.

Відповісти

Підтримати

anonymous 14.07.2010 11:02

Нужно быть очень точным в выражениях, если пишешь на форуме программистов.
Ты написал «10 основных структур данных».
Причем товарищ выше (а по его сообщениям раньше в его адекватности я не сомневаюсь) 10 не назвал. Да и некоторые структуры с натяжкой можно было бы объединить в одну.

Ну так теперь давай, яви нам знания основных структур данных))

Відповісти

Підтримати

Дмитрий Ковтун SDE II в Amazon 14.07.2010 11:01

to Serzh-GT

Это си#??? Не знаю его вообще, но могу догадатося что будет false ибо obj.Get () вызывает метод унаследованный который вернет type A, а obj.GetType () вызывает метод системый который вернет type B. С точки зрения типов это совершенно разные типы. Правильно ответил?

Відповісти

Підтримати

svini 14.07.2010 11:01

Мне интересно как они доработали до такого опыта. А меморилики бывают даже с GC.

Відповісти

Підтримати

anonymous 14.07.2010 11:01

На всеукраинские олимпиады значит не ездили. Я вот до сих пор забыть не могу всё то, что мне там попадалось и как делал.

Ну значит Вы исключение. Что никак не меняет общей картины.

Відповісти

Підтримати

Jakmir iOS Developer в Weird Gravity 14.07.2010 10:58

Что значит громлю? Просто по своему опыту из универа и работы вижу, что туда идут не отягощенные душевными терзаниями по поводу алгоритмов и анализа сложности люди.

На всеукраинские олимпиады значит не ездили. Я вот до сих пор забыть не могу всё то, что мне там попадалось и как делал.

Відповісти

Підтримати

anonymous 14.07.2010 10:56

anonymous, а ты на чем пишешь? И почему же ты сишарперов громишь анонимно?

Что значит громлю? Просто по своему опыту из универа и работы вижу, что туда идут не отягощенные душевными терзаниями по поводу алгоритмов и анализа сложности люди. Да и по работе оно им не надо в 99% случаев.

Это как в школе, когда люди которым на все положить поступают обычно на экономический.

LOL. Назови плз десяток основных структур данных.

Ты не можешь из головы назвать 10 структур данных/сортировок? Канонический точкаНЕТчик?

Відповісти

Підтримати

Jakmir iOS Developer в Weird Gravity 14.07.2010 10:56

anonymous
LOL. Назови плз десяток основных структур данных.

Стек, очередь, список, дерево, граф, хеш-таблица,...

Пока это вспомнил

Відповісти

Підтримати

anonymous 14.07.2010 10:52

“True”?

Відповісти

Підтримати

Sergey Gavriliuk Team Lead, Solution Architect, Senior .NET Backend Developer в Kuadriga 14.07.2010 10:50

вот реальная задача. не поверите, но правильный ответ дали 2 из 10 человек. или вы скажите, что я придираюсь))
class A {
public Type Get () {
return GetType ();
} }
class B: A {}
static void Main (string [] args)
{
A obj = new B ();
Console.Write (obj.Get () == obj.GetType ()); }

Відповісти

Підтримати

anonymous 14.07.2010 10:50

как то все меньше и меньше народу думающего.

На всю биомассу количество думающего народу всегда одно и то же. Примерно 1% общей массы. Народу в ИТ сейчас лезет и правда немеренно. Процент дураков растет намного быстрее процента умных.

Таже тенденция касается и этого топика. Умные люди сюда не пишут.

Відповісти

Підтримати

maxdz 14.07.2010 10:46

> А какая разница между массивом и списком?

Большая:)

Відповісти

Підтримати

maxdz 14.07.2010 10:45

> как то все меньше и меньше народу думающего.

Eго не меньше. Просто, пасётся такой «думающий народ» — в более приятных местах, чем совковая Украина.

Відповісти

Підтримати

anonymous 14.07.2010 10:45

Gorik

А какая разница между массивом и списком? А то я вот уже месяц по собеседованиям хожу, никуда меня брать не хотят, все спрашивают в чем же разница, а я ничего толком родить не могу. И в гугле меня, кстати, забанили.

Відповісти

Підтримати

anonymous 14.07.2010 10:45

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

Відповісти

Підтримати

anonymous 14.07.2010 10:43

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

Відповісти

Підтримати

anonymous 14.07.2010 10:43

До сложности алгоритмов иногда и не доходит много народу отваливается еще на стадии обработки ошибок;)

Відповісти

Підтримати

anonymous 14.07.2010 10:42

anonymous

LOL. Назови плз десяток основных структур данных.

Відповісти

Підтримати

anonymous 14.07.2010 10:36

anonymous, а ты на чем пишешь? И почему же ты сишарперов громишь анонимно?

Відповісти

Підтримати

Alexandr Gavriluk 14.07.2010 10:33

anonymous 3 мин. назад
Времменную сложность я спрашиваю часто. Но мне хватает обьяснения на пальцах, без цитаты учебников. Главное чтобы человек понимал разницу.
И как успехи? Какой процент претендующих, например, на должность мидла.НЕТ хоть что то понимает в оценке сложности алгоритмов и знает сложность десятка основных структур данных и сортировок?

А зачем? Были здесь утверждающие, что нафиг алгоритмы, когда есть готовые фреймворки.

Відповісти

Підтримати

anonymous 14.07.2010 10:29

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

И как успехи? Какой процент претендующих, например, на должность мидла.НЕТ хоть что то понимает в оценке сложности алгоритмов и знает сложность десятка основных структур данных и сортировок?

Відповісти

Підтримати

Sergey Gavriliuk Team Lead, Solution Architect, Senior .NET Backend Developer в Kuadriga 14.07.2010 10:24

Я конечно не хочу никого обидить, но чего вы ждете от программистов на точкаНЕТ, что они реально будут знать, что доступ к элементу массива О (1), а к элементу списка О (н) и что они вообще будут знать что это за «О» такая и с чем ее едят?

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

Відповісти

Підтримати

anonymous 14.07.2010 10:23

Я конечно не хочу никого обидеть, но чего вы ждете от программистов на точкаНЕТ, что они реально будут знать, что доступ к элементу массива О (1), а к элементу списка О (н) , и что они вообще будут знать, что это за «О» такая и с чем ее едят?

А вы кроме сложности алгоритмов ничего не знаете? Дальше не продвинулись? Это ваш порог компетентности? (Спасибо DedushkaGrga за инфу)

Відповісти

Підтримати

Sergey Gavriliuk Team Lead, Solution Architect, Senior .NET Backend Developer в Kuadriga 14.07.2010 10:20

Простите, но вы действительно «оптимизируете» заменой списков на массивы???

Интересный вывод)) С какой строчки моего поста вы его взяли?))

Відповісти

Підтримати

anonymous 14.07.2010 10:18

Я конечно не хочу никого обидить, но чего вы ждете от программистов на точкаНЕТ, что они реально будут знать, что доступ к элементу массива О (1), а к элементу списка О (н) и что они вообще будут знать что это за «О» такая и с чем ее едят?

Відповісти

Підтримати

anonymous 14.07.2010 10:14

по сабжу — бугога:)

Відповісти

Підтримати

anonymous 14.07.2010 10:14

Так внутри метода объявить класс например в C# нельзя, можно создать объект анонимного типа. Может имелось ввиду это?

внутри метода можно объявить классы в Java — это локальные классы. им можно давать имена. есть и анонимные

Відповісти

Підтримати

anonymous 14.07.2010 10:01

Так внутри метода объявить класс например в C# нельзя, можно создать объект анонимного типа. Может имелось ввиду это?

Відповісти

Підтримати

anonymous 14.07.2010 09:54

Или например «внутренний клас, обьявленный внутри метода, НЕ МОЖЕТ ИМЕТЬ ИМЕНИ и поэтому называется анонимным».

т.е. вы даже не предполагаете, что такое высказывание могло быть сделано намеренно? С целью посмотреть на реакцию.

Відповісти

Підтримати

Nobody 14.07.2010 09:53

Принцип Питера детектед.

Відповісти

Підтримати

anonymous 14.07.2010 09:47

Ну, а что тут удивляться? Я как то работал с ТимЛидом у которого за плечами 10ть лет. Так вот, не знать базовых вещей — для него это было нормой. Его гонор перекрывал брешь космического мастаба в его знаниях.

Відповісти

Підтримати

anonymous 14.07.2010 09:45

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

Відповісти

Підтримати

anonymous 14.07.2010 09:44

сам обновляє топік

Відповісти

Підтримати

anonymous 14.07.2010 09:36

Ну это типа вброс был, думаю к вечеру тема наберет обороты...

Відповісти

Підтримати

anonymous 14.07.2010 09:36

Ну и?

Відповісти

Підтримати

Підписатись на коментарі

Ваша пошта

Не підписуватись