Очень часто на Reddit или Quora я вижу вопросы вида «Как понять, смогу ли я стать успешным программистом?» (На самом деле, эта статья является расширенным продолжением моего недавнего ответа на Quora.) Когда кто-то задумывается о смене карьеры или интересуется разработкой и хочет знать, что для этого требуется, неизбежно возникает этот самый вопрос.
Вообще, я думаю, что это главный барьер в умах людей, которые не получали фундаментального образования по программированию. Думать, что программист из вас так себе, совершенно естественно, и это мешает вам взяться за новое дело. Это как мечтать стать актером, но сомневаться, что вы вообще умеете играть.
Будучи преподавателем на курсе «Full-stack Web-development», я работал со многими программистами-новичками. Хорошая новость в том, что мне редко встречались студенты, которые вообще не могли научиться программировать. Я считаю, что умение программировать — такой же базовый навык, как умение читать, писать и считать. Это под силу любому, так как это одна из способностей человека, но этому действительно надо учиться.
За два года преподавания, я наблюдал мучения студентов в процессе обучения и видел у них несколько схожих проблем. Если вы взглянете на их список и почувствуете, что это все про вас, можете быть уверены — хороший программист из вас точно не получится и, возможно, вам стоит заняться чем-то другим. Однако, если вы останетесь верны своей цели стать разработчиком, вы сможете преодолеть все препятствия.
Этот список поможет вам понять, сможете ли вы стать хорошим программистом, а также что делать, если вы решите это изменить.
1 | Вам не хватает любознательности
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Основа любого обучения — это большой интерес к предмету изучения. Если ваш ум не питает особого интереса к технологиям, вам не хватит энергии и запала, чтобы глубоко и подробно изучить программирование и добиться успеха в этой области.
Напротив, мир технологий как огромный океан захватывающих областей, пересекающихся идей и будоражащих воображение возможностей. Потребуется внушительный запас внутренней мотивации, чтобы погрузиться в него и открыть для себя все, что только возможно.
Воспитывайте в себе любопытство: Спросите себя, на самом ли деле вам интересно программирование. Если ваш честный ответ — «нет», найдите что-то, что действительно вас увлекает. Не тратьте зря время и силы. Но если вы ответили «да», тогда заставьте себя найти нечто новое, с чем вы еще не сталкивались, признайте насколько обширен этот океан и ныряйте глубже.
2 | Вам не хватает самостоятельности и находчивости
Если вы не разовьете в себе умение решать проблемы самостоятельно, вам ни за что не стать успешным программистом.
Без сомнения, чтобы стать успешным разработчиком, вы должны быть уверены в ваших собственных способностях учиться. Это, кстати, один из самых важных жизненных навыков — если вам больше 18, никто не обязан вас учить. Такова реальность. Находить необходимую информацию и помощь, если она вам требуется, — это только ваша задача.
В мире разработки всю нужную вам информацию можно найти в волшебном месте, ранее известном как Information Super Highway. У этой гигантской библиотеки есть одна большая дверь — Google. Понять, что вы можете просто вбить в поиск все, что вам захочется, и получить доступ необходимой информации — это первый барьер на вашем пути к приобретению навыков, которые потребуются вам в мире IT.
Помимо умения гуглить, важно также научиться читать документацию и спецификации, которые есть у всех языков программирования и очень прозрачно объясняют, как работает язык. Это все равно, что использовать словарь: когда вы встречаете слово, которое вы не знаете, вы смотрите его в словаре. Самый быстрый и надежный способ развить и закрепить ваши навыки программирования — это просто читать документацию. Там есть буквально все.
Используйте все ресурсы: Поймите, что на все ваши вопросы уже есть ответы. Прежде, чем спрашивать кого-то, загуглите и почитайте документацию. Приберегите возможность потратить чье-то время на тот случай, когда вы действительно пытались найти ответ, но не смогли.
3 | Вам не хватает упорства перед лицом проблемы
Если вы сдаетесь, едва столкнувшись с проблемой, вам ни за что не стать успешным программистом.
Суть программирования есть решение проблем. Это и есть причина создания компьютеров! Всякий раз, когда вы начинаете работать над программой, вы сталкиваетесь с целой «стопкой» проблем. И как только вы находите решение одной проблеме, почти всегда возникает другая. Вы движетесь вперед, но всегда есть новые препятствия.
Надо признать, что этот ворох проблем бывает пугающим и обескураживающим. Если вы думаете, что все должно «просто работать», вам не хватит энергии и сил настойчиво продолжать работу, пока проблемы появляются одна за другой и понемногу выбивают вас из эмоционального равновесия. Ваша работа заключается именно в том, чтобы понять, почему что-то не работает.
По моему преподавательскому опыту, в группе всегда есть один или два студента, у которых как будто есть какая-то врожденная способность находить больше неприятностей, чем другие, причем очень часто это случайные и непонятные проблемы. Таким студентам я напоминаю, что чем больше проблем они встречают, тем больше у них возможностей изучить что-то глубоко и тщательно. Если через эти проблемы они могут обрести полное понимание, они станут увереннее гораздо быстрее, именно потому что столкнулись и справились с бoльшим количеством проблем, чем другие.
Терпение и принятие: Вам нужно понять, что эта область состоит из проблем, и относиться к ним стоит не как к проблемам, а как к вызовам. Каждый брошенный вам вызов, который вы сумеете преодолеть, даст вам больше знаний, более глубокое понимание и улучшит вашу способность находить новые препятствия и быстрее решить старые.
4 | Вы не ощущаете радости от успеха в решении проблем
Если вы не испытываете чувство восторга и выполненного достижения, когда решили проблему, вам ни за что не стать успешным программистом.
С выше описанной ситуацией, когда вы легко сдаетесь, связано и отсутствие «приятных ощущений», когда вы находите успешное решение проблемы. Когда исправление ошибок превращается в однообразный механический труд, которому нет конца, вы теряете азарт, сопутствующий поиску и нахождению решения задачи.
Когда вы успешно решаете проблему, в мозг выбрасывается заряд дофамина. Это сродни прохождению уровня в видео игре или решению кроссворда или судоку. Всем известно это приятное чувство, когда вы упорно боретесь с трудной задачей и в конце-концов побеждаете. Но если вы теряете способность чувствовать этот восторг, или вас это просто никогда на волновало, вам не понять и не ощутить радость от программирования. Если для вас программирование — это однообразная скучная работа, где вы просто хотите получить результат, не напрягаясь, вы никогда не станете по-настоящему хорошим программистом.
Отмечайте ваши победы: Каждый раз, когда вы находите ответ на мучивший вас вопрос, не важно, насколько он незначителен, принимайте это как повод для гордости, отвлекитесь на минутку и поздравьте себя с успешно выполненным заданием. Позвольте чувству успеха охватить вас и зарядить энергией для последующих задач.
5 | Вам не хватает терпения в учебе
Если вы ощущаете нехватку терпения в учебе и ждете, что вы сможете все освоить легко и быстро, вам ни за что не стать успешным программистом.
Человек — создание весьма ограниченное. Несмотря на то, что все в нашем мире движется все быстрее, и компьютеры являются, пожалуй, главной причиной этого, мы не можем развиваться быстрее, чем позволяют наши способности. Наш мозг работает в определенном темпе, и в зависимости от нашего прошлого, наших убеждений, эмоционального состояния и здоровья мы все учимся и усваиваем информацию с разной скоростью.
Мир технологий похож на бескрайний океан. Вам не добраться до его края, вам никогда не стать таким профессионалом, который знает абсолютно все и которому больше нечего учить. Если вас это обескураживает, вы будете постоянно испытывать давление от необходимости «догонять» прогресс и чувствовать, что ваших знаний никогда не будет достаточно. Если вы не в силах принять то, что вы уже знаете, и затем выучить что-нибудь еще, вам будет казаться, что вы никуда не движетесь, и вы просто сдадитесь.
Вместо этого, постарайтесь насладиться процессом обучений и думать о нем, как о путешествии. Все новые знания или новые навыки, которые вы приобретаете, должны вдохновлять и радовать вас. Как и когда вы находите решение проблеме, вы должны чувствовать гордость за ваши достижения и признавать, что вы сделали шаг вперед, даже если это маленький шажок.
Награждайте себя за ваш прогресс: В программировании учить придется много, и это путешествие никогда не закончится. Но знания накапливаются, поэтому вам стоит гордиться тем, что вы уже знаете, и верить, что все ваши старания в учебе создают прочную базу для вашей карьеры, куда бы она вас не завела.
6 | Вы чувствуете скуку или усталость от долгих размышлений
Если вы ленитесь думать и вы считаете сконцентрированное размышление скучной рутинной обязанностью, вам не стать успешным программистом.
Программирование — это мыслительная деятельность. Человек, как вид, успешен в этом, однако реальность такова, что даже несмотря на то, что мы делаем это все время, мы ленимся по-настоящему размышлять. Способность поддерживать концентрацию при решении единственной проблемы в течение какого-то времени вызывает сложности, если вы к этому не привыкли.
Проявляется это по-разному. Вы можете долго сидеть, уставившись в экран, чувствовать, что на ваши мысли давит тяжелая туча, прокрастинировать, бесцельно переключаться между вкладками браузера, или отчаянно исследовать StackOverflow в поисках нужного «ответа». Все это означает, что вы столкнулись с ментальными ограничениями и нужно найти выход.
Программируя, вы, естественно, будете уставать, а мыслительная деятельность будет буквально сжигать энергию так же, как и физическая. Когда ваш организм не привык к такому расходу умственной энергии, вам будет сложно оставаться собранными. Но это как занятия в спортзале: чем больше вы это делаете, тем сильнее вы становитесь.
Ваш мозг — это мышца: Поверьте, ваш мозг — как мышца: чем больше вы его напрягаете, тем сильнее он становится, и тем более эффективно вы мыслите. Пока вы собираете воедино части головоломки, систематизируете, анализируете и развиваете идеи, находить решения становится все легче.
7 | Вы не способны думать самостоятельно
Если вы ждете, что кто-то будет думать за вас, и не хотите всматриваться в детали своего положения, вам ни за что не стать успешным программистом.
Изучая что-то новое, очень часто мы чувствуем что наших знаний и опыта недостаточно для того, чтобы иметь собственное мнение. Выступить с инициативой, сделать или сказать что-то неправильно кажется очень рискованным.
У всех нас есть этот внутренний страх быть неправым. И когда этот страх препятствует вашему исследовательскому любопытству, вы подавляете в себе способность развивать реальные знания, знания, полученные из собственного опыта, побед и поражений. Если вы полагаетесь на мнение «гуру», популярного блогера, «лучшую практику» или ответ из учебника, это значит, что вы не разбираетесь в программировании полностью и глубоко.
Нужно развивать свое собственное мнение о том, что работает и что нет. Нужно понимать, почему вы считаете, что ваше решение хорошее, какие у него преимущества. Нужно развивать тонкий взгляд, который замечает не только очевидные детали. Нужно уметь отстаивать свою точку зрения, и тогда, если вы изменитесь, вы обретете новое видение и оно будет вашим собственным.
Думайте сами: С помощью собственного опыта и умения мыслить критически формируйте свои собственные мнения. Делайте обдуманные предположения, занимайте сторону в споре и будьте готовы изменить ее, если появляется новая информация.
8 | Ваше мышление негибкое, узкое и/или неорганизованное
Если вы не очень гибки в своем мышлении и у вас сложности с организацией вашего кода, а также ваших мыслей, вам ни за что не стать успешным программистом.
Я иногда вижу в студентах две крайности. Первая — узкий и негибкий подход к мышлению. Такое отношение заставляет их отвергать помощь и, несмотря на фидбэк, не дает им меняться. Все видится только с одной стороны, все предложения игнорируются.
Вторая крайность, с которой я сталкиваюсь, — неорганизованность в мыслях. Студенты сами создают себе сложности все без всякой необходимости, их код беспорядочный, в нем сложно разобраться. Они усложняют задачи и пишут по 100 строк кода там, где хватило бы 10.
Когда оба эти образа мысли объединяются, результатом оказывается такой жесткий и напряженный подход к программированию, своего рода метод грубой силы, который приводит к многочисленным слоям исправлений багов и «костылей». Что действительно необходимо в такой ситуации, так это способность вернуться к началу, переосмыслить первоначальное решение, отказаться от него и реорганизовать код.
Неспособность увидеть другие возможности или получить фидбэк мешает вам расти и развиваться. Неорганизованность замедляет вас и не дает видеть шаблоны, которые в ином случае были бы очевидны. И общее качество вашей работы ухудшается.
Самокритика: Всегда следует сделать шаг назад, чтобы увидеть целиком всю картину того, как вы подходите к задачам. Как можно сделать это лучше? Есть ли что-то, что могло бы облегчить вашу жизнь? Чего вам не хватает и что могло бы вам помочь?
9 | Вы хотите знать один «правильный» ответ вместо признания спектра «хороших» и «плохих» ответов.
Если воспринимать конечную цель программирования как нахождение верного решения, а не спектра возможных решений, вам ни за что не стать успешным программистом.
В начале изучения навыкам программирования студенты часто хотят знать, является ли то, что они сделали, «правильным». Ответ на этот вопрос всегда — «зависит от обстоятельств».
Computer Science — это наука оценивания компромиссов. Получив различные комбинации обстоятельств, найдете ли вы лучшее решение? Все зависит от обстоятельств и целей. Когда вы воспринимаете программирование как тест с верными и неверными ответами, вы теряете возможность видеть всю картину и отказываетесь от творческого подхода. Любое решение может быть «верным», если оно оправдано в данных обстоятельствах.
В реальности программирование больше похоже на написание стихотворений или рассказов (или романов, если программы достаточно большие). В вашем коде есть своя эстетика и красота, иногда видимая лишь вам и другим программистам. Причины, по которым вы выбрали какое-либо решение и то, каким вы себе его представляете, гораздо важнее, чем «правильно» или «неправильно». Образ мысли художника позволяет играть с различными вариантами и возможностями, а не считать какое-либо решение единственным верным. В этом и есть красота программирования — есть много разных способов решения проблемы, и рассмотрение разных возможностей приводит к ощущению того, какой из них лучше подойдет в тех или иных условиях.
Будьте креативными: Поймите, что есть множество способов решить проблему, а опыт и выдержка помогут вам со временем развить отличное понимание того, какие решения больше подходят в данной ситуации, чем другие. Видеть полную картину, представлять себе различные возможности и доверять своей интуиции полезно для нахождения лучших решений, полностью удовлетворяющих вашей задаче.
10 | Вы не уделяете достаточно внимания деталям
Если вы пренебрегаете деталями и упускаете из вида мелочи, вам ни за что не стать успешным программистом.
Компьютеры любят точность. Когда дело касается программирования компьютера, необходимо предоставлять ему исключительно точные команды таким образом, как того ожидает компьютер. Если вы этого не делаете, ничего не сработает. Среднего не дано — код либо работает, либо нет.
Это означает, что программисту необходимо быть внимательным к деталям. Каждый пробел, скобка или точка с запятой важны. Если они не там, где надо, ничего не сработает. Когда компьютер выбрасывает сообщение об ошибке, вы должны уметь взглянуть на него и понять четко, о чем он вам сообщает. В реальной жизни, если вы упустите подобные детали, вы потратите часы на поиски проблемы, которая на самом деле является результатом простой опечатки.
Как говорится, дьявол кроется в деталях. И в программировании это действительно так.
Уделяйте внимание деталям: Мелочи важны и вам придется это принять. Как только вы это сделаете, вы начнете просматривать ваш код на наличие чего-то, что не на своем месте. Можно организовать свой код и использовать различные инструменты, помогающие идентифицировать проблемы быстрее.
Бонус: Вы сосредоточены на бизнесе
Вот, что я понял, наблюдая со стороны: студенты, имеющие предпринимательскую жилку, часто более сосредоточены на результате, чем на процессе. Они хотят получить «рабочее приложение», которое позволит им продвинуться дальше с их бизнес-идеей, они хотят «сначала выйти на рынок» и видят длительное обучение как барьер на пути к их цели — запуску их бизнеса.
Анализируя студентов, которым было реально трудно расти как программистам, я пришел к выводу, что нехватка терпения в процессе обучения является серьезным препятствием и действительно мешает разобраться в технологии. Для них технологии — всего лишь средство достижения цели, но не обширная серьезная область знаний, которую нужно исследовать и получать удовольствие.
Я также встречал студентов, которые желали начать работать сильнее, чем другие, и испытывали значительные сложности в обучении. Они часто торопились найти заказчиков, подписывались на работу, которую даже не в состоянии были выполнить самостоятельно! Они хватались за все найденные ресурсы/шаблоны чтобы только проект начал работать, или же отдавали часть работы на аутсорс кому-то еще. У них реально плохо получалось программировать, но потрясающе получалось убеждать людей платить им за это!
Я бы хотел добавить, что студенты, желающие начать бизнес, великолепно понимают в продажах, связях и развитии, но испытывают гораздо больше трудностей в самом программировании. Их естественное желание создать финансовые возможности и связать людей и решения делает их нетерпеливыми в разборе нудных деталей, что предполагает программирование.
Заключение
Хотя научиться программировать довольно сложно, это совершенно точно возможно. Приведенный выше список содержит такие подходы и образы мыслей, которые встают у вас на пути, однако большинство людей в состоянии преодолеть эти препятствия и стать компетентными программистами, и даже мастерами своего дела.
Если вы хотите научиться программировать, отправляйтесь в это путешествие! Помните об описанных мной проблемах и начинайте исследовать все множество ресурсов, доступных онлайн, это ускорит ваше продвижение вперед. Вы точно не пожалеете.
Дисклеймер: все сказанное выше — мое собственное мнение, основанное на профессиональном опыте преподавания веб-разработки. Оно может отличаться от мнения BrainStation.
Комментарии (468)
justhabrauser
08.01.2020 23:48+6Кроме №9 все тезисы могут быть применены к любой профессии.
Вообще к любой.
Всю статью можно переписать так:
"Если будешь хорошим — то будешь хорошим. А если будешь плохим — то ничего у тебя не получится."
Suvitruf
08.01.2020 23:48+2Это всё про любую интеллектуальную деятельность можно сказать, а не только про программирование.
justhabrauser
08.01.2020 23:53-2Подставьте "дворник".
cyberly
09.01.2020 00:10+5«Дворник», вроде, к интеллектуальным профессиям не относится… Однако, если подразумевать нечто типа «специалист по клинингу» — там много разного интересного оборудования и целый мир всякой спецхимии, с этим всем можно разбираться, «придумывать нестандартные решения» и далее в том же духе, что делает тезис Suvitruf снова верным.
justhabrauser
09.01.2020 15:09-3«Дворник», вроде, к интеллектуальным профессиям не относится…
Кто так решил?
И что есть "интеллектуальная профессия"?
Илита?
PS. ну разве что под "интеллектуальной профессией" понимать вид деятельности, при котором
больше работают головойменьше работают руками, и основная физическая нагрузка приходится на пятую точку.
DP2
10.01.2020 12:09Если брать в качестве критерия «хорошего дворника», то у него может оказаться немало «разного интересного оборудования».
Ему потребуется интеллектуальная деятельность, например для расчёта расхода реагента с учётом температуры сейчас и ближайшим вечером. Или для оптимизации затрат на очистку стоянки с учётом непрекращающегося снегопада и времени приезда начальства :). Ну и т. п.
—
gatoazul
09.01.2020 15:04Вы думаете, дворнику не нужно принимать никаких решений?
justhabrauser
09.01.2020 15:07Я думаю что выделять
илитуинтеллектуальную деятельность как нечто особенного немного неверно.
Работа как работа. Ничего особенного. Дворником отнюдь не проще.
Hivemaster
09.01.2020 15:52Я могу делать работу любого дворника, а любой дворник мою не может.
GrimMaple
09.01.2020 15:55Вы уверены, что сдюжите 8 часов махать метлой, долбить лёд, посыпать дороги песком и кучу других обязанностей дворника?
justhabrauser
09.01.2020 16:04Точнее не махать метлой, а мести.
Махать-то сможет, мои дети в 2 года так могли. Именно махать метлой, не мести.
Hivemaster
09.01.2020 16:20Не просто уверен, я знаю, так как работал дворником.
GrimMaple
09.01.2020 18:35Тогда вам очень повезло, ибо я разваливаюсь после подметания своей квартиры х)
akryukov
09.01.2020 17:01Для этого требуются какие то особенные умственные способности, что вы дворника в интеллектуальную профессию записали?
GrimMaple
09.01.2020 18:38Я не записывал дворника в интеллектуальные профессии, просто не был уверен в
Я могу делать работу любого дворника
Я бы развалился через полчаса подметания улиц. То, что господин Hivemaster может подметать улицы и не умирать от этого — хвала ему во всех смыслах
mayorovp
09.01.2020 15:58Но, например, любознательность или там терпение в учёбе явно не являются важным профессиональным качеством дворника. А для программиста — являются. Значит, совершенно одинаковыми эти две профессии не являются...
justhabrauser
09.01.2020 16:02-1Конечно не являются!
Чтобы быть нормальным дворником, надо чтобы руки нормально отросли.
А вот людям спроблемными рукамиальтернативной моторкой приходится идти в погроммисты и выкручиваться как получится.
PS. надеюсь понятно, что это просто взгляд с другой кочки зрения, а не повод для холивара :-)
mayorovp
09.01.2020 16:08Но интелектуальной профессия "дворник" от смены точки зрения всё равно не становится.
justhabrauser
09.01.2020 16:10-1Конечно не становится!
Чтобы быть дворником, надо кроме головы еще и прямые руки иметь.
А с прямыми руками ту же Windows написать сложно (такой, какая она есть)
Так что нет, не становится.
mayorovp
09.01.2020 16:12То есть вы согласны, что дворник — не интелектуальная профессия? Тогда с чем вы спорите?
justhabrauser
09.01.2020 16:18Как только дадите четкое, явное и неоднозначное определение понятия "интеллектуальная профессия" — сразу же.
PS. насколько мой склероз подсказывает — в ОКПДТР ничего такого нет.
oisee
08.01.2020 23:49+2TL;DR;:
«Если вы несамостоятельный ленивый нелюбознательный хмыропуз, то из вас ничего не получится».oleg_go
09.01.2020 00:02-3Отнюдь — можно же в депутаты ГД пойти, идеальная будет кандидатура
Hivemaster
09.01.2020 07:48А вы попробуйте. Подобраться к такой кормушке намного сложнее, чем стать сеньором транснациональной корпорации.
Foxbator
09.01.2020 09:49Тут дело в наборе навыков и характере, кому-то проще стать сеньором, кому-то депутатом. От человека зависит.
helgihabr
09.01.2020 14:09Я бы немного перефразировал: переступить через некоторые свои принципы, подбираясь к кормушке, да, сложнее, чем стать сеньором в IT.
Но с другой стороны, дефицит специалистов во многих (во всех?) отраслях довольно велик, как и в политике тоже.
Lure_of_Chaos
09.01.2020 00:06+4(на правах грустного юмора) Почему мне не быть хорошим программистом несмотря на 15 лет опыта:
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Мне интересно, как написан код библиотек\фреймворков и т.д., но мне всё равно, как устроен компьютер (знаю на уровне школьника и ладно)
Если вы не разовьете в себе умение решать проблемы самостоятельно, вам ни за что не стать успешным программистом.
Я не хочу потерять день на решение проблемы мучаясь дебагом, которое способен мгновенно выдать интернет\коллега\мануал.
Если вы сдаетесь, едва столкнувшись с проблемой, вам ни за что не стать успешным программистом.
Решит коллега. Поменяю саму задачу или способ решения.
Если вы не испытываете чувство восторга и выполненного достижения, когда решили проблему, вам ни за что не стать успешным программистом.
Нет, ведь самое трудное еще впереди. Или просто еще 10 таких же проблем (тикетов)
Если вы ощущаете нехватку терпения в учебе и ждете, что вы сможете все освоить легко и быстро, вам ни за что не стать успешным программистом.
Когда мне было 20 — все давалось легко и быстро. Теперь я точно знаю, что мне не понять, например, криптографию и другую высшую математику, и просто туда не лезу.
Если вы ленитесь думать и вы считаете сконцентрированное размышление скучной рутинной обязанностью, вам не стать успешным программистом.
Потому что, шьёрт побьери, это рутина! Это выматывает! Это бессонные ночи и литры кофе! И вообще, очевидное и изящное решение, как известно, приходитво сненеожиданно, само.
Изучая что-то новое, очень часто мы чувствуем что наших знаний и опыта недостаточно для того, чтобы иметь собственное мнение. Выступить с инициативой, сделать или сказать что-то неправильно кажется очень рискованным.
От нас требуется писать быстро и без ошибок, у нас нет времени на рефакторинг и глобальные переделки, нет мотивации среди нескольких неплохих решений долго выбирать наилучшее. ***к ***к и в продакшн!
Ваше мышление негибкое, узкое и/или неорганизованное
Поэтому важно работать в команде. За годы работы на почти каждую проблему сразу всплывает собственный типичный подход «я всегда так делал», и уже не видно альтернатив.
Если воспринимать конечную цель программирования как нахождение верного решения, а не спектра возможных решений, вам ни за что не стать успешным программистом.
Когда-то я доводил код до формы, устраивающей меня. Сначала писал простыню говнокода, которая просто работает, а потом рефакторил, придавая универсальность и гибкость, в попытках написать идеальный код… Теперь я останавливаюсь на простыне, которая хотя бы не плоха — идеальный код никому не нужен, да и тот код, что я нахожу красивым, врядли *всем* покажется тоже красивым.
Если вы пренебрегаете деталями и упускаете из вида мелочи, вам ни за что не стать успешным программистом.
Я крайне нетерпелив и невнимателен. Тот код, который еще мной же не пересматривался и не правился, набит ошибками «нулевого указателя» и «лишней единицы». Я это знаю, а потому не проверяю, как учитель орфографию учеников, а пишу юнит-тесты. Только тесты могут выявить эти глупые ошибки из невнимательности. Я не стараюсь.
А потому, у меня много опыта и я не был и не буду хорошим программистом :DinnovaIT
09.01.2020 00:47+2Когда-то я доводил код до формы, устраивающей меня. Сначала писал простыню говнокода, которая просто работает, а потом рефакторил, придавая универсальность и гибкость, в попытках написать идеальный код… Теперь я останавливаюсь на простыне, которая хотя бы не плоха — идеальный код никому не нужен, да и тот код, что я нахожу красивым, врядли *всем* покажется тоже красивым.
А если этот кусок кода придется поддерживать лет 10? Такое же отношение будет? На своих проектах я стараюсь писать сразу правильно(все равно какая то чушь получается). За то через 3-5 лет когда необходимо что то добавить я сам себе говорю спасибо, за правильно написанный код. И не приходится рефакторить днями, то что написано за пару часов.Lure_of_Chaos
09.01.2020 08:34Я все же зря написал про «простыню», мой код все же не напоминает код школьника и я даже прошел этап «мне стыдно за код, написанный несколько лет назад» — я иногда открываю свои проекты, писаные много лет назад, чтобы что-то улучшить, добавить. Смотрю — и не нахожу возможных улучшений (все же я плохой программист, да? :) )
Однако я пишу код так, что он может быть нечитаем со стороны. Например, я инлайню сложные выражения, если они используются однажды, вместо вынесения их в отдельную переменную. Также (речь про Java) раньше я ставил final и this. везде, где только можно (сейчас я так не делаю)
Т.е. меня будут ругать за то, что я не пишу
int width = innerWidth/2; // здесь может быть выражение и посложнее этого int height = innerHeight/2; out(width, height, text);
а пишу
out(innerWidth/2, innerHeight/2, text);
за что меня часто и ругают «непонятно, что здесь написано!»
Хмф, зато я сразу вижу возможные ошибки («а что, если аргумент будет null — все упадет с NPE», «слишком большая область видимости — руками изменят и все упадет») и пишу код так, чтобы уменьшить вероятность ошибок и неправильного обращения с обьектом.
Зато подход «сначала пишем как пишется, потом рефакторим до годного» оправдывает себя тем, что не приходится задавать вопросы «а что, если...» на раннем этапе — сначала ставится вопрос «как решить эту задачу», и когда уже PoC-код работает, переходим к рефакторингу «сделать код универсальным, сделать код безопасным»
fzn7
09.01.2020 09:34Отличный подход. Многие угрозы переоценены. Откровенно раздражает, когда начинаются придирки
symbix
11.01.2020 12:20Смотрю — и не нахожу возможных улучшений (все же я плохой программист, да? :) )
Смотря на каком уровне. Если на уровне процедуры/метода/функции, это нормально. А если на уровне архитектуры приложения не видите, что улучшить, у меня плохие новости.
Politura
09.01.2020 00:52+1Угу, а как оно было 15 лет назад? :) Все-таки это не вопросы померить то, насколько ты опытный программист сейчас, а то, сможешь ли ты дойти с нуля до опытного. Подстажите, плиз, как стать опытным программистом если нет ни любопытства, ни желания что-то изучать и не испытываешь удовольствия от того, что получил работающее решение?
Lure_of_Chaos
09.01.2020 08:4315 лет назад мне было всё интересно.
Я благодарен отцу за то, что еще раньше, когда мне было 10 лет, у него получилось заинтересовать меня программированием и обучить основам бейсика на Спектруме, поэтому вопрос «кем я буду, когда вырасту» был однозначно «программистом».
Мне было интересно все, это был сумбурный подход «все интересно, во всем разобраться, все попробовать сделать самому», кладбище мертворожденных проектов тянет на отдельный мир.
Извините, а отвечая на Ваш вопрос «как стать опытным программистом если нет ни любопытства, ни желания что-то изучать» — иметь мотивацию, которую я наблюдал у младших коллег «за это хорошо платят, поэтому идем на SO, копипастим работающий код и изменяем под свои нужды»
Эх, каюсь, но подходом «не знаю как сделать — нахожу решение на SO, понимаю принцип и пишу свой код» пользуюсь и до сих пор, а то и даже «не понимаю код, что написали на SO — копирую как есть, изменяю те места, которые понимаю, но до тех пор, пока код работает»
Nikita_Danilov
10.01.2020 11:29Категорически извиняюсь, честно говоря, у меня имеется ощущение, что вы отчасти лукавите. :)
То ли специально чрезмерно иронизируете, то ли преувеличиваете своё ощущение усталости от похожих задач, то ли еще как назвать. Например:
Я крайне нетерпелив и невнимателен. Тот код, который еще мной же не пересматривался и не правился, набит ошибками «нулевого указателя» и «лишней единицы».
Противоречит упомянутому ниже вашему хорошему качеству:
Хмф, зато я сразу вижу возможные ошибки («а что, если аргумент будет null — все упадет с NPE», «слишком большая область видимости — руками изменят и все упадет») и пишу код так, чтобы уменьшить вероятность ошибок и неправильного обращения с обьектом.
В любом случае, хочу отметить пару опасных допущений данной фразы:
мне не быть хорошим программистом несмотря на 15 лет опыта… А потому, у меня много опыта и я не был и не буду хорошим программистом.
1) «Хороший» программист (инженер) — не звание на всю жизнь, нельзя лишь почевать на лаврах прошлых заслуг, человек на определенном этапе развития может быть таковым, а потом может выгореть или решить немного отдохнуть и перейти в режим просто «Норм» — в среднем нормально решает знакомые задачи знакомыми методами без лишнего погружения и разбора деталей.
2) Цифра стажа — не определяет автоматически попадение в категорию «Хорошего», лишь повышая вероятность накопления определенного опыта, т.к. см. 1 первый — важно и как человек провел эти года, и каков он сейчас.
kababok
09.01.2020 00:56+1Честно говоря, первым делом полез посмотреть, сколько у вас подписчиков и не входите ли вы в Кольцо Переводов… =D
justhabrauser
09.01.2020 01:10+1Не, это просто очередная проба пера.
Ну или зарождение нового Редактора Хабра (тьфу-тьфу).
workbohdan
09.01.2020 03:13-1Нет правильного или неправильного ответа. Есть работающий или неработающий вариант :)
LucasP
09.01.2020 06:55Любознательность — это конечно хорошо, главное в скорости и любознательности не выгореть)
Lure_of_Chaos
09.01.2020 08:51По опыту — выгорание происходит тогда, когда творческая натура сталкивается с рутиной исправления 100500 тупых багов.
sergey-gornostaev
09.01.2020 09:05В моём опыте бо?льшая часть выгоревших — это люди, не испытывавшие ни малейшей тяги к программированию, но пришедшие в него за деньгами или по настоянию родителей.
Lure_of_Chaos
09.01.2020 09:08Возможно, к ним уже не применим термин «выгорание», т.к. они уже пришли «выгоревшими», но какое-то время отчаянно боролись между «мне это не интересно» и «но за это же платят» в постоянном компромиссе «как сделать быстро, некачественно, но чтобы мне за это ничего [плохого] не было»
Archon
09.01.2020 12:37Если они сумели полюбить программирование хотя бы из-за денег, то это уже какая-никакая тяга. Врождённая неотключаемая зацикленность на одной-единственной профессии встречается редко. Средний человек по умолчанию не имеет тяги вообще ни к чему, но потом собирается с силами и заставляет себя полюбить какую-то сферу деятельности.
Ну а про способы борьбы с рутиной и депрессией, они у всех разные. К сожалению, многие идут по пути наименьшего сопротивления и выбирают один из трёх вариантов: спиться, зожнуться, либо сектантствовать. Хотя как по мне, эти варианты практически бесполезны, и огонёк не возвращают. Творческую натуру надо кормить разнообразными творческими занятиями, тогда она будет периодически проявляться и в работе.
Barma2012
09.01.2020 10:21Суть программирования есть решение проблем. Это и есть причина создания компьютеров! Всякий раз, когда вы начинаете работать над программой, вы сталкиваетесь с целой «стопкой» проблем
Мне кажется, лучше рассматривать программирование как стопку задач, а не стопку проблем )))
Проблема — это ИМХО нечто внезапное и неприятное. Например, когда посреди разработки монитор сдох.
А написание кода — какая же тут проблема, если добровольно за это взялся?
Lure_of_Chaos
09.01.2020 10:37Даже в такой формулировке это всё равно проблемы.
Проблема: аргх, у нас в системе опять что-то сломалось, пользователи злы и не могут работать, репутация тает
Задача: выяснить, что сломалось, почему сломалось и как быстро это исправить
Анализ: возник непредвиденный кейс, невыявленный ранее из-за сложности системы
Сопутствующая проблема: Исправить сходу не получится из-за ограничений платформы и отсутствия нужных инструментов
Сопутствующая задача: выяснить способы обхода проблемы
Сопутствующий анализ: определить наилучшее в данной ситуации обходное решение
Сопутствующее решение: реализовать решение
Решение: выкатить сопутствующее решение, устранить возможность похожих проблем в будущем.
И при таком подходе «проблема -> задача -> анализ -> решение» не возникает противоречия, а неизбежный фрустрирующий фактор сведен до минимума.
Решение:
GrimMaple
09.01.2020 12:11Скорее всего это проблемы перевода (pun unintended)
В английском слово «problem» имеет смысл «задача», в контексте решения задач. «Solve this problem» — «Решите эту задачу». Во время перевода смысл слегка потерялся :)
greck
09.01.2020 13:5210 критериев — это слишком много.
Для многих достаточно одного: вам 18+ лет и вы ни разу ничего не прогали в 3 часа ночи.
Поясню. Призвание к 18 годам должно уже проявится, и что-то на каком-то языке программирования вы уже должны уметь писать. Без призвания сидеть перед монитором с буквами — это свою угробить жизнь. Чтобы сидеть и прогать в 3 часа ночи нужно 1) любопытство и я бы даже сказал страсть 2) воля к победе и бесстрашие перед множеством проблем, упорство 4) способность разгребать доки и чужой код 5) самостоятельность… короче, 1 критерий вместо 10, и в отличие от перечисленных в статье этот один легко определяется (каждый сам для себя легко на него ответит, самообман невозможен).muhaa
09.01.2020 14:07-1Согласно вашему критерию фактически ниодна девушка не может быть программистом.
Atrax
09.01.2020 14:42Что ж вы за всех-то обобщаете? Мне доводилось работать с увлекающимися девушками-программистами. Уж на программирование-то не надо набрасывать флера профессии "здоровых белых мужчин-гетеросексуалов". Хотя, что я говорю… PHP CE закрыли как раз из-за этого :(
muhaa
09.01.2020 15:48-1Давайте внимательнее. Здесь важны соотношения. Они увлекающиеся, но если школьница не сидела прям до 3 ночи за программированием, то это не означает, что ей не быть хорошим программистом. Потому что это нормальное поведение для одаренной школьницы, которой интересно программирование.
Напротив, если парень не сидел за программированием ночами уже в школе, то его шансы стать хорошим программистом сильно падают, потому что большинство из них сидит.
Офтоп: Как-то в детстве я сказал, что не намерен плакать по поводу смерти Брежнева, потому что мы не родственники и получил кучу «минусов» от учителя и одноклассников, хотя в целом это была правда. Что изменилось с тех пор? Покажи людям красную тряпку и готовься отгребать :).
lair
09.01.2020 17:14+1То есть вы считаете, что поведение (в отношении учебы) увлеченного школьника зависит от того, какие у этого школьника гениталии?
Asharah
09.01.2020 20:51Побуду адвокатом дьявола, но можно предположить, что muhaa ссылается на гипотезу о том, что люди разного пола обладают разными особенностями концентрации внимания.
Считается, что представителям мужского пола легче войти в состояние потока, в то время как женщины более способны к многозадачности.
спойлерВпрочем, быстрое гугление не дало удовлетворительного подтверждения этой теории. Тем не менее, периодически встречаюсь с этой точкой зрения в категории «все же знают» и делаю вывод, что она распространена.
О справедливости судить не возьмусь.muhaa
09.01.2020 21:07-1Все проще. Я просто заметил что критерий неверный. Потому что школьницы не сидят ночами экспериментируя с технологиями программирования. Но все равно некоторые потом становятся программистами.
Но борцы с предрассудками читают между строк то что им хочется.syrslava
09.01.2020 21:12+2школьницы не сидят ночами экспериментируя с технологиями программирования
Вы не могли бы пометить, на основании чего такой вывод сделан? Мне действительно интересно =Dmuhaa
10.01.2020 00:09Друзья, знакомые, коллеги, искал персонал, люди рассказывали о себе.
Atrax
10.01.2020 17:16Выборочное восприятие, не? Любое подобное обобщение некорректно. Ибо сродни "все серийные маньяки за месяц перед преступлением хотя бы однажды пили воду". Но, но выводов их этого все равно делать нельзя...
muhaa
10.01.2020 23:58Объективное восприятие. Предубеждений у меня нет. Вот глупость и самообман бесит.
lair
11.01.2020 00:17Предубеждений у меня нет.
Так не бывает, прямо скажем. Предубеждения есть у любого человека, воспитанного в обществе.
muhaa
11.01.2020 00:26Я не воспитан в обществе. У меня критический научный склад ума.
lair
11.01.2020 00:28+1Я не воспитан в обществе.
Гм. Мне казалось, вы упоминали одноклассников. Следовательно, вы учились в школе. Нет? У вас нет высшего образования? Вы не работали в коллективе?
У меня критический научный склад ума.
Это очень легко сказать, но очень сложно доказать. На мой личный вкус для научного склада ума вы слишком легко обходитесь с наблюдениями.
lair
09.01.2020 23:00Критерий, несомненно, неверный: школьники не сидят ночами, экспериментируя с технологиями программирования, но некоторые все равно потом становятся программистами. Я вот, например.
Но сказали вы совсем не это.
muhaa
09.01.2020 23:47Сидят. Я сидел. Все мои друзья программисты которых знаю сидели. Моя жена программист но у нее даже компьютера не было. Критерий годный для мужчин но сильно недостоверный для женщин.
lair
09.01.2020 23:55Сидят. Я сидел. Все мои друзья программисты которых знаю сидели.
Я же вам уже сказал, что я вот не сидел. Почему-то этот пример — в отличие от примера вашей жены — вы отвергаете.
Так что нет, для мужчин этот критерий такой же негодный.
muhaa
10.01.2020 00:00Настолько же не годный? В точно такой же степени? Т.е. если навскидку спросить среднюю жену на должности программиста программировала ли она по ночам до 18 то вероятность положительного ответа та же что для парня? Моя статистика говорит обратное. Возможно ваша выборка предвзята?
lair
10.01.2020 00:08В точно такой же степени?
Ну да. Вы привели один контр-пример, я привел один контр-пример.
Моя статистика говорит обратное.
На какого размера выборке собрана ваша статистика, как проводились измерения, какой критерий оценки статистической достоверности использовался?
Мне, впрочем, вообще интересно, как вы собираетесь подтверждать критерий "если не засиживался — хорошим программистом не станет", безотносительно пола.
muhaa
10.01.2020 00:29На какого размера выборке собрана ваша статистика, как проводились измерения, какой критерий оценки статистической достоверности использовался?
Для меня это выглядит как троллинг. Вам хочется нарисовать себе врага и переболтать его и все тут.
Мне, впрочем, вообще интересно, как вы собираетесь подтверждать критерий «если не засиживался — хорошим программистом не станет», безотносительно пола.
Это был довольно несерьезный критерий, высказанный не мной. Заключался он в том, что те кто не заболел с самого начала в последствии не будут слишком хороши. В основном это верно. Не считая, того факта, что женщинам психологически в гораздо меньшей степени свойственно «болеть» технологиями. Или вы хотите спорить именно насчет фактов нарушения режима дня, засиживания ровно до 3 часов и так далее?
Собственно единственный тезис заслуживающий обсуждения — это тот факт, что мужчинам свойственно гораздо сильнее увлекаться техникой и в частности программированием чем женщинам. Увлечение, которое для мужчины почти как основной инстинкт, для женщины карьера, хобби, самоутверждение, одна из интересных вещей. Сидеть в подвале, набитом электроникой и компьютерами, как доктор зло — типичная мечта мальчишки конца 80, и фактически ниодной девчонки того времени (исключения конечно существуют всегда, но это исключения). Кстати, я начинал работать в отделе АСУ, полностью состоящем из женщин программистов, а потом работал в коллективе где отношение было пополам. Так что я знаю о чем говорю.
Сейчас программирование превратилось в рутину, обычную профессию, поэтому не особо знаю что твориться в головах у молодежи сейчас.lair
10.01.2020 00:34+1Для меня это выглядит как троллинг. Вам хочется нарисовать себе врага и переболтать его и все тут.
Неа, мне хочется обойтись без голословных утверждений.
Это был довольно несерьезный критерий, высказанный не мной.
Вы однако, с ним согласились: "Критерий годный для мужчин".
В основном это верно.
В основном это верно ровно настолько, насколько верно, что чем раньше начнешь заниматься чем-то, тем больше у тебя времени на освоение навыка. И, одновременно с этим, чем сильнее ты увлечен тем, чем занимаешься, тем больше ресурсов ты в это можешь вложить. И, внезапно, это одинаково верно вне зависимости от пола.
Но вот насчет "заболеть" вопрос сильно отдельный, и как раз с ним я и спорю в первоначальном критерии. Не надо "болеть" программированием, чтобы быть хорошим программистом.
Или вы хотите спорить именно насчет режиа дня, засиживания ровнго до 3 часов и так далее?
… а если не спорить, то может внезапно выясниться, что все-таки нет никакой разницы между применимостью этого критерия в зависимости от пола.
muhaa
10.01.2020 01:29В основном это верно ровно настолько, насколько верно, что чем раньше начнешь заниматься чем-то, тем больше у тебя времени на освоение навыка. И, одновременно с этим, чем сильнее ты увлечен тем, чем занимаешься, тем больше ресурсов ты в это можешь вложить. И, внезапно, это одинаково верно вне зависимости от пола.
Стать программистом можно исходя из разных мотиваций и эти мотивации зависят от пола. Поэтому это работает по разному. В общем это уже стало слишком сложно. Я сам запутался что мы тут друг другу доказываем.
Но вот насчет «заболеть» вопрос сильно отдельный, и как раз с ним я и спорю в первоначальном критерии. Не надо «болеть» программированием, чтобы быть хорошим программистом.
А, вы об этом. Совершенно верно. Можно быть хорошим программистом не болея программированием. В 90-е годы правда таких почти не было. Сейчас есть, потому что это уже просто работа за деньги а не увлечение.
Холодный профессионал почти всегда может не уступать горячему энтузиасту в практических задачах. Энтузиаст, но плохой профессионал понапишет или понапихает фреймворков, на-изобретает сложных алгоритмов. Профессионал, но не энтузиаст просто найдет хорошее решение задачи. В итоге реальный эффект будет примерно одинаковым.
Хотя, если брать средне-статистически, таки энтузиастов среди сильных программистов пока еще большинство. Кого ни спроси, все нерды с детства по сути.lair
10.01.2020 01:33эти мотивации зависят от пола.
Почему?
(ну и сразу: как это доказать?)
Кого ни спроси, все нерды с детства по сути.
Я не знаю, кого вы считаете сильным программистом, но я знаю достаточно хороших программистов, которые не были нердами в детстве.
muhaa
10.01.2020 01:54Я не знаю, кого вы считаете сильным программистом, но я знаю достаточно хороших программистов, которые не были нердами в детстве.
Вспомнил одного такого. Написал буквально пару программ для себя после школы, а потом после первого же проекта попал в тимлиды и ведущие разработчики без особых усилий. По-моему фишка была в том, что у него был старший брат, который перехватывал инициативу и ему было уже просто не интересно идти по следам. Поэтому случайно он не был нердом. Больше особо не вспоминается. Возможно поколение 2000-х оно другое, не знаю.
Сильные — это конечно не те которые могут написать код или UI по спецификации. Те кому доверяют отвечать за архитектуру чего-то не совсем ординарного или ее часть как минимум.
Насчет зависимости мотиваций от пола, тут можно приводить тысячу примеров, даже не знаю с чего начать. Внешняя сторона очевидна: программистов мужчин больше, увлекающихся техникой мальчишек больше и так далее. Конкретно, я в детстве писал игры на ассемблере и пара моих одноклассников увлекались чем-то подобным, а мои одноклассницы вообще не интересовались что такое компьютер. Однажды я написал «мега-фреймворк» чисто из программистского зуда и подсадил на него свою компанию, хотя мне это фактически запрещали. Можете представить, чтобы подобную глупость сделала женщина, и которая при том была бы довольно средним программистом вроде меня? Зачем ей это (откуда такие мотивации)? И так далее. В чем причина — в гормонах или в воспитании, это более сложный вопрос, который мы тут явно не решим.
gdsmiler
10.01.2020 10:05Можете представить, чтобы подобную глупость сделала женщина
Да, глупость не уникальна для мужчин
Зачем ей это (откуда такие мотивации)?
Затем же зачем и вам
программистов мужчин больше
В восьмидесятые, в СССР, было ровно наоборот и програмирование считалось более женской професией (сужу по рассказам родителей) да и сейчас ситуация исправляется и женщин в ИТ все больше
muhaa
10.01.2020 12:46-1Я говорю о той действительности которую вижу. В вашем круге знакомств есть женшина-крутой программист, которая и фреймворк напишет если надо и архитектуру спроектирует и проект вытянет? В моем нет никого даже близко похожего. С одной стороны в программировании в целом пока женщ н мало. Но с другой стороны раз их мало, значит туда должны попадать самые лучшие и самые мотивированные. Значит в среднем они должны превосходить мужчин. Но ведь нет такого. В общем извините, платон мне друг но истина дороже. Может я что-то упускаю, время покажет.
lair
10.01.2020 17:58+1В вашем круге знакомств есть женшина-крутой программист, которая и фреймворк напишет если надо и архитектуру спроектирует и проект вытянет?
В моем круге знакомств и мужчин таких крайне мало. Если посчитать их долю от доли всех виденных мной мужчин-программистов, а потом взять ту же долю от всех виденных мной женщин-программистов, получится сильно меньше единицы.
Но с другой стороны раз их мало, значит туда должны попадать самые лучшие и самые мотивированные. Значит в среднем они должны превосходить мужчин.
Эээ… конечно, нет. Даже если предположить, что первое предложение верно (что не факт), второе из него никак не вытекает.
muhaa
10.01.2020 18:36-2Т.е. вы их не видели, я их не видел, но они точно есть и в приличном количестве. Понимаете же что это не убедительно. Заметте, я не говорю что женщины менее способны. По моей выборке в способностях разницы нет. Им просто не так интересно по каким-то причинам. Больше гормональным или больше культурным не знаю.
По последнему вашему возражению не понял. Выглядит как отрицание очевидного.lair
10.01.2020 19:09они точно есть и в приличном количестве.
… а откуда взялось "в приличном количестве"?
Им просто не так интересно по каким-то причинам.
… в вашей выборке?
Больше гормональным или больше культурным не знаю.
Не знаете, но говорите, что причина в поле.
Выглядит как отрицание очевидного.
Вам очевидно, что женщины в среднем должны превосходить мужчин? Или вы о каком-то другом возражении?
muhaa
11.01.2020 00:11… а откуда взялось «в приличном количестве»?
Слово «приличном» появилось, чтобы вы не привели единичный пример из интернета. Но вы все равно нашли к чему прицепиться. Раз вы выкручиваетесь, значит у вас нет настоящих оснований для уверенности. Вам просто хочется отстаивать модное мнение, выгодное вам психологически. Если бы сейчас был СССР, то вы так же горячо убеждали бы меня в преимуществах коммунизма.
Если бы вы вместо демагогии сразу привели какие-то убедительные примеры, я бы сразу сдался. Потому что была бы ваша выборка против моей.
… в вашей выборке?
В вашей в целом тоже, если судить по примерам, которые вы приводили выше.
Не знаете, но говорите, что причина в поле.
Мотивация скорее всего связана с полом, но я не уверен, что эта связь настолько сильная, что будет иметь принципиальное значение в другой культуре воспитания женщин.
Вам очевидно, что женщины в среднем должны превосходить мужчин? Или вы о каком-то другом возражении?
Вроде того. Тезис был довольно ясный, возражений к нему я не увидел.
lair
11.01.2020 00:16Чтобы вы не привели единичный пример из интернета.
Ну то есть это какое-то придуманное вами утверждение. Окей.
Раз вы выкручиваетесь, значит у вас нет оснований правоты.
Оснований какой правоты, собственно? Я пока просто задаю вопросы и привожу примеры.
В вашей в целом тоже.
О нет. В моей выборке женщинам не менее интересно, чем мужчинам.
Мотивация скорее всего связана с полом
Почему бы? Как это доказать?
Тезис был довольно ясный, возражений к нему я не увидел.
Я могу повторить возражение, если вы с первого раза не увидели: высказывание "в среднем они [женщины] должны превосходить мужчин" никак не вытекает из утверждения "раз их [женщин] мало, значит туда [в программирование] должны попадать самые лучшие и самые мотивированные". Впрочем, и высказывание "должны попадать" не вытекает из "раз их мало", но это уже нюансы. Оба ваших "значит" ничем не обоснованы.
muhaa
11.01.2020 00:39Я могу повторить возражение, если вы с первого раза не увидели:
Это не возражение. Это просто отрицание. Давайте поясню.
Возьмем 100 китайцев и 100 индусов. Допустим, все индусы работают программистами, а китайцы пока не имеют такой возможности или желания по каким-то причинам. Потом китайцы открывают для себя эту возможность. При этом, работа интересная и платят дочерта. В какой-то момент 10 китайцев тоже пробились в программисты.
Теперь сравниваем средний уровень китайцев и индусов на рынке. Если даже предположить, что в программисты попали совершенно случайные китайцы, то они должны иметь тот же средний уровень что и индусы. Но на самом деле это очень мало вероятно. Первые — это всегда лучшие, потому что это те кому интереснее и у кого лучше получается. Значит средний китаец на рынке должен быть сильнее среднего индуса (пока соотношение типа 10 к 100).
И аналогично это по идее должно работать для женщин и мужчин…lair
11.01.2020 00:43+1Если даже предположить, что в программисты попали совершенно случайные китайцы, то они должны иметь тот же средний уровень что и индусы.
Совершенно не обязательно, потому что вы исходите из равных возможностей, которые в вашем примере отсутствуют. Но не суть. Дальнейшего это не меняет.
Первые — это всегда лучшие, потому что это те кому интереснее и у кого лучше получается.
А чем, простите, обосновывается это утверждение? Первые — это просто… первые. Те, кто первым попробовал. Может быть, они просто самые жадные. Или самые бедные. Или самые удачливые.
И особенно это относится к "лучше получается". Лучше, чем у кого? Они первые, им не с кем сравнивать.
muhaa
11.01.2020 00:50-3Вы сказали, что вы хороший программист. Напрягитесь и выдайте что-то, что я хотя-бы смогу понять.
lair
11.01.2020 00:51Что конкретно вам не понятно в моем комментарии? Вопрос, на чем основано ваше утверждение, что первые — всегда лучшие?
muhaa
11.01.2020 01:03Потому что если мы ничего не знаем о ситуации, то это естественное предположение для высокооплачиваемой, престижной и не пыльной работы. Если есть какой-то фактор, который конкретно в нашем случае нарушает эту логику, укажите его.
Такой фактор конечно же есть, и это именно он: изначально более низкая мотивация к подобного рода работе. Другого не видно.lair
11.01.2020 01:08это естественное предположение для высокооплачиваемой, престижной и не пыльной работы
Вот вам и наглядная демонстрация ваших предубеждений.
То, что для вас это "естественное предположение", не делает его верным — или хотя бы очевидным для других. Я вот не понимаю, почему первые люди, рванувшие в сторону "высокооплачиваемой, престижной и непыльной работы" должны быть лучше подходящими для этой работы.
Проще говоря, вот у вас есть сто человек. Проходит слух, что где-то есть какая-то хорошая работа. Какие десять человек первыми пойдут на этот слух?
muhaa
11.01.2020 01:23Не важно кто пойдет. Важно кого в итоге возьмут на работу. Им придется конкурировать за рабочие места с мужчинами. Скорее возьмут все равно тех что выше среднего.
Вытекающая из вашего сообщения гипотеза, что по настоящему потенциально одаренные в области программирования женщины пока не пошли в программирование мне кажется крайне неубедительной. Как минимум она противоречит тому что вы выше сами же утверждали: что для них все работает так же как для мужчин. Опровергнуть что-то подобное конечно нереально, но я работал с женщинами, ставил им задачи, брал их на работу. В этом смысле у них все работает в точности как у мужчин, только в меньшем масштабе (из за менее прямой мотивированности по моим оценкам).lair
11.01.2020 01:29Не важно кто пойдет. Важно кого в итоге возьмут на работу.
… а возьмут на работу тех, кто удовлетворяет условиям. Не лучших из лучших в популяции, а тех, кто удовлетворяет условиям. Пришло десять человек, все десять выше минимальной границы — взяли. При наличии конкурса — взяли тех, кто лучше других конкурсантов (а не, опять же, всей популяции).
Скорее возьмут все равно тех что выше среднего.
Выше среднего чего? Среди кого?
Вытекающая из вашего сообщения гипотеза, что по настоящему потенциально одаренные в области программирования женщины пока не пошли в программирование
Эта гипотеза никак из моего сообщения не вытекает. Это ваша гипотеза, вы с ней и разбирайтесь.
muhaa
11.01.2020 01:46Эта гипотеза никак из моего сообщения не вытекает. Это ваша гипотеза, вы с ней и разбирайтесь.
Я вынужден был ее сочинить от вашего имени, потому что вы не объясняете как так получается. Вы просто пишите что не согласны и все. Типа это все равно ничего не доказывает и всегда можно найти другие объяснения. Можно всегда, но обычно работает наиболее простое и понятное объяснение (а не наиболее политкорректное, увы).lair
11.01.2020 01:51Я и говорю: сами сочинили — сами и разбирайтесь.
А я пока даже не понимаю, что именно вы ожидаете, что я объясню. В основном меня интересуют основания для ваших утверждений и доказательства для ваших выводов, и пока что с ними весьма скудно.
muhaa
11.01.2020 01:59+1Объясните по каким причинам немногочисленные работающие женщины программисты обычно в среднем не дотягивают по уровню даже до среднестатистического случайно взятого программиста-мужчины на этом же предприятии. Что останавливает женщин, которые потенциально могут быть ведущими программистами компаний, но сегодня не работают программистами пойти в программисты и разбавить этих недотягивающих крутыми специалистами-женщинами?
lair
11.01.2020 02:04Объясните по каким причинам немногочисленные работающие женщины программисты обычно в среднем не дотягивают по уровню даже до среднестатистического случайно взятого программиста-мужчины на этом же предприятии.
Я не вижу смысла (и не могу) объяснять что-то, чего я не наблюдаю. В компании, где я работаю, ситуация другая.
Что останавливает женщин, которые потенциально могут быть ведущими программистами компаний, но сегодня не работают программистами пойти в программисты
О, множество вещей, вот прямо начиная с общественной позиции "это не женское дело" и распространенного мнения, что женщины худшие программисты, чем мужчины. На следующем месте будут наниматели, которые принципиально не берут женщин на работу, потому что, в числе прочего, женщина может в любой момент уйти в декрет, а зачем им это надо. На этом список не заканчивается, но уже достаточно, в принципе.
(Что характерно, примеры этих позиций сравнительно регулярно встречаются в комментариях на хабре)
muhaa
11.01.2020 02:16+1Я не вижу смысла (и не могу) объяснять что-то, чего я не наблюдаю. В компании, где я работаю, ситуация другая.
Хорошо, принимается. Но я пока такого не видел. Предполагаю, что вы рассматриваете только подмножество программистов, делающих довольно простую и рутинную работу, исключая из выборки тех кто решает действительно сложные задачи. Это подгон под желаемый результат.
О, множество вещей, вот прямо начиная с общественной позиции «это не женское дело» и распространенного мнения, что женщины худшие программисты, чем мужчины.
Не проходит. Через это сито предрассудков первыми на работу должны пробиться одаренные женщины-прирожденные программисты. Женщин со средними способностями прокинут из за предвзятости. И затем мы должны наблюдать картину, когда средняя женщина программист намного круче среднего программиста мужчины (хотя возможно ее никуда особо не пускают). Но это не та картина, которую мы наблюдаем. Нужно другое объяснение.
Lissov
11.01.2020 02:24+1Через это сито предрассудков первыми на работу должны пробиться одаренные женщины-прирожденные программисты.
«одаренный специалист» и «умеет пробиваться через сито предрассудков» это разные скиллы.
Женщин со средними способностями прокинут из за предвзятости.
«Способности» это нечто трудно измеримое, на работу принимают по измеряемой опыту и квалификации. А они не бывает врождёнными, и те кого откинут на нижнем уровне просто не имеют шанса дорасти до верхнего.muhaa
11.01.2020 02:48«одаренный специалист» и «умеет пробиваться через сито предрассудков» это разные скиллы...«Способности» это нечто трудно измеримое, на работу принимают по измеряемой опыту и квалификации.
Не видел такого. Нпример, я после как-то после 3 слов взял на работу программистку без опыта и она до сих пор лучший специалист во отделе (парни приходили и покруче, но больше чем на пол-года не задерживались). Потому что если человек говорит с тобой на одном языке, это сразу понятно независимо от пола и даже опыта. Проблемы предрассудков сильно преувеличены.lair
11.01.2020 03:01+1Не видел такого.
Какого конкретно?
Проблемы предрассудков сильно преувеличены.
Это так кажется, пока эти предрассудки не направлены на вас. А когда ты каждый день слышишь какую-нибудь фразу, которую ничем, кроме предрассудка, объяснить нельзя (и регулярно сталкиваешься с последствиями этих фраз) — так уже не кажется.
0xd34df00d
11.01.2020 17:28Это так кажется, пока эти предрассудки не направлены на вас. А когда ты каждый день слышишь какую-нибудь фразу, которую ничем, кроме предрассудка, объяснить нельзя (и регулярно сталкиваешься с последствиями этих фраз) — так уже не кажется.
Вы так говорите, будто предрассудки — это что-то, что относительно мужчин не бывает.
lair
11.01.2020 17:29Отнюдь. Бывает, и я регулярно с ними сталкиваюсь. Просто многие люди их не замечают (и/или не испытывают от них дискомфорта).
0xd34df00d
11.01.2020 17:34Скорее «не замечают». Я лично почти уверен, что ещё не до конца осознал, насколько я зависим от «мужчина должен» (хотя казалось бы — даже детей кормить не надо).
Интересно, кстати, что когда на этом же хабре в комментах кто-то говорит про неженское дело (как вы абсолютно справедливо вспомнили), то его, гм, не одобряют. Когда кто-то говорит про то, что надо кормить семью, то такого неодобрения нет. Но это так, мысли вслух.
lair
11.01.2020 17:40Скорее «не замечают».
И это лишний раз подтверждает, что проблема предрассудков не преувеличена.
Собственно, ни в оригинальной фразе, ни в моем ответе не было ничего про предрассудки в сторону женщин (или вообще по гендерному признаку).
Когда кто-то говорит про то, что надо кормить семью, то такого неодобрения нет.
Я подозреваю, что от формулировки зависит. Лично меня позиция "давайте платить мужчине больше, ему семью кормить" раздражает не меньше, чем соседняя гендерно-ориентированная. Позиция "давайте платить семейному больше, у него семья" — тоже, как и позиция "людям после X лет надо больше денег, им надо семью кормить". При этом позиция "я хочу больше денег, мне семью кормить" меня лично ничем не раздражает (до тех пор, пока человек не считает, что у него большее право на деньги, чем у конкурента, которому надо кормить не семью, а хобби), потому что каждый сам для себя выбирает свои расходы.
0xd34df00d
11.01.2020 17:42Собственно, ни в оригинальной фразе, ни в моем ответе не было ничего про предрассудки в сторону женщин (или вообще по гендерному признаку).
Я лёгкий намёк на это распарсил в первой фразе из того, что я тогда процитировал: «Это так кажется, пока эти предрассудки не направлены на вас.» Сорян, если вы это не имели в виду.
Я подозреваю, что от формулировки зависит.
Да просто сам факт. Это (и реакция социума) реинфорсит позицию мужчины как добытчика, что мужчинадолжен (в данном случае зарабатывать бабло), не так ли?
lair
11.01.2020 17:47Я лёгкий намёк на это распарсил в первой фразе из того, что я тогда процитировал
Вы распарсили неверно (что, кстати, опять показывает распространенность предрассудков). Но не суть, да.
Это (и реакция социума) реинфорсит позицию мужчины как добытчика, что мужчинадолжен (в данном случае зарабатывать бабло), не так ли?
Если в формулировке упоминается гендер, то да. Но из приведенных мной примеров это есть только в первом, и я сразу явно говорю, что это меня раздражает не меньше любого другого гендерного стереотипа.
0xd34df00d
11.01.2020 17:52Там по полу автора всё видно, плюс по некоторым оценкам гендерного распределения людей на хабре (ну это что касается заплюсованности/незаминусованности соответствующих комментов).
Никогда не встречались с феминистическим мнением, что когда конкретная женщина говорит, что не её дело карьеру строить, а её дело — дом-семья-быт, то, в общем, она поддерживает этим патриархат?
lair
11.01.2020 17:56Там по полу автора всё видно
Эээ… но нет же. Если мужчина пишет "мне семью кормить", это не обязательно значит, что ему кормить семью, потому что он мужчина. А какие еще выводы вы можете сделать из пола автора?
Никогда не встречались с феминистическим мнением
Встречался. Я с каким-то невообразимым количеством мнений встречался, и далеко не со всеми из них согласен, безотносительно привязанного ярлыка.
0xd34df00d
11.01.2020 17:58Ну вот, значит, вы знаете, о чём я говорю. А отсутствие таких же возражений (при наличии аналогичных возражений женщинам про киндер-кирхе-кюхе) — ИМХО ещё один признак предубеждений, просто уровнем выше.
lair
11.01.2020 18:09ИМХО ещё один признак предубеждений, просто уровнем выше.
Так я вроде и писал уже в этой дискуссии, что предубеждения есть у любого человека.
lair
11.01.2020 02:26Предполагаю, что вы рассматриваете только подмножество программистов, делающих довольно простую и рутинную работу, исключая из выборки тех кто решает действительно сложные задачи. Это подгон под желаемый результат.
Ровно наоборот, ваше предположение — это подгонка под тот результат, который вам бы хотелось. И оно неверно: все девушки-программисты, с которыми я контактирую в компании, работают в команде, отвечающей за ядро системы, и там предостаточно "действительно сложных задач".
Через это сито предрассудков первыми на работу должны пробиться одаренные женщины-прирожденные программисты.
Снова нет: мне неизвестно о какой-либо корреляции между способностью к программированию и способности преодолевать общественное сопротивление. Вам известно? Можете показать хорошее исследование?
Женщин со средними способностями прокинут из за предвзятости.
Опять-таки, люди, которые не берут женщин на работу, потому что это женщины, в моем опыте, не смотрят на их квалификацию. Поэтому я нахожу это ваше утверждение безосновательным.
И затем мы должны наблюдать картину, когда средняя женщина программист намного круче среднего программиста мужчины
Я, прямо скажем, не понимаю, как вы оцениваете "средних", и как вы их вообще берете. Зато я могу поделиться тем наблюдением, что в конкретно моей выборке (в конкретных компаниях, опять-таки), худшая женщина-программист была лучше худшего мужчины программиста, причем с хорошим отрывом.
lair
11.01.2020 02:43Необходимая оговорка — я, естественно, сравниваю в рамках сопоставимого опыта: если, грубо говоря, все девушки распределены в опыте 3-15 лет, мужчин с опытом 25-35 мы не рассматриваем.
Почему (в моей нынешней зоне наблюдения) среди разработчиков нет женщин старше — вопрос отдельно интересный, конечно.
muhaa
11.01.2020 03:03И оно неверно: все девушки-программисты, с которыми я контактирую в компании, работают в команде, отвечающей за ядро системы, и там предостаточно «действительно сложных задач».
Если так, это круто и необычно для меня. Возможно я что-то не учитываю в своих выводах.
Снова нет: мне неизвестно о какой-либо корреляции между способностью к программированию и способности преодолевать общественное сопротивление. Вам известно? Можете показать хорошее исследование?
Конечно. Называется «Капитал» К. Маркса. Никакие предрассудки не заставят бизнес закономерно брать слабых женщин вместо умных женщин просто потому, что слабые лучше сумели себя подать.
lair
11.01.2020 03:06+1Называется «Капитал» К. Маркса.
Это не исследование.
просто потому, что слабые лучше сумели себя подать.
Вообще-то, это регулярно происходит безотносительно пола собеседуемого.
Никакие предрассудки не заставят бизнес закономерно брать слабых женщин вместо умных женщин
А я, собственно, нигде и не говорил о том, чтобы брать слабых вместо сильных. Я говорил о том, что не брать вообще. И вот это я видел своими глазами.
muhaa
11.01.2020 03:22А я, собственно, нигде и не говорил о том, чтобы брать слабых вместо сильных. Я говорил о том, что не брать вообще. И вот это я видел своими глазами.
Но этот факт не связан с природной мотивированностью женщин к программированию. Т.е. предрассудки могут существовать как на пустом месте, так и на реальной почве. Для того, чтобы рассматривать природу отдельно а предрассудки отдельно я и предложил сравнивать не количество женщин и мужщин в программировании а средний уровень среди имеющихся. И дальше смотрите про китайцев-индусов и все покругу…lair
11.01.2020 03:27Но этот факт не связан с природной мотивированностью женщин к программированию.
Не связан. Потому что нет никакой "природной мотивированности" к профессиям.
Но. Вы спросили "что останавливает женщин [...] пойти в программисты" — я ответил.
я и предложил сравнивать не количество женщин и мужщин в программировании а средний уровень среди имеющихся
И как вам это поможет оценить мотивированность?
Что еще веселее, как вообще вы предлагаете оценивать (не то что сравнивать) "средний уровень"? Как правильно составить выборку? По какой методике оценивать? Как усреднять?
Если же говорить об обычных человеческих наблюдениях, то мы уже выяснили, что они у нас с вами радикально отличаются, а потому обсуждать их весьма бесполезно.
0xd34df00d
11.01.2020 17:26О, множество вещей, вот прямо начиная с общественной позиции "это не женское дело" и распространенного мнения, что женщины худшие программисты, чем мужчины.
Забавно, что у вашего оппонента отсылки к распространённости вы критикуете, но при этом сами же их делаете.
У вас есть что-то кроме anecdotical evidence?
На следующем месте будут наниматели, которые принципиально не берут женщин на работу, потому что, в числе прочего, женщина может в любой момент уйти в декрет, а зачем им это надо.
Есть работодатели, которые не берут мужчин без военного билета, потому что они могут уйти в армию.
lair
11.01.2020 17:27У вас есть что-то кроме anecdotical evidence?
Лично у меня — нет.
Есть работодатели, которые не берут мужчин без военного билета, потому что они могут уйти в армию.
Есть.
0xd34df00d
11.01.2020 17:31Лично у меня — нет.
Ну, тогда я только могу повторить предыдущую фразу про забавность.
Есть.
То есть, получается, что разницы-то между полами в этом плане и нет? А учитывая, что декрет закон защищает, а уход в армию — нет (за вами не обязаны держать место), и в требованиях к работнику вы можете написать «наличие военного билета», но не можете написать «бесплодность» или, не знаю, «неуход в декрет за всё время работы под угрозой штрафа в 100500 денег», то что ж получается? Получается, что женщинам тут лучше?
lair
11.01.2020 17:35Ну, тогда я только могу повторить предыдущую фразу про забавность.
Я, собственно, с ней и не спорю.
То есть, получается, что разницы-то между полами в этом плане и нет?
Нет, не получается. В моих наблюдениях работодатели, которые не берут мужчин из-за армии, встречаются намного реже чем те, которые не берут женщин из-за декрета.
Получается, что женщинам тут лучше?
Не, не получается. Именно потому, что (в России в этой области) закон смещен в сторону защиты женщин, женщины оказываются менее привлекательными кандидатами для работодателей.
0xd34df00d
11.01.2020 17:40Нет, не получается. В моих наблюдениях работодатели, которые не берут мужчин из-за армии, встречаются намного реже чем те, которые не берут женщин из-за декрета.
А по моим — ровно наоборот.
Именно потому, что (в России в этой области) закон смещен в сторону защиты женщин, женщины оказываются менее привлекательными кандидатами для работодателей.
На закон, я слышал, можно влиять.
Предполагая, что среди женщин есть рациональные агенты, и предполагая, что женщины действительно оказываются менее привлекательными, можно было бы ожидать наличия более-менее выраженных идей типа «а давайте отменим обязательный декрет» или хотя бы «а давайте добавим в ТК возможность прописывать отказ в трудовом договоре от возможности ухода в декретный отпуск».
Однако, мы этого почему-то не наблюдаем.
lair
11.01.2020 17:44А по моим — ровно наоборот.
Вполне возможно.
На закон, я слышал, можно влиять.
Можно.
Однако, мы этого почему-то не наблюдаем.
Что, в частности, может означать, что ваш рациональный подход к проблеме отличается от рационального подхода других людей.
0xd34df00d
11.01.2020 17:50Что, в частности, может означать, что ваш рациональный подход к проблеме отличается от рационального подхода других людей.
Рациональный подход — это такая штука, которая при равных вводных приводит к равному результату.
Так что либо среди женщин нет рациональных агентов (с чем даже последний сексист не согласится, думаю), либо они считают, что профиты от защиты перевешивают недостатки от порождаемой ей непривлекательности.
Либо, конечно, ну вот просто везёт мне не натыкаться на такие мнения, но внутренний Байес говорит, что этим событием можно пренебречь.
lair
11.01.2020 17:52Рациональный подход — это такая штука, которая при равных вводных приводит к равному результату.
Но почему вы думаете, что у вас равные вводные? Одна из проблем общественных начинаний именно в том, что вводные слишком обширны и разнообразны, чтобы различные рациональные агенты опирались на гарантированно один и тот же их набор.
0xd34df00d
11.01.2020 17:54Я исхожу из довольно небольшого множества предположений. Помимо уже упомянутых, например, это и желание быть привлекательным в глазах работодателя и строить карьеру (или что-то такое, лень формулировать формально). Понятно, что если женщинам плевать на карьеру, то от привлекательности будет ни холодно, ни жарко.
lair
11.01.2020 17:56Я исхожу из довольно небольшого множества предположений.
А другие рациональные агенты, возможно, из большего. Поэтому и выработанная стратегия оказывается другой.
0xd34df00d
11.01.2020 17:58Так из какого? Что я упускаю в своих рассуждениях?
lair
11.01.2020 18:10А вот об этом вам лучше поговорить с теми, кто, собственно, вырабатывает стратегию, не совпадающую с вашей. Я могу только строить предположения, первым из которых будет отсутствие веры в реальную возможность влиять на закон.
Lissov
11.01.2020 02:16+2Теперь сравниваем средний уровень китайцев и индусов на рынке.
Это отличный пример, отлично подходящий для женщин тоже. Рассмотрим случаи:
1. Вам пришло 5 резюме, случайным образом все от индусов.
2. Индусы имеют систему образования, комьюнити, наставников у которых можно учиться. 10 пробившихся китайцев всего этого не имели и строят с нуля.
3. Допустим 5% популяции гениальны. А чем заняты остальные 90 китайцев? Есть немалый шанс, что 5 гениальных тоже будут там, а вот те 10 — это самые слабые. А вот 5 гениальных индусов будут программистами.
4. Как сейчас популярно, Вам поставили задачу нанять 22 программиста, и строго 50/50 китайцев и индусов. Вы прособеседовали и выбрали 11 хороших индусов, всех 10 китайцев пришлось взять без отбора, ещё и одного который вообще не умеет программировать.
5. Комбинация 1+2. Соседняя фирма наняла 8 индусов и 8 китайцев, причём китайцев отобрала лучших и платит им немало. Вам осталось выбирать из 92 индусов и 2 китайцев.
6. Физиологический. Представим, что китайцы, отучившись до определённого уровня, обычно на 2 года уезжают в Тибет и забывают о программировании вообще. И повторяют это ещё пару раз. Индусы же продолжают дальше работать и набираться опыта.
Попробуйте оценить видимый средний уровень во всех вариантах.0xd34df00d
11.01.2020 17:36Индусы имеют систему образования, комьюнити, наставников у которых можно учиться. 10 пробившихся китайцев всего этого не имели и строят с нуля.
Тут я потерялся, кто из них — женщины, так как всякие буткампы только для женщин есть, курсы только для женщин есть, и так далее, а аналогичных вещей только для мужчин нет.
Представим, что китайцы, отучившись до определённого уровня, обычно на 2 года уезжают в Тибет и забывают о программировании вообще. И повторяют это ещё пару раз. Индусы же продолжают дальше работать и набираться опыта.
Это всего лишь означает, что китайцам в Тибете интереснее, чем дальше работать.
lair
11.01.2020 17:41Тут я потерялся, кто из них — женщины, так как всякие буткампы только для женщин есть, курсы только для женщин есть, и так далее, а аналогичных вещей только для мужчин нет.
Я подозреваю, что потерялись вы потому, что здесь речь не о том, какое сообщество более ущемлено, а о том, как выборки из разных сообществ по-разному отражают их потенциальные способности.
(это не считая того, что аналогии врут)
0xd34df00d
11.01.2020 17:43Тут я потерялся окончательно, ну и ладно. Аналогии действительно врут, так что фиг с ним.
lair
11.01.2020 17:50Давайте я вам просто напомню исходную формулировку: "Раз людей, любящих бабочек, в программировании мало, значит туда должны попадать самые лучшие и самые мотивированные. Значит в среднем они должны превосходить людей, которые бабочек не любят."
0xd34df00d
11.01.2020 17:55А разве не «раз против людей, любящих бабочек, действует отрицательный отбор, значит…»?
lair
10.01.2020 17:55+2Поэтому случайно он не был нердом.
Случайно. Очень занятно, как наблюдения, которые не вписываются в вашу картину мира, объявляются случайными.
Те кому доверяют отвечать за архитектуру чего-то не совсем ординарного или ее часть как минимум.
Таких, которые при этом не были бы нердами, я знаю больше одного.
Насчет зависимости мотиваций от пола, тут можно приводить тысячу примеров, даже не знаю с чего начать.
Начните хотя бы с одного примера. Пока что вы приводите примеры, в которых собственно мотивации никак не обозначены.
Можете представить, чтобы подобную глупость сделала женщина
Могу. Более того, я пару подобных случаев знаю.
Зачем ей это (откуда такие мотивации)?
А зачем это вам? Я с равным успехом ничего не знаю ни про их, ни про вашу мотивации.
Я вот, скажем, знаю, из каких мотиваций я делаю крупные рефакторинги (наполовину любовь к чистоте, наполовину — понимание, что это упростит дальнейшую работу), и, удивительным образом, коллега, сидящая неподалеку, недавно делала рефакторинг доверенной ей подсистемы из тех же мотиваций.
В чем причина — в гормонах или в воспитании, это более сложный вопрос, который мы тут явно не решим.
… это, однако, не помешало вам уверенно сказать, что мотивации зависят от пола (а не от воспитания).
Atrax
10.01.2020 17:19Любая выборка предвзята, если она берется из личного окружения. Правила репрезентативных выборок в статистике гораздо сложнее.
lair
09.01.2020 22:58ссылается на гипотезу о том, что люди разного пола обладают разными особенностями концентрации внимания.
Это та гипотеза, согласно которой девочки усидчивее и прилежнее?
Считается, что представителям мужского пола легче войти в состояние потока, в то время как женщины более способны к многозадачности.
Ой, нет, все наоборот.
Vilaine
11.01.2020 09:04та гипотеза, согласно которой девочки усидчивее и прилежнее?
А разве второе — не факт? Академический успех, по-моему, и есть оборотная сторона прилежания (при условии равных способностей).lair
11.01.2020 11:59А разве второе — не факт?
В общем случае, насколько мне известно, нет. В каких-то обществах — да, это наблюдаемая разница, но я не видел исследования, которому бы удалось изолировать пол от воспитания.
greck
10.01.2020 00:05Так, я же написал в своем критерии про 18+. Для <18 мой критерий неприменим, для <18 все гораздо сложнее.
muhaa
09.01.2020 13:54Для тех одаренных и умных людей, которые с огорчением поняли, что им не быть программистами:
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Критерий правильный, но многие сейчас частично без этого обходятся. Особенно если программист женского пола.
Если вы не разовьете в себе умение решать проблемы самостоятельно, вам ни за что не стать успешным программистом…
Это справедливо для большей части профессий. Без этого вообще стать кем-то сложно.
Если вы сдаетесь, едва столкнувшись с проблемой, вам ни за что не стать успешным программистом.
Если вы не испытываете чувство восторга и выполненного достижения, когда решили проблему, вам ни за что не стать успешным программистом.
Некоторым радость решенной проблемы заменяет радость получения зарплаты. Это конечно не лучший вариант но тоже работает.
Если вы ощущаете нехватку терпения в учебе и ждете, что вы сможете все освоить легко и быстро, вам ни за что не стать успешным программистом.
Многие люди ненавидят учебу (если говорить о формальном учебном процессе, то у меня это просто фобия). Ничего фатального, можно всему научиться по мере поступления проблем на работе. Непонимание сначала накапливается, потом оно начинает мешать, потом можно почитать книгу на досуге и все недостающее осознать.
Если вы ленитесь думать и вы считаете сконцентрированное размышление скучной рутинной обязанностью, вам не стать успешным программистом…
В целом верно, но в реальности не все так категорично. Среди программистов, как и в других областях, людей, которые предпочитают кодить вместо того чтобы думать хватает. Работа иногда находится и для них.
Если вы ждете, что кто-то будет думать за вас, и не хотите всматриваться в детали своего положения, вам ни за что не стать успешным программистом…
Если вы не очень гибки в своем мышлении и у вас сложности с организацией вашего кода, а также ваших мыслей, вам ни за что не стать успешным программистом.
Вы хотите знать один «правильный» ответ вместо признания спектра «хороших» и «плохих» ответов.
Однозначно это проблема в образе мышления, от которой надо просто избавиться. Здесь дело даже не в программировании. Мне кажется этот образ мышления прививается системой образования, в которой для любой задачи всегда заложен правильный ответ. В реальной жизни наоборот, его никогда нет.
Если вы пренебрегаете деталями и упускаете из вида мелочи, вам ни за что не стать успешным программистом.
Это ерунда. Множество отличных программистов ненавидят детали и делают по 10 ошибок в каждой функции. Для этого есть тесты и дебаггер. Если в код изначально заложена работоспособная концепция, то так или иначе его можно заставить работать при любой ненависти к деталям. Если мозгов на работоспособную концепцию не хватило, внимания к деталям может быть недостаточно.
В целом, чтобы быть программистом нужно иметь мозг, который был бы неплох хотя-бы в одной из сходных с программированием области (математике, технике, естественных науках) и иметь мотивации тренировать этот мозг в направлении программирования.
Задача, которую решает мозг программиста по сути сводится к планированию и описанию того, что должно происходить с детерминированной системой, состоящей из байтов, для достижения заданной цели :). У одних людей мозг лучше приспособлен к этой задаче, у других хуже. И эта способность тренируется в определенных пределах.Atrax
09.01.2020 14:48можно всему научиться по мере поступления проблем на работе
Когда окунаешься, например, в криптографию, становится очень жаль времени, потерянного под девизом "какое отношение алгебра и геометрия имеют к программированию?". Очень распространенный среди "молодняка" клич, которые досконально знают все детали стандартов С++ и не понимают, как находить стратегию игры в простейшие крестики-нолики и при чем тут деревья.
Задача, которую решает мозг программиста по сути сводится к планированию и описанию того, что должно происходить с детерминированной системой, состоящей из байтов, для достижения заданной цели :)
Можно еще проще. "Задача программиста сводится к выборочному намагничиванию быстро вращающихся пластин". С уходом жеских дисков определение, конечно, устаревает, но суть не меняется.
muhaa
09.01.2020 16:01Можно еще проще. «Задача программиста сводится к выборочному намагничиванию быстро вращающихся пластин». С уходом жеских дисков определение, конечно, устаревает, но суть не меняется.
Так можно обозвать программистом любого сколь угодно простого агента. Суть моего определения на самом деле гораздо глубже.
На первый взгляд программирование кажется высоко-интеллектуальной областью, вроде высшей математики или научных исследований. Но с годами начинаешь понимать, что решаешь довольно простую задачу: представить что нужно получить в итоге и найти поведение для компьютера (машины Тьюринга по сути), которое приведет к нужному результату.
Mat1lda
09.01.2020 17:06+1Особенно если программист женского пола.
Почему у всех проблемы с этим то????))))
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Вот прям вижу, как JS-разраб, пилящий на реакте, должен лезть в архитектуру ЭВМ…HackerDelphi
10.01.2020 04:22А вот именно в этом и кроется проблема прожорливости современного софта: «программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно
stilic
10.01.2020 05:11А вот именно в этом и кроется проблема прожорливости современного софта: «программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно
Всё дело только в деньгах.
Бизнесу нужно быстро.
Если мне заплатят в 10 раз больше — я буду сидеть и оптимизировать. Я это люблю.
Но если я буду этим заниматься прямо сейчас — я просто протяну ноги от голода.
khim
10.01.2020 06:51Бизнесу нужно быстро.
Бизнесу — нет. «Эффективным манагерам» — да.tundrawolf_kiba
10.01.2020 18:42Бизнесу все же — да. Бизнесу нужно зарабатывать деньги. Если от неоптимизированности по каким-нибудь техническим характеристикам будет падать доход — бизнес будет давать задачи на оптимизацию, иначе в приоритете оптимизация по скорости разработки.
HackerDelphi
12.01.2020 09:36По моим наблюдениям в те места, где реа т не нужен его тащат «программисты». Более того, бывают случаи, когда все эти фреймворка не нужны, но их тащат. И здесь сказываете именно некомпетентность.
Vilaine
11.01.2020 09:09проблема прожорливости современного софта: «программисты» не знают как устроен компьютер
Условно 99% проблем производительности ПО решаются на уровнях сильно выше hardware. В обычных ЯП этот уровень почти недоступен, а хаки платформы могут привести к деградации в будущем.
Ресурсы, доступные ПО, вроде памяти и вычислительные, не очень связаны с устройством компьютеров и интуитивно известны всем. Их ограниченность просто игнорируют до какого-то момента.
Lure_of_Chaos
11.01.2020 21:07«программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно
Возник вопрос: а как программисту на условном реакте поможет знание архитектуры ЭВМ? Ибо от реакта до железа нагорожена такая туева хуча абстракций, так что, чтобы понять, какой машинный код отдастся на сьедение железу, придется очень хорошо разбираться в устройстве всех этих слоев, а не только нижайшего. А следовательно, почти невозможно, учитывая ограниченность человеческих ресурсов и огромное количество альтернатив…
Откуда я делаю вывод, что такому программисту необходимо лишь среднее понимание принципов устройства того же реакта и знание хороших практик, а с остальным разберется машина (за что спасибо умным и талантливым разработчикам хороших фреймворков, умных компиляторов и т.д.)khim
11.01.2020 22:17Возник вопрос: а как программисту на условном реакте поможет знание архитектуры ЭВМ?
Ну например знание того, что операции со строками занимают время, грубо говоря, пропорциональное длине этих строк — а для целых чисел это не так может помочь и «программисту на условном реакте».
Откуда я делаю вывод, что такому программисту необходимо лишь среднее понимание принципов устройства того же реакта и знание хороших практик, а с остальным разберется машина (за что спасибо умным и талантливым разработчикам хороших фреймворков, умных компиляторов и т.д.)
Никакие, сколь угодно умные и талантливые, разработчики компиляторов и фреймворков не могут изменить законов физики и математики.
С одной стороны вы правы — почти ничего, кроме умения избегать алгоритма маляра Шлемиэля от разработчика в 99% случаев не требуется… с другой — не зная, хотя бы примерно, как «внутри» устроены все эти абстракции — его легко посадить где угодно.
Когда я вижу, что программа добавляет к часовому ролику субтитры за 3 минуты, к двухчасовому — за 12 минут, а к трёхчасовому — почти за полчаса… мне даже не нужно знать сколько там абстракций использовалось в этих фреймворках… я точно знаю, что программист их использовавший некомпетентен — и где-то там внутри сидит очередной «маляр Шлемиэль»…
BugM
12.01.2020 02:05Ну например знание того, что операции со строками занимают время, грубо говоря, пропорциональное длине этих строк — а для целых чисел это не так может помочь и «программисту на условном реакте».
Это любимые всеми алгоритмы. O(n) где n длина строки. И пусть оно хоть на машине тьюринга исполняется. От железа не зависим никак.
С одной стороны вы правы — почти ничего, кроме умения избегать алгоритма маляра Шлемиэля от разработчика в 99% случаев не требуется… с другой — не зная, хотя бы примерно, как «внутри» устроены все эти абстракции — его легко посадить где угодно.
И это тоже обычные аглоритмы. Напиши нормальный алгоритм, и он нормально работать будет. На любой машине.
В итоге пришли к тому что у фронтов тоже надо спрашивать на собеседованиях как развернуть список. Иначе они такого понапишут.HackerDelphi
12.01.2020 09:38Так насколько я понял речь про то, что зачастую выполняют операции со строками, вместо операций с числами.
Dabbuger
09.01.2020 14:06начиная с 4-го пункта всё про меня.
20 лет назад я понял, что не смогу стать программистом хотя и мечтал об этом. Ну, а после этой статьи даже сомнения отбросил )))
markmariner
09.01.2020 14:40Статья не имеет смысла потому, что эти качества невозможно оценить.
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Если мне интересно, как работает компьютер и технологии, но больше меня интересует общение с моей женой и семьёй — это не очень любопытно или уже норм? Если меня интересует больше дизайн или подводное плаванье, но я не хочу этим зарабатывать, то это тоже сразу крест? Что значит «очень любопытно», а что значит «не очень любопытно»?
Если вы не разовьете в себе умение решать проблемы самостоятельно, вам ни за что не стать успешным программистом.
Никто из нас не может решать все проблемы самостоятельно. Лучшие умы говорят, что они пришли к чему-то потому, что основное до них придумали другие. Если я погуглил, прочитал книжку, спросил у коллеги, делегировал задачу и в итоге она решена — считается ли всё это, что я могу решать проблемы самостоятельно?
Если вы сдаетесь, едва столкнувшись с проблемой, вам ни за что не стать успешным программистом.
Как понять, когда пора сдаться потому, что игра не стоит свеч, а когда ты просто рано сдался?
Если вы не испытываете чувство восторга и выполненного достижения, когда решили проблему, вам ни за что не стать успешным программистом.
Если я ошущаю приятное чувство, но это не тот восторг, который был 10 лет назад, то что теперь?
Если вы ощущаете нехватку терпения в учебе и ждете, что вы сможете все освоить легко и быстро, вам ни за что не стать успешным программистом.
Как понять, что такое легко и быстро? Быстро насколько? Если я жду, что разберусь в Питоне за полгода достаточно хорошо для старта — это слишком быстро или нет?
И так далее все пункты.
Проблема же здесь в том, что никто в новой деятельности не чувствует уверенности во всех этих пунктах.muhaa
09.01.2020 16:22Если мне интересно, как работает компьютер и технологии, но больше меня интересует общение с моей женой и семьёй — это не очень любопытно или уже норм?
Тут все понятно. Вы не программист. (шутка)
Никто из нас не может решать все проблемы самостоятельно. Лучшие умы говорят, что они пришли к чему-то потому, что основное до них придумали другие.
Поверьте, эти умы всегда лгут. Подобные вещи говорят чтобы показать скромность, коллективизм и чтобы не замочили раньше времени как безумного одиночку. В наше время кругом интернет и это не так заметно, но в 90-е когда я начинал программировать совершенно нормально было сначала изобрести концепцию (вплоть до ООП), а потом про нее прочитать. Не говоря уже о банальном решении любой мыслимой задачи самостоятельно (решения конечно были страшными временами). Те у кого нет такого свойства могут быть программистами конечно тоже, но это однозначно минус.
stilic
09.01.2020 14:45Все упомянутые автором признаки можно для инженерной профессии (да и не только инженерной) приложить.
И вывод будет тот же — «если вам не интересна ваша профессия, то вы будете в профессии весьма посредственным специалистом».
rsync
09.01.2020 15:18> Вот, что я понял, наблюдая со стороны: студенты, имеющие предпринимательскую жилку, часто более сосредоточены на результате, чем на процессе. Они хотят получить «рабочее приложение», которое позволит им продвинуться дальше с их бизнес-идеей, они хотят «сначала выйти на рынок» и видят длительное обучение как барьер на пути к их цели — запуску их бизнеса.
это недостаток? барьер на пути к программисту?
по моему так наоборот.
Поручаешь человеку 2*2. Отходишь от него, поскольку задача простая.
Возвращаешься
— закончил?
— нет еще!
— в чем трудности?
— трудностей нет, просто пока успел сделать только фабрику классов, а к собственно задаче только подбираюсь
— зачем тут фабрика классов?
— ну вдруг потребуется потом 2 * 3 или 2! так с фабрикой я их быстро сделаю
Поручаешь другому человеку 2 * 2
еще не успел отойти от него а уже 1+1+1+1=4. Не совсем правильно. Методически криво… Но работает. И тестами обложено.
Вот из таких получаются хорошие программисты. Когда надо будет — он разберется с операцией умножения. А сейчас уже он задачу решил.Atrax
09.01.2020 15:54+1Вот из таких получаются хорошие программисты. Когда надо будет — он разберется с операцией умножения. А сейчас уже он задачу решил.
Да не будет он разбираться с операцией умножения. Потому, что его "горизонт событий" не выходит за пределы задачи. А вот сменить "вселенский масштаб" первого разработчика сильно проще — очерчиваешь ему границу всего проекта и… у тебя уже "полуфабрикат тимлида", который вместе с архитектором сможет весь проект вытянуть быстрее, чем архитектор с кучей "быстрых рук", которые без внимания на минуту не оставить.
Но это каждый выбирает сам, с кем работать.
rsync
09.01.2020 16:07-1два программиста пишут код
у обоих задача решена, какой из программистов написал лучший код?
мой критерий такой:
1. при прочих равных тот у кого больше покрытие тестами (говнокод, хорошо покрытый тестами — поддаётся рефакторингу. Идеальный код не покрытый тестами к рефакторингу не готов)
2. при прочих равных и с учетом пункта 1 — тот который содержит меньше строк кода. в нем легче разобраться.
> А вот сменить «вселенский масштаб» первого разработчика сильно проще
я вот как руководитель иногда не могу это преодолеть.
приходится увольнять.mayorovp
09.01.2020 16:11При смене архитектуры модульные тесты не всегда спасают. Часто даже мешают. Так что расширяемость архитектуры тоже важна.
khim
09.01.2020 16:51Есть лакмусовая бумажка: если вам нужно будет «расширять архитектуру» (скажем добавить поддержку Windows или PostgreSQL) — поговорите с тем, кто будет это реально делать. Если такого человека ещё нет — забейте. YAGNI: пока у вас нет пользователей понять — правильно ли вы что-то спроектировали всё равно невозможно. А вот когда пользователи появятся — тогда и начинайте думать.
Единственный случай когда расширение происходит «без сучка и задоринки» — это когда вы делаете «базовую версию» и вы же её потом «расширяете». Если «расширяет» кто-то другой — уже нужно говорить с ним и приходить к компромиссам, а если «расширять» будет неизвестно кто — то с вероятностью 90% ваш «задел» придётся сначала «извести под корень», а уже потом всё сделать «правильно» — так, чтобы не было протягивания силовых проводов через канализацию…mayorovp
09.01.2020 17:10Я говорю не про оставление "заделов", а про неоставление "граблей".
khim
09.01.2020 18:09Ну грабли тоже разные бывает. У меня, скажем, в коде есть место, где используется алгоритм сложностью аж в целых O(N?) — притом, что, если дописать ещё тыщёнку строк кода можно обойтись O(N).
Почему нет «задела» и «оставлены грабли»? Потому что N, в данном случае — это количество регистровых аргументов у инструкции. И оно как бы равно 3 у 80386, а у процессоров с FMA4 — оно равно 5… думаю что процессоров с N == 6 мы не увидим никогда.
Это «задел» или «грабли»? Вот как вы оцениваете?mayorovp
09.01.2020 18:53Я это оцениваю как изолированный кусок кода, который в случае чего можно без проблем заменить. Граблями он станет если перестанет быть куском кода, а будет перемешан с другими алгоритмами и размазан по всей программе.
khim
09.01.2020 19:05Он довольно-таки много с чем «перемешан». И если, вдруг, в x86 появятся 7-аргументные инструкции, то всё придётся переделывать (6-аргументные потребуют десятков гигабайт памяти при компиляции, но «со скрипом» должны пролезть).
Однако мой опыт подсказывает, что шансов на то, что нам придётся переделывать потому что, скажем, индустрия перейдёт на какой-нибудь RISC-V — гораздо больше.
khim
09.01.2020 16:43+2Не понимаю откуда у всех такое патологическая увлечённость «покрытием тестами» и «рефакторингу».
В конечном итоге вам же платят не за то, чтобы двигать сущности по кругу из одного класса в другой, а за то, чтобы написать работающий код!
Я вообще скептически отношусь к юниттестам (хотя уважаю функциюнальные, проверяющие что достаточно большой компонент в целом работоспособен) — по моему опыту затраты на их поддержание себя не окупают.rsync
09.01.2020 17:02код который используется бизнесом или обязан развиваться или его бизнес закапывает, потому что «переходит на другое решение».
не бывает бизнесов работающих на коде который не развивается.
а развитие это всегда и рефакторинг
а рефакторинг и развитие на коде без тестов становятся очень и очень дороги
вот например помните ICQ?
Aol, миллиардные бюджеты.
почему ICQ помер? Skype смог сделать голосовые звонки. неужели к ICQ с миллиардами прибылей нельзя было их приделать?
можно, но в свой код они не могли оперативно вносить изменения и… потому проиграли
а дальше Skype. Его сильно подвинули Viber и Watsapp. почему?
потому что выдали мобильного клиента. неужели Skype с его миллиардными бюджетами не мог оперативно сделать мобильного клиента?
они в свой код не могли оперативно вносить изменения… и потому проиграли.0xd34df00d
09.01.2020 17:55+1Лучше писать на тех языках, где типизация избавляет от потребности в юнит-тестах.
rsync
09.01.2020 18:151. типизация не избавляет от потребности юниттестирования
2. юниттестирование — лишь малая часть тестирования. Очень мало функций которые можно тестировать изолировано от например баз данных
3. если говорить о вебе, то типизация в скриптовых языках — следствие плохого дизайна языков0xd34df00d
09.01.2020 19:10Дисклеймер: я работаю не в области веба и почти не сталкиваюсь с языками, где типизация добавлена «потом».
Так вот, по личному опыту типизация избавляет. Особенно вот прям если конкретно говорить о рефакторинге. Начинаешь что-то менять, избавляешься от ругани тайпчекера — а все интеграционные тесты сразу зелёные.
khim
09.01.2020 18:20+1не бывает бизнесов работающих на коде который не развивается.
Бывает. У какой-нибудь dmallocа последний commit — был несколько лет назад. Что не мешает миллиардам людей и кучей бизнесов его использовать.
неужели к ICQ с миллиардами прибылей нельзя было их приделать?
«Приделать» можно было. Сделать так как в Skype (который мог «через машину соседа» в Internet выходить — нет). Кстати современный Skype тоже так не умеет.
можно, но в свой код они не могли оперативно вносить изменения и… потому проиграли
Вы, наверное, из какой-то другой, параллельной, вселенной. Потому что как раз в нашей — ICQ постоянно вносила в свой клиент какие-то идиотские изменения. Боролась со сторонними клиентами. А вот сделать что-то фундаментально новое — нет, не могли. Для этого ведь одних unit-тестов недостаточно.
потому что выдали мобильного клиента. неужели Skype с его миллиардными бюджетами не мог оперативно сделать мобильного клиента?
Не мог. Потому что фишка WhatsApp была в том, что он использовал очень простой и лёгкий протокол — а у Skype всё было совсем не так… а платили тогда за каждый байт.
Ну и главное — WhatApp был завязан на телефонные номера, а Skype нужно было что-то делать с пользователями, у которых телефонных номеров не было.
они в свой код не могли оперативно вносить изменения… и потому проиграли.
Вот как раз бессмысленные изменения, типа тех, которые позволяет делать постоянный бессмысленный рефакторинг с юнит-тестами, они могли делать — и делали.
А чего они не могли делать — так это вносить изменения, затрагивающие всю инфраструктуру. И не могли они этого сделать, в частности, потому что от этого посыпались бы все их юниттесты, где были «зашиты» все эти ожидания.rsync
09.01.2020 18:42> Бывает. У какой-нибудь dmallocа последний commit — был несколько лет назад. Что не мешает миллиардам людей и кучей бизнесов его использовать.
malloc — одна лишь небольшая частичка, кирпичик.
это не бизнес.
так-то и quicksort годами не меняется.
я не об этом.
я о коде который пишет программист на работе
> «Приделать» можно было. Сделать так как в Skype (который мог «через машину соседа» в Internet выходить — нет).
вот в чем причина этого «нет»? только в том что кодовая база пребывала в таком состоянии что «нет»
а почему?
а потому что
1. тестов нет
2. бизнеспроцесс вследствие 1 так построен что внедрение новых фень очень длительно и муторно
а так ICQ были лидерами рынка, им надо было всего-то навсего побарахтать руками и остаться на плаву.
> Вы, наверное, из какой-то другой, параллельной, вселенной. Потому что как раз в нашей — ICQ постоянно вносила в свой клиент какие-то идиотские изменения.
здесь требовались изменения в dataflow и протокол.
а изменения в раскраску контактов в списке — это так, косметика
> Ну и главное — WhatApp был завязан на телефонные номера, а Skype нужно было что-то делать с пользователями, у которых телефонных номеров не было.
ватсапп победил потому что у него был мобильный клиент, а у скайпа мобильного клиента не было.
> А чего они не могли делать — так это вносить изменения, затрагивающие всю инфраструктуру.
при наличии тестов/CI изменения затрагивающие всю инфраструктуру возможны
при отсутствии тестов/CI в большом проекте неизбежно присутствует множество мест вида «это писалось давно уволившимся гуру, чтобы вносить сюда изменения надо понять как это работает».
А внесение изменений — всегда вероятность ошибок.
а тесты — это способ работы с этой вероятностью.khim
09.01.2020 19:30я о коде который пишет программист на работе
А dmalloc и quicksort кто пишет? Не программист? Эльфы?
И не надо говорить, что malloc написан раз и навсегда: мы свой собственный аллокатор писали как раз месяц назад (почему и зачем — отдельный вопрос… но от malloc'а нам пришлось отказаться).
В том, что у них были договора с разными компаниями, которые не позволяли этого сделать. Вплоть до того, что одно время GMail позволял общаться в чате с пользователями ICQ. И это им казалось более важным, чем обеспечение качественных голосовых звонков.> «Приделать» можно было. Сделать так как в Skype (который мог «через машину соседа» в Internet выходить — нет).
вот в чем причина этого «нет»
только в том что кодовая база пребывала в таком состоянии что «нет»
Да не в кодовой базе там было дело.
Я вообще на вас удивляюсь — вы, с одной стороны, рассказываете сказки про потребности бизнеса, а с другой — делаете вид, что модификация кода может быть ограничена только кодовой базой, а не чем-то ещё.
Создаётся ощущение что и программировании и о бизнесе у вас очень поверхностное понятие…
а так ICQ были лидерами рынка, им надо было всего-то навсего побарахтать руками и остаться на плаву.
Уууу… как всё запущено. Барахтать руками — за чей счёт, извините? Вы не в курсе, что с 1998го года ICQ принадлежала AOL? И что задачей программистов была не борьба со Skype, а интеграция с AIM и популяризация сервисов собственно AOL?
В том-то и дело, что проблема ICQ — была не в коде (его можно было переписать несколько раз легко… что, на самом деле, и было проделано), а в неверных бизнес-решениях. Никакого отношения к качеству кода не имевших.
здесь требовались изменения в dataflow и протокол.
Здесь требовались изменения в бизнес-модель, прежде всего. А как раз протокол ICQ меняла и не раз и не два.
ватсапп победил потому что у него был мобильный клиент, а у скайпа мобильного клиента не было.
Вот только не нужно сказок, а? Был у Skype мобильный клиент. И на iOS был. И на Android был. И на Symbian был. И даже на PSP был и на всякой экзотике типа N9. И даже специальные телефоны «под Skype» делали.
Однако проблема была в том, что для того, чтобы общаться через Skype вам нужно было знать как выглядит аккаунт вашего собеседника… а в WhatsApp — нет. Потому появившийся позже WhatsApp рос гораздо быстрее Skype. Но поскольку Microsoft хотел использовать Skype как способ убедить всех использовать Microsoft-аккаунт… идея использовать просто номер телефона — ему не понравилась. Та же самая история была у Google и Google Hangouts…
Опять-таки: проблема не в коде, проблема в бизнес-модели.
а тесты — это способ работы с этой вероятностью.
Вот только для внесения изменений нужны мозги в первую очередь, а тесты — это уже «рюшечки».
vorput
10.01.2020 12:13+3говнокод, хорошо покрытый тестами — поддаётся рефакторингу. Идеальный код не покрытый тестами к рефакторингу не готов
Весьма странное утверждение, чтобы не сказать больше… Довелось мне как-то поработать с индийскими вьюношами — постградами (но американских колледжей): хитропопые молодые люди, при всей своей бесталанности и лени, прекрасно освоили «правила игры» в scrum. Говнокод, который они регулярно «выдавали на гора», зачастую не решал проблем и не закрывал issue (хотя они утверждали обратное, естественно — но не пользователи :D ), зато был покрыт бессмысленными юнит-тестами (грубо говоря, подтверждающих, что 2+2 всегда равно 4, а errorMessage всегда будет содержать слово «Error»). Поскольку эти, якобы resolved issues, приходилось переоткрывать на следующих спринтах как «новые», то scrum master был в общем доволен автоматически собираемой статистикой: 100% покрытие юнит тестами, sprint velocity держался на высоком уровне, в общем, графики были красивые.
Только вот «индусский» (условно, так как все они были американскими гражданами и родились в США — от пап-мам индусских H1Bшников) говнокод на, в общем-то, не такой уж сложной задаче, ухитрялся «ронять» Google Chrome по memory overflow (больше такого я нигде не видел!), и периодически «доставал» кастомеров медлительностью и забагованностью.
Рефакторить то, что данные вьюноши наваяли, было бессмысленно — их нужно было выгнать, и переписать все с 0, начиная с архитектуры. Но… Насколько мне известно, воз и ныне там, бывшие пост-грады говнокодеры превратились ныне, небось, в «сеньоров»-говнокодеров. Последнего investment им хватит еще на год-два, так что «работа идет, контора пишет».rsync
10.01.2020 12:45+1вот еще признак плохого программиста — утверждение "тут надо переписывать с нуля"
khim
10.01.2020 17:20+2Это скорее вопрос опыта. Мне не один год потребовался, чтобы научиться «переписывать с нуля, изменяя по 100 строк кода за раз».
Это, как ни удивительно, почти всегда возможно (если не учитывать того, что иногда, на завершающих этапах получается так, что вы добавляете 100 строк, а удаляете 5000), но требует зачастую ещё больше усилий, чем переписывание всего с нуля… но оно того стоит.
Дело в том, что переписывание с нуля вы не можете остановить и «быстренько закрыть issue» — потому бизнес и ненавидит подобные идеи.
А вот «переписывание с нуля по 100 строк за раз» — остановить можно. Да, это немного снизит темп (и сделает переписывание ещё дороже), но зато ваш заказчик не будет «сосать лапу» пока вы всё переписываете, а вам не придётся сидеть ночами, чтобы успеть всё закончить до тех пор, пока всю вашу деятельность не решат выкинуть нафиг…dzsysop
10.01.2020 17:29Мне не один год потребовался, чтобы научиться «переписывать с нуля, изменяя по 100 строк кода за раз».
То что вы описываете это не переписывание с нуля. Это правильный процесс регулярного рефакторинга и переход на новые рельсы. Это действительно возможно и эффективно и доступно классным спецам.
Но бизнес почему-то больше любит обещателей «мы перепишем все полностью с нуля». Никто из менеджеров почему-то не верит в эффективный и полный рефакторинг за год, но почему-то многие верят в переписывание с нуля за тот же период.khim
11.01.2020 18:11+1Но бизнес почему-то больше любит обещателей «мы перепишем все полностью с нуля».
Бизнес? Нормальный бизнес их ненавидит всеми фибрами души. Ну вот как тут.
Никто из менеджеров почему-то не верит в эффективный и полный рефакторинг за год, но почему-то многие верят в переписывание с нуля за тот же период.
Ну дык тут как раз всё логично. Эффективность манагера ведь не то же самое, что эффективность фирмы. Он ведь своими деньгами не рискует. Соответственно подход, который с вероятностью 90% приведёт к краху, но с вероятностью 10% приведёт к гигантским бонусам — для него предпочтительнее, чем подход, который с вероятностью 90% принесёт небольшой доход, а с вероятностью 10% — не сделает ничего.
vorput
10.01.2020 17:22Собеседование с вами у меня бы заняло время ровно до вашей фразы про говнокод со 100% покрытием юнит-тестами. И я бы даже не стал вам врать, что «мы вам перезвоним».
P.S. И еще мне почему-то кажется, что у вас не профиля на гитхабе…
niksite
10.01.2020 22:08Если "покрыто тестами" означает не "говнотесты для coverage на отвяжись", а нормальные функциональные тесты, покрывающие требования заказчика, то покрытый ими говнокод таки да — имеет большую maintainability и business value. Его всегда можно будет переписать, если клиент того пожелает. В отличии от гениального кода без тестов.
rsync
10.01.2020 22:29+1именно это я и имел ввиду :)
ревьювим мы например ручку http
смотрим в тесты
варианты вызывающие ошибки есть?
варианты с неверными форматами значений есть?
варианты штатной работы тестируются? все?
если ответы на все вопросы "да"
то в тело ручки можно и не смотреть
разве что заглянуть в то какие запросы к БД она делает
внутри хоть ORM наговнокоден, пофиг
Atrax
10.01.2020 17:36У нас с вами разный опыт, видимо. Мне действительно проще поднять команду от клавиатуры до понимания проекта. Объяснять уже в процессе приходится сильно меньше. Особенно в тех кошмарах, которые начинаются "нада прям вот щас" с ТЗ в стиле "сделайте круто, вы же умеете". И да, я не руковожу проектами и не решаю вопросы "как правильно работать". Я архитектор и работаю в заданных условиях. Реальный мир, к сожалению, далек от радужных пони из псевдокитайских коанов о программировании.
Whuthering
09.01.2020 16:56+1Реальность, увы, такова, что те, у кого 1+1+1+1=4, тесты обычно тоже не пишут.
0xd34df00d
09.01.2020 17:55Мне куда интереснее, что тут можно тестами обкладывать.
niksite
10.01.2020 22:14Критерии приемки как минимум.
Если стоит таска "сделать программу что принимает на вход 2+2 и выдает на выходе 4", то так и писать "assert call ('2+2') == '4'". Тем самым гарантируя что и после сотни рефакторингов эта программа все ещё будет представлять заявленную функциональность.
olsamurai
09.01.2020 17:45+1Скажем так, это у вас в распоряжении дав программиста: академический и говнокодер. Первый конечно будет по началу ко всему подходить с размахом. Но преимущество в том, что он многое знает, просто применяет не все к месту. Этому можно научить достаточно легко. Второй же, скорее всего знает очень мало и его доучить будет стоить титанических усилий! Как пример, первый умеет работать и молотком, и дрелью, и пилой, и отверткой. Второй только молотком. Так вот, второй и шуруп вам забъет, и и дырку под дюбель выдолбит (немно эпокситки и будет все в порядке). А вот стул он вам сделает… я бы на него не садился…
rsync
09.01.2020 17:48-1Вы плохо прочитали.
я говорил о программистах пишущих тесты.
(все прочие — не программисты, вообще-то)
olsamurai
09.01.2020 18:10Ну во первых вы так быстро оцениваете людей… Собеседования проводите? Когда я начинал 28 лет назад, не было концептов тестов, фреймворков, юниттестов, моков и прочего. Мы тогда просто «тестили». Тестами покрывать хорошо атомарные действия и функции. Я писал не так давно систему визуального тестирования полного процесса. Готовая не подошла по многим причинам. Это такое, что врагу не пожелаешь. Вам там говнокодер так все покроет, что только держись. На ее поддержание уходит куча времени! И в конечном итоге процентов 10 все равно нельзя однозначно протестировать. Как говорил мой учитель (по жизни): надо сначала подумать, потом написать, а потом протестировать. Писать и тестровать, не думая, займет куда больше времени.
khim
09.01.2020 18:23Писать и тестровать, не думая, займет куда больше времени.
Золотые слова. Но судя по реакции собеседника на предложение писать код так, чтобы неправильных код просто не скомпилировался… вы с ним вообще с разных планет, а то и из разных миров.
olsamurai
09.01.2020 18:41Если вы имеете ввиду его: 0xd34df00d, то это единственный пользователь на которого я подписан. И умение писать им код на с++ может вызывать только «уважуху»! Хотя во многих других вопросах я с ним не согласен ;)
khim
09.01.2020 18:47Нет, я про реакцию на это предложение от rsync.
Который, похоже, не понимает ни как использовать типы для замены unittest'ов (что, на самом деле, всегда возможно, однако не всегда желательно), ни почему люди пытаются добавить типы в скриптовые языки… такая себе проекция карго-культа, которым он овладел «в совершенстве» на весь мир…rsync
09.01.2020 19:11-1Который, похоже, не понимает ни как использовать типы для замены unittest'ов
я действительно не понимаю как типы могут заменить тесты
Как типы помогут определить что эта функция написана с ошибкой?:
int sum(int a, int b) { return a - b; }
как тесты могут выявить здесь ошибку — очевидно:
tap.eq(sum(2, 2), 4, "2 + 2 == 4");
ни почему люди пытаются добавить типы в скриптовые языки
люди пытаются добавить типы в скриптовые языки из за… однажды совершенной глупости.
глупость состоит в неправильном применении оператора "+". Отсюда всё и растёт
типы добавляют из за того что пытаются исправить вот эту глупость
$ node > '2' + 2 '22' > '2' - 2 0
при этом пытаются исправить не саму глупость, а последствия глупости
0xd34df00d
09.01.2020 19:28Как типы помогут определить что эта функция написана с ошибкой?
Нуу… Мне нужно будет написать две функции с типами
sum_left_0 : (x : Int) -> sum 0 x = x sum_right_0 : (x : Int) -> sum x 0 = x
Написать вторую у меня получится, а первую — нет. Тут-то типы мне и помогут.
как тесты могут выявить здесь ошибку — очевидно:
tap.eq(sum(2, 2), 4, "2 + 2 == 4");Хаха, отличный пример!
Как этот тест поможет поймать функцию, которая вместо сложения выполняет умножение?
rsync
09.01.2020 19:34Нуу… Мне нужно будет написать две функции с типами
смотрите:
- вы удвоили число кода
- вы не решили вопрос того чтобы ваши типы находили Вам ошибки
- если вы это же избыточное число кода написали бы в тест, то ситуация была бы много лучше.
Как этот тест поможет поймать функцию, которая вместо сложения выполняет умножение?
дык второй тест:
tap.eq(sum(3, 3), 6, "3 + 3 == 6");
и вот Вы уже уверены что функция складывает.
если уверенности всё еще нет пишете еще один
tap.eq(sum(17, 3), 20, "17 + 3 == 20");0xd34df00d
09.01.2020 19:39+1вы удвоили число кода
А когда вы пишете тесты, то вы не увеличиваете объём кода?
вы не решили вопрос того чтобы ваши типы находили Вам ошибки
Почему? Тут именно типы ошибки мне и нашли (вернее, нашли несоответствие написанной функции спеке, которую мы держим в голове о том, что такое сумма двух чисел).
если вы это же избыточное число кода написали бы в тест, то ситуация была бы много лучше.
Как тест может проверить выражение с квантором всеобщности?
и вот Вы уже уверены что функция складывает.
Нет, не уверен. Вдруг она первый аргумент складывает сама с собой, а второй вообще игнорирует?
если уверенности всё еще нет пишете еще один
А если всё ещё нет? Как вы понимаете, когда пора остановиться?
Вдруг я начал с теста «3 + 3 = 6» и потом добавил к нему тест «17 + 3 = 20». Как это защитит от функции, которая просто прибавляет 3 к первому аргументу?
rsync
09.01.2020 19:48А когда вы пишете тесты, то вы не увеличиваете объём кода?
в продакшене у меня работает мало кода. У Вас — вдвое больше.
а код в тестах = воспомогательный на стадии разработки.
пользователям он не нужен. А Вы пользователю навялили вдвое больше кода.
:)
Как тест может проверить выражение с квантором всеобщности?
если любой подход доводить до абсолюта — получится абсолютная глупость.
но вернёмся к типам:
типы не решают проблем нахождения ошибок в алгоритме.
вот у Вас есть функция
void sort_int(size_t count, int *elements) { ... }
Как при помощи ваших типов найти в ней ошибки?
Нет, не уверен. Вдруг она первый аргумент складывает сама с собой, а второй вообще игнорирует?
не уверены — добавляете тесты в тестовую кодобазу.
до тех пор пока уверенность не появится.
когда другой программист будет редактировать Ваш код и накосячит, тестовая кодобаза ему об этом сообщит.
0xd34df00d
09.01.2020 20:01в продакшене у меня работает мало кода. У Вас — вдвое больше.
Этот код не работает в продакшене. Он даже не попадает в итоговый бинарь. Тут главное — чтобы тайпчекер его проверил, после чего тайпчекер его выкидывает.
И это, кстати, одна из причин, почему external verification я люблю больше, чем internal — не нужно думать о том, что пруфтермы протекут в рантайм, как здесь.
Кстати, как вы напишете тест, что какая-нибудь ваша хитрая функция всегда завершается?
Как при помощи ваших типов найти в ней ошибки?
Вы просто пишете тип, что функция должна возвращать сортированный список. Например — там кода чуть больше, чем нужно для этой задачи, но мне было интересно сделать это с нуля из самообразовательных целей, а не имеющимися средствами.
не уверены — добавляете тесты в тестовую кодобазу.
до тех пор пока уверенность не появится.Я не далее как вчера доказывал корректность одной функции преобразования ручк
амиой на бумажке (так как писал на C++) — у неё, к счастью, при определенной подмене параметров получается обратная, и я доказал для себя соответствующую теорему. Как это записать в тестах, непонятно.rsync
09.01.2020 20:54Этот код не работает в продакшене. Он даже не попадает в итоговый бинарь. Тут главное — чтобы тайпчекер его проверил, после чего тайпчекер его выкидывает.
то есть цель написания кода чтоб тайпчекер его выбросил?
ну вот, а я всегда писал код чтоб решить бизнес задачу. вот в этом наше с Вами отличие :)
Кстати, как вы напишете тест, что какая-нибудь ваша хитрая функция всегда завершается?
man alarm
Как это записать в тестах, непонятно.
так же как с sum выше: взять и набрать достаточно большую (уверенность!) таблицу вход-выход
мы с Вами пришли выше к трем значениям по sum, но можно же взять и 333
0xd34df00d
09.01.2020 20:58то есть цель написания кода чтоб тайпчекер его выбросил?
Цель написания кода — чтобы тайпчекер его проверил. Выкидывание после проверки (как и удаление типов после проверки, чтобы в рантайме с сырыми байтиками оперировать и не тратить время) — желательное свойство, но не основная цель.
ну вот, а я всегда писал код чтоб решить бизнес задачу. вот в этом наше с Вами отличие :)
Но тесты у вас точно так же в проде не работают.
man alarm
Удобно-то как. В прод тоже так пойдёт?
так же как с sum выше: взять и набрать достаточно большую (уверенность!) таблицу вход-выход
Я никогда не мог понять, что значит «достаточно». В тепле, сухости и безопасности я чувствую себя только после написания доказательства.
rsync
09.01.2020 21:24Цель написания кода — чтобы тайпчекер его проверил.
нельзя подменять цели и средства. Проверка кода тайпчекером — средство (не цель!) которое выявит определённый класс ошибок. и только.
причём бОльшая часть возможных ошибок в этом классе происходит исключительно из за ошибок дизайна операторов сравнения и арифметики (использование операторов не по назначению):
пример некорректного дизайна оператора +:
a = 'hello '; b = 'world'; console.log(a + b);
Удобно-то как. В прод тоже так пойдёт?
если в проде есть вероятность зацикливания, то и в прод такое можно.
Есть обширный класс задач принципиально не имеющих решения за конечное время.
Вы не писали скажем алгоритм вероятностного градиентного спуска?
Я никогда не мог понять, что значит «достаточно».
Достаточно это достаточно.
Если Вам не понятно это то я тут не могу помочь. Разве что примеров набросать.
Вы ловите рыбу. 1-2-10. В какой-то момент Вы понимаете что рыбы уже много и Вам её не съесть, пропадёт. Рыбы — достаточно. Больше ловить не стоит.
Вы едите рыбу. В какой-то момент наступает насыщение. Вы поели достаточно. Больше есть не стоит.
Вы пишете тесты. В какой-то момент Вам очевидно что все закоулки Вашей программы тестами покрыты. Тестов достаточно. Больше писать не стоит.
0xd34df00d
09.01.2020 21:36нельзя подменять цели и средства. Проверка кода тайпчекером — средство (не цель!) которое выявит определённый класс ошибок. и только.
Я о том коде, который предназначен для тайпчекера, и который нужен только тайпчекеру.
А что до классов — так вроде мы ж с этим уже разобрались, разве нет? Типы позволяют проверить, что сортировка работает корректно и всегда, для любых типов с подходящей операцией сравнения, а не только для десятка выбранных случаев строк или интов, условно.
Более того, вот эта вся ерунда позволяет находить ошибки в спеках. Я сначала случайно написал функцию нахождения НОД как принимающую два неотрицательных числа, и, в общем, когда у меня не получилось что-то доказать про наибольший общий делитель нуля и нуля, я понял, в чём проблема. Тесты бы не помогли найти такое вообще никогда.
если в проде есть вероятность зацикливания, то и в прод такое можно.
Но в проде уже поздно делать проверки. Проверки лучше делать до прода.
Есть обширный класс задач принципиально не имеющих решения за конечное время.
Их не так много, как может показаться.
Вы не писали скажем алгоритм вероятностного градиентного спуска?
Для, например, неотрицательной (или, более общо, ограниченной снизу) loss function он очевидно завершим.
Вы пишете тесты. В какой-то момент Вам очевидно что все закоулки Вашей программы тестами покрыты. Тестов достаточно. Больше писать не стоит.
Если я не доверяю себе в написании программы, то почему я доверяю себе в написании тестов (что, похоже, по меньшей мере так же сложно, учитывая, что писать тесты правильно и в нужном объёме нетривиально, люди там ещё мутационное тестирование потом вспоминают, ещё всякую ерунду для тестов тестов)?
rsync
09.01.2020 21:48Если я не доверяю себе в написании программы
тесты — это способ проверки не только себя, но и программиста который будет рефакторить Ваш код после Вас.
в математике (из которой Вы примеры приводите) многие валидные операции могут быть неинтересны бизнесу. И наоборот.
Бизнес может захотеть чтобы 25 разделить на ноль было ноль. Или чтобы НОД нуля был 42. И программист пойдёт вставлять в Ваш код if с исключительным случаем.
Он должен как-то убедиться что не сломал все прочие случаи.
А Вы тесты не написали.
Абзац. Руководитель проекта принимает решение выбросить весь код на помойку целиком.
Вот так вот и выбрасываются на помойку такие монстры как ICQ
0xd34df00d
09.01.2020 21:58Бизнес может захотеть чтобы 25 разделить на ноль было ноль. Или чтобы НОД нуля был 42. И программист пойдёт вставлять в Ваш код if с исключительным случаем.
Может, мне с бизнесами везло, но вот почему-то ни разу таких ситуаций не было.
rsync
09.01.2020 22:24+1
Может, мне с бизнесами везло, но вот почему-то ни разу таких ситуаций не было.
в бухгалтерии, строительстве итп таких задач полно
есть коэффициенты A / B
если B = 0 то и результат считается 0 равен при любом значении A.
Вы так часто и с такой уверенностью поминаете ICQ
ICQ, Skype, etc — примеры бизнесов вытесненных ТОЧНО ТАКИМИ ЖЕ бизнесами с одной дополнительной фичей.
что-то мешало внедрить эту одну фичу в проект?
отсутствия денег не было, бюджеты миллиардные. Ан нет — разорились/проданы/потеряли всех клиентов.
Почему? Задача оказалось не по плечу. Все другие объяснения нахожу менее разумными.
0xd34df00d
09.01.2020 22:41если B = 0 то и результат считается 0 равен при любом значении A.
Замечательно. Значит, у вас будет
safeDiv : Rational -> Rational -> Rational
для которой будет выполняться, например,
safeDiv_nonzero : (m, n : Rational) -> Not (n = 0) -> (m `safeDiv` n) * n = m safeDiv_zero : (m : Rational) -> (m `safeDiv` 0) = 0
(бумбурум зделой хайлайтинг для идриса)
Потом ещё можно написать вещи типа
safeDiv_mult : (m, d1, d2 : Rational) -> Not (d1 = 0) -> Not (d2 = 0) -> (m1 `safeDiv` d1) `safeDiv` d2 = m `safeDiv` (d1 * d2)
и любые другие интересные вам утверждения.
А можно, например, вообще ограничиться постулированием, что для ненулевых делителей функция ведёт себя как надо:
safeDiv_is_div : (m, n : Rational) -> Not (n = 0) -> m `safeDiv` n = m / n
Ну и потом просто доказываете это всё, и всё.
rsync
09.01.2020 22:54Ну и потом просто доказываете это всё, и всё.
тесты — и есть доказательство того что Вы написали правильно и не ошиблись.
0xd34df00d
09.01.2020 22:55тесты — и есть доказательство того что Вы написали правильно и не ошиблись.
Тесты не могут это доказывать. Тесты могут продемонстрировать ошибку, и доказать, что ошибок нет на одном (пяти, десяти, 333) конкретном входе. Не более.
rsync
09.01.2020 23:06да и демонстрации ошибки достаточно (знаю Вам не нравится это слово). Доказательство не требуется.
если вернуться опять же к тому же вероятностному градиентному спуску. Его доказать вообще невозможно. Ответ находится с какой-то вероятностью. Чем дольше считаем тем точнее ответ. Есть вероятность что идеальное решение найдем через 2 итерации. Или через 50 млн. Тоже всего лишь вероятность.
Ваше "доказательство" если оно не выражено в автоматической проверке валидности кода — бессмысленно при рефакторинге. А если оно выражено в виде автоматической проверки, то это и есть написанный тест.
0xd34df00d
09.01.2020 23:22да и демонстрации ошибки достаточно
Для чего? Для демонстрации корректности работы?
(знаю Вам не нравится это слово).
Слово-то хорошее, просто я не понимаю, когда конкретно в тестах надо остановиться, а когда — нет.
Его доказать вообще невозможно. Ответ находится с какой-то вероятностью.
Глобальный экстремум находится с какой-то вероятностью. Локальный-то находится всегда (если не переборщить с размером шага, чтобы оно вылетало из экстремума). А дальше уже начинаются надстройки типа simulated annealing, мультистарта и прочей подобной ерунды, которую точно так же можно переформулировать в терминах завершимости.
Кроме того, вы на самом деле можете доказывать не завершимость, а продуктивность (что следующий результат за конечное число шагов) — это полезно не только для алгоритмов оптимизации, но и для серверов.
Правда, мы с коданными эффективно работать ещё не умеем. Вот что тут
ones1равноones2, у меня доказать не получилось:
zeroes : Stream Int zeroes = 0 :: zeroes ones1 : Stream Int ones1 = 1 :: ones1 ones2 : Stream Int ones2 = map (+ 1) zeroes
Впрочем, это так, мысли вслух.
А если оно выражено в виде автоматической проверки, то это и есть написанный тест.
Можете к этому и так относиться. Только этот тест не запускается, не имеет никакого рантайм-кода, и вообще весьма далёк от того, что обычно люди называют тестами. И сформулировать эту проверку валидности помогают именно типы.
rsync
09.01.2020 23:49Для чего? Для демонстрации корректности работы?
цель не просто написать код
цель — иметь возможность его развивать в том числе когда Вы (автор кода) покинете этот коллектив и будете трудиться в другом.
кода много, людей над ним работающих — много.
каждый новый человек далеко не сразу понимает код целиком. Он исправляет те кусочки которые ему удалось понять.
При этом, поскольку полного понимания у него нет, то ему нужен инструмент который ему скажет что он сломал что-то ещё или наоборот — что деструктивных изменений он в код не привнёс.
для этого существуют тесты и CI
Можете к этому и так относиться. Только этот тест не запускается, не имеет никакого рантайм-кода, и вообще весьма далёк от того, что обычно люди называют тестами. И сформулировать эту проверку валидности помогают именно типы.
типы помогают сформулировать только узкий кусочек проверок
с кодом функции sum или sort Вы так и не показали как типы Вам помогают избежать ошибок.
Вернёмся к sum
Программист написал
int sum(int a, int b) { return a - b; }
он ошибся (опечатался) вместо плюса поставил минус.
Типы указаны и для
aи дляbи для возвращаемого значения. Однако программа невалидна.
Типы никак не помогают.
Другой пример
double pow5(double x) { return x * x * x * x * x * x; }
программист ошибся и сделал 6 умножений вместо пяти.
Типы указаны и для возвращаемого значения и для аргументов. Однако ошибку увидеть они не позволяют.
И это всё простые примеры.
Типизация — позволяет видеть ошибки неправильно сдизайненных языков, вроде JavaScript, Python итп
где авторы языка почему-то навертели на математический оператор нематематическую функциональность, огребли от этого и вместо того чтобы исправить проблему в том месте где она у них возникла — стали бороться со следствиями — вводить типы.
Если же говорить о проблеме типов: когда она возникает? Проблема несоответствия типов возникает когда мы данные получаем из разных источников и где-то "забыли" привести их к нужному типу.
в 99.9% случаев это проблемы строк и чисел.
Проблемы в том что вместо объекта "пользователь" пришел почему-то объект "стул" наблюдаются крайне редко. Значительно чаще — когда вместо широты
55.23пришла широта'55.23'. Первая взята из JSON, а вторая из атрибута XML-дерева.
Решать проблему можно двумя путями: разделить математические и строковые операторы как это делают некоторые языки или внедрять типы.
Внедрение типов, увы — почти повсеместная практика.
Давайте мы из языка похожего на человеческий сделаем язык похожий на язык роботов.
и в итоге получается. Ты программисту даёшь задание 2 и 2 сложить, а он в ответ тебе какие-то доказательства сочиняет. Фабрики классов пишет. А бизнесу ни доказательства ни фабрики не нужны. Ему нужно чтобы "сухо, светло и медведь" (ц)
0xd34df00d
10.01.2020 00:04цель — иметь возможность его развивать в том числе когда Вы (автор кода) покинете этот коллектив и будете трудиться в другом.
Я не понимаю, как возможность продемонстрировать наличие конкретной ошибки этому помогает. Как оно помогает избежать эту же ошибку — понимаю. Как оно гарантирует корректность реализации (если корректность чуть сложнее, чем «произвольная функция, в этих N точках имеющая эти N значений») — понять не могу физически.
с кодом функции sum или sort Вы так и не показали как типы Вам помогают избежать ошибок.
Не понял. А там выше (или по ссылке на гитхаб) что было?
Там написаны типы функций, которые постулируют (привет Карри-Говарду). Дальше вы пишете сами эти функции, а тайпчекер проверяет, что то, что вы написали, соответствует этим типам.
Ты программисту даёшь задание 2 и 2 сложить, а он в ответ тебе какие-то доказательства сочиняет.
Ты программисту даёшь задание 2 и 2 сложить. а он в ответ тебе какие-то юнит-тесты пишет.
rsync
10.01.2020 00:21Не понял. А там выше (или по ссылке на гитхаб) что было?
это не то о чём я спрашивал.
вот Вам конкретный sum с ошибкой в алгоритме.
Не в типах ошибка, а в алгоритме.
или лучше pow5. Если на sum/sort с большим грехом пополам натянуть можно типы (оверхед уже становится больше чем тесты написать), то на чуть более слабо обратимую математику типы уже не натянуть. На необратимую математику не натянуть вовсе.
Но необратимую математику тоже вполне можно программировать ведь (крипта та же).
Там написаны типы функций, которые постулируют (привет Карри-Говарду). Дальше вы пишете сами эти функции, а тайпчекер проверяет, что то, что вы написали, соответствует этим типам.
большинство задач вообще нематематические.
как Вы например рейс кондишен (вернее его отсутствие) будете постулировать и доказывать?
Ты программисту даёшь задание 2 и 2 сложить. а он в ответ тебе какие-то юнит-тесты пишет.
юниттесты позволяют передать эту работу другому программисту
поэтому они обоснованны
а фабрики классов и какие-то доказательства — остаются сферическим конём в вакууме
0xd34df00d
10.01.2020 00:29вот Вам конкретный sum с ошибкой в алгоритме.
Не в типах ошибка, а в алгоритме.Которую могут поймать типы, как я показал в том коде.
На необратимую математику не натянуть вовсе.
Тут дело не в обратимости, а в выполнимости тех или иных свойств, которые вы ожидаете от тех или иных объектов. Например, для суммы одно из таких свойств — то, что элемент, обозначаемый 0, является для неё единицей и слева, и справа.
С криптой у меня нет опыта, но я знаю, что люди там чего-то доказуемое (а не тестируемое) для всяких блокчейнов ваяют.
как Вы например рейс кондишен (вернее его отсутствие) будете постулировать и доказывать?
Тоже типами! Если у меня есть нет глобального разделяемого состояния, то у меня нет рейскондишонов, а отсутствие такого состояния можно выразить в типах.
Например, вот эта библиотека:
We would like to tell you that if you're programming with Safe Haskell (-XSafe), that this library provides a formal guarantee that anything executed with runPar is guaranteed-deterministic. Unfortunately, as of this release there is still one back-door that hasn't yet been closed.
If an adversarial user defines invalid Eq instances (claiming objects are equal when they're not), or if they define a compare function that is not a pure, total function, and then they store those types within LVars, then nondeterminism may leak out of a parallel runPar computation.
In future releases, we will strive to require alternate, safe versions of Eq and Ord that are derived automatically by our library and by the GHC compiler.
В более мощных языках, чем Haskell, можно потребовать доказательство корректности упомянутых в тексте Eq и Ord. В частности, именно типы позволяют вообще сформулировать это требование и затем написать соответствующее (формально верифицируемое) доказательство.
юнит тесты позволяют передать эту работу другому программисту поэтому они обоснованны
Так и доказательства позволяют.
rsync
10.01.2020 01:03Вы неправильно описали тип
как это выяснить?
0xd34df00d
10.01.2020 01:29Чтобы понять, как ответить на этот вопрос, давайте рассмотрим другой:
Вы неправильно написали тест.
Как это выяснить?
rsync
10.01.2020 08:32тест и код взаимосвязаны, но пишутся раздельно
соответственно комбинации с неправильным тестом или кодом выявляются с большой степенью вероятности
я ответил на Ваш вопрос?
0xd34df00d
10.01.2020 18:10Ну так реализация вашей функции и утверждения о её поведении пишутся раздельно. И не возникает проблем с тем, чтобы выбрать, какое именно подмножество данных протестировать, что уменьшает вероятность ошибки.
rsync
10.01.2020 08:31тест и код взаимосвязаны, но пишутся раздельно
соответственно комбинации с неправильным тестом или кодом выявляются с большой степенью вероятности
я ответил на Ваш вопрос?
rsync
10.01.2020 08:31тест и код взаимосвязаны, но пишутся раздельно
соответственно комбинации с неправильным тестом или кодом выявляются с большой степенью вероятности
я ответил на Ваш вопрос?
dzsysop
09.01.2020 22:53что-то мешало внедрить эту одну фичу в проект?
вы уверенны что одну?
бюджеты миллиардные.
В тыньге? бюджеты никогда не резиновые.
Почему? Задача оказалось не по плечу. Все другие объяснения нахожу менее разумными.
Это вы зря. Вы только что привели примеры из строительства и бухгалтерии.
Такая же ситуация и с программными продуктами.
Программный продукт это не только и не столько функционал. Это еще люди, деньги и бизнес. Если у продукта есть конкурент (конкурент — это не техническое, а бизнес понятие), и у конкурирующего продукта есть какие-то фичи, которых нет у нас и нет каких-то фишек, которые у нас есть, то это не значит что мы должны все чужих фишки к себе тянуть и избавляться от всего лишнего что есть у нас. Потому как это надо еще понять кто у кого копирует, какие фишки нужные, а какие мусорные. Насколько совпадает целевая аудитория и прочее и прочее.
Предположим что мы все же выяснили что конкурент растет за счет какой-то фичи. Мы (руководство) можем решить что нам не нужен тот клиент который нужен нашим конкурентам и что мы доминируем в какой-то своей нише. Это обычное бизнес-решение, это никак не связано с «оказалось не по плечу». Просто любой менеджер понимает что нельзя быть лучшим всегда и во всем. (Всех денег не заработать; на двух стульях не усидеть; за двумя зайцами погонишься ни одного не поймаешь)
Даже если руководство видит что какую-то фичу таки надо бы перенять у конкурентов, это совсем не значит что у компании на это будут ресурсы. Текущий бюджет далеко не всегда мега-профитабельный, а выбивание инвестиций требует экономического обоснования и бизнес-плана, а это задача со многими неизвестными.
Так что все же не всегда, если что-то не было сделано, это потому что «оказалось не по плечу.»rsync
09.01.2020 23:01Ваши рассуждения верны до тех пор пока мы не вспомним что ватсап всего одной фичей (наличие мобильного приложения) убил скайп
а скайп всего одной фичей (голосовая связь) убил ICQ
а телеграм всего парой фич (простота написания ботов и каналы) втащил в себя бизнес и набрал солидную базу клиентов.
в ответ ватсапп напрягся и тоже запустил каналы. А вот с ботами не задалось ни у вастаппа ни у вибера. поэтому Телеграм продолжает отжимать у них долю.
как-то так
Static_electro
09.01.2020 22:55Так прямо из ваших предпосылок напрашивается вывод, что разорились из-за неудачных организационных решений. А не потому что не могли "написать фичу". С их деньгами они могли этих фич по две в неделю делать, тупо переписывая все с нуля каждый раз.
Static_electro
09.01.2020 22:12Вы так часто и с такой уверенностью поминаете ICQ, что у меня возник вопрос. Вы там работали? Или откуда знаете про их подходы к программированию?
khim
09.01.2020 23:03+1Вы там работали?
В AOL я не работал, но когда я был «молодым и зелёным» мы были одним из парнёров AOL. И потому примерно представляю что и как они могли требовать от программистов.
Да даже и не нужно никакого «инсайда». Вспомните, что они сделали с Netscape! Они совершенно искренне считали, что для них — куда полезнее использовать Netscape и Mozilla только как рычаг для давления на Microsoft, продвигали AOL Browser вместо чего-то на движке Mozilla и так далее.
Это были «нормальные бизнесмены» со своими «нормальным подходами», занимавшиеся «консолидацией» (в частности пытавшихся объединить AIM и ICQ), продажами диалап-доступа и о какой-то блажи типа голосового чата — они просто не думали. Они думали о том, как подписчиков себе вернуть.
Ну действительно: какой идиот в компании, которая живёт за счёт продаж диалапа разрешит изменить флагманский продукт так, чтобы он перестал на этом самом диалапе работать, а требовал бы широкополосного доступа, с которым у вас проблемы, а зато у ваших конкурентов — всё хорошо?
Да, при взгляде назад — это кажется безумием и бредом… но вот так AOL себя видела в те годы.
А как раз наличие тестов и возможность менять код — это всё было вторично, по сравнению с этим.
EvgeniiR
10.01.2020 11:24так же как с sum выше: взять и набрать достаточно большую (уверенность!) таблицу вход-выход
Я никогда не мог понять, что значит «достаточно». В тепле, сухости и безопасности я чувствую себя только после написания доказательства.
Компромисс, когда на починку багов уходит приемлемо небольшое количество времени а учиться писать на Идрисе не нужно.
Я, кстати, по вашей ссылке, заглянул в предисловие TAPL, и мне очень понравилась цитата оттуда:
«Formal methods will never have a significant impact until they can be used by people that don’t understand them.»0xd34df00d
10.01.2020 18:16Это другой вопрос. Мы ж тут не о практической применимости говорим (на практике и тесты не всегда есть/нужны/приветствуются), а о том, как типы могут заменить тесты.
Я тут, кстати, сейчас смотрю на такую тему, как logically quantified types — это такое подмножество зависимых типов где, как я понимаю, и вывод типов, и term finding разрешимы, что означает, что можно не доказывать вручную вещи типа того, что если a > b, а b > c, то a > c, а скормить это SMT-солверу, и пусть он там крутится. Понятно, что эргономику это очень сильно повышает.
Кроме того, у меня есть подозрение, что задача определения, типизируем ли терм DT-языка в LT, или же ему нужны полноценные DT, разрешима, и причём довольно очевидным образом, но это уже совсем другая история.
Nashev
10.01.2020 10:08Уносить часть тестов в тайпчекер — тоже вполне себе вариант… Плюсы у него есть. Но от этого они не перестают быть тестами, кстати.
mayorovp
10.01.2020 10:00Нуу… Мне нужно будет написать две функции с типами
У вас получились тесты, только более мощные. Но главный недостаток тестов никуда не делся — вам всё ещё надо их придумывать.
К примеру, ваших sum_left_0 и sum_right_0 всё ещё недостаточно для полного доказательства, что эта функция и правда выполняет суммирование. Это может быть и побитовое исключающее "ИЛИ".
0xd34df00d
10.01.2020 18:19У вас получились тесты, только более мощные.
Вы можете их так назвать, но только тогда получается, что любой механизм проверки и верификации кода — тесты. Как-то дискриминирующая сила понятия теряется.
Но главный недостаток тестов никуда не делся — вам всё ещё надо их придумывать.
Только в случае с «обычными» тестами мне надо придумать утверждения и придумать примеры, которые бы подходили под эти утверждения и доказать, что множества примеров достаточно. Ой, опять доказательства, тьфу ты...
Тут мне надо придумывать заведомо меньше.
К примеру, ваших sum_left_0 и sum_right_0 всё ещё недостаточно для полного доказательства, что эта функция и правда выполняет суммирование. Это может быть и побитовое исключающее "ИЛИ".
Отличное замечание! Естественно, это не всё множество утверждений о поведении суммы.
mayorovp
10.01.2020 18:45Вы можете их так назвать, но только тогда получается, что любой механизм проверки и верификации кода — тесты. Как-то дискриминирующая сила понятия теряется.
Любой внешний механизм.
Тут мне надо придумывать заведомо меньше.
А вот не факт. Теста
sum 2 3 == 5достаточно, чтобы исключить ошибки вида "глупая опечатка".
Более умные ошибки исключаются методом внимательного взгляда: в такой простой функции им просто неоткуда взяться.
0xd34df00d
10.01.2020 20:21Любой внешний механизм.
То есть, если функция производит доказательство корректности ответа рядом с этим ответом, то тогда это не тест?
А вот не факт. Теста sum 2 3 == 5 достаточно, чтобы исключить ошибки вида "глупая опечатка".
Более умные ошибки исключаются методом внимательного взгляда: в такой простой функции им просто неоткуда взяться.Ну это как раз понятно, для такой функции и я бы писал только те
теоремылеммы, которые нужны для доказательства каких-то свойств более сложных функций, которые где-то у себя внутри в реализации складывают числа.
akryukov
10.01.2020 20:41Любой внешний механизм.
Если есть внешний, то подразумевается и внутренний. Что вы понимаете под внутренним механизмом проверки и верификации кода?
mayorovp
11.01.2020 09:49Ну, собственно, типизация в обычном её понимании и есть такой внутренний механизм.
0xd34df00d
11.01.2020 17:47Так тут ровно те же типы. В конце концов, можно написать
sum : (x, y : Nat) -> (s : Nat ** (x = 0 -> s = y) ** (y = 0 -> s = x) ** {- еще десяток свойств -})
но зачем?
khim
11.01.2020 18:19По-момему дискуссия соврешила очередной оборот и пошла на второй (третий, четвёртый?) круг. Напомню, с чего всё началось: как использовать типы для замены unittest'ов (что, на самом деле, всегда возможно, однако не всегда желательно).
Вот, собственно, в замечания в скобках всё и упирается. Если у вас достаточно «сильная» система типов (C++, в принципе, уже достаточен) — то вы любой unittest, в принципе, можете выразить в типах… но далеко не всегда это имеет смысл. Ну просто потому что если вы добъётесь того, что у вас всё-всё-всё прописано в типах, но однократная компиляция вашей программы занимает два дня… то толку от этого будет немного.rsync
11.01.2020 18:40+1
в типах нельзя например выразить стейт, хранимый в БД
class User: def save(self): dbh.perform('save.sql', self.db_variables) ...
типизация — это вариант тестирования, но типизация решает небольшой диапазон проблем, которые решает тестирование.
0xd34df00d
11.01.2020 19:34небольшой
Зависит от соотношения объёма внутренней логики и взаимодействия с внешним миром.
Впрочем, что вы будете тестировать для этого
User?rsync
11.01.2020 19:42Впрочем, что вы будете тестировать для этого User?
тестировать факт успешности сохранения в бд, загрузки из бд
поиска юзера в бд итп
часть функционала при этом (например индексирование) будет исключительно на стороне БД и типы ваши к ней не прикрутить
не будете же вы отказываться от БД только из за типов
khim
11.01.2020 19:47Зачем отказываться? В unit-test'ах mock bd (если у вас тест ходит в прод, то это уже совсем не unit-test), то же самое можно сделать и с типами.
rsync
11.01.2020 19:54если у вас тест ходит в прод, то это уже совсем не unit-test
поэтому я не люблю понятие "юнит-тест".
просто тест.
мой подход такой: тест обязан ходить в такую же БД в какую будет ходить прод.
а моки это — зло
docker для обеспечения этого всего очень хорошо подходит :)
BugM
11.01.2020 20:09+1Ваши юнит тесты все сильнее начинают напоминать интеграционные. Медленные, сложные, инфрастуктуру требуют. Их не то что при каждой сборке, а даже при каждом коммите не прогнать.
А в интеграционных тестах уже не надо тестировать сохранение и чтение из БД User. Достаточно протестировать интерфейсы системы. Если на них все правильно, то какая разница как там что в БД сохраняется и читается? Может и БД уже нет, все порефакторили на инмемори хранение.rsync
11.01.2020 20:20Ваши юнит тесты все сильнее начинают напоминать интеграционные.
Вы отвечаете на комент начинающийся словами "я не люблю термин 'юнит-тест'"
с точки зрения того что это тест на код юнита user.py — это юнит тест. с точки зрения того что в тесте задействована БД — это интеграционный тест.
Их не то что при каждой сборке, а даже при каждом коммите не прогнать.
отлично прогоняются. при каждом коммите.
вот проект — 600 тыс строк кода. 450 тыс строк тестового кода.
тесты идут 25 минут.
тестируется именно каждый коммит.
а разработчик может запускать тесты именно той подсистемы которую модифицирует (эти вообще быстро идут)
рабочий воркфлоу такой:
- разработчик пишет тест
- разработчик пишет функциональность
- разработчик делает коммит
- получает репорт о том прошли ли все остальные тесты
- при необходимости фиксит непройденные тесты
- делается релиз, деплой итп
BugM
12.01.2020 02:16Вы отвечаете на комент начинающийся словами «я не люблю термин 'юнит-тест'»
Так все равно скатываемся до определений. То что тестирование as code это хорошо и правильно все в курсе и никто не спорит. Вопрос только в том что и как тестировать.
отлично прогоняются. при каждом коммите.
вот проект — 600 тыс строк кода. 450 тыс строк тестового кода.
тесты идут 25 минут.
С одной стороны завидую вашему железу (у нас они часы идут) с другой для коммита 25 минут это тоже долго. За 25 минут можно найти ошибку глазами, поправить и потом еще раз найти.
Комит должен быть моментальным. Единицы минут край. Закомитить в ветку любой кусок кода который с виду работает это нормально и правильно.
рабочий воркфлоу такой:
Воркфлоу хороший. Только при долгих тестах его гонять по много раз не выйдет. Долго. Надо большую часть ошибок находить до тестов. Тесты скорее для самопроверки. Мол я все правильно написал.
0xd34df00d
11.01.2020 20:04тестировать факт успешности сохранения в бд, загрузки из бд
Тут ИМХО смешивается два слоя: сериализация пользователя и работа с БД. Проверить сериализацию можно в типах. Проверять работу с БД — задача библиотеки БД, класс
Userтут ни при чём.
поиска юзера в бд итп
Не тестируете ли вы тут случаем ORM?
часть функционала при этом (например индексирование) будет исключительно на стороне БД и типы ваши к ней не прикрутить
Тесты, тащем, тоже.
не будете же вы отказываться от БД только из за типов
Но я могу в типах выразить зависимость от БД и сформулировать, что для моковой реализации БД всё работает так, как ожидается. Более того, я в типах могу выразить, что мой код ходит только в ту БД, которую я ему подсунул. В тестах это выразить будет сложно.
rsync
11.01.2020 20:15Тут ИМХО смешивается два слоя: сериализация пользователя и работа с БД
не вижу ничего плохого в смешении.
каждый слой в случае чего выдаёт свои наборы ошибок, а тест проверяет успешность всей системы в целом.
Проверять работу с БД — задача библиотеки БД, класс User тут ни при чём.
у меня в MVC парадигме есть сущность такая — User.
эта сущность может быть сохранена в БД, может быть восстановлена из БД, может производиться поиск итемов этой сущности, может производиться показ списка. Могут проводиться иные манипуляции.
все эти манипуляции написаны в сущности User и используют работу с БД внутри себя.
изоляция User от БД в парадигме MVC — это дефакто отказ от парадигмы MVC.
какую парадигму взамен MVC Вы предложите?
Тесты, тащем, тоже.
тесты очень легко сюда ложатся.
сохраняем юзера в БД а потом из теста напрямую идем в БД-записи и выполняем сверку.
Но я могу в типах выразить зависимость от БД и сформулировать, что для моковой реализации БД всё работает так,
- само моканье целой БД — задача очень высокой сложности
- при этом моканье зло (в соседнем посте описал почему)
- моканье БД даст вам возможность типами протестить например сохранение записи в БД, ок.
но возьмем реальный мир. Например после сохранения записи в БД требуется отправить уведомления какие-то каким-то сервисам. Типовое: пользователь нажимает кнопку в "заказе", а биллинг в ответ списывает денежку с пользователя, а еще исполнитель получает СМС.
0xd34df00d
12.01.2020 01:52какую парадигму взамен MVC Вы предложите?
ХЗ, я просто пишу код.
У меня есть просто рекорд, отвечающий тому, что должно быть сохранено в БД, и я просто его скармливаю ORM'у.
И типы позволяют не проверять руками, что мне там пришло от БД. Я просто работаю с объектом так, будто он уже валидирован, корректен и так далее.
Более того, типы могут гарантировать, что у вас генерируется только корректный SQL (уж коли мы говорим о БД).
сохраняем юзера в БД а потом из теста напрямую идем в БД-записи и выполняем сверку.
Так что вы проверяете-то? Я не понимаю, от ошибок какого класса вы хотите оградиться этим тестом?
Например после сохранения записи в БД требуется отправить уведомления какие-то каким-то сервисам. Типовое: пользователь нажимает кнопку в "заказе", а биллинг в ответ списывает денежку с пользователя, а еще исполнитель получает СМС.
Это даже можно не проверять. Вы просто тегируете ваш тип данных набором дополнительных меток на уровне типов. Если метку
HasSentSMSдобавляет только функция отправки SMS, и если вы в результате требуете наличия этой метки, то этим вы гарантируете, что функция отправки SMS будет вызвана. Даже тесты писать не надо.
Чуть более лайтовый пример этого подхода — примерно так я здесь гарантирую, что на разных стадиях обработки неких опций доступны разные значения, и, более того,
CTStringилиCTStringVec, скажем, могут существовать только на стадииParsed, но на стадияхSupportedилиValueих гарантированно нет.
EvgeniiR
12.01.2020 09:21у меня в MVC парадигме есть сущность такая — User.
эта сущность может быть сохранена в БД, может быть восстановлена из БД, может производиться поиск итемов этой сущности, может производиться показ списка. Могут проводиться иные манипуляции.
все эти манипуляции написаны в сущности User и используют работу с БД внутри себя.
изоляция User от БД в парадигме MVC — это дефакто отказ от парадигмы MVC.
Ну здравствуйте. А откуда такие требования в MVC?
1. Если вдруг мы говорим про Веб, то напомню что MVC был создан для десктопных приложений, и описан Трюгве тут в 1979 году. В вебе испольуется лишь MVA(он же mediating controller MVC).
2. В MVC нет ничего про БД. То что у вас получилось в моделях по сути называется Active Record, и там действительно сложно отделить логику от взаимодействия с БД. Потому, собственно, AR и считается антипаттерном.
какую парадигму взамен MVC Вы предложите?
Писать адекватный код и думать о coupling/cohesion а не на аббревиатурки любоваться.
Про оригинальный MVC уже и вспоминают то не часто, чего к нему цепляться то.
но возьмем реальный мир. Например после сохранения записи в БД требуется отправить уведомления какие-то каким-то сервисам.
Возьмём реальный мир — бизнесу нет дела до хранилища и записей.
Уведомления отправляются не о записи в БД, а о том что совершилось какое-то известное бизнесу действие.
Вобщем, привет доменные ивенты, либо просто дёргать сервис напрямую после коммита транзакции, если проще хочется.
проблему mock'ов знаете главную?
консистентность с реальным миром
Поэтому интеграционные тесты всё-равно нужны, да.
Только вот взаимодействие с реальным миром можно изолировать, чтобы логику системы спокойно покрывать юнитами.rsync
12.01.2020 10:291. Если вдруг мы говорим про Веб, то напомню что MVC был создан для десктопных приложений, и описан Трюгве
зачем нужен этот исторический экскурс? допустим MVC придуман изначально для десктопа. Что-то это меняет?
сейчас он успешно применяется в вебе
кроме того нет никаких отличий десктопного приложения от браузерного. Вот мы с Вами общаемся на этой странице. Такие же кнопки, чекбоксы, скроллы, итп как и на прочих десктопных приложениях.
django — MVC
mojo — MVC
и так далее
2. В MVC нет ничего про БД.
в MVC про хранение (вообще работу с данными) данных отвечает M
2. В MVC нет ничего про БД. То что у вас получилось в моделях по сути называется Active Record, и там действительно сложно отделить логику от взаимодействия с БД. Потому, собственно, AR и считается антипаттерном.
если мы говорим об особенностях реализации M в MVC, то можно говорить и о AR, почему бы и нет.
но в общем это просто составляющая MVC
допустим мы генерим html на сервере, тогда M — слой работы с хранилищем, C — слой работы с собственно вебом и арбитраж, V — слой формирования представления
если мы допустим пришли к тому что перенесли V на клиента, то сама модель MVC у нас сохранилась, просто размазалась в пространстве. MC остались на сервере V уехало на клиента. причем на клиенте оно возможно снова стало MVC. а на сервере всё равно MVC просто V выродился до примитивной сериализации в JSON/XML/итп
Потому, собственно, AR и считается антипаттерном.
кем считается? теми 14 человеками (больше там нет) которые пытаются заменить тесты типами и пишут на маргинальных языках программирования?
не смешите мои тапочки. MVC — самый распространённый в вебе паттерн.
и проблемы со скоростью разработки именно тогда и начинаются когда программисты ломают этот паттерн.
Возьмём реальный мир — бизнесу нет дела до хранилища и записей.
Уведомления отправляются не о записи в БД, а о том что совершилось какое-то известное бизнесу действие.
я написал «после сохранения в БД» а не «о сохранении в БД» Вы спорите с собственным тезисом, а не тем что выдал Вам оппонент.
Поэтому интеграционные тесты всё-равно нужны, да.
Только вот взаимодействие с реальным миром можно изолировать, чтобы логику системы спокойно покрывать юнитами.
изоляция (моки и тому подобные технологии) может очень дорого стоить, о чём собственно и идёт речь.
гораздо дешевле не изолироваться от внешнего мира, а построить виртуальный внешний мир.
присутствует в проекте БД? отлично, перед запуском тестов — поднимаем БД. Имеется очередь? отлично — поднимаем и её. Хранилище S3? Mongo? Postgresql? подымаем все их!
затем запускаем тест. Тест в этом случае простой (мало кода) и полный (не функциональность с отрезанными частями проверяет а полную).
Моки совсем уж внешних систем могут присутствовать конечно, но именно совсем внешнихEvgeniiR
12.01.2020 10:43зачем нужен этот исторический экскурс? допустим MVC придуман изначально для десктопа. Что-то это меняет?
сейчас он успешно применяется в вебе
Если немного разобраться, будет понятно что всё что по вашей ссылке на самом деле MVC не является.
Как минимум потому что в вебе и всяких там ASP.NET контроллер является связующим звеном между View и Model, что паттерну MVC противоречит.
кроме того нет никаких отличий десктопного приложения от браузерного. Вот мы с Вами общаемся на этой странице. Такие же кнопки, чекбоксы, скроллы, итп как и на прочих десктопных приложениях.
Отличие в том что взаимодействие идёт через request/response. Просто так забиндить select на вьюхе к полю в модели не получится.
если мы говорим об особенностях реализации M в MVC, то можно говорить и о AR, почему бы и нет.
но в общем это просто составляющая MVC
Можно, но не обязательно. Модель в MVC не обязана быть AR.
V выродился до примитивной сериализации в JSON/XML/итп
Это и противоречит MVC. View должен быть объектом подписанным на обновления в модели.
кем считается? теми 14 человеками (больше там нет) которые пытаются заменить тесты типами и пишут на маргинальных языках программирования?
Жаль что даже Фаулер Мартин не известен вам. Впрочем, разводить тут демагогию не интересно. Кому интересно пройдёт по ссылочкам и разберётся.
MVC — самый распространённый в вебе паттерн.
и проблемы со скоростью разработки именно тогда и начинаются когда программисты ломают этот паттерн.
Так это баззворд распространённый, а как определение спросишь, у 10 разных программистов будет 5 разных «MVC».
Проблемы со скоростью разработки от сломанного MVC? Давайте статистику(и определение MVC, желательно).
гораздо дешевле не изолироваться от внешнего мира, а построить виртуальный внешний мир.
присутствует в проекте БД? отлично, перед запуском тестов — поднимаем БД. Имеется очередь? отлично — поднимаем и её. Хранилище S3? Mongo? Postgresql? подымаем все их!
затем запускаем тест. Тест в этом случае простой (мало кода) и полный (не функциональность с отрезанными частями проверяет а полную).
Integrated tests are a scam — советую.rsync
12.01.2020 11:02A Model is an active representation of an abstraction in the form of data in a computing system
Вы вот спорите и приводите цитаты которые сами не читаете.
Модель — это про слой данных
данные в современное время обычно где-то хранятся (да можно говорить о приложении MVC без БД, например MVC на фронте, но и там обычно где-то хранилище да есть).
Это и противоречит MVC.
не противоречит. вырождение слоя до минимального != вырождение слоя до нуля
Можно, но не обязательно. Модель в MVC не обязана быть AR.
я где-то писал что обязана?
очень часто бывает — да
Integrated tests are a scam — советую.
дайте суть одним предложением.
lair
12.01.2020 11:20допустим MVC придуман изначально для десктопа. Что-то это меняет?
сейчас он успешно применяется в вебеНа самом деле, это распространенное заблуждение. То. что применяется в вебе — это не то, что было придумано изначально, это другой паттерн, который назывался, чтобы всех запутать, Model 2. Но поскольку в нем использовались же те термины, его тоже начали называть MVC (сначала — MVC Model 2), что и привело нас туда, где мы сейчас.
А полезно это знать, потому что роли компонентов в оригинальном MVC и MVC-для-веба отличаются, и поэтому надо очень аккуратно смотреть, на какое описание паттерна ссылаешься. Вот например...
в MVC про хранение (вообще работу с данными) данных отвечает M
… в некоторых MVC-фреймворках (например, asp.net MVC и все, что из него выросло) за работу с данными фактически отвечает контроллер (или, правильнее, находящийся за контроллером доменный слой), а то, что в Model 2 называется Model, отвечает только за транспорт между контроллером и представлением (и поэтому появляются рекомендации называть это ViewModel, чтобы, опять же, избежать непонимания).
кем считается?
Ну вот мной, например. А Фаулер в PoEAA пишет, что это простой паттерн, который перестает справляться по мере роста сложности домена.
не смешите мои тапочки. MVC — самый распространённый в вебе паттерн.
Да, но при чем здесь AR? Я много лет пишу для MVC, но ни разу не использовал AR.
изоляция (моки и тому подобные технологии) может очень дорого стоить
Угу. Особенно в сравнении с
меется очередь? отлично — поднимаем и её. Хранилище S3? Mongo? Postgresql? подымаем все их!
У меня вот проект, в котором активно используется AWS (вы вот помянули S3). Так вот, поднять все нужные сервисы — это, во-первых, долго, а, во-вторых, стоит денег (а учитывая, что тесты хочется гонять часто, это становится дорого). Плюс немедленно возникает проблема изоляции теств друг от друга — вы же не будете поднимать окружение заново для каждого из тысячи тестов?
rsync
12.01.2020 11:57У меня вот проект, в котором активно используется AWS (вы вот помянули S3). Так вот, поднять все нужные сервисы — это, во-первых, долго, а, во-вторых, стоит денег
докер для этого придумали. поднять докер с s3 хранилищем или скажем с SQS очередью (произвольным вариантом) или с RabbitMQ или Mongo или с Pg или с кластером из монг, постгрей итп
стоит нынче очень недорого. 3-10 строк написать в docker-compose. Однократно на всю жизнь проекта.lair
12.01.2020 12:09докер для этого придумали
Расскажите мне, как поднять в докере Amazon Textract или Amazon Cognito. Особенно когда в Cognito сконфигурены обработчики событий на лямбдах.
(это не считая того, что если на проекте нет докера, то это дополнительная нагрузка на инфраструктуру, и особенно веселой она становится, когда инфраструктура на винде)
И, кстати, в этот момент этот контейнер с S3 и становится моком. Разве нет?
А отсюда, кстати, вытекает следующий занятный факт: мне теперь надо (как минимум) два ряда интеграционных тестов — первый использует контейнеры, а второй использует реальные продакшн-сервисы (с реальным механизмом развертывания). Я не очень понимаю, почему это дешевле, чем просто сделать все те же самые моки в коде (и это будет подниматься и работать в десятки раз быстрее).
PS… а потом мы добавили в этот проект Azure.
rsync
12.01.2020 12:24-1обработчики событий на лямбдах.
я давно засматриваюсь на лямбды амазона, мало того в одном из моих проектов вариант лямбд реализован свой.
однако лямбды амазона мы не применяем (хотя выглядит красиво) именно из за того что над ними очень сложно настроить процесс тестирования.
кстати, вот если руки дойдут, то я свою реализацию лямбд со временем допилю — и сделаю к ней имплементатор амазоновского API. и Вы сможете тестировать.
а пока, я считаю, это (у амазона, яндекса и прочих кто лямбдами занимается) недоделанная технология. лучше от неё дистанцироваться.
ну а уж если у вас кто-то неопытный не подумав принял решение их применять — ну чтож мучайтесь с моками и прочим.
(это не считая того, что если на проекте нет докера, то это дополнительная нагрузка на инфраструктуру, и особенно веселой она становится, когда инфраструктура на винде)
- докер можно держать только в тестовой инфраструктуре
- инфраструктура на винде — это ещё один слой извращений. в этом я не разбираюсь, увы.
И, кстати, в этот момент этот контейнер с S3 и становится моком. Разве нет?
эм. нет.
он полноценное S3 хранилище.
и файлики можно посмотреть и протокол полностью поддерживается.
моком он бы был если бы эмулировал заглушками часть функционала.
Википедия: Mock-объект (от англ. mock object, буквально: «объект-пародия», «объект-имитация», а также «подставка»)
тут же нет имитации
тут полноценный S3, полноценный PostgreSQL, полноценная Монга, полноценный nginx, итп
никаких моков.lair
12.01.2020 12:33над ними очень сложно настроить процесс тестирования.
С чего бы вдруг?
и Вы сможете тестировать.
Я уже сейчас могу это тестировать. И, собственно, тестирую.
лучше от неё дистанцироваться.
… и на что вы предлагаете заменить лямбды в событиях Cognito?
докер можно держать только в тестовой инфраструктуре
Об этом и речь: нам придется поднять докер только ради тестов. Это дополнительные накладные расходы.
эм. нет.
он полноценное S3 хранилище.Он от этого моком быть не перестал.
"Classification between mocks, fakes, and stubs is highly inconsistent across the literature. Consistent among the literature, though, is that they all represent a production object in a testing environment by exposing the same interface."
Вы испольуете не тот же (по имплементации!) сервис, что в продакшне — вот и вам и мок (ну или test dummy, или stub, если хотите, смысл не меняется).
тут же нет имитации
Как это нет? S3 — это конкретный сервис развернутый Амазоном. А то, что вы видите в докере — это что-то, что поддерживает тот же API и ту же функциональность (и, вполне возможно, с определенными ограничениями).
khim
11.01.2020 19:46в типах нельзя например выразить стейт, хранимый в БД
В настоящей БД — нет. Но можно сделать тип, который будет до вызова функцииperformбудет удовлетворять одному набору условий, а после вызова — другому. Для того, чтобы превратить тесты в типы — этого будет достаточно.
Но в результате вы, фактически, породите себе compile-time базу данных, compile-time mock GUI и массу всего в том же роде.
А я сравнивал на простейших алгоритмах — и в clang и в gcc compile-time исполнение программы примерно на три-четыре порядка медленнее, чем у скомпилированной программы.rsync
11.01.2020 19:49Но в результате вы, фактически, породите себе compile-time базу данных, compile-time mock GUI и массу всего в том же роде.
проблему mock'ов знаете главную?
консистентность с реальным миром
0xd34df00d
11.01.2020 19:34Если у вас достаточно «сильная» система типов (C++, в принципе, уже достаточен) — то вы любой unittest, в принципе, можете выразить в типах…
C++ для этого слабоват, боюсь.
Ну просто потому что если вы добъётесь того, что у вас всё-всё-всё прописано в типах, но однократная компиляция вашей программы занимает два дня…
Или прогон тестов будет занимать два дня.
Хотя, не могу не признать, что мне иногда хочется впилить в хаскелевский и идрисовский тайпчекеры что-то вроде jit.
khim
11.01.2020 20:02C++ для этого слабоват, боюсь.
Для Mock'ов достаточен. Засовываете данные вconstexpr char[], параметризуете этой переменной свой тип — и добавляете туда все свойства, какие вам нужны.
Дальшеstatic_assert'ами можно любые unit test'ы описать.
Практического смысла в этом, впрочем, нет: во-первых у вас весь-весь-весь код должен будет стать параметризуемым, чтобы этот подход можно было применить, во-вторых сообщения об ошибках будут такими, что понять из них — где ошибка это ещё два дня потребуется, на этот раз уже человеческих…
Это как с доказательством Теоремы Бёма — Якопини: да, любой алгоритм может быть, чисто механически, превращён в структурный вид — но это не значит, что его станет легче понять… так и любой unit-test можно «перегнать в типы»… но не факт, что после этого что-то станет кому-то понятнее… скорее наоборот.0xd34df00d
11.01.2020 20:06Для Mock'ов достаточен. Засовываете данные в constexpr char[], параметризуете этой переменной свой тип — и добавляете туда все свойства, какие вам нужны.
Я позабыл, как там в уже готовых версиях C++ с компилтайм-выделением памяти, компилтайм-векторами-хешмапами, и так далее?
khim
11.01.2020 20:29Я позабыл, как там в уже готовых версиях C++ с компилтайм-выделением памяти
Аллокаторы уже есть, вроде. Но их можно и симулировать.
компилтайм-векторами-хешмапами
А вот это — ушло в C++23. Но это стандартная библиотека, её можно «у себя» сделать какую угодно, язык для этого менять не нужно.
0xd34df00d
09.01.2020 19:23Один из наиболее хорошо показыавющих обратное примеров из моей практики — один недокомпилятор, что я в своё время писал. Там юнит-тестов вообще не было, были только интеграционные тесты — у меня было что-то вроде спеки на поведение компилятора в виде документации для конечных пользователей с примерами кода на языке, плюс некоторые граничные случаи, которые я сам придумал.
Соответственно, были тесты, что фронтенд парсит то, что надо парсить, и не парсит то, что не надо парсить. Были тесты, что сообщения об ошибках имеют смысл. Были тесты, что оптимизатор не меняет семантику кода (хотя там я пожалел, что не имел более выразительного языка, где я мог бы это формально доказать). Были тесты, что весь пайплайн (от фронта до сгенерированного беком кода) на соответствующих входах выдаёт ожидаемый результат (по факту тоже взято из доков для поьзователей).
При этом покрывать каждый юнит юнит-тестами? Зачем? Практика показала, что если продумать типы и за ними следить, то юнит-тесты писать не нужно.
rsync
09.01.2020 19:29https://habr.com/ru/post/483218/#comment_21107822
вообще чистых Юнит-тестов редко бывают. Изолировать скажем функцию сохранения данных в БД от БД невозможно. Поэтому практически любой тест чаще всего… интеграционный.
Мне поэтому не нравится разделение тестов на юнит-тесты и интеграционные тесты.
инструмент написания тестов один и тот же.
в python — это например pytest.
в perl — Test::More и так далее
отдельно но рядышком с тестами стоит система CI подымающая это самое окружение (базы данных итп)
как-то так (должно быть)
0xd34df00d
09.01.2020 19:34Я до сих пор не очень понимаю, чем юнит-тесты от интеграционных отличаются (разные люди говорят разное), так что исхожу из такого интуитивного понимания.
Код пишется, чтобы решать задачу. Если мы тестируем, как он решает задачу (что выплюнутый компилятором бинарь производит нужные действия на нужном входе), то это интеграционный тест.
Если мы тестируем какую-то внутреннюю деталь реализации, которая в воображаемом ТЗ не написана (что, условно, упрощение и минимизация стейтмашины её не ломают), то это ближе к юнит-тестам.khim
09.01.2020 20:10Я отношу к юнит-тестам всё, что нельзя проверить через «официальный» интерфейс разрабатываемого модуля.
То есть если разбить задачу на много-много мелких модулей, описать что каждый из них делает и зафиксировать это в документации — то у вас все тесты станут интеграционными… только возможность что-то рефакторить окажется дико затруднена, так как вам, после этого, нужно будет править и тесты и документацию… и только потом — код.
EvgeniiR
10.01.2020 10:48Я до сих пор не очень понимаю, чем юнит-тесты от интеграционных отличаются (разные люди говорят разное)
Чёткого определения и нет, так ведь не только с юнит тестами.
По сути основное момент в том что за счёт тестирования маленьких изолированных кусков кода мы всегда можем сказать где ошибка если тест упал.
Это тесты которые в первую очередь близки к коду и интересны исключительно разработчикам.
Их используют вместо интеграционных и пр. так как они:
— Быстро выполняются
— Позволяют покрыть все пути выполнения кода(потому что методы с ветвлениями if/case etc.) тестятся изолированно друг от друга.
— Позволяют представить удобство пользования новым модулем с точки зрения клиентского кода, и влияют на качество кода если следить за сложностью тестов/количеством моков и т.п. Если юзать TDD то удобство интерфейса вообще ставится во главу угла.
То есть хорошо покрытый unit-тестами метод, это в идеале метод у которого ими покрыты все ветвления, все ожидаемые исходы.
Всякие практики проектирования действительно могут окупиться если проект развивается и масштабируется(масштабируется разработка, нужно вводить людей, ограничивать количество связей, коммуникаций и зависимостей), и эти практики применяются вдумчиво и по назначению.
А многие любят просто всё усложнять, и получаются все эти лозунги мол «дизайн/тесты etc. не нужны / не окупаются» или натягивания совы на глобус.
Самое интересное что можно глянуть, наверное, вот — www.youtube.com/watch?v=VDfX44fZoMckhim
10.01.2020 17:32А многие любят просто всё усложнять, и получаются все эти лозунги мол «дизайн/тесты etc. не нужны / не окупаются» или натягивания совы на глобус.
Вот только у разных людей понятия над тем, что такое просто и что такое сложно — разные.
Пример из жизни. Жил-был модуль, в нём было порядка 100'000 строк кода и порядка 1000 тестов. Я его переписал и создать один ragel-файл на 5'000 строк кода и один тест (перебирающий все возможные случаи на основании файла-спеки от вендора).
Это усложнение или упрощение? Мне казалось что всё стало проще (и статистика это подтвердила: после переписывания единственная ошибка, в этом модуле найденая, оказалась связана с тем, что железяка не соответствовала спеке), однако у адептов TDD было ровно противоположное мнение (даже несмотря на то, что ошибок в этом модуле до моего вмешательства было найдено и исправлено… в количестве).EvgeniiR
10.01.2020 17:45Вот только у разных людей понятия над тем, что такое просто и что такое сложно — разные.
Ну, не противоположные, но от ситуации зависит, да. Вопрос лишь в стоимости поддержки всего добра, и пусть команда оптимизирует как ей нужно.
Пример из жизни. Жил-был модуль, в нём было порядка 100'000 строк кода и порядка 1000 тестов. Я его переписал и создать один ragel-файл на 5'000 строк кода и один тест (перебирающий все возможные случаи на основании файла-спеки от вендора).
Это усложнение или упрощение?
Если в нём было легко разобраться и легко вносить нужны изменения — вопрос зачем вы его переписывали.
Полагаю что раз переписали, проблемы с предыдущим были. Тогда вопрос лишь в том помогло ли переписывание от этих проблем избавиться.
Если обучить нового человека работать с новым инструментом несложно, и поддерживать систему стало проще то всё отлично.
однако у адептов TDD было ровно противоположное мнение (даже несмотря на то, что ошибок в этом модуле до моего вмешательства было найдено и исправлено… в количестве).
Адепты, такие адепты. Тесты не самоцель, вот и всё.
Почему я говорил про натягивание совы на глобус — я склоняюсь к тому что в подавляющем большинстве проектов, чтобы сделать их сильно более пригодными к поддержке и развитию, нужны не какие-то сложные архитектуры, не заученные определения паттернов и принципов, которые люди пытаются туда впихнуть, не тесты сквозь зубы, а, блин, минимальная адекватность и понимание что для чего делается, и небольшой ресёрч доступных инструментов.
То есть, конкретнее — перестать лепить всё в большие процедуры(и избавляться потом от дублирования наследованием и прочим), сокращать количество зависимостей — то есть минимально научиться в декомпозицию и слабо-зависимые модули.
Вобщем, то дойти до мидлварь, по аналогии с докладом Марко — www.youtube.com/watch?v=MjpiHy_e8kQ&list=LLd6OFj5xQf9ZhwBb4EVbdSw, а не распилить всё на микросервисы и т.п., как делают некоторые(или многие, статистики нет).
Более сложные решения — по мере надобности.khim
10.01.2020 18:01Если в нём было легко разобраться и легко вносить нужны изменения — вопрос зачем вы его переписывали.
Это был ключевой элемент безопасности системы и, соответственно, любая ошибка в нём была потенциальной дырой в безопасности.
Тогда вопрос лишь в том помогло ли переписывание от этих проблем избавиться.
Как показали дальнейшие несколько лет — помогло.
Если обучить нового человека работать с новым инструментом несложно, и поддерживать систему стало проще то всё отлично.
Ну… скажем так: что-либо изменить и надеяться что оно будет работать — стало сложнее. Потому как «ручек» для управления стало меньше и любое изменение требовало не написания простенького теста, а изменений в спеке (одной из двух: одной — пришедшей от безопасников, другой — от «железячников»). Но все нобходимые за последующие несколько лет изменения были, в конечном итоге, сделаны.
Вопрос «стало бы поддерживать систему проще» — я бы отнёс к разряду философских: изменения стали даваться куда большей кровью, зато авралы и срочное выкатывание апдейтов при обнаружении очередной дыры — исчезли совсем.
Адепты, такие адепты. Тесты не самоцель, вот и всё.
Если тесты не самоцель — тогда почему вокруг них, «покрытия» и прочего столько шума?
EvgeniiR
10.01.2020 18:15Вопрос «стало бы поддерживать систему проще» — я бы отнёс к разряду философских: изменения стали даваться куда большей кровью, зато авралы и срочное выкатывание апдейтов при обнаружении очередной дыры — исчезли совсем.
Предположу, что стабильность релизов и спокойствие важнее скорости )
Адепты, такие адепты. Тесты не самоцель, вот и всё.
Если тесты не самоцель — тогда почему вокруг них, «покрытия» и прочего столько шума?
Так шум он вокруг того что модно.
Я, если что, ни сколько не имею ввиду что тесты не нужны. Просто в среднестатистическом проекте узкое место, ну, не они.
А некачественные тесты не сильно лучше их отсутствия(или вообще хуже).
В целом юнит тесты как средство хороши, и с темой проектирования находятся рядом, просто юнит тесты это следующий этап после определения чего нам вообще нужно.
0xd34df00d
10.01.2020 18:25ragel
О.
А у вас не было такого, что ragel пытался построить DFA с экспоненциальным взрывом числа состояний (для NFA известного вида)? Там можно как-то попросить его оставить NFA?
khim
10.01.2020 19:06А у вас не было такого, что ragel пытался построить DFA с экспоненциальным взрывом числа состояний (для NFA известного вида)?
Нет. Построенный автомат был большим (тысячи состояний), но не настолько большим, чтобы это стало проблемой.
Там можно как-то попросить его оставить NFA?
Вряд ли. Гораздо хуже что у него комбинация машин не работает как комбинация в математическом смысле.
Потому все тесты пришлось перенести на уже полностью построенную машину.
0xd34df00d
10.01.2020 18:23По сути основное момент в том что за счёт тестирования маленьких изолированных кусков кода мы всегда можем сказать где ошибка если тест упал.
Неочевидно. А если ошибка на границе двух маленьких изолированных кусков?
Ну вот один кусок кода ожидает положительное число, а другой кусок кода иногда возвращает отрицательное число. Их писали два разных программиста, и они оба свои маленькие кусочки протестировали хорошо, но иногда, на некоторых данных получается так, что ну вот не состыковываются эти кусочки.
EvgeniiR
10.01.2020 23:22По сути основное момент в том что за счёт тестирования маленьких изолированных кусков кода мы всегда можем сказать где ошибка если тест упал.
Неочевидно. А если ошибка на границе двух маленьких изолированных кусков?
Ну вот один кусок кода ожидает положительное число, а другой кусок кода иногда возвращает отрицательное число. Их писали два разных программиста, и они оба свои маленькие кусочки протестировали хорошо, но иногда, на некоторых данных получается так, что ну вот не состыковываются эти кусочки.
Ну,словить баг, написать тест, залить хотфикс, написать постмортем…
если прям запариваться, можно при вызове метода с конкретными аргументами известными при написании кода пойти написать юнит тест с таким значением.
Если значение не известно, понятно что гарантий нет, но если покрыты тестами ветвления и граничные условия шансы словить такой баг не очень велики.
А если вы про возможность доказать типами — мне нравится, да. Я начал ради интереса Хаскель тыкать, но в продакшн то всё равно пишуна пхпне на нём, приходится стат. анализом обмазываться.0xd34df00d
10.01.2020 23:54Ну, словить баг, написать тест, залить хотфикс, написать постмортем…
если прям запариваться, можно при вызове метода с конкретными аргументами известными при написании кода пойти написать юнит тест с таким значением.Ну так проблема в том, что метод ожидает положительное число (квадратный корень из него считает, например, где-то в процессе), а ему передали отрицательное. На что тут юнит-тест писать?
А если вы про возможность доказать типами — мне нравится, да. Я начал ради интереса Хаскель тыкать, но в продакшн то всё равно пишу на пхп не на нём, приходится стат. анализом обмазываться.
Ну из хаскеля так себе средство для доказательств, но да, лучше, чем ничего.
EvgeniiR
11.01.2020 00:51Ну так проблема в том, что метод ожидает положительное число (квадратный корень из него считает, например, где-то в процессе), а ему передали отрицательное. На что тут юнит-тест писать?
На клиентский код. Либо требовать модуль с расчетом как зависимость и мокать в тестах, проверяя что он вызывается с корректными данными (я бы скорее всего не стал, кстати, тут получается неоднозначно, есть некоторый порог ожидаемой стабильности вызываемого кода), либо просто надееяться что на одном из тестов покрывающих клиентский код эта ситуация произойдет и тест на него упадёт.
0xd34df00d
11.01.2020 17:56А можно просто выразить в типах неотрицательность входного числа, и плохой код не соберётся :]
EvgeniiR
11.01.2020 18:23А можно просто выразить в типах неотрицательность входного числа, и плохой код не соберётся :]
Если в экосистеме ЯП на котором я пишу в прод было бы что-то мощнее чем пара не очень популярных стат. анализаторов я бы непременно этим воспользовался, а так увы.
BugM
11.01.2020 02:25Какое хорошее определение. Надо запомнить.
Юнит тесты реально нужны для сложных или неочевидных кусков кода. Понятно что таких лучше избегать, но как-то не всегда получается. Все остальное отлично покрывается интеграционными тестами.
У интеграционных есть один минус. Они сильно повышают требования к разработчикам. «Написать ерунду и если тест упадет перепишем» и так до всех работающих тестов уже не выйдет. Интеграционные тесты часто работают по много часов и место ошибки показывают очень примерно. Искать ими ошибки накладно по времени.khim
11.01.2020 03:23У интеграционных есть один минус. Они сильно повышают требования к разработчикам.
А разве это не плюс?
«Написать ерунду и если тест упадет перепишем» и так до всех работающих тестов уже не выйдет.
А надо? Сколько раз видел применение этого подхода — кончалось всё всегда одинаково: получается «всё ещё ерунда… но теперь с тестами».
Это, конечно, отличная вещь для «эффективных манагеров», которые могут на этом демонстрировать разнообразные красивые графики с разными KPI… но бизнесу это не нужно.
Если у вас есть конкуренты, к которым реально можно уйти — то с кучи… добра, сыплющего во все стороны сообщениями об ошибках при малейшем отходе пользователя от «магистрально-протестированной линии» люди таки рано или поздно уйдут.
А если конкурентов нет — то можно вот вообще всех этих «эффективных манагеров» с «дешёвыми разработчиками» убрать — и здорово увеличить прибыль.
Юнит тесты реально нужны для сложных или неочевидных кусков кода. Понятно что таких лучше избегать, но как-то не всегда получается.
Там где не получается — лучше подумать как разбить задачу на несколько отдельных компонент и описать реальный интерфейс между ними.
Который, соотвественно, уже и протестировать.BugM
11.01.2020 18:54А разве это не плюс?
Ну для кого как. Нанимать кого подешевле и прикрываться тестами это вполне рабочая и часто встречающая стратегия.
Нанимать кого получше во первых дорого, а во вторых еще найти надо.
На рынке нет достаточного числа хороших безработных разработчиков.
Там где не получается — лучше подумать как разбить задачу на несколько отдельных компонент и описать реальный интерфейс между ними.
Который, соотвественно, уже и протестировать.
Да да. Но ситуации разные бывают. И сроки горят, и на рефакторинг времени нет и вообще делать некому. Писать сложно и непрозрачно и прикрываться тестами иногда приходится. Главное чтобы это правилом не становилось.
WoWkiler_11
09.01.2020 15:18Написано слишком общо. Эти пункты подходят к большинству профессий, подразумевающих умственный труд.
rrMice
09.01.2020 15:19Странный пост, если честно. Без данных навыков нельзя стать хорошим специалистом вообще (врач, ученый, журналист...).
bat654321
09.01.2020 15:19У меня нет этих признаков, и всё равно — я плохой программист.
Бодо Шифер считает, что всему основа — самодисциплина. Без неё не работает ничего.
Roston
09.01.2020 15:25Список вообще универсальный. Если изменить расшифровку каждого пункта — применимо к любой профессии.
gdt
09.01.2020 15:43Внезапно статья по делу (среди моря статей про N признаков чего-либо). На самом деле мало быть умным/одарённым и т. д. — для достижения любого результата нужно упорно трудиться. Каждый пункт имеет смысл. Конечно, можно научиться что-то кодить и не имея вышеописанных признаков, стать грамотным разработчиком — вряд ли.
iago
09.01.2020 15:58Пролистывая тезисы, увидел
2 | Вам не хватает самостоятельности и находчивости
7 | Вы не способны думать самостоятельно
Скажите, стоит читать или снова вода на киселе?
kreo_OL
09.01.2020 16:16Что есть — хороший программист?
taujavarob
09.01.2020 21:16Программист которого увольняют в последнюю очередь. (С)
dzsysop
09.01.2020 21:33Так себе критерий.
При наличии начальника дурака, первыми на увольнение как раз будут хорошие программисты не умеющие лизать зад и имеющие отличную от начальника точку зрения.
Neifmetus
09.01.2020 18:33Список признаков выглядит очень субъективным и категоричным. Как известно без труда ничего не получится, но для того, чтобы стать хорошим программистом не обязательно иметь несколько маниакальный подход к работе (после 10 пунктов создается образ киборга-программиста, в жизни которого есть только работа). Например, можно сравнить Теслу и Эдисона. Один был более одержим наукой, другой пытался свою работу, скажем так, монетизировать. Но нельзя же сказать, что один хороший инженер, а другой плохой
khim
09.01.2020 19:02Но нельзя же сказать, что один хороший инженер, а другой плохой
Можно. Тесла — гениальный изобретатель, но плохой инженер. Эдиссон — менее прозорливый изобретатель, но куда лучший инженер. Что позволяло ему доводить до ума даже не самые лучшие идеи. Посмотрите на результат войны токов: объективно не самый лучший вариант, использованный Эдиссоном, тем не менее, прожил десятилетия и дожил до наших дней.
В то же время Тесла, несмотря на всю гениальность, так и не смог разработать «всемирную систему».
Один был более одержим наукой, другой пытался свою работу, скажем так, монетизировать.
Он не был «одержим наукой», к сожалению — иначе от него бы научные труды остались. Он был одержим конкретной задачей, которая, похоже, в те годы не могла быть решена (если она может быть решена в принципе). Тут он очень похож на Эйнштейна, который вложил в попытки объединить теорию гравитации и квантовую механику многие годы… но не добился, в результате, ничего. Но для науки это нормально… а для инженерии — нет. Умение сказать «это, в настоящее время, невозможно» и начать делать что-то,
что, в настоящее время, таки можно сделать — важное умение для инженера…Neifmetus
09.01.2020 20:04Я оценивала по пунктам выше и они оба подходили под все (8й с натяжкой, тут сложно оценить вообще подходит ли человек под него или нет). И получалось странно, подходят оба, а хороший один. Опять же вопрос: а хороший, это какой?
Умение сказать «это, в настоящее время, невозможно» и начать делать что-то,
что, в настоящее время, таки можно сделать — важное умение для инженера…
Довести до конца… Играясь с гипотезами, можно до конца и не довести. Если он примет, что «это невозможно» — можно говорить об узости мышления. А может он выдвинул гипотезу, довел до конца, а любознательности не проявлял, тогда он тоже плохой?
adictive_max
09.01.2020 19:22Изучая что-то новое, очень часто мы чувствуем что наших знаний и опыта недостаточно для того, чтобы иметь собственное мнение. Выступить с инициативой, сделать или сказать что-то неправильно кажется очень рискованным.
Может я чего-то не понимаю, но мне всегда казалось, что «изучая что-то новое» — это просто по определению обозначает, что у вас недостаточно знаний для обоснованного мнения.
kotov666
09.01.2020 20:18Как же в Бейсике было просто и понятно все, казалось все так логично, а сейчас даже в синтаксис тяжело вникать, особенно когда только только начинаешь.
Dron007
09.01.2020 20:55Многое справедливо, но почему-то нет ни слова о математически-логическом складе ума. Конечно, что-то развивается, но есть и предрасположенность. Считаю, идеальный тест на способность к абстрактной логике это тест про «летающих начальников». Можно так и найти по фразе «хорошие начальники не летают». Там есть пара вопросов с небольшой неоднозначностью — зависит от формулировок и связано с неоднозначностями самого языка. Но в целом очень хорошая проверка.
vvf1973
09.01.2020 20:55программирование, имхо, — это не какая-то особенная профессия, и 10 признаков, перечисленных в статье, подходят ко всем остальным профессиям, не связанных с монотонным трудом, да и к монотонному труду это тоже в общем-то можно отнести: конвейерная сборка, мойщик посуды, уборщик — результаты разные получаются как раз по многим из 10 признаков. В любом случае, по крайней мере, в России в всех профессиях подавляющее большинство людей — это случайные люди, мало соответствующие своей профессии, своим должностным обязанностям. Увы и ах.
retar
09.01.2020 20:55Правильнее назвать:«10 признаков того, что хороший специалист в выбранной вами области из вас не получится».
Emulyator
09.01.2020 22:21Локальный конкурс вопрос-ответ (победитель по лайкам).
Вопрос:
Что делать, когда вроде все признаки имеются много лет, а хорошим программистом себя не ощущаешь?centralhardware
09.01.2020 22:39+1Избавиться от синдрома самозванца и начинать оценивать объективно, Барух про это лучше расскажет
rrrrex
09.01.2020 22:47О каких деталях речь, чему надо уделять внимание, если сейчас большая часть кода скрыта в фреймворках.
lair
09.01.2020 23:04Во-первых, у фреймворка тоже есть детали. Во-вторых, это куча инфраструктурного кода скрыта в фреймворках — как раз чтобы вы могли уделять внимание деталям прикладного.
sergeperovsky
09.01.2020 23:10Из вас не получится хороший железнодорожник…
Постойте. Какой именно железнодорожник? Машинист? Проводник? Составитель поездов? Диспетчер? Билетный кассир? Ревизор? Для этих профессий нужны очень разные качества.
Разработка ПО не менее разнообразная отрасль, а всех нас чехом называют программистами. И каждый считает НАСТОЯЩИМ ПРОГРАММИСТОМ именно себя и с этой точки зрения рассуждает о необходимых качествах и навыках.
decomeron
10.01.2020 07:05Заголовок спойлераNikita_Danilov
10.01.2020 11:27Уточню (обращу внимание) пункт «Бонус» — автор подразумевает именно тех, кто в первую очередь ориентирован на создании бизнеса — очень быстро такому человеку надоест копаться в техническом утройстве инструмента. Здесь соглашусь.
Однако, как и говорится в 3м пункте: «Суть программирования есть решение проблем». Опять же соглашусь, на мой взгляд, программист-практик обязан держать в голове решаемую проблему бизнеса из реального мира, а не фокусироваться на абстрактном творческом процессе.
vladdimir
10.01.2020 12:15Вода. Все это актуально для любой профессии или навыка. К тому же, это состояния человека, которые часто меняются.
Иногда мне плевать, как и что работает, главное — чтобы работало. Иногда я теряю ход времени, копаясь в исходниках.
В некоторые моменты, я искренне считаю, что программирование не для меня. В другие — наоборот.
Не все проблемы я могу решить самостоятельно. И т.д.
Сейчас, в профориентации (и психологии, и философии также) доминируют гуманистические взгляды, суть которых в том, что успех в чем-либо зависит не от предпосылок (исходных характеристик, предрасположенности, задатков, таланта и т.д.), а от мотивации и волевой сферы.
Кратко: если очень хочется, то получится.
Думать так — это конструктивно. Но совершенно не учитывать возможности и ограничения исходных данных — губительно.
Как по мне, есть 2 ограничения:
1. Олигофрения.
2. Слепота и повреждение рук.
Впрочем, некоторые физические ограничения тоже можно обойти, если прям очень сильно хочется. На счет легких и пограничных форм умственной отсталости — писать код можно, как конструктор собирать, но вряд ли получится глубоко вникнуть в сложные абстрактные концепции.
Все остальное — преодолимо.
Griboks
Интересное мнение. Однако, нельзя написать две точки входа в одной программе. Всегда есть реализованное решение и остальные. Если вам кажется, что существует целый спектр «хороших» решений, значит вы недостаточно глубоко изучили вашу конкретную задачу. Всегда есть обстоятельства, иногда даже не связанные с программированием, которые выделяют из хороших то самое единственно верное решение.
justhabrauser
Единственно верное решение — это "2 x 2 = 4".
Все остальные решения — это компромиссы.
innovaIT
С этим тоже можно поспорить. Гораздо быстрее будет.
0010<<1
fougasse
Далеко не факт, плюс, на 0 в некоторых языках программирования начинаются восьмеричные числа.
gatoazul
Компьютеры бывают не только двоичные.
khim
А это — зависит от языка. В Python умножение быстрее, чем сдвиг, например.
innovaIT
Надо будет по внимательней ознакомиться. На сколько помню, сдвиг бита выполняется за один такт, а умножение за 4. Это для x86. Почему в питоне по другому не понятно. Что там такого можно было накрутить?
khim
По ссылке ходить не пробовали? Там написано.
innovaIT
Пробовал. С первого раза не осилил. Имею полное среднее. Дальше не учился. Только собираюсь. Для меня длинная арифметика — это филькина грамота. Сейчас понял так, что даже к целому числу в питоне сдвиг применяется как к максимально возможному поддерживаемому числу в питоне. Соответственно проц может предугадать ветвление и умножение, выполнится быстрее чем сдвиг. И теперь до меня начинает доходить мысль: Я ненавижу динамические ЯП. На входе вечно пишешь typeof. В переменную добавляешь её тип. И вечно ловишь непредсказуемый глюки. Правда только по своей вине. Почему столько холивара между статический типизацией и динамической? Чего я не понимаю в этом? Статика же во многом лучше?! Ни в одной статье не смог найти плюсы динамики. Может плохо искал?
khim
Скорее не там искали. Используя динамические языки сложнее написать код, который всегда работает корректно, но проще написать код, который иногда работает корректно.
Соответственно быстрее закрываются таски, проще получать премии и так далее.
А иногда 100% корректность не нужна в принципе: например вспомогательные скрипты, используемые для сборки программы — если они как-то отрабатывают на ваших данных, которые у вас есть и дают правильный результат… то вам же неважно что они сделают с другими данными, которых у вас нет!
FreeNickname
Лайфхак: зайти по ссылке и ввести в поиске по странице слово «сдвиг»)
innovaIT
И что это даст. Я прочитал про сложную арифметику. В моем мире её нет. Есть 1С, которая меня от этого огораживает, и даже мешает понять. Есть ПЛК. Там все просто. Сдвиг это быстро, умножение требует ресурсов проца. Понять с лету я не могу.
kraidiky
Правильнее говорить по другому: Питон на столько медленный и длинный, что в нём даже сдвиг медленнее, чем умножение.
OstinWeatherbee
просто для сдвига используется два символа, а для умножения — один
dmrt
Еще быстрее будет просто: 4
dimaaan
В некоторых системах счисления может получиться не 4, а 10 или даже 11 :)
Lure_of_Chaos
А то и syntax error «operation 'x' is not defined» [:
justhabrauser
Здесь человек привык принимать Единственно Верные Решения ™ — а вы со своими троичным и четверичными системами…
innovaIT
Вы сами себе отвечаете?
GokenTanmay
Предлагаете использовать «единичную» систему?
aikixd
Микросервисная архитектура. По сервису для каждой задачи:
2 х 2,
2 х 3,
2 х 4...
0xd34df00d
Математики так и делают. Вот это вот Z и S — это они.
Bedal
зачем так примитивно? Система исчисления с основанием е — куда забавнее.
fougasse
10 в любой системе счисления 10 ;)
Atrax
Кроме единичной, всех непозиционных и не использующих арабские цифры.
Если уж на то пошло.
fougasse
del
khim
Позиционная система с основанием 1. Дробных чисел в ней нет, а целые — без проблем. Нуль == пустая строка.
Calm12
10 в любой системе счисления — это ее основание.
Lure_of_Chaos
кроме единичной :D
rsync
единичной системы не бывает, поскольку в любой системе должен быть 0 и число от него отличающееся.
соответственно минимальная система счисления — двоичная: состоит из 0 и 1
единичная система состоит из одних нулей и бессмысленна
Lure_of_Chaos
не спешите. вот она:
0: _
1: 1
2: 11
3: 111
4: 1111
5: 11111
и т.д.
вот что вики знает: Унарная система счисления
rsync
нуля нет — практического смысла не имеет, о чем я и говорил
обучение детей счету о котором упоминается: надо вспомнить что обучают на палочках счету в десятичной системе, а не единичной
то есть похожесть != использование
0xd34df00d
Вам там не совсем корректно сказали.
0: Z
1: SZ
2: SSZ
3: SSSZ
и т. д.
rsync
S и Z — два знака. а в единичной системе возможен только один знак.
ни в какой другой системе счисления не используется «отсутствие цифры» как обозначение нуля. А тут натянуто за уши.
использование «отсутствие цифры» для обозначения цифры говорит о неполноте «системы счисления» и следовательно её бессмысленности.
так же в этой системе счисления невозможна (формализация) операция деления без перехода к другим системам счисления
0xd34df00d
Z может быть только в конце строки и имеет по большей части техническую роль. Значение числа зависит только и исключительно от количества S в строке.
Короче, можете выкинуть Z.
Почему?
Система счисления — это всего лишь представление.
mayorovp
В любой системе счисления, имеющей основание и цифры 1 и 0, так точнее.
ilmarin77
найдите точное численное решение задачи X*X=2, без компромиссов пожалуйста.
pyur
x = sqrt(2)
syrslava
одно?)
ilmarin77
для любителей задача сложней, X*X*X=3
soniq
public int X { get { if (!x) { x = true; return 3; } return 1; } }
NeocortexLab
ответом является «трижды обрезанный»… а уж почему его так порубали — загадка
Griboks
Вы не поняли смысл моего сообщения. Я об этом и написал, что из множества решений, удовлетворяющих требованиям, всегда можно выделить одно, наиболее оптимальное в данной ситуации.
А если кто-то из этого множества выбирает рандомное решение (они все кажутся одинаковыми), значит он просто не достаточно детально изучил данную ситуацию.
Nalivai
А еще таких решений может быть несколько, и они правда могут быть одинаковыми. А могут быть оптимизированны по разным параметрам. А еще их может совсем не быть.
Griboks
Нет, оптимальное решение всегда одно, оптимизированное по всем параметрам сразу, и оно всегда существует.
Crazyvlad
Как же скучно жить в черно-белом мире…
всегда есть не нулевая вероятность получить несколько оптимумов при конечном количестве параметров.
Griboks
В том и дело, что эта вероятность стремится к нулю. В теории она нулевая, на практике — зависит от глубины исследования (стремится к нулю).
Prototik
Назовите любой алгоритм сортировки и вам назовут мильйон причин, в чём оно не оптимально.
soniq
Похоже на задачку буриданова осла, если честно. С сортировкой-то что не так? Если нет убедительных причин поступить иначе: берите sort из стандартной библиотеки, и не надо ничего выдумывать.
Dim0v
С сортировкой не так то, что сортировать можно очень разные данные и в очень разных условиях. Массив из 10 элементов эффективнее будет сортировать вставками. Из 10 миллионов элементов — квиксорт (если массив упорядочен случайно). Для 3 элементов эффективнее будет нахардкодить дерево из ифов. Если подключить сюда еще размер данных для сортировки (просто инты или 10-мегабайтные структуры?), тип структуры контейнера (массив или односвязный список?), характер данных (почти отсортированные? Случайно упорядоченные? Отсортированные в почти-обратном порядке?), то количество оптимальных для каждого отдельного случая алгоритмов растет еще больше.
sort из стандартной библиотеки — это компромисс, который good enough для самых распространенных случаев. Но даже в каждом из них — далек от оптимальности. Не говоря уже об искусственно созданных "плохих" входных данных, которые есть у любого алгоритма сортировки.
soniq
Он не просто good enough, у него еще и нулевая стоимость поддержки и реализации. Если, конечно, ваш продукт это не разработка и поддержка популярного фреймворка или этой самой стандартной библиотеки.
Dim0v
"Нулевая стоимость поддержки и реализации" не равно "оптимально по всем параметрам". Помимо стоимости поддержки и реализации есть и другие параметры. Часть из них я упомянул в своем комментарии.
soniq
А, у вас какое-то своё толкование задачи оптимизации. В классическом смысле это поиск минимума (или максимума) некоторой функции от этих самых параметров. Как правило, эта функция: полная стоимость решения с учетом ограничений. И в очень редких случаях sort не подходит, или не оптимален.
Dim0v
Нет, у меня толкование вполне классическое.
Что конкретно входит в "полную стоимость решения с учетом ограничений"? И с какими весами?
И, как сказал Prototik, можно назвать мильйон таких "редких случаев", в которых библиотечный sort будет неоптимальным.
soniq
Видимо без примеров тут не обойтись. Если таких редких случаев «мильйон» не должно составить труда найти кейсы когда библиотечный сорт не подошёл. В интернете куча исходников популярных проектов, не библиотек, с большим количеством контрибуторов.
Найдёте хотя бы три?
Dim0v
Труда действительно не составляет. Правда не могу понять, чем вам не угодили библиотеки. Но да ладно.
https://github.com/git/git/blob/master/pack-revindex.c#L27
https://github.com/torvalds/linux/blob/master/lib/sort.c#L199
https://github.com/antirez/redis/blob/unstable/src/pqsort.c#L99
А мой вопрос вы решили проигнорировать? Про количественный и качественный состав "полной стоимости решения с учетом ограничений".
soniq
Спасибо за примеры. У каждого из них есть история и на фоне миллионов ссылок на стандартные функции они отлично иллюстрируют мой тезис
Особенно мне нравится вот этот коммит в гит. Тут и исследование, и обоснование, и видно как начали со стандартной сортировки.
С ядром линукса тоже была увлекательная история. Только редис выбивается немного, сишный кусорт вполне способен посортировать в середине массива.
Я не знаю, про какие критерии вы хотите узнать. Серебряной пули нет, и в каждом конкретном случае функция стоимости и набор критериев будет отличаться. Если у вас задача опубликовать статью про новый алгоритм сортировки, то очевидно что никакой существующий алгоритм не подойдёт.
Dim0v
Я немного утратил нить вашего тезиса.
Все началось с сообщения о том, что в любом алгоритме сортировки (к слову, даже не в реализации, а именно в алгоритме) есть минусы и что для любого из них можно назвать множество примеров, где этот алгоритм не будет оптимальным. Вы в ответ стали возражать, зачем-то приводя в пример sort из стандартной библиотеки исходя из его превосходства по каким-то отдельным критериям, которые далеко не всегда имеют решающее значение и которые, вообще говоря, никак не относятся к алгоритму как таковому.
Теперь вот оказывается, что вы все таки не считаете библиотечный sort той самой серебряной пулей, которая оптимальна всегда и везде. И для него тоже есть множество примеров, где он не оптимален.
Можете тогда пожалуйста конкретнее прояснить, с чем именно вы не согласны и каков ваш посыл? Что зачастую можно написать std::sort и все будет хорошо? Ну да. Только с этим никто и не спорил и речь вообще о другом была.
soniq
Началось все с утверждения, что «для любой задачи существует оптимальное решение». Хочу заметить, что это не то же самое, что «существует оптимальное решение, подходящее к любой задаче». Первое утверждение я считаю верным, второе очевидно некорректно.
Конкретно про сортировки. Я не спорю, что есть разные алгоритмы с разными характеристиками. Но считаю, что в среднем программист скорее выиграет сто миллионов в лотерею и перестанет программировать вообще нежели ему придётся решать задачу где встроенная сортировка не подойдёт. И считаю неправильным употреблять для описания таких случаев эпитеты: «множество», «зачастую», «мильены».
iboltaev
Это скорее для квиксорта характерно, там от способа выбора опорного элемента много зависит. Хипсорт и мержсорт к такому устойчивы вроде.
Dim0v
Да, вы правы. С "у любого" я слегка погорячился.
Но общий посыл от этого не меняется — не существует серебряной пули, которая будет одинаково эффективно сортировать любые данные в любых условиях. Даже если речь о sort-е из стандартной библиотеки (любого языка).
Dim0v
Мне нужно сложить 2 целых числа.
Можете назвать оптимальное решение, оптимизированное по всем параметрам сразу?
saboteur_kiev
Подумайте, откуда взялась поговорка, что «лучшее — враг хорошего».
Всегда есть несколько оптимальных и удовлетворительных решений.
Потому что оптимизировать по всем параметрам невозможно. Мы не живем в статичном мире.
killla
Нам преподаватели в институте по рукам били за такое применение термина «оптимальный».
Не бывает абстрактно оптимальных решений. Решение может быть оптимальным только по определенному критерию оптимальности. При этом по другим критериям это решение зачастую не будет оптимальным (например, по времени решения задачи).
dic.academic.ru/dic.nsf/ruwiki/1587468
Выбор критериев, назначение весов критериям, путь до решения — всё это весьма субъективно. Каждый человек будет решать задачу по-разному. Каждое решение будет оптимально по одному критерию и минимально удовлетворять остальным критериям ТЗ. И все решения будут «хорошими», т.е. рабочими.
qyix7z
Еще за применение термина «наиболее оптимальное» стоит бить. Оно либо оптимальное, либо нет. Нескольких оптимальных, из которых можно выбрать «наиболее» не существует.
Griboks
многокритериальная оптимизация
Субъективно? Вы наверное забыли, что речь идёт о проблеме выбора для субъекта. Очевидно, что его выбор будет субъективным) Я говорю лишь о том, что этот выбор может и должен быть обоснованным, единственным. Всегда есть обстоятельства, которые склонят чашу весов в чью-то пользу. Невозможно существование двух разных, но равных по значениям критериев решений.
khim
Мы не знаем как устроено железо, на котором это всё будет исполняться (потому что железо на котором мы начинаем всё это писать отличается от того, которое у нас будет к моменту, когда мы закончим), мы не знаем какие у нас будут данные к моменту, когда всё напишем (если бы знали всё в точности — то ничего писать было бы не нужно вообще) и так далее.
Знаете — тут так же, как с Колмогоровской сложностью. Торетически — она для любых данных существует. Практически — вычислить её нельзя.
Да, в одном случае невычислимость — фундаментальное математическое свойство, в другом — банальное следствие того, что мы не располагаем полной постановкой задачи в момент, когда начинаем её решать… но практически — следствие одно: нам приходится использовать какие-то другие методы.
P.S. Вообще вся эта дискуссия напомнила мне одну хорошо известную всем статью где говорится что, в сущности, от программиста требуется всего две вещи:
1. Толковый и
2. Доводит дело до конца
И там же был пример того, почему пункт #2 неверноятно важен: Толковые, но не доводящие дело до конца работники обычно просиживают ученую степень в больших компаниях, где их никто не слушает из-за их полной непрактичности. Они скорее станут думать об академическом подходе к проблеме, а не о выпуске продукта в срок. Их легко узнать по склонности к поиску теоретического сходства между двумя совершенно разными концепциями. Например, они могут заявить: «Таблицы — это, в сущности, частный случай языка программирования», а затем исчезнуть на неделю и написать потрясающую статью о теоретических атрибутах вычислительной лингвистики электронных таблиц как языка программирования. Круто, но бесполезно.
Вот ваше рассуждение про существование оптимального решения «для сферической задачи в вакууме» — оно из той же оперы. Формально — круто, чё… философы были бы довольны… а практически — совершенно бесполезно.
soniq
Так про то и речь. Если у вас куча неизвестных в задаче, и все решения кажутся на одно лицо — идите и изучайте ее подробней. Тогда выяснится, что одно решение не подходит по ограничениям, другое очень сложно реализовать, третье и вовсе не решает задачу. И у вас останется одно, то единственно лучшее, оптимальность которого вы сможете обосновать.
Griboks
Нет, вы ошибаетесь, это широко известная задача многокритериального выбора.
Дано несколько альтернатив (в нашем случае решений поставленной начальником задачи/проблемы), каждая из которых имеет значения по всем критериям. Необходимо выбрать одну альтернативу.
Далее составляется матрица альтернатив, выставляются весовые коэффициенты критериям, выполняется свёртка, альтернативы ранжируются и выбирается лучшая.
1. Матрица альтернатив содержит в столбцах альтернативы, в строках — критерии, а в пересечениях — значения каждой альтернативы по каждому критерию.
2. Каждому критерию приписывается весовой коэффициент. Выбор весовых коэффициентов — отдельная известная задача, для которой придуманы 5-10 разных методов решения.
3. Свёртка, в общем случае, может быть разной. В нечёткой логике обычно используется минимаксная, кто-то использует сумму и т.д. В данной задаче я бы использовал сумму.
5. Ну и в качестве целевой функции выбора из ранжированного списка альтернатив я бы использовал [f(c1,c2,c3,...)=a]>min.
Соответственно, я утверждаю, что всегда есть одна и только одна альтернатива, минимизирующая целевую функцию. Почему? Потому что в реальности критериев очень много, и мы может увеличивать их количество при надобности. Критериями выступают не только технические характеристики типа скорости, памяти, но и такие как: перспективы развития продукта, опыт, наличие инструментов разработки, шаблоны, целевая аудитория, знание языка/системы… Следовательно, вероятность совпадения значений целевых функций альтернатив для такого огромного количества критериев (на практике, начиная с 5) стремится к нулю.
А вот что вы утверждаете, я понять не могу.
soniq
По каждому отдельному критерию отношение порядка между решениями будет разным. В общем случае, не существует такого решения, которое было бы лучше всех остальных по каждому параметру отдельно.
Взять тот же latency/throughput. Обычно они связаны обратной зависимостью и улучшая одно — неизбежно ухудшаешь другое.
Из этого следует, что не существует универсального критерия на все случаи жизни, и программист уровня миддл должен уметь предложить разные варианты: с лучшим latency, с большим throughput, более дешевое в реализации и пр.
Lissov
Правильно — пока программист Петя будет составлять матрицу альтернатив и выбирать лучшее решение, задалбывая бизнес вопросами про весовые коеффициенты, программист Вася выбрал решение «примерно» и оно уже ушло в прод.
Посмотрев на это, менеджер Коля замечает, что выбор оптимального решения это тоже задача сама по себе. И по его «матрице альтернатив» для сайта-визитки оптимальным способом решения этой задачи является выбор «шестым чуством по опыту», а потому Вася молодец а Петю уволить.
soniq
С такими матрицами альтернатив Вася так и будет клепать сайты-визитки, а Петя через пару лет научится обосновывать свои решения быстро и убедительно. Так что его схантят обратно уже на директорскую позицию.
Griboks
А потом чуйка Васю подведёт его чуйка, прод упадёт, компания потеряет много денег, а Васю и Колю уволят.
А Петя тем временем напишет инструмент для составления матриц за 5 минут.
Lissov
Проблема не в инструменте для вычислении матрицы, а в выяснении весов, которые по определению может сказать только бизнес. Но при этом бизнес платит деньги Васе и Коле за опыт в принятии экспертных решений, и за то чтобы его спрашивали про веса только там, где бизнесу «важно». При этом чтобы они сами определяли, где именно «важно».
А академически верный подход Пети для бизнеса выглядит как саботаж и нежелание решить задачу. Потому из Пети не получится ни хороший программист, ни хороший директор.
soniq
Что важно для бизнеса, а что нет как раз и определяет эти веса параметров. Как вы собрались выяснять, что важно для бизнеса не спрашивая при этом, что ему важно?
Lissov
А можно я просто процитирую себя?
soniq
Если нам важен какой-то параметр, его вес будет больше чем у тех, которые не важны. Например, у параметра «научная новизна» при разработке сайта-визитки вес будет скорее отрицательный. При подготовке доклада на конференцию наоборот, больше многих остальных.
С параметром «стабильность в проде» ситуация противоположная, для доклада это не важно, и его вес равен нолю, а для визитки это критично.
Но определять, надо ли, и до каких пределов жертвовать параметром А в пользу параметра Б — это именно ответственность тех, кого мы тут называем «бизнес».
Иногда эти приоритеты долго не меняются и очевидны, тогда Коля может сэкономить пару минут на расспросах, но можно и спросить, никого никогда за это не увольняли. А вот истории, когда Вася сам попытался угадать что важно а что нет, но не спросил и в результате промахнулся — обычно заканчиваются очень печально.
Lissov
Из моего опыта, истории когда «Вася» выяснял и выяснял требования до мельчайших деталей и строго бездумно им следовал, заканчивались куда плачевнее. Правда, как правило только для «Васи».
Понятно, что нужен баланс. И высооплачиваемые специалисты за то и получают много, что в рамках своих компетенций много и хорошо «угадывают» (я бы скорее назвал это принятием решений, основанном на здравом смысле и опыте вместо строгого расчёта. Но можно и так). И чем выше должность и зарплата, тем больше свобода решений.
soniq
Мой опыт показывает, что если исполнитель здорово облажается с приоритетами, весом параметра в целевой функции, например ему скажут что прод критичен для бизнеса, а он там тестить начнёт потому что «а что такого-то?» то могут и уволить. Хотя такое случается редко, все же люди чаще склонны слушать что им говорят.
Если же он неверно предположит значение параметра целевой функции, например скажет что сделает за неделю, а провозится месяц — то обычно за это не наказывают вообще, просто не дают более ответственных задач.
saboteur_kiev
А если альтернатив будет не несколько а несколько сотен, пока вы все пересчитаете, конкуренты уже уйдут вперед на не самом оптимальном решении, а лидер вообще на костыльном, но зато через год он скупит всех окружающих для рефакторинга.
Такой критерий как «время принятия решения» очень сильно меняет приоритет практически всех других критериев, что порождает множество оптимальных решений, а не только одно.
soniq
Да, но все равно не понятно, как в дискретном пространстве решений может быть несколько глобальных минимумов целевой функции. Не всегда известно, как этого минимума достичь, где он находится, и даже что это за функция. Но минимум ?!.
shurricken
в коробке два шарика — черный и белый.
надо набрать максимальное количество шариков одного цвета.
Какой цвет набирать наиболее оптимальнее?))
sHaggY_caT
Не всегда. На поле
Галуа это не так. Да и если вычислять во float, не в каждом языке программирования 2*2 точно равно 4
Ну и про системы исчисления (двоичные, шестнадцатеричные, десятичные) выше уже написали. Так что таки спектр верных ответов, а не один ответ на все случаи жизни. Такие дела.
vectorplus
Можно реализовать через сложение :)
Vacxe
С определенной точностью вы правы
Flying
Обожаю комментарии на хабре, под комментарием "2x2=4" — пара десятков комментариев с аргументированными возражениями и контр-примерами, где ещё такое встретишь?
justhabrauser
Заметим, что исходный посыл ("Если вам кажется, что существует целый спектр «хороших» решений, значит вы недостаточно глубоко изучили вашу конкретную задачу") так сильно не возбудил.
perfect_genius
И как же здорово, что теперь есть возможность сворачивать ветки комментариев!
innovaIT
Вы сами ответили на свой вопрос.
Только я б переформулировал, лучшее. Но решений, в большинстве случаев, больше чем одно.
justhabrauser
"Лучшее" — по каким критериям?
"Мы делаем быстро, дешево и качественно. Выберите 2 из 3".
Выберите "лучшее".
innovaIT
Мы сейчас про программирование. Тут нету понятия быстро и дёшево. Есть проблема есть решения. Среди этих решений, есть лучшее, но не единственно верное. В моем понимании лучшее, это наиболее понятное и менее ресурсоемкое.
lair
Разве? Программирование — это активность, она занимает время. Следовательно, есть "быстро" и "медленно". Программирование так же требует ресурсов (и как активность, и как решения), и эти ресурсы могут стоить денег. Отсюда — "дорого" и "дешево".
Бывает так, что увеличение понятности приводит к увеличению потребляемых ресурсов. И как же выбирать "лучшее" в вашем понимании?
innovaIT
В контексте статьи, не идет речи про быстро, качественно, не дорого. Если брать в размерах продукта, да. Есть быстро и медленно. Дорого и дешево. Если брать в контексте простейшей задачи, при это знать ЯП достаточно хорошо, то может сложиться так что: быстро и хорошо и дешево. А лучшее, это как правило всегда компромисс. Тут даже можно добавить, что и ресурсоемкоть не так легко померить. В одном случае повышенное потребление ОЗУ, в другом, повышенное потребление процессорного времени и HDD/SSD.
lair
Почему? В статье речь идет об образовании, а в образовании тоже есть временные (и ресурсные) ограничения.
tretyakovmax
Это самое дешевое для заказчика при условии что оно хоть как-то работает
lair
Как вы меряете "самое дешевое для заказчика"? Самое дешевое в разработке, в работе или в поддержке? Что дешевле — сделанное за Х денег за год, или за 1.2X денег за месяц?
lamerok
Вы про просто хобби программирование? Хотя даже тут, можно вечно искать наиболее понятное и менее ресурсоемкое решение.
Я вот свой код 3 летней давности считал тогда простым и оптимальным. А сейчас смотрю и удивляюсь, как такая лажа в продукт шла? Но если бы я 3 года назад продолжил бы искать более оптимальное и понятное решение, то возможно, уже программистом и не был бы — уволили бы меня.
innovaIT
Я даже про обучение. Встаю в ступор на каждом шагу. Есть гайд, пытаешься ему следовать. А тебе попадается необъяснимое поведение в ЯП. Приходится отходить от гайдов и городить костыли.
lamerok
Это странно, потому что обычно все объясняется стандартом ЯП, иногда бывает необъяснимое поведение компилятора, но тогда скорее всего надо просто прочитать Errata на него.
innovaIT
Я сейчас завяз в яве/котлине. И у меня появилось куча вопросов про implements Runnable для котлина. Говорят так делать нельзя. А мне надо. Там еще и c++. Еж с ужом для 1С мобильной платформы. И вот на Яве я легко расширяю класс в runnable, а в котлине это не работает. Готового решения не нашел. Но да, я только учусь. Может еще не пришло просветление. Errata это больше к хардварной части. Ловил веселые глюки в codesys. При прямом обращении к биту состояния в слове, получал всегда 0(false). И только через промежуточную переменную все работало как надо.
zagayevskiy
Что именно нельзя и не работает? Пример кода, плз.
innovaIT
Про codesys? Овновский контроллер. Опрос модуля ввода и модуля вывода. mdo1_1.4 = mdi11_1.5. Так не работает. С начало мы ложим значение бита mdi в переменную, а затем подаём на выход. Так работает корректно.
AlexWoodblock
Я думаю, zagayevskiy спрашивал про Kotlin. Мне бы тоже было любопытно услышать, почему в Kotlin'е нельзя пользоваться Runnable — пользуюсь им часто и с удовольствием :)
Есть интересные случаи, на которые можно попасться, вроде описанного тут, но вообще никто не запрещает использовать Runnable так, как вздумается.
cyberly
А вот в веб-разработке… честно говоря, не могу вспомнить, чтобы мне попадалась Errata на что-либо, с чем я имел дело…
innovaIT
Ой. Вспомилось видео с javascript — www.youtube.com/watch?v=et8xNAc2ic8
cyberly
«менее ресурсоемкое» оно может быть в реализации, в поддержке или с точки зрения машинных ресурсов. Это уже три разных реализации. «Наиболее понятных» решений, если утрировать, тоже может быть несколько, в зависимости от бекграунда тех, кому они «понятнее».
innovaIT
В реализации и в поддержке — это я называю наиболее понятным. Ресурсоемкое — соответственно — машинные ресурсы.
lair
… ну то есть (периодически) весьма противоречащие друг другу вещи.
innovaIT
В чем противоречие? Красивая реализация, легка в поддержке. Или не так?
lair
Во-первых, не всегда красивая реализация легка в поддержке.
Во-вторых, далеко не всегда красивая или легкая в поддержке реализация потребляет меньше или хотя бы столько же ресурсов, чем некрасивая и сложная в поддержке.
innovaIT
Ну так на это я и написал. Компромисс. Всегда можно сложную реализацию обернуть в еще одну функцию/процедуру. С соответствующим комментарием. Что сюда нельзя, тут начинается магия. И не стоит это место трогать.
lair
Ну так компромис — это как раз когда вы балансируете между противоречащими друг другу вещами. Странно, что вы продолжаете спрашивать, "в чем противоречие".
Это как раз называется "сложно в поддержке".
innovaIT
Может не было очень больших проектов у меня. А в чем сложность поддержки в этом? В таких функциях/процедурах действительно магия происходит, но как правило они железо бетонные. Менять в них что то не приходиться. Ну или их хоронят. Заметил тенденцию, все что ранее написано, не трогают. А пишут новое. Дабы ничего не сломать.
cyberly
Ну так и пишут иногда «почти такое же, но более другое», в итоге получается зоопарк «одинаковых, но разных» функций, которые не очень понятно, чем отличаются. Добавляется лишний слой, единственная задача которого — решить, в каком случае какую из этих волшебных функций вызывать. «Чтобы ничего не сломать» превращается в основной принцип разработки и добавление любой мелкой фичи на 90% состоит из изучения вопроса, может ли она что-то сломать, где она может это сломать и как проверить, сломает ли. Никто толком не понимает, что как работает и как модули зависят друг от друга. Никто точно не уверен, что можно выбросить, а что нет.
innovaIT
Вот с этим согласен на 147%. Когда пришло время переписать часть обработок, выяснилось что из 10к строк, требовалось всего строк 700-900, остальное мусор, годами копившийся. Но мне пришлось получить добро на такой шаг. И потом я 2 дня сидел на телефоне, на всякий случай. Но вот смотрю я на front-end и понимаю: такой фокус там не прокатит. А в back все еще хуже. Особенно если это api. Там всегда вопрос ставиться: хороним старый, пишем новый. К третьей итерации, получается что-то годное.
Yoooriii
Бывает и такое. У меня на прошлом проекте использовалась куча сторонних библиотек. Когда начали пытаться оптимизировать, стало проясняться, что библиотечки используются процентов на 10 и это в лучшем случае. Особенно меня впечатлило использование одной из либ. Из всего ее многообразия мы использовали только одну директиву #define, то есть даже не код библиотеки, а всего навсего макрос.
tmin10
Значит это сложно в поддержке: вместо того, чтобы поменять одно место в коде, тебе надо разобраться в логике его работы и написать всё заново, но уже с новыми свойствами. На это может уйти много времнни
lair
В том, что "сюда нельзя". Непонятно, что делать, если там проблема, или если маленькая проблема вокруг, или если надо переиспользовать с изменениями.
Ну то есть ставим крест на переиспользовании.
justhabrauser
Вы точно программизмом занимаетесь?
Или нагуглили это всё?
innovaIT
Да не. Я программист 1С. Не обращайте внимания. Я не занимаюсь программированием.
justhabrauser
Ну, если когда-нибудь займетесь программированием (не только 1С), то сами выведете, что:
"Лучшим решением является то, которое оптимально удовлетворяет требования заказчика".
На минуточку — "оптимально", а не "наилучшим образом".
Потому что удовлетворить наилучшим образом все требования — невозможно как класс.
innovaIT
Ещё одно спорное утверждение. Иногда заказчик не знает как ему лучше. И полагается на то, что я ему предложу. И я сам исхожу из того, что оптимально, а что нет.
VolCh
Для меня оптимально и наилучшим образом — синонимы.
ZloyGremlinJE
В 1с это утверждение точно так же работает.
killla
Термин «оптимальный» в технике как раз и означает «наилучший» по заданному критерию оптимальности.
dic.academic.ru/dic.nsf/ruwiki/1587468
Видимо в понятие «наилучшим образом» вы не закладываете все нужные заказчику критерии, оставшиеся в умолчаниях, такие как время и финансовые затраты.
gatoazul
Программирование — еще более многофакторное, чем просто быстро и дешево.
markoni
Вы, простите, ерунду написали. «Задача А реализована программистами М и Д через Ж...» — реализованное решение? Да. Работает? Да, в основном. Есть спектр лучших решений этой задачи? — Да, вагон! А вот «реализаторы через Ж» как раз «недостаточно глубоко изучили конкретную задачу». Как-то так.
Lure_of_Chaos
и «реализаторы через Ж» уже выпустили готовый продукт, а М и Д сидят ночами накануне дэдлайна
markoni
Не выпустили они ничего, потому как их велосипед CR не проехал :) Я к тому, что посыл «то, что реализовано — правильно» — неверный в корне. Можно реализовать аутентификацию с хранением открытых паролей в базе, и прочими creds в коде. Реализовано? Конечно! А это правильное/хорошее решение?
lamerok
Если в требованиях не было про то, как должны храниться пароли, то вполне себе нормальное решение. Может там защита не нужна… Например, какой-нить внутрикорпоративный сервис, для поиска общедоступной информации… Зачем городить огород, где он не нужен?
Реализовано правильно, это когда по требованиям.
VolCh
Кроме явных требований заказчика есть неявные у него же, есть требования регуляторов разных юрисдикций, есть лучшие практики (юридически я бы их отнёс к обычаям делового оборота). И может иск о ненадлежащем исполнении договора или служебных обязанностей и не выиграет в суде, но репутацию вам подмочит, если будете хранить пароли в открытом виде, когда даже на сайте ЯП указано, что так делать нельзя
lamerok
Неявные требования тоже требования. Если есть закон о персональных данных, то это тоже требование…
creker
А потом случайно порт оказывается открытым наружу, и мы читаем новость об очередной утечке данных. Есть здравый смысл и лучшие практики. Если есть пароли, то в открытом виде их быть не должно.
lamerok
И что? У нас, например внутренняя система учёта времени, там мой пароль 1. Ну утечет он, что с этого? Данные с этой системы чисто информативные для сотрудников…
Зачем там сложная система аутентификации? 7
mayorovp
А зачем тогда там вообще пароль?
lamerok
Чтобы случайно под другим юзером не зайти..
FForth
А раньше был 111?
Прогресс однако.
tmin10
Смотря где в открыом виде. В дженкинсе есть защищённые переменные, но они отдаются приложению строкой, только в логах маскируются. Это, разве, плохая практика?
Lure_of_Chaos
Если внутренняя система, если по ТЗ и прочим требованиям удовлетворяет.
Реализовано? Реализовано. Быстро. Дешево.
Не нужно пилить фейсбук там, где достаточно 2 html страничек.
justhabrauser
Расскажите погроммистам 1С
innovaIT
Ну вот мне и расскажите. На 1С можно тоже писать хорошо и правильно. А где не хватает производительности, задействовать другие механизмы.
Lure_of_Chaos
Возможно, дело в том, что в 1С, как правило, идут программисты с заниженной планкой социальной ответственности?
Я сам (сдуру) заглядывал в исходники фреймворка от той же конторы (Битрикс) а от того, что я там увидел, меня трясет от каждого упоминания — такое впечатление, что его делали люди, которые только вчера научились включать комп, а сегодня ваяют на пхп.
innovaIT
Это совсем разные конторы. Но да. Иногда и там и там видишь хаос вместо кода.
cyberly
Deverex
Речь скорее всего о том, что программных реализаций решений, позволяющих получить искомый результат — более одного. Кроме того, сам результат может быть гибкой функцией, если нет железобетонного ТЗ с эскизами форм, отчетов и т. п. Заказчик не всегда может внятно представлять автоматизацию глубже понятия "должно что-то стать быстрее и удобней".
16tomatotonns
Спектр — «ранжирование решений по корректности для данного конкретного случая», а не «набор одинаково хороших решений для всех случаев». Такое тоже бывает, но не так часто.
mayorovp
Тут главное не забывать, что от смены обстоятельств этим самым "единственно верным решением" может оказаться какое-то другое из спектра "хороших".
centralhardware
Согласен с вами, но это единственно верное решение будет меняться от каждого аспекта и в понимание каждого другого программиста. И в итоге у нас как раз и получается спектр — общий случай лучшего решения, который может быть применен к конкретной ситуации для получения того самого лучшего решения.
Griboks
Вы правы, обстоятельства действительно могу сильно измениться. Но вот насчёт личных убеждений и точек зрения не могу с вами согласиться. Решение должно быть как-то (вернее, математически и однозначно) обосновано. Чтобы другому программисту или начальнику не пришлось лично проводить исследование вопроса повторно, а он мог бы просто посмотреть на формулы/числа/ссылки.
А риски и перспективы развития следует, конечно же, учитывать. Может программист знает не всё, но предусмотреть банальное масштабирование желательно.
mamitko
Рискну предположить, что догадываюсь, что имел в виду комментатор.
Мне часто помогает представить как бы какая-то штука была реализована в идеальном мире. Типа, решение, повторяющее или моделирующее логику того, что нужно сделать как оно есть. А уже потом компромиссами превратить его в то, что можно сделать в конкретных условиях. А иногда, если костылей «вынужденных решений» накопилось еще не много, получается и без компромиссов.
miraage
Легко. У меня есть сервис (use-case) регистрации пользователя. Одна точка входа через web-морду, вторая — через CLI.
werevolff
В этом и соль: есть реализация, но если ты не видишь её сильных или слабых сторон, то ты не станешь успешным программистом. Есть задача: вывести результат 2x2. Хороший программист обязан:
Поэтому, ты обязан знать паттерны решения твоего вопроса. Полюбому, есть набор решений, которые подскажут тебе, что контекст использования может отличаться от ТЗ. Или было бы разумно реализовать паттерн, который отвечал бы ожиданиям большинства вариантов юзкейсов.
Oleh_Vasyliev
Но можно написать две точки входа для компиляции, если тебе нужен вариативный результат
niksite
Получается, не выйдет из вас хорошего программиста. Так?