кстати, по поводу темы.
в течение всей карьеры есть у меня одно наблюдение. Когда я читал код своих коллег, то заметил интересную особенность.
Наиболее работающий и эффективный код как раз пишут те, кто пишет без наворотов.
На нескольких работах были у меня коллеги, у которых, когда смотрел код, восхищался — как они много и правильно пишут, и все работает, и почти нет багов. лично у меня производительность на порядок ниже.
но... в их коде я часто замечал всякое отсутствие навороченности — более того, применяются конструкции и стиль кодирования, за который бы на любом собеседовании ехидно бы высмеяли, и детали, которые каждый второклассник-дотнетчик знает, не соблюдены. Так, например, сравнение строки с пустым литералом вместо сравнения длины с нулем, неиспользование стрингБилдера, сложение строк вместо стрингбилдера и string.format, чрезмерное и неоправданное использование сессии и элементов постбэка в вэбе, даже наименования параметров метода с большой буквы режут глаз, ибо ни под какую нейм-конвеншн не подходят.
работа с БД тоже построена так, что один и тот же запрос исполняется несколько раз, вместо того, чтобы создать класс, который достает всю инфу сразу, о кэшировании вообще нет и речи. и многое другое.
однако, возникала ли у меня хоть когда-либо мысль раскритиковать такой код? нет нет и еще раз нет! код простой, не использует паттернов, во многом не оптимален с точки зрения производительности, но главное... он работает! и работает, мало того, правильно и безбажно! и лопатит огромные объемы бизнес-логики, которые увлекающийся какими-нибудь фреймворкнаворотами, паттернами и фабриками талантливый кодерок попросту не осилит и погрязнет в них. Я вот, например, писать так много, быстро и правильно — не умею, и склонен, как тот кодерок, погрязать в абстракциях.
да даже элементарных проверок на нулл для полей методов во многих местах в этмо коде нету, из-за чего случаются падежи, (например, прямый обращения объект.метод1.поле2 при том ,что сам объект==нулл). ну и что — это поправляемо, зато код работает правильно, четко и выполняет свою задачу — а заказчик проверяет отнюдь не качество кодирования...
И такой, как я привел выше, код — встречал я на нескольких работах как раз у наиболее грамотных, продвинутых и высокопроизводительных коллег.
поэтому маловажность бизнес-логики тут напрасно недооценивают.
Здравствуйте, sss1024, Вы писали:
S>да лана. Такова статистика. Новые проекты начинаются на C# или ещё на чём-то подобном.
Ты знаешь, ситуация ровно наоборот. В связи со всякими C# и Java в последние годы сообщество С++ программистов довольно неплохо очистилось от балласта, и я был приятно удивлен, что нынче практически не попадаются "невменяемые".
Здравствуйте, Ikemefula, Вы писали:
J>>у музыкантов — да, а у переводчиков — нет. Вон шароварщики почему-то студентам советских вузов предпочитают нативов I>Ога, двухлетних нативных детей для переводов разговоров на бытовые темы.
да, придумать фигню, а потом ее опровергнуть — это твоя методика ведения дискуссии, я помню.
Здравствуйте, Ikemefula, Вы писали:
J>>к зеркалу — ты влез в чужой диалог, ты и перечитывай. J>>Заодно и свой ответ landerhigh, которомы ты возразил "вильнув" и переведя тему с бытового перевода на перевод профессиональный I>Читать ты не умеешь. Так что тренируйся: I>"то можно нанимать например переводчика, который даже не знает английских букв" I>Если речь о найме, то и еду понятно, что перевод профессиональный.
"еду" может быть и понятно, а про бытовой я тебе уже несколько раз написал. Так что с претензиями по умению читать к зеркалу.
к примеру здесь:
не важно как обстоят дела в китайском или прочих языках, если тебе нужен переводчик для общения, он должен быть хорошим переводчиком именно для общения, тем более что он еще и дешевле чем переводчик с совершенно бесполезным на бытовом уровне знанием юридической специфики.
я тебе выделил даже, что бы ты не путался в словах
I>Теперь читаем слова одного дурачка
Здравствуйте, jhfrek, Вы писали:
I>>Читать ты не умеешь. Так что тренируйся: I>>"то можно нанимать например переводчика, который даже не знает английских букв" I>>Если речь о найме, то и еду понятно, что перевод профессиональный.
J>"еду" может быть и понятно, а про бытовой я тебе уже несколько раз написал. Так что с претензиями по умению читать к зеркалу.
Да, ты несколько раз хотел поменять исходную задачу, это заметно.
Скажи ты что нибудь внятное, например, "человек со знанием двух языков, но без знания алфавита и грамматики в ряде случаев может быть полезнее студента ин-яза", то можно было бы согласиться
Но ты пошел дальшеи наплел ахинеи столько, что превратил идею в сфероконя.
J>
J>не важно как обстоят дела в китайском или прочих языках, если тебе нужен переводчик для общения, он должен быть хорошим переводчиком именно для общения, тем более что он еще и дешевле чем переводчик с совершенно бесполезным на бытовом уровне знанием юридической специфики.
J>я тебе выделил даже, что бы ты не путался в словах
Это хороший пример, показывае как ты пробуешь изменить условие.
I>>Теперь читаем слова одного дурачка
J>ты себя перечитываешь?
Вот ты уже свои слова перестал узнать, что неудивительно.
Здравствуйте, jhfrek, Вы писали:
J>>>у музыкантов — да, а у переводчиков — нет. Вон шароварщики почему-то студентам советских вузов предпочитают нативов I>>Ога, двухлетних нативных детей для переводов разговоров на бытовые темы.
J>да, придумать фигню, а потом ее опровергнуть — это твоя методика ведения дискуссии, я помню.
Здравствуйте, Ikemefula, Вы писали:
I>Скажи ты что нибудь внятное, например, "человек со знанием двух языков, но без знания алфавита и грамматики в ряде случаев может быть полезнее студента ин-яза", то можно было бы согласиться
ты сумел превозмочь ЧСВ и понять что я имел в виду в самом начале — респект. Значит не зря я тратил свое время на переписку.
BTW, он может быть полезнее не только студента, но и супер-специалиста. Просто потому что дешевле и физически доступнее
Здравствуйте, любой, Вы писали:
Л>Здравствуйте, TarasCo, Вы писали:
TC>>Это как считать. Допустим, есть два программиста: плохой и хороший. Они работают за 50тр и 100тр соответственно. Оба имеют семью. У первого после оплаты комунальных платежей, покупки необходимых вещей и продуктов останется денег разве что на фотомыльницу. У второго — на хорошую зеркалку. Вроде, все справедливо?
Л>А какие зеркалки — хорошие? Та, что я привёл даже без объектива в 2 таких месячных зарплаты не укладывается. А это далеко не предел. 40-мегапиксельные скоростные камеры стоят в районе $20000.
Если чё, то тут речь идет, видимо, про среднеформатные цифровые зеркалки целиком или цифровые задники для пленочных среднеформатных зеркалок. Только фигня в том, что они ни капли не скоростные и из-за огромного количества точек на матрице обладают весьма скромным диапазоном рабочих ISO — на 800 уже мало кто будет их использовать. Потому применяются они в довольно узкой области — студийная рекламная или fashion / glamour съемка. Так что простому любителю они вряд ли будут сильно полезны в чём-то.
Здравствуйте, AndrewVK, Вы писали:
AVK>Это ладно. Здесь были вакансии, требующие в 2003-2004 году опыт использования дотнета более 3 лет.
В 2004 — вполне возможно.
"By late 2000 the first beta versions of .NET 1.0 were released." (из wiki)
В этом не уверен, но в январе-феврале 2001 года Visual Studio .NET уже был широкодоступен.
Здравствуйте, Denis Mingulov, Вы писали:
DM>В этом не уверен, но в январе-феврале 2001 года Visual Studio .NET уже был широкодоступен.
First beta version без коммерческой лицензии довольно сложно засчитывать за реальный опыт использования. Помню я эту первую бету — хромала на обе ноги. Побаловаться можно, использовать нельзя даже без студии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Я не знаю, шутите Вы или всерьез, но все очень сильно зависит от рынка, на котором работаете.
Допустим, делается некрупная онлайн система (ну, так для числа посещений порядка 10 тысяч в сутки, скажем, число форм/страниц порядка 100). Заказ для забугорного заказчика, принцип примерно такой: сделали, протестировали на наборе данных, отдали заказчику погонять на его площадке, получили таньгу и забыли.
Тады да, соглашусь, подход неплохой, позволяет срубить побольше денег с меньшими затратами. Наколбасить кода, получить деньгу и перейти к следующему заказчику.
Ежели вы работаете над большим продуктом, каждый экземпляр которого пользуется кучей пользователей (скажем, некоторая веб-платформа для конечных клиентов, число инсталяций порядка 1000), и должны поддерживать его на протяжении сравнительно длительного времени, то это очень чревато получением проблем на свою пятую точку. Нужна производительность — запросы должны быть оптимальными чуть менее, чем полностью, проанализирована статистика, индексы где надо созданы и пр. Нужно качество, чтобы не плодить недовольных пользователей и не получать по голове от начальства за отказы кастомеров от использования продуктом и требования refund.
Например.
Не проверили объект на валидность — рано или поздно граблями получим по лбу, так как данные подсунули не те, которые ожидались, библиотека, которую пользуем, содержит косяки, или нашу утилитную функцию начали использовать в контексте, который мы не протестировали или не подозревали. В результате, не проверенный код возврата, не проверенные границы значений, да и null-pointer наконец привели к исключению, бросаемому, скажем, в 1% случаев. Помножим на 10 тысяч в день на кастомера — 100 случаев в день. Помножим на 1000 кастомеров — 100 тысяч инцидентов в день. Допустим, 0.1% из них получит жалобу, до нашего сапорта дойдет 100 запросов в день. Они сядут разбираться своими силами, день-два-три-неделю. Поднимут наверх. В конще концов дойдет до девелоперов.
Сесть поковырять и дойти до проблемы — 2-3 дня, решить — 1 день, проверить что не сломались остальные сценарии и этот починили — 2-3 дня. Выкатить фикс, сообщить кастомерам, написать инструкцию, написать в форумы, что пробему решили и пр. — еще время. В общем, от обнаружения проюдемы до решения у кастомера — от недели до месяца в остром случае, а иногда и годы требуются. Скока за это время инцидентов произойдет? Что конечные пользователи скажут про разработчиков (MS/Adobe/Google/Amazon/ebay must die?)
Помножим на число проблем. Обеспечены работой на долгие годы. Крутимся, на виду у начальства, показываем полезность и периодически просим повышения. Круто, но как-то грустно. Оно надо? Каждому — свое.
При этом, когда подходишь к некоторым таким разработчикам, самый первый и самый стандартный ответ — "у меня на машине все работает, я проверял, у этих кастомеров что-то не то с кривизной рук". Через полгода-год гонор у кого-то поутихает, но не всегда. Мы тут прогресс вперед двигаем, а какие-то пользователи под ногами путаются и жить мешают, мы же все о них заботимся, чтобы им было лучше, а они еще и возмущаются.
Причем, что интересно, люди достаточно часто, начинают использовать какие-то методы оптимизации своей работы, например, выносят код в библиотечные/утилитные методы, переходят на новую библиотеку/framework и пр. Те, которые обращают внимание на качество кода (своего и чужого), получают более качественное и более-менее оптимальное решение. Причем иногда получаются довольно удивительные вещи, например, одной строчкой кода в юнит-тесте протестировать реакцию метода на нулевые/пустые аргуметны поочередно, по одному (на .Net, ага, Expressions и пр. вкусности). И производительность (в количестве выполненной работы) хорошая, и кавчество с этой точки зрения не страдает.
Про соответствие вопросам на собеседованиях и тому, что надо делать в реальности на работе — избитый вопрос. Точно так же и то, что на собеседовании очень сложно понять психологический портрет кандидата и понять насколько он/она сможет решать важные нетехнические вопросы/проблемы. Сложно обеим сторонам, но как-то эту преграду можно туннелировать и решить. Кандидатам — подготовиться по списку стандартных вопросов. Работодателям — устраивать некоторое подобие аттестации.
Истина, как всегда где-то посередине между крайностями. Например, смотреть реакцию на разные вопросы с открытыми ответами — типа, начальство настаивает на таком варианте решения проблемы. Ваши действия? Или вот, есть такая глобальная проблема — какие подходы видите, как будете решать, плюсы и минусы? и пр. Причем, это не спасает во всех 100% случаев, да хоть и в 50%, тоже сложно все это проверить. Жисть такая.
В общем, резюме, я за непроверку объекта на null-reference бил бы линейкой по рукам. А наколбасить 500 строк кода за день особой заслугой не считаю. Даже хорошо документированного. Плавали-знаем. Нужен какой-то баланс качества и количества. В разных ситуациях — разный.
При этом, кодирование в общем объеме работы занимает от 5 до 95% времени на одного разработчика. Тоже от компании и проекта зависит. И кто какую нишу смог занять, там тому и счастье. Поменялось что — прыгай в другую лунку, при возможности.
За сим раскланяюсь,
Ваш Капитан Очевидность.
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
Здравствуйте, quwy, Вы писали:
D>>Последние два месяца прорезюмировал просто толпу соискателей на программистов по с++. Каково было мое удивление что 90% людей не знаю ДЛЯ ЧЕГО НУЖЕН ВИРТУАЛЬНЫЙ ДЕСТРУКТОР. Как такое может быть? Куда делись настоящие программситы, а не оходники за деньгами? Что творится с людьми? Q>Хорошо нам, делфистам, у нас деструкторы изначально виртуальные и никто не задает по этому поводу глупых вопросов
Ну, нам, жавистам, еще проще. Деструкторов вообще нет, и все методы по-умолчанию виртуальные. Правда, вопросы по тому, зачем нужен метод finalize есть(хотя в реале он используется крайне редко, и, в отличие от виртуальных деструкторов в плюсах, знание о нем таким уж необходимым не является), но это зависит от степени фимозности головного мозга у собеседующего.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, msk78, Вы писали:
M>Но. Всё равно на новой работе придётся заниматься немного другим.
но это не факт. придет такой человек и напортачит. деструктор виртуальным не объявит, где следует, память потечет, придется вылавливать странные баги. если считать, что понимание виртуального деструктора — это то, что можно по ходу работы узнать, то что, собственно, считать базой?
M>Я, например, на текущей работе уже несколько раз использовал WMI, но ведь никто меня, НИКТО, не спрашивал при приёме работу его знания. Но ведь как-то работаю, делаю своё дело. У нас используется система управления бизнес-потоками K2.NET. И тоже всё в порядке — работаю, выполняю свои функции — меня предупредили, что она есть, почитал, усвоил. Коллеги помогли.
мне кажется, что одно дело язык, другое — конкретные компоненты и фреймворки.
M>Современный мир программирования — это мир командной работы! Скажите человеку, что у вас в проекте используются виртуальные диструкторы и что это важно и он будет их использовать.
а потом ему надо будет сказать, что у нас используются виртуальные функции и что это важно, и он полезет узнавать, что это такое. потом про dynamic_cast какой-нить узнает, потом то, потом другое, а там, глядишь, уже и язык выучил
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, sss1024, Вы писали:
S>>да лана. Такова статистика. Новые проекты начинаются на C# или ещё на чём-то подобном.
V>Ты знаешь, ситуация ровно наоборот. В связи со всякими C# и Java в последние годы сообщество С++ программистов довольно неплохо очистилось от балласта, и я был приятно удивлен, что нынче практически не попадаются "невменяемые".
В этой теме звучит несколько странно, не находишь?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, мыщъх, Вы писали:
М> однако, разница в стоимости вызова виртуальных и невиртуальных функций довольно-таки существенна
а сильно существенна? т.е. что я хотел узнать, это правда, что может быть такой случай, когда именно виртуальность вызова особенно сильно тормозит код?
