замечено, такие инвестиции окупаются крайне плохо, т.к. часто они сравнимы со стоимостью разработки с нуля, а то и больше. Никакого парадокса здесь, кстати, нет, даже если систему дешевле переписать, чем сопровождать, скорее всего её не будут переписывать, т.к. нужна она здесь и сейчас, а и переписать и сопровождать дороже, чем просто сопровождать.
Второй способ — это сразу нанять нормальных специалистов и сразу получить хорошее решение. Так вот, при втором способе решение не будет стоить дороже. Во-первых, нормальные специалисты на рынке труда стоит не (намного) дороже говнокодеров, просто они реже попадаются (т.е. выше затраты на поиск). Во-вторых, нормальный специалист в среднем выдаёт результат немного быстрее (простой эксперимент — задачка по обращению списка — говнокодеры делают её долго и мучительно, результат содержит ошибки, требует дополнительного тестирования и переделывания). В-третьих, создание любой программы требует работы с кодом, работать с хорошим кодом быстрее и проще.
Какой из этого следует вывод? Надо нанимать хороших программистов, это выгодно. Причем это очевидно всем крупным успешным компаниям — MS, Google, Facebook, Яндек и пр. специально создают вокруг себя ажиотаж, а потом применяют очень агрессивную методику отбора (кто был у них на собеседованиях, тот знает, в Фесбук сейчас вообще можно попасть только через Facebook Programming Challenge).
Кто и зачем пропагандирует говнокод и решения от MS? Вот это мне не понятно. Я заметил, что во всяких говноконторах (преимущественно интеграторы и IT аутстафферы) довольно низкий уровень программистов и очень низкое качество кода. Менеджмент там весьма далёк от IT, зачем писать качественный код и как нанимать сильных программистов они слабо себе представляют (кстати, зачем платить программисту много денег — они тоже слабо себе представляют). Пройти собеседование в такую контору очень легко, но нормальному программисту там делать совершенно нечего, я считаю.
ПМ>Во-вторых, нормальный специалист в среднем выдаёт результат немного быстрее (простой эксперимент — задачка по обращению списка — говнокодеры делают её долго и мучительно, результат содержит ошибки, требует дополнительного тестирования и переделывания).
эк тебя задел этот разворот списка
тех, кого ты называешь "нормальными" -- на самом деле, скажем так, продвинутые, в отличие от программистов "широкого профиля", обычно с академическим бэкграундом и т.д.
и я в общем-то солидарен с тобой насчет того, что продвинутые специалисты это хорошо, но и денег они стоят существенно больше твоих 100к
вряд ли ты наберешь из них целую команду и будешь при этом конкурентноспособен в своем CRM -- реалистичный вариант это взять скажем 2 продвинутых на 5-7 обычных
при этом ты, похоже, как-то недооцениваешь тех, кто не умеет списки обращать и не знает про О() -- в связи с тем, что я тебя поймал на этом О(cos ln sin x), надеюсь, ты понимаешь, что я не себя выгораживаю?
совсем не обязательно быть мастером спорта, чтобы работать строителем, и на собеседовании достаточно убедиться, грубо говоря, что человек не в инвалидной коляске ездеет
С инвестициями в качество кода можно очень сильно переборщить. Есть другая крайность: слишком большое внимание к качеству кода. Если у вас человек будет по пол-дня рассуждать что ему вынести в public interface и должен класс быть синглтоном или нет, то код, может быть, получится хороший, но вот продукт — вряд ли. Все-таки time to market очень важен, более того, он иногда важнее того что называют качеством.
Но вообще смысла брать людей, не имеющих писать код смысла мало, мне кажется что не умеющие писать код скорее всего и задачи-то решать не умеют.
Здравствуйте, kosmik, Вы писали:
K>вынести в public interface и должен класс быть синглтоном или нет, то код, может быть, получится хороший, но вот продукт — вряд ли. Все-таки time to market очень важен, более того, он иногда важнее того что называют качеством.
Думаю, что если квалифицированному специалисту сообщат, что time to market является приоритетом, то ООП — это последнее, что он выберет. Поэтому и вопросов о синглетонах не возникнет.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Думаю, что если квалифицированному специалисту сообщат, что time to market является приоритетом, то ООП — это последнее, что он выберет. Поэтому и вопросов о синглетонах не возникнет.
Здравствуйте, Lloyd, Вы писали:
L>И что же он выберет?
Что-нибудь, что больше подходит для прототипирования в данном случае. Если это что-то совсем маленькое, то какой-нибудь скриптовый язык с большим набором библиотек, вроде Питона, если что-то посерьёзнее, то Хаскель, например — писать на нём раз в 5 быстрее, чем на Джаве или C++ и потом переделать гораздо проще будет.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Здравствуйте, kosmik, Вы писали:
K>>вынести в public interface и должен класс быть синглтоном или нет, то код, может быть, получится хороший, но вот продукт — вряд ли. Все-таки time to market очень важен, более того, он иногда важнее того что называют качеством.
ПМ>Думаю, что если квалифицированному специалисту сообщат, что time to market является приоритетом, то ООП — это последнее, что он выберет. Поэтому и вопросов о синглетонах не возникнет.
time to market не является приоритетом в солидных фирмах, отбор персонала жестокий и как правило лучше всего рабоатет смесь теоретиков и практиков, по возможности людей разной национальности так как образ мышления очень разный. качество кода и продукта стоит бесспорно на 1 месте, время играет второстепенную роль.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Что-нибудь, что больше подходит для прототипирования в данном случае. Если это что-то совсем маленькое, то какой-нибудь скриптовый язык с большим набором библиотек, вроде Питона,
Т.е. питон — это не ооп?
ПМ>если что-то посерьёзнее, то Хаскель, например — писать на нём раз в 5 быстрее, чем на Джаве или C++ и потом переделать гораздо проще будет.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Что-нибудь, что больше подходит для прототипирования в данном случае. Если это что-то совсем маленькое, то какой-нибудь скриптовый язык с большим набором библиотек, вроде Питона, если что-то посерьёзнее, то Хаскель, например — писать на нём раз в 5 быстрее, чем на Джаве или C++ и потом переделать гораздо проще будет.
я не понял, вы всерьёз думаете что в солидных фирмах вам дадут право выбора инструмента?
такие вопросы решаются коллективно в совещаниях и по мнению большинства/аргументации иногда голосованием но окончательно принимает решение начальник отдела(руководитеь проекта)
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Прежде всего, хотелось бы заметить, что инвертировать в качество кода можно по-разному.
Ты конкретно завелся, я смотрю
ПМ>Что-нибудь, что больше подходит для прототипирования в данном случае. Если это что-то совсем маленькое, то какой-нибудь скриптовый язык с большим набором библиотек, вроде Питона, если что-то посерьёзнее, то Хаскель, например — писать на нём раз в 5 быстрее, чем на Джаве или C++ и потом переделать гораздо проще будет.
Не всегда можно выбрать. Например наш API — только C++. У кого-то только Java.
Здравствуйте, pik, Вы писали:
pik>time to market не является приоритетом в солидных фирмах, отбор персонала жестокий
Я не знаю, что ты понимаешь под "солидной фирмой", но если говорить о большинстве европейских (не американских) контор, ты подбор идет по критерию отсутствия амбиций, чтобы сидел на невысокой зарплате и был доволен.
pik>и как правило лучше всего рабоатет смесь теоретиков и практиков, по возможности людей разной национальности так как образ мышления очень разный.
Выделенное действительно очень важно. Американцы так и делают, европейцы стараются иностранцев не брать. В двух самых националистических странах (Германия и Франция) к иностранцам относятся, как к мусору, стараются не брать вообще, кроме как на самые низкие зарплаты, потом эксплуатировать их, играя на их подвешенном статусе иностранца (потерял работу — вылетел из страны). Финляндия, Дания тоже очень не любят иностранцев.
pik>качество кода и продукта стоит бесспорно на 1 месте, время играет второстепенную роль.
В 99,99 контор время и маркетинг стоят на первом месте, качества кода и продукта на последнем.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Думаю, что если квалифицированному специалисту сообщат, что time to market является приоритетом, то ООП — это последнее, что он выберет. Поэтому и вопросов о синглетонах не возникнет.
Разве ООП == качество кода?
Здравствуйте, pik, Вы писали:
pik>я не понял, вы всерьёз думаете что в солидных фирмах вам дадут право выбора инструмента?
Я же говорю фирму, куда набирают серьезных программистов, а не говнокодеров, для которых обращение списка — сложная задача.
pik>такие вопросы решаются коллективно в совещаниях и по мнению большинства/аргументации иногда голосованием но окончательно принимает решение начальник отдела(руководитеь проекта)
pik>time to market не является приоритетом в солидных фирмах, отбор персонала жестокий и как правило лучше всего рабоатет смесь теоретиков и практиков, по возможности людей разной национальности так как образ мышления очень разный. качество кода и продукта стоит бесспорно на 1 месте, время играет второстепенную роль.
Солидная компания — не обязательно успешная компания. Вот например была такая компания Sun — вполне солидная, только нисколько не успешная.
На куче рынков с низкими затратами на вход (не только в IT) стратегия успешной компании может быть в возможности иметь высокую маржу пока не подтянулись конкуренты. Я не говорю что это справедливо для всех, но нужно помнить что понятие качества тоже достаточно многогранно и к тому же является всего лишь одним из потребительских качеств продукта.
Например не факт что качество кода имеет большое значения для всяких аутсорсеров и консалтеров, они могут не нести отрицательных издержек "говнокода", а если не будет еще и репутационных, то они вполне могут на это все забить и будут правы.
Здравствуйте, 0x7be, Вы писали:
0>Разве ООП == качество кода?
Нет, ООП — это вообще бред двух норвежцев, которые объелись грибов и решили прикрутить понятия из теории систем к языкам программирования. Естественно, никакого математического фундамента под этим не было (позже Лука Карделли попытался натянуть на ООП теорию типов — получилось примерно как презерватив на глобус), и никакого развития ООП с 67-года — тоже. Я бы сейчас даже так сказал — хотите написать говно — выбирайте ООП. Ах да, есть одно преимущество — куча программистов на рынке, испытывающих серьёзные проблемы при написании простейших алгоритмов, но зато выучивших названия паттернов и готовых по полдня обсуждать как правильно написать очередную фабрику абстрактных синглетонов.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Нет, ООП — это вообще бред двух норвежцев, которые объелись грибов и решили прикрутить понятия из теории систем к языкам программирования. Естественно, никакого математического фундамента под этим не было (позже Лука Карделли попытался натянуть на ООП теорию типов — получилось примерно как презерватив на глобус), и никакого развития ООП с 67-года — тоже.
ООП — это виток эволюции, который произошел в результате борьбы с известными
проблемами программирования. Всякие математические фундаменты и теории тут не при чем.
Переходя энную тысячу строк кода, становится банально тяжело управлять функциями с
пятнадцатью аргументами и структурами с открытыми полями — не вижу ничего порочного в том,
чтобы аккуратно упаковать это все в классы и дать сему процессу вполне адекватное название.
ПМ>Я бы сейчас даже так сказал — хотите написать говно — выбирайте ООП. Ах да, есть одно преимущество — куча программистов на рынке, испытывающих серьёзные проблемы при написании простейших алгоритмов, но зато выучивших названия паттернов и готовых по полдня обсуждать как правильно написать очередную фабрику абстрактных синглетонов.
Мой знакомый сел за руль в мертвецки пьяном состоянии, после чего на большой скорости въехал на
стрелу снегоуборочной машины и повредил себе ноги, став хромым до конца жизни. В этом виноваты,
разумеется, производители его "Жигулей", не предусмотревшие опции катапультирования, а также
водитель снегоуборочной машины, но уж никак не он сам !
