Pull to refresh
15
0
bormotov @bormotov

User

Send message
прям с первых тезисов стало страшно
Вот выдали нам (тестировщикам) функционал и сказали:

— Держи, тестируй!

А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение! ツ


Предлагаю вспомнить, что такое тестирование ПО. Хорошее определение в википедии

Тести́рование програ́ммного обеспе́че́ния — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определённым образом (ISO/IEC TR 19759:2005)


Ключевые слова: проверка соответствия между реальным поведением программы и её ожидаемым поведением. Если ожидаемое поведение не описано, какие тесты получатся?

Предлагаю задуматься, когда говорят «держи, тестируй!» и не дают спецификацию (ТЗ), тестировщик сам чего хочет добиться? Что-то сделать? Что-то сделать, за что платят деньги? Получить удовольствие? Получить новые знания/умения? Закрепить текущие знания/умения?

Или таки проверить соответствие?
вы так говорите, как будто xml или json должно быть удобно читать глазами человека.
хорошее дополнение, спасибо.
Но очевидно, что ни о строении атома, ни о электромагнитных волнах, рассказывать не обязательно.
Для одних это осознанный шаг начать программировать и вот тут выбор ЯП — они топят за пониманием основ и т.п.


понимание основ — в смысле понимание железа? Если в процессе изучения С/С++ не отобъют охоту и не нанесут непоправимую травму, интересно было бы посмотреть, как объясняют многоядерность CPU, многопоточное и асинхронное выполнение, обмен данными по сети (и в разрезе могоядерности, многопоточности, асинхронности), обобщеное (non)blocking IO.
Какие там еще есть важные основы, дополняйте.

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

Зато потом, несомненно понимающие основы разработчики одного из крупнейших онлайн магазинов, выкатывают приложение, которое умеет умеет «бибикнуть» телефоном, и собщить «товар доставлен», а когда приходишь забрать, требуется еще 20-30 секунд до того, как считывателю штрихкод с номером заказа, потому, что в том конкретном месте покрытие мобильной сети «так себе».
То, что одновременно с этим «бибиком» и уведомлением, можно всю фигню загрузить в телефон по быстрому домашнему интернету, при обучении основав, видимо не рассказали. А жаль. Мне, как человеку, который пользуется результатами труда «понимающих основы» программистов, хотелось бы, что бы они в первую очередь мои пользовательские задачи понимали лучше, а уж потом «основы».
Был у меня опыт, в конце 90-ых или самом начале 2000-ых.
Питон тогда еще был 1.5.2, ядро линукса вроде уже 2.x, но не суть. Попросили по-изучать задачу, захват изображения с web-камеры в приложение, и какую-то обработку (по теперешним меркам — тривиальную).
Важно то, что для макетирования задачи нужно было какой-то UI сделать, что-то у человека спрашивать, как-то с полученным видео-потоком это всё сочеталось. Начинать реализацию такого рода макета на C/C++ без опыта написания приложений с UI — это сразу неделя-две. Взять что-то скриптовое — один день. Питон был сподручнее, да и другие альтернативы на линуксе тогда сходу давали Tk в качестве UI. Наверное, v4l уже тогда был, но тоже не принципиально — поток байт с устройства получить труда не составило.
А вот для отображения нужно было разобраться какие байты за какими идут и как это всё ожидает виджет.

Думаю, уже многие правильно догадались: каждый полученный с камеры кадр, он же матрица байт, нужно было как-то обработать. Вложенные циклы на питоне, даже для разрешения 320x200 на том железе работали больше секунды на кадр, а хотелось 640x480.
Да, никаких list comprehension тогда не было даже в виде PEP.

Думаю, опять многие догадались: написать одну, даже выделю — ОДНУ — функцию обработки кадра на C и вызывать из питона заняло, тоже примерно один день (в первый раз писал C-расширение). Да-да, ровно те-же вложенные циклы, условного «транспонирования матрицы».
В итоге оно успевало 640x480 24 кадра в секунду (реально камера вроде такое не выдавала) с запасом.

Почему всё это вспомнил и даже решил написать комментарий?

Где-то с начала 2000-ых, лично я считаю ANSI C — это такой «portable assembler», это когда разработчик действительно должен понимать происходящее «в железе». C++ — это когда нужно на малых вычислительных ресурсах делать много полезной работы, с каким-то комфортом.

Сколько (в количестве разработчиков которые их решают) такого рода задач вообще? Семь процентов? Один процент? Пол процента?

С тех пор, больше всего промышленного кода я написал на python, следующий jvm-based (scala, java). Код, который приносил и до сих пор приносит реальную пользу людям. Расширение на C для питона писал может еще пару раз — обертки к уже готовым С/С++ библиотекам, которые по какой-то причине не сделали до меня.

Нужно ли человеку, который хочет отдать рутину железяке, тратить неделю-две, вместо двух дней? Тратить годы, на изучение инструмента, который реально требуется в проценте случаев, вместо пары недель, и применимости в 99% случаев?

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

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

Гораздо важнее в самом начале хоть в каком-то виде ознакомиться не столько и конкретным языком, сколько с парадигмами: процедурная/структурная (наиболее близкая к железу), функциональная, О/ОО(П), декларативная, что-то забыл? В каких случаях нужна строгая типизация, в каких статическая, в каких не нужны и как это всё вообще между собой соотносится.
И с архитектурой приложений, в каких случаях и почему полезно доступ к данным выделять отдельно, отображение данных отдельно, обработку отдельно, вот это всё.

Всё это принесен несоизмеримо больше пользы, нежели «мы понимаем, как оно там внутри».

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

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

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

Гораздо чаще ситуация, когда есть «задачи бизнеса» с одной стороны, и деньги, примерно с той-же стороны.
Хорошая архитектура решения, поддерживаемый код и так далее — это же всё часть решения. То есть, всё это нужно делать в рамках решения задачи бизнеса.

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


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

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

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

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

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

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

вспомнил про библиотеку github.com/typelevel/squants
2020 год, если вдруг кто не заметил.
В качестве внекласного чтения рекомендую почитать pep на всякие comprehensions, и найти дату, когда reduce вынесли в модуль functools

p.s. аааа!!! pop-202, list comprehension создан в 2000 году…
долго переходил с map-filter-reduce на list/dict comprehensions, циклы for — это даже читать не очень просто.
Сейчас циклы использую только если прям массово нужны side-effects в процессе обработки, или есть коллеги, которым тяжело читать coomprehensions.

И про эффективность не забываем, конечно
Не понимаю, что значит «кодер» во фразе «кодер не нужен». Кто это?

Ближайшие лет 20, точно, для 90% задач, железо дешевле чем грамотный человек. Мы, раз в несколько лет проверяем.

Очень много кода, может быть написано один раз, работать годами, и «держать нагрузку», просто добавлением железа. К тому времени, как в этот код возникает необходимость смотреть глазами и править, очень высокая вероятность, что исходные требования поменялись настолько, что экономически выгоднее решить эту новую задачу заново.
За пару-тройку лет инструменты делают заметные шаги вперед.
За лет 5-6, драматические.
Берем любой живой язык программирования (у которого в пределах этого года выходили новые сборки), и смотрим историю изменений за 5 лет.
Не все задачи нужно решать красиво. Очень часто, решить быстро, важнее, чем решить красиво. Самый простой маркер — это решение нужно всего один раз.

p.s. и да, не все задачи вообще нужно решать. Лучший код — это код, который не написан.
видимо не удалось сразу сразу донести мысль:

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

Чем более масштабный проект (типа язык питон), тем больше цена за отправку «пулл-реквеста». Попробуйте прикинуть, сколько потребуется вложить сил, что бы пройти через процедуру PEP.

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

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

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

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

какие-то конкретные идеи по внесению минимальных правок в имеющийся питон

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

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

когда-то давно, в моём кругу общения была ходовая фраза «хорошо быть молодым и сумасшедшим»

Еще «байка из прошлого»: в одно время, был человек (лет через пять после того я вспомнил, пытался найти — никаких не смог), у которого был сайт, и был опубликован прототип интерпретатора proton. Запускался сам, имел какой-то не очень сложный способ, как портировать исходники питоновской stdlib в его протон. На уровне базовых концепций были очень близоки. Автор утверждал, что вот это результат работы, примерно месяца fulltime, с нуля.
С тех пор, средства разработки очень далеко шагнули вперед, не только по удобству, но даже и «по ширине» — больше всего уже написано готового. Не говоря уже о прям «новой жизни» целого направления «транспайлеров» (трансляторов, препроцессоров, итд — как не назови). Это еще проще, не нужно возиться с реализацией низкого уровня.

Добрый совет: попробуйте вашу бодрость духа, направить в русло получения результата, который можно ощутить.
нужно не забыть поплнить запасы попкорна к моменту, когда будут аналогичный «разбор» хаскеля. Или эрланга.
до «трактора из России», есть более простые движения «из Рамблера» (вдруг там еще кто-то остался?), из Сбертеха/Сбербанка (там уж точно есть достаточно грамотных специалистов)
кто-то где-то сбоку от Рамблера плохо учил историю отрасли, а скорее всего, вообще не не понимает как всё в реальности работает.
Никаких «выжить» в этом направлении нет.
Ваши реплики, не опровергают необходимость комплексного подхода. Максимум, показывают что мои примеры не достаточно наглядные. Ок, мои примеры так себе.

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

Рассматривайте системы в целом, комплексно. Как говорят «наличие корреляции не означает причинно-следственной связи».

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

И еще реплика: в своём родном городе я работал в двух кварталах от дома, пешком это пять минут. Перехева в Москву, первые годы снимал квартиру в Одинцово (ездил в МГУ), первый-второй по расписанию автобус (маршрутка) в по счастловой случайности останавливался «за углом от дома», это было 5:45, первая или вторая остановка от конечной, высокий шанс сесть, и потом 2-2.5 часа досыпать. Привет развилка на Минском шоссе, Можайка Три Кита, потом еще всё ползло по Можайке, и только на Кутузовском хоть как-то ехало. Да, это было 15 лет назад, но люди в своих машинах по Минскому с этого направления тоже ехали пару часов утром. И никакой навигатор им не мог проложить более быстрый маршрут. Электрички — хорошо если в третью физически сможешь зайти в Одинцово.

К чему все эти ужасы рассказываю?

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

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity