MVP паттерн. Само ГУИ делать так, чтобы там не было логики. Выбрать такую реализацию паттерна, где данные связаны с контролами через биндинг. Это позволит меньше кодировать этот самый паттерн.
Далее, т.к. логики в представлении нет, то мокается интерфейс и всё нормально.
Это понятно, что ТДД не дает стопроцентной гарантии. И со всеми пунктами согласен.
А какая альтернатива? Утки?
Тесты дают довольно высокую гарантию и пока других настолько эффективных методов не найдено. Кроме ревью, но ревью кода не даст идеально проверить, если кода много, а во вторых, не бывает автоматического ревью и в случае изменений очень тяжело опираться на это.
Скажу по своему опыту, чем полезно ТДД. Почему-то программисты стыдятся признаться, что пишут баги. И есть такая известная штука — чрезмерный оптимизм в оценках сроков. Потому что не учитывают время отладки. Каждый представляет себя таким профи, который с ходу — раз и всё работает. И это даже часто так и бывает. Только работает с багами.
Цена бага значительно растет в зависимости от интервала от начала написания и когда его найдут. Написание автоматических тестов после кодирования позволяет большинство из них обнаружить. А написание теста до кода — позволяет их не написать вообще. И это важно тоже, потому что если вы забылись и написали чуть больше кода, а потом приступили к тестированию и обнаружили баг, то возможно, весь код придется переписать.
Это чем-то похоже на слепой и не слепой набор. ТДД — слепой. Вы смотрите на результат все время. Не ТДД, а тесты сразу после кода — вы смотрите на клавиатуру, набрали строку кода, поднимаете голову, а там либо ошибка, либо раскладка клавиатуры была не та.
ТДД — это на самом деле прямой метод кодирования. Сначала требования — потом код. Читай — сначала тест на требование — потом код. Не ТДД — это сначала код, который как кажется будет удовлетворять еще не поставленному требованию, а потом требование.
Не надо никого убеждать. Заказчику об этом знать не обязательно. Это в водопаде была фаза тестирования, а автоматические тесты до этого не писались.
В ТДД тесты пишутся не в отдельной фазе. Поэтому время на это спрашивать у заказчика не нужно.
Давайте посмотрим несколько вариантов:
1. Пишем код. Вручную дебажим. Пробегаем по веточкам в коде, чтобы увидеть, что проблем нет.
2. Пишем код. Пишем тест. При достаточном опыте, время не очень больше 1.
3. Пишем тест. Пишем код. Не очень отличается от 2.
Вы же не просите у заказчика время на ручной дебаг? Или заказчик запрещает касаться клавиатуры и набирать что либо кроме кода проекта?
А у меня например, всегда открыто окно еще одного функционального языка. Посчитать быстро что-то или даже код на шарп сгенерировать. И никто не запрещает. Если заказчик настолько умный в процессах, что начнет экономить время на тестах — пусть сам и пишет код.
Заказчик дает требования и обсуждает сроки. Это хреновый, очень хреновый заказчик, который будет говорить, как вам реализовывать и в какой последовательности что делать.
Заказчика вообще не спрашивают, абсолютно, хочет ли он ТДД или нет. Это процесс разработки. Это как чистоплотность — мыть руки перед едой. Это личное дело программиста.
Тут надо у заказчика спрашивать — согласен ли он оплачивать процесс целиком с вот такими-то сроками? А ТДД как раз эти сроки уменьшает и еще и надежность заметно повышает.
Спрашивать «согласен ли заказчик оплачивать ТДД» равносильно «Согласны ли вы, чтобы мы сделали проект быстрее и качественнее?»
Я бы даже сказал: вначале тише не поедешь, дальше вообще не будешь ехать.
Может код в несколько классов — и легко меняется вдруг, по требованию заказчика, но дальше, без тестов, он почти не меняется никак.
Тут с ТДД есть одна проблема в спорах. Те, кто его не пробовали, а только слышали, спорят, что он не нужен. И они отчасти правы — когда они попробуют, то где-то так, как они полагают, и получится.
Для быстрых и стабильных изменений надо научиться писать тесты. Оно вроде понятно, но если рука не набита, то медленно, криво, а при изменениях требований кажется ад. Но даже здесь, при ненабитой руке присутствует для них пока не очевидная выгода. А именно: код набросать всегда намного меньше времени, чем отлов багов и сопровождение. А если их изначально намного меньше, то в перспективе время сильно экономится.
Но если руку набить, учитывать некоторый баланс между кодом и тестами, то всё происходит гораздо веселее. Код уже бьется на удобные для тестирования куски, тесты пишутся по существу и т.д. Тогда тесты становятся мощным средством для изменений.
Это из-за отсутствия тестов ходят анекдоты про программистов:
— Сынок, Солнце светит? Ты проверял? Тогда ничего не трогай.
Что за чушь, что ТДД мешает быстрому развитию проекта. Основа экстремального программирования. Философия поддержки постоянных изменений.
Я тоже так делаю, но с угрызениями совести и с осознаванием недостаточного джедайства.
Архитектура рождается из кода в TDD потому, что она по-сути рождается декларативно: тесты создают ограничения, а из ограничений рождается что-то само собой. Т.е. такой подход позволяет к написанию кода относиться как не к конструированию, а как к переводу требований (как от заказчика, так и от себя самого).
С опытом привычка планировать почти прошла.
Но с другой стороны на прототип ТДД не распространяется. Если вам надо очень быстро соорудить макет, чтобы что-то пощупать (ГУИ) или нащупать возможный алгоритм или вариант решения — то такой подход вполне себе оправдан без угрызений совести.
Еще. Для прототипирования желательно выбирать или язык такой или такое средство, чтобы время на разработку стремилось к нулю. А потом, если надо, переписывать с ТДД на чистовик. Или не переписывать, если не надо. Но плохо писать нечто среднее между прототипом и проектом, покрывая его потом тестами. Ни туда ни сюда. С одной стороны, если создание прототипа заняло больше времени, чем нужно, а он не показал, что так делать проект не стоит — потеря времени. А если удался, а вы пишете не на кратком языке или средстве — есть соблазн не переписывать (уже время потрачено)
Да просто доказали что-то, а конкретно что — название исследования не отражает.
Я работал немного на плюсах (в проектах паре участвовал), а потом долго на шарпе. Просто безумство утверждать, что шарп более подвержен ошибкам. А по слухам, Хаскель тем более, гораздо строже.
Могу предположить, что у языков есть некоторая мощность выражения мысли и некоторая избыточность. И корреляция между ними отрицательная. Если больше в языке приходится писать избыточной информации, то больше и возможностей у компилятора обратить на это внимание.
Но опечатки — это самые тупые ошибки, которые встречаются не часто. И действительно, отлавливаются во многих случаях компилятором. А вот работа с указателями и с памятью вживую часто с т.з. компилятора корректна или он не может доказать корректность.
Короче, по опыту, плюсовики намного больше ошибок допускают (это я не по себе сужу, я не имею большого опыта, но работал с плюсовиками). И производительность у них намного меньше. Подчеркну — намного.
А есть языки, в которых можно очень кратко и элегантно выражать свою мысль. И изменение пары символов — это не ошибка, а изменение смысла кода. И, думается, в этом случае ошибок будет меньше. Потому как не нужно измерять количество ошибок на размер файла. Лучше измерять — на задачу. И если язык декларативный, позволяет кратко описывать проблемы, не позволяет ошибаться с памятью и т.д. — то очевидно, на нем и производительность программиста выше, и багов меньше. Особенно смысловых.
Научиться не сложно. Хотя, лично у меня несколько лет, наверное, ушло. Точнее, начал сразу через месяц тренировок. Но много ошибался. Хотя, это оттого, что не очень много тренировался на тренажерах. Просто прошел базу и заставил себя работать только вслепую.
Но заметил, что тренировки по вечерам, даже немного, давали быстро результат. Снижалось количество ошибок. Я использовал Stamina.
Если учесть, что я еще на языке J тогда работал, где код, что-то вроде: +/*@#]:
))
Но ничего, вслепую тоже можно. В стамине есть и такой режим
Заметно повышается производительность. Надо бы сравнивать. Возможно вы думаете, что производительны, но могли бы быть быстрее.
Почему:
1. Вы смотрите на код. Вы не думаете о клавишах. Когда вы набираете вслепую, то не задумываетесь о положении пальцев. Просто в голове возникает мысль — появляется текст на экране. Не воруется внимание. Это на автомате.
2. Вы замечали за людьми, которые смотрят на клавиатуру, сколько раз они ошибаются, но видят это не сразу, а потом правят? А какой ужас испытывают, когда забыли раскладку переключить?
3. Поднимание и опускание головы — ворует внимание. Гораздо тяжелее концентрироваться на коде.
Когда внимания не хватает, вы слабее в охвате кода, в архитектуре. А чем меньше занимает рутина, тем больше высвобождается времени на стратегические мысли.
У меня другая модель. Я изначально считаю, что мы занимаемся очень плохими делами. Никакой красоты, никакой эстетики. И оценка, что лучше или что хуже исходит из этого. Т.е. лучше то, что меньше приносит вреда.
Каждая строчка кода — это зло. Это увеличение энтропии. Хаос растет.
Вот пример. Мне недавно дали задачу — оптимизировать код. Код делает некоторые сложные вычисления и обрабатывает много данных. Работает верно, но сутки. Надо было ускорить.
Делал. Как обычно. Сначала переписал код на нормальный язык программирования. Потом нашел узкое место, которое дало ускорение на порядок. Потом код оброс классами, скрывающими некоторую логику, не относящуюся к задаче напрямую. Вроде всё хорошо. Но главный алгоритм так и остался — циклы на пару страниц. 5 отдельных шагов с циклами. Код читается скверно. Оно и понятно. Надо выделять методы. Выделил. При этом общался плотно с заказчиком и выяснил, что и как лучше назвать, что каждый шаг делает.
Теперь, вроде, код разбит на куски, каждый кусок не очень большой. Но код стал более читаемый? Отнюдь! Теперь главный цикл состоит из вызовов пяти методов. И как только мне нужно что-то понять или далее подумать как оптимизировать, мне проще открыть старый код, когда всё было в одном методе. Почему код не стал более понятным? Потому что я его не упростил, разбивая на методы. Я его усложнил. Потому что ввел новые понятия, которых до этого не существовало — имена методов.
И с одной стороны нельзя не разбивать код, потому что внимание не может следить за многими объектами одновременно, и с другой стороны разбиение не добавляет ясности, кроме случаев, когда новые введенные понятия (имена методов, например), не являются совсем новыми, а хорошо известны из жизни. Часто так бывает? Нет.
Где же гармония? Всё, что ни делалось — всё хаос. Ничего с этим не возможно поделать. Наша задача — только находить баланс в коде и минимизировать субъективно сложность.
Работать программистом в банке — наверное может и затошнить. Но и нет вообще нигде отрасли в программировании, как мне кажется, где была бы красота и романтика. Красоту ощущают новички, которые только первый раз сталкиваются с какой-то проблемой и ее решением. Тогда они испытывают нечто платоновское — удивление и радость познания.
Бывают результаты, а бывает процесс достижения результатов. Я ни в грош не ставлю людей, которые только стремятся к результату. Но не любят процесс. Таких миллиарды и они результатов не достигают )))
Да, я болею за проект. Как одна из интересных задач для меня — это сэкономить конторе деньги посредством скорости и качества написания кода, а также соответствования требованиям. Но это просто увлекательный процесс для меня. Не более. Всяким обещаниям премий, акций и чего-то еще в будущем — я давно не верю. Просто договариваюсь о стабильной устраивающей зарплате.
Ответ на оба вопроса — пох. Я бы не брал на работу людей, которые говорят — важно. Видимо это джуниоры.
Представьте себе работающего программиста, который говорит, что ему крайне важно, чтобы контора получала больше бабла с помощью его кода. Кода — какого-нибудь управления предприятием. Наверное, человек неадекватный.
Мне лично совершенно не важны задачи, которые ставит перед собой контора. Деньги, которые получаю, тоже не главный мотив. Мне просто нравится сам процесс программирования. Говорить, что важен позарез результат — вранье. Сомневаюсь, что даже даст мне какой-то новый опыт. Но интересно просто так развивать проект. В том числе, за более короткий срок создать более лучший код
Да общайтесь с ним. Человек неадекватный. Судя по инфе о нем — не программист даже. Объясняет мне, специалисту по ИИ, бред про ИИ (невозможность тестирования) и мне, специалисту в одном из декларативных языков, что этот подход не применим ко всем задачам ))
Это не так. У меня акаунт не был привязан к телефону. И писали сообщение о попытке взлома. Т.к. я параноик, то или не буду туда ходить или не буду свой реальный номер давать.
А по существу есть что сказать? Какие мои утверждения хотите опровергнуть? Оскорбления меня как-то мало волнуют от человека, не следящего за аргументацией, с недостаточным возрастом и опытом.
А статья умилила ))))) Это дурацкий подход, совсем дурацкий. Хоть и для шатла. Если люди могут всё тщательно планировать в воображении и еще тянуть тонны мусора в виде истории ошибок и на каждую строчку кода по куче комментариев — это значит, что код и задачи у них не очень сложные. Если вы можете в воображении держать всё, значит, ну немного сложнее тетриса программа ))))
Слышал. Только брак ПО и брак детали автомобиля — разные вещи совершенно. Брак детали является случайной величиной и происходят постоянно отклонения от нормы.
Нет. Просто исправить баг, из-за которого автомобиль спутает цвета светофора. Или примет тряпку за человека. Или не заметит знак, расположенный под определенным углом при определенном освещении.
Вы предлагаете писать код без багов. Правильно?
Точно, предлагаю писать код без багов. Разница между багом и браком в том, что последний случайный и может оказаться в любом случайно выпущенном автомобиле. Может, конечно, и серийно, но не рассматриваем этот случай. А вот баг копируется массово, а это значит, что не нужна такая дыра в ПО автомобиля, чтобы его на ходу чинить. Просто вдруг автомобили не начинают путать цвета. В ПО ничего вдруг не происходит. Поверьте, я на самом деле программист.
С багами в ПО, конечно, есть проблема. Проблема в том, что заставляют писать ПО, чтобы минимум затрат на разработку и максимум результата. А надежность чтобы была «приемлема». Но одно дело писать для бизнеса, а другое для обеспечения безопасности людей. Баги — это величина конечная и счетная. Только либо не существует способа доказать, что их уже нет в ПО (а это реально может быть), либо есть способ доказать, что они ПО соответствует требованиям, но нет способа доказать, что требования правильные (то, что хотели)
Вы внимательно читаете, что я пишу? Какое отношение имеет взлом устройства владельцем к воровству самого устройства?
Да, может невнимательно прочитал. Но и здесь, уверен, законы рынка. Соотношение затрат и пользы. Если говорить о том, легко ли заблокировать программное обеспечение телефона от взлома, то наверное сложно. Потому что программное обеспечение телефона призвано развлекать владельца разными способами. А когда оно надоест, его меняют. Кстати, у меня телефон старый, простой и перепрошить его невозможно. Это на вопрос — легко или сложно перепрошить. А были, помню, первые игры ручные (волк ловил яйца и тому подобные), так там даже картинки нельзя было менять ))
И не глючили игры )
Есть некая фирма Apple, которая заинтересована в том, чтобы 100% устанавливаемых на ее устройства приложений приходили из ее магазина. На нем данная фирма зарабатывает больше, чем на мобильниках, потому она материально заинтересована в том, чтобы никто не мог обойти ее запреты.
Черт. Не уверен. Есть некая фирма Майкрософт, которая «заинтересована» в продаже своего лицензионного софта. Но тем не менее на просторах СНГ почти не борется с пираством. Почему? Потому что выгодно.
Чем может быть эплу выгодно? Точно не знаю, пофантазирую. 1. Законодательство наших гондурасов. Как платить деньги эплу. В странах, где нет официально понятия «электронные деньги». 2. Уровень покупательной способности. Наши страны просто славятся по менталитету склонностью к воровству. Надави на них, найдут что-то другое — андроид. И кстати, так оно и есть — где больше халявы, там и наши. Как же удержать хоть немного рынок? Хотя бы телефоны покупают — и то ладно. А кое-кто и присел на игры или ПО, так может он потенциальный покупатель мака.
У ПО есть одна особенность — оно размножается копированием. Это не некоторая исчерпаемая материальная ценность. Поэтому, если нельзя поиметь большие деньги, думают, как можно поиметь маленькие. Я сомневаюсь, что кто-то в эпл или майрософт мечтает больше о мести, чем о прибыли.
Допустим, в совершенно обычном автомобиле выявился дефект тормозной системы. Вы хоть раз слышали о том, чтобы производитель недобровольно компенсировал ущерб?
Сейчас люди управляют автомобилем. Поэтому они многое не требуют от заводов. Потому как есть некоторая уверенность в своем управлении. Далее, эти же люди прекрасно понимают, что бывает износ у деталей. И тормоза со временем могут отказывать. Это не вина завода. Представьте, что люди начали бы гибнуть точно по вине завода. Т.е. выпустили с такими дефектами, прямо серией. Как думаете, люди бы молчали или производитель бы выглядел в хорошем свете и не компенсировал? Но это мы говорим о механических деталях и материалах, где идеала не бывает. А если автомобиль полностью управляет движением и от него зависит ваша жизнь, то тут требования другие. И тут даже далекому от компьютеров человеку будет тяжело объяснить, что мол, износились электроны или потерлись транзисторы в схеме.
Тут или баг или не баг.
И следующие ответы прямо следуют из того, что я написал выше.
Запретить возможность перепрошивки в принципе (безумие с точки зрения удобства конечного пользователя — да и все равно энтузиасты будут перепаивать память).
А разрешить возможность перепрошивки — это безумие с т.з. производителя. Давайте определимься с целями. Мы говорим не о планшете с играми в салоне автомобиля. Мы говорим о системе управления автомобилем, в число которой входит лазер. У этой системы есть только одна цель — безопасно вести автомобиль. Добавить туда сервис оповещения о погоде или о месячных жены? Это не сюда. С чего вдруг энтузиасты полезут туда что-то перепаивать? За это им надо что-то отрывать. Даже — уголовная отвественность. Потому как они рискуют уже не только своими жизнями. Найдут производители багу? При таких рисках перепрошивать по инету — просто глупо. Сейчас, если находят баг в автомобиле — их меняют на новые за свой счет. Тут может быть то же самое. Менять с половиной железа где-то на спецстанции, создавая специальное для каждого автомобиля.
Конечно, радар могут спереть и обвинить завод в этом нельзя. Но во-первых, сразу же могут появиться смерти: человек давно руль не держал, а тут пришлось ехать самому, да еще и совершил аварию с ни в чем не виновными людьми. А если он был просто болен и не справился с управлением, но не ожидал, что украдут радар. Во-вторых, если рассматривать будущее в общем, где легко записывается на видео всё, что угодно, где кроме радаров и украсть нечего — то и радары воровать не будут. Наверное, найдутся и другие развлечения.
И при этом вы говорите, что в 90-е было хуже, чем до них?
И я такого не говорил. Я говорю о сейчас по сравнению с 90-ми. Но если на вскидку, то да, до 90-х было немного лучше. В плане воровства и бандитизма. В советское время больше воровали у государства. С заводов что-то тащили. Но такого бандитизма, как в 90-е, конечно, не было.
Неважно, коврик это или айфон. В любые времена всегда воровали то, что представляет ценность на данный момент. Неважно, что именно.
Важно. Я бы не делал обобщения. Основа воровства — зависть. Психологическая основа. Не знаю, насколько она неискоренима, но проявляться она может по разному. Если есть ценности и их очень хочется иметь, но при этом они никак не отслеживаемые, то воровство процветает. А если каждый предмет можно будет отследить — не только сложность этого ремесла увеличивается, но и смысл теряется. Люди хвастаться кому-то могут материальными благами только тогда, когда они не из секонд-хенда. А если в ложках, в радарах или в других мелочах будут датчики, но ну их нах воровать. Проще купить.
Клептоманов упускаем, пусть ими врачи занимаются. Но позволю себе предположить, что их будет заметно меньше, если не будет объективных оснований для такой деятельности.
Когда я слышу абсолютно безумные фантазии, я заявляю, что это именно безумные фантазии.
Это правильно. Но не допускать, что вы — безумный фантазер — не верно ))
Предсказания — это вообще-то плохая тема для спора. У меня просто некое предположение, что с воровством покончат. Воровство происходит от бедности, зависти и от того, что что-то плохо охраняется. Не знаю, как на счет первого и второго, но в третьем нам уже сейчас многое по силам.
Так не бывает в гражданских приборах. Иначе там потребуется радикально иной подход к разработке ПО. Вне зависимости от назначения этого ПО. Цены тоже будут вовсе не гражданскими. Любые современные чипы вплоть до тех, которые забрасывают людей в космос, поддаются перепрошивке.
Знаете как расшифровывается слово ROM? Read-Only-Memory. Именно такие и были первые ПЗУ. Они не поддавались перепрошивке. А знаете почему? Потому что это наиболее простой способ. Программы, как и данные, состоят из ноликов и единиц. Для задания неперепрошиваемой памяти не нужны даже транзисторы — нужны просто разрывы в цепи или не разрывы.
Но сейчас в перспективе дешевле изготовить перепрошиваемую память. Т.к. ПО быстрее устаревает, чем железо.
Для тех, кого забрасывают в космос — требования другие. Их больше волнует разгерметизация или другие космические проблемы, чем инопланетяне с паяльниками. Доступа к тем схемам у любопытных хакеров нет.
Чепуха. И по поводу «отвечать за безопасность», и по поводу «блокировать интерфейсы».
Посмотрите на рынок мобильников. Что мешает той же Apple сделать невзламываемое устройство, если по-вашему это так просто? Они уж точно ни капельки не заинтересованы в джейлбрейке… Есть способы отвязать телефон от оператора — тем это тоже на куй не сдалось.
Кроме того — уже сейчас автомобили напичканы электроникой по самое не балуй. И ничего, перепрошиваются без проблем.
Можно догадку? Apple заинтересована. Чем чаще у вас воруют телефон, тем чаще вы покупаете новый. А те, кто воруют, не входят в сегмент их рынка. Т.е. они бы его по такой цене никогда и не купили бы.
Автомобили? Ну где-то та же логика. Если своруют, с компанией ничего не случится — это ваши проблемы. Но перепрошивка лично вам выгоднее, потому что не надо новое устройство покупать, а можно перепрошить. Если бы я покупал телевизор с невозможностью перепрошивки, то через полгода он бы устарел.
Но эта логика никак не относится к сохранности вашей жизни. Опять догадка: если вы будете покупать автоматический автомобиль, у вас будет страховой договор. Если не что-то хуже для завода. За езду пьяным за рулем на неавтоматическом автомобиле отвечаете только вы, а также за аварии, которые совершили. Тогда будет иначе. Отвечать будет завод. И дать возможность перепрошивки вместе с возможностью убить, на это мало кто согласится. Тем более, что для ключевого железа ПО врядли будут бесконечные изменения, вроде входа в твитер или злых птичек. Не должен работать лазер с другим авто — значит не должен — это раз в полгода не меняется.
«Потом» ничем не будет отличаться от «сейчас» еще тысячи лет. Разве что железки будут другие. Такой вывод можно сделать на основании того, что за десяток тысяч лет тоже никаких изменений не фиксировали. Разве что мера наказания за воровство менялась.
Не делите на черное и белое. Люди за 20 лет довольно сильно поменялись (как я помню). Может кардинальных нет изменений, с чего-то все время злое зло. Но тем не менее, система ценностей меняется. Если тысячу лет вас бы за коврик у входной двери убили, то сейчас такой коврик не интересен с т.з. убийства. Я, кстати, об этом и речь веду, что не стоит лазерный радар представлять, как вершину счастья, даже через десятки лет.
А все, что представляет ценность — воруют. Детишки даже трехконечные звезды с копотов мерседесов срывают, потому что в их среде это тоже ценная вещь, пусть с нашей точки зрения им надо за такое руки отрывать — сам по себе значок ни стоит ни черта, но его потеря неведомым образом снижает ценность автомобиля.
Мы уже говорим про относительность ценностей? Тогда осталось дойти до соглашения, что со временем цена предметов меняется. Алюминиевые ложки! ))
Вы откуда этот бред берете?
Хотел повеселить ))
У всех разный уровень интеллекта, разные черты характера и разное воспитание.
Возможно это корень спора. Конечно, конечно. С голубой кровью и не воровавшие люди существовали всегда. Но как-то процент менялся. В голод, например, и за кусок хлеба убить могли. А сейчас иногда и просящий подаяния выбрасывает.
Швейцария в 90-е. Никто не запирал двери домов, никто не запирал автомобили, преступности не было. Если у кого и была сигналка, то только для удобства.
Понаехали? )))
Ваши способности к анализу поражают :)
Не спешите с обвинениями ))) Читал недавно статью от уважаемого программиста, где-то из хабра ссылка, так его цитата (в вольной форме): «даже если ваш коллега несет полную чушь, это еще не значит, что он не прав»
Далее, т.к. логики в представлении нет, то мокается интерфейс и всё нормально.
А какая альтернатива? Утки?
Тесты дают довольно высокую гарантию и пока других настолько эффективных методов не найдено. Кроме ревью, но ревью кода не даст идеально проверить, если кода много, а во вторых, не бывает автоматического ревью и в случае изменений очень тяжело опираться на это.
Скажу по своему опыту, чем полезно ТДД. Почему-то программисты стыдятся признаться, что пишут баги. И есть такая известная штука — чрезмерный оптимизм в оценках сроков. Потому что не учитывают время отладки. Каждый представляет себя таким профи, который с ходу — раз и всё работает. И это даже часто так и бывает. Только работает с багами.
Цена бага значительно растет в зависимости от интервала от начала написания и когда его найдут. Написание автоматических тестов после кодирования позволяет большинство из них обнаружить. А написание теста до кода — позволяет их не написать вообще. И это важно тоже, потому что если вы забылись и написали чуть больше кода, а потом приступили к тестированию и обнаружили баг, то возможно, весь код придется переписать.
Это чем-то похоже на слепой и не слепой набор. ТДД — слепой. Вы смотрите на результат все время. Не ТДД, а тесты сразу после кода — вы смотрите на клавиатуру, набрали строку кода, поднимаете голову, а там либо ошибка, либо раскладка клавиатуры была не та.
ТДД — это на самом деле прямой метод кодирования. Сначала требования — потом код. Читай — сначала тест на требование — потом код. Не ТДД — это сначала код, который как кажется будет удовлетворять еще не поставленному требованию, а потом требование.
В ТДД тесты пишутся не в отдельной фазе. Поэтому время на это спрашивать у заказчика не нужно.
Давайте посмотрим несколько вариантов:
1. Пишем код. Вручную дебажим. Пробегаем по веточкам в коде, чтобы увидеть, что проблем нет.
2. Пишем код. Пишем тест. При достаточном опыте, время не очень больше 1.
3. Пишем тест. Пишем код. Не очень отличается от 2.
Вы же не просите у заказчика время на ручной дебаг? Или заказчик запрещает касаться клавиатуры и набирать что либо кроме кода проекта?
А у меня например, всегда открыто окно еще одного функционального языка. Посчитать быстро что-то или даже код на шарп сгенерировать. И никто не запрещает. Если заказчик настолько умный в процессах, что начнет экономить время на тестах — пусть сам и пишет код.
Заказчика вообще не спрашивают, абсолютно, хочет ли он ТДД или нет. Это процесс разработки. Это как чистоплотность — мыть руки перед едой. Это личное дело программиста.
Тут надо у заказчика спрашивать — согласен ли он оплачивать процесс целиком с вот такими-то сроками? А ТДД как раз эти сроки уменьшает и еще и надежность заметно повышает.
Спрашивать «согласен ли заказчик оплачивать ТДД» равносильно «Согласны ли вы, чтобы мы сделали проект быстрее и качественнее?»
Может код в несколько классов — и легко меняется вдруг, по требованию заказчика, но дальше, без тестов, он почти не меняется никак.
Тут с ТДД есть одна проблема в спорах. Те, кто его не пробовали, а только слышали, спорят, что он не нужен. И они отчасти правы — когда они попробуют, то где-то так, как они полагают, и получится.
Для быстрых и стабильных изменений надо научиться писать тесты. Оно вроде понятно, но если рука не набита, то медленно, криво, а при изменениях требований кажется ад. Но даже здесь, при ненабитой руке присутствует для них пока не очевидная выгода. А именно: код набросать всегда намного меньше времени, чем отлов багов и сопровождение. А если их изначально намного меньше, то в перспективе время сильно экономится.
Но если руку набить, учитывать некоторый баланс между кодом и тестами, то всё происходит гораздо веселее. Код уже бьется на удобные для тестирования куски, тесты пишутся по существу и т.д. Тогда тесты становятся мощным средством для изменений.
Это из-за отсутствия тестов ходят анекдоты про программистов:
— Сынок, Солнце светит? Ты проверял? Тогда ничего не трогай.
Что за чушь, что ТДД мешает быстрому развитию проекта. Основа экстремального программирования. Философия поддержки постоянных изменений.
Архитектура рождается из кода в TDD потому, что она по-сути рождается декларативно: тесты создают ограничения, а из ограничений рождается что-то само собой. Т.е. такой подход позволяет к написанию кода относиться как не к конструированию, а как к переводу требований (как от заказчика, так и от себя самого).
С опытом привычка планировать почти прошла.
Но с другой стороны на прототип ТДД не распространяется. Если вам надо очень быстро соорудить макет, чтобы что-то пощупать (ГУИ) или нащупать возможный алгоритм или вариант решения — то такой подход вполне себе оправдан без угрызений совести.
Еще. Для прототипирования желательно выбирать или язык такой или такое средство, чтобы время на разработку стремилось к нулю. А потом, если надо, переписывать с ТДД на чистовик. Или не переписывать, если не надо. Но плохо писать нечто среднее между прототипом и проектом, покрывая его потом тестами. Ни туда ни сюда. С одной стороны, если создание прототипа заняло больше времени, чем нужно, а он не показал, что так делать проект не стоит — потеря времени. А если удался, а вы пишете не на кратком языке или средстве — есть соблазн не переписывать (уже время потрачено)
Я работал немного на плюсах (в проектах паре участвовал), а потом долго на шарпе. Просто безумство утверждать, что шарп более подвержен ошибкам. А по слухам, Хаскель тем более, гораздо строже.
Могу предположить, что у языков есть некоторая мощность выражения мысли и некоторая избыточность. И корреляция между ними отрицательная. Если больше в языке приходится писать избыточной информации, то больше и возможностей у компилятора обратить на это внимание.
Но опечатки — это самые тупые ошибки, которые встречаются не часто. И действительно, отлавливаются во многих случаях компилятором. А вот работа с указателями и с памятью вживую часто с т.з. компилятора корректна или он не может доказать корректность.
Короче, по опыту, плюсовики намного больше ошибок допускают (это я не по себе сужу, я не имею большого опыта, но работал с плюсовиками). И производительность у них намного меньше. Подчеркну — намного.
А есть языки, в которых можно очень кратко и элегантно выражать свою мысль. И изменение пары символов — это не ошибка, а изменение смысла кода. И, думается, в этом случае ошибок будет меньше. Потому как не нужно измерять количество ошибок на размер файла. Лучше измерять — на задачу. И если язык декларативный, позволяет кратко описывать проблемы, не позволяет ошибаться с памятью и т.д. — то очевидно, на нем и производительность программиста выше, и багов меньше. Особенно смысловых.
Научиться не сложно. Хотя, лично у меня несколько лет, наверное, ушло. Точнее, начал сразу через месяц тренировок. Но много ошибался. Хотя, это оттого, что не очень много тренировался на тренажерах. Просто прошел базу и заставил себя работать только вслепую.
Но заметил, что тренировки по вечерам, даже немного, давали быстро результат. Снижалось количество ошибок. Я использовал Stamina.
Если учесть, что я еще на языке J тогда работал, где код, что-то вроде: +/*@#]:
))
Но ничего, вслепую тоже можно. В стамине есть и такой режим
Почему:
1. Вы смотрите на код. Вы не думаете о клавишах. Когда вы набираете вслепую, то не задумываетесь о положении пальцев. Просто в голове возникает мысль — появляется текст на экране. Не воруется внимание. Это на автомате.
2. Вы замечали за людьми, которые смотрят на клавиатуру, сколько раз они ошибаются, но видят это не сразу, а потом правят? А какой ужас испытывают, когда забыли раскладку переключить?
3. Поднимание и опускание головы — ворует внимание. Гораздо тяжелее концентрироваться на коде.
Когда внимания не хватает, вы слабее в охвате кода, в архитектуре. А чем меньше занимает рутина, тем больше высвобождается времени на стратегические мысли.
Каждая строчка кода — это зло. Это увеличение энтропии. Хаос растет.
Вот пример. Мне недавно дали задачу — оптимизировать код. Код делает некоторые сложные вычисления и обрабатывает много данных. Работает верно, но сутки. Надо было ускорить.
Делал. Как обычно. Сначала переписал код на нормальный язык программирования. Потом нашел узкое место, которое дало ускорение на порядок. Потом код оброс классами, скрывающими некоторую логику, не относящуюся к задаче напрямую. Вроде всё хорошо. Но главный алгоритм так и остался — циклы на пару страниц. 5 отдельных шагов с циклами. Код читается скверно. Оно и понятно. Надо выделять методы. Выделил. При этом общался плотно с заказчиком и выяснил, что и как лучше назвать, что каждый шаг делает.
Теперь, вроде, код разбит на куски, каждый кусок не очень большой. Но код стал более читаемый? Отнюдь! Теперь главный цикл состоит из вызовов пяти методов. И как только мне нужно что-то понять или далее подумать как оптимизировать, мне проще открыть старый код, когда всё было в одном методе. Почему код не стал более понятным? Потому что я его не упростил, разбивая на методы. Я его усложнил. Потому что ввел новые понятия, которых до этого не существовало — имена методов.
И с одной стороны нельзя не разбивать код, потому что внимание не может следить за многими объектами одновременно, и с другой стороны разбиение не добавляет ясности, кроме случаев, когда новые введенные понятия (имена методов, например), не являются совсем новыми, а хорошо известны из жизни. Часто так бывает? Нет.
Где же гармония? Всё, что ни делалось — всё хаос. Ничего с этим не возможно поделать. Наша задача — только находить баланс в коде и минимизировать субъективно сложность.
Работать программистом в банке — наверное может и затошнить. Но и нет вообще нигде отрасли в программировании, как мне кажется, где была бы красота и романтика. Красоту ощущают новички, которые только первый раз сталкиваются с какой-то проблемой и ее решением. Тогда они испытывают нечто платоновское — удивление и радость познания.
Бывают результаты, а бывает процесс достижения результатов. Я ни в грош не ставлю людей, которые только стремятся к результату. Но не любят процесс. Таких миллиарды и они результатов не достигают )))
Да, я болею за проект. Как одна из интересных задач для меня — это сэкономить конторе деньги посредством скорости и качества написания кода, а также соответствования требованиям. Но это просто увлекательный процесс для меня. Не более. Всяким обещаниям премий, акций и чего-то еще в будущем — я давно не верю. Просто договариваюсь о стабильной устраивающей зарплате.
Представьте себе работающего программиста, который говорит, что ему крайне важно, чтобы контора получала больше бабла с помощью его кода. Кода — какого-нибудь управления предприятием. Наверное, человек неадекватный.
Мне лично совершенно не важны задачи, которые ставит перед собой контора. Деньги, которые получаю, тоже не главный мотив. Мне просто нравится сам процесс программирования. Говорить, что важен позарез результат — вранье. Сомневаюсь, что даже даст мне какой-то новый опыт. Но интересно просто так развивать проект. В том числе, за более короткий срок создать более лучший код
И представления о программах весьма наивные.
А статья умилила ))))) Это дурацкий подход, совсем дурацкий. Хоть и для шатла. Если люди могут всё тщательно планировать в воображении и еще тянуть тонны мусора в виде истории ошибок и на каждую строчку кода по куче комментариев — это значит, что код и задачи у них не очень сложные. Если вы можете в воображении держать всё, значит, ну немного сложнее тетриса программа ))))
Надо не только строгие костюмы носить и вводить практики взаимных проверок. Надо и технологии программирования и языки подходящие применять, для снижения количества багов. Не верите, что можно написать код, доказано без багов относительно требований?
ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BA%D0%BB%D0%B0%D1%80%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
Это было риторическое сообщение. Я не собираюсь с вами далее продолжать общение.
Но одно другому не мешает. Если даже вы будете редко выезжать из дому, то вам все равно не захочется терять часы времени.
Слышал. Только брак ПО и брак детали автомобиля — разные вещи совершенно. Брак детали является случайной величиной и происходят постоянно отклонения от нормы.
Точно, предлагаю писать код без багов. Разница между багом и браком в том, что последний случайный и может оказаться в любом случайно выпущенном автомобиле. Может, конечно, и серийно, но не рассматриваем этот случай. А вот баг копируется массово, а это значит, что не нужна такая дыра в ПО автомобиля, чтобы его на ходу чинить. Просто вдруг автомобили не начинают путать цвета. В ПО ничего вдруг не происходит. Поверьте, я на самом деле программист.
С багами в ПО, конечно, есть проблема. Проблема в том, что заставляют писать ПО, чтобы минимум затрат на разработку и максимум результата. А надежность чтобы была «приемлема». Но одно дело писать для бизнеса, а другое для обеспечения безопасности людей. Баги — это величина конечная и счетная. Только либо не существует способа доказать, что их уже нет в ПО (а это реально может быть), либо есть способ доказать, что они ПО соответствует требованиям, но нет способа доказать, что требования правильные (то, что хотели)
Да, может невнимательно прочитал. Но и здесь, уверен, законы рынка. Соотношение затрат и пользы. Если говорить о том, легко ли заблокировать программное обеспечение телефона от взлома, то наверное сложно. Потому что программное обеспечение телефона призвано развлекать владельца разными способами. А когда оно надоест, его меняют. Кстати, у меня телефон старый, простой и перепрошить его невозможно. Это на вопрос — легко или сложно перепрошить. А были, помню, первые игры ручные (волк ловил яйца и тому подобные), так там даже картинки нельзя было менять ))
И не глючили игры )
Черт. Не уверен. Есть некая фирма Майкрософт, которая «заинтересована» в продаже своего лицензионного софта. Но тем не менее на просторах СНГ почти не борется с пираством. Почему? Потому что выгодно.
Чем может быть эплу выгодно? Точно не знаю, пофантазирую. 1. Законодательство наших гондурасов. Как платить деньги эплу. В странах, где нет официально понятия «электронные деньги». 2. Уровень покупательной способности. Наши страны просто славятся по менталитету склонностью к воровству. Надави на них, найдут что-то другое — андроид. И кстати, так оно и есть — где больше халявы, там и наши. Как же удержать хоть немного рынок? Хотя бы телефоны покупают — и то ладно. А кое-кто и присел на игры или ПО, так может он потенциальный покупатель мака.
У ПО есть одна особенность — оно размножается копированием. Это не некоторая исчерпаемая материальная ценность. Поэтому, если нельзя поиметь большие деньги, думают, как можно поиметь маленькие. Я сомневаюсь, что кто-то в эпл или майрософт мечтает больше о мести, чем о прибыли.
Сейчас люди управляют автомобилем. Поэтому они многое не требуют от заводов. Потому как есть некоторая уверенность в своем управлении. Далее, эти же люди прекрасно понимают, что бывает износ у деталей. И тормоза со временем могут отказывать. Это не вина завода. Представьте, что люди начали бы гибнуть точно по вине завода. Т.е. выпустили с такими дефектами, прямо серией. Как думаете, люди бы молчали или производитель бы выглядел в хорошем свете и не компенсировал? Но это мы говорим о механических деталях и материалах, где идеала не бывает. А если автомобиль полностью управляет движением и от него зависит ваша жизнь, то тут требования другие. И тут даже далекому от компьютеров человеку будет тяжело объяснить, что мол, износились электроны или потерлись транзисторы в схеме.
Тут или баг или не баг.
И следующие ответы прямо следуют из того, что я написал выше.
А разрешить возможность перепрошивки — это безумие с т.з. производителя. Давайте определимься с целями. Мы говорим не о планшете с играми в салоне автомобиля. Мы говорим о системе управления автомобилем, в число которой входит лазер. У этой системы есть только одна цель — безопасно вести автомобиль. Добавить туда сервис оповещения о погоде или о месячных жены? Это не сюда. С чего вдруг энтузиасты полезут туда что-то перепаивать? За это им надо что-то отрывать. Даже — уголовная отвественность. Потому как они рискуют уже не только своими жизнями. Найдут производители багу? При таких рисках перепрошивать по инету — просто глупо. Сейчас, если находят баг в автомобиле — их меняют на новые за свой счет. Тут может быть то же самое. Менять с половиной железа где-то на спецстанции, создавая специальное для каждого автомобиля.
Конечно, радар могут спереть и обвинить завод в этом нельзя. Но во-первых, сразу же могут появиться смерти: человек давно руль не держал, а тут пришлось ехать самому, да еще и совершил аварию с ни в чем не виновными людьми. А если он был просто болен и не справился с управлением, но не ожидал, что украдут радар. Во-вторых, если рассматривать будущее в общем, где легко записывается на видео всё, что угодно, где кроме радаров и украсть нечего — то и радары воровать не будут. Наверное, найдутся и другие развлечения.
И я такого не говорил. Я говорю о сейчас по сравнению с 90-ми. Но если на вскидку, то да, до 90-х было немного лучше. В плане воровства и бандитизма. В советское время больше воровали у государства. С заводов что-то тащили. Но такого бандитизма, как в 90-е, конечно, не было.
Важно. Я бы не делал обобщения. Основа воровства — зависть. Психологическая основа. Не знаю, насколько она неискоренима, но проявляться она может по разному. Если есть ценности и их очень хочется иметь, но при этом они никак не отслеживаемые, то воровство процветает. А если каждый предмет можно будет отследить — не только сложность этого ремесла увеличивается, но и смысл теряется. Люди хвастаться кому-то могут материальными благами только тогда, когда они не из секонд-хенда. А если в ложках, в радарах или в других мелочах будут датчики, но ну их нах воровать. Проще купить.
Клептоманов упускаем, пусть ими врачи занимаются. Но позволю себе предположить, что их будет заметно меньше, если не будет объективных оснований для такой деятельности.
Это правильно. Но не допускать, что вы — безумный фантазер — не верно ))
Предсказания — это вообще-то плохая тема для спора. У меня просто некое предположение, что с воровством покончат. Воровство происходит от бедности, зависти и от того, что что-то плохо охраняется. Не знаю, как на счет первого и второго, но в третьем нам уже сейчас многое по силам.
Знаете как расшифровывается слово ROM? Read-Only-Memory. Именно такие и были первые ПЗУ. Они не поддавались перепрошивке. А знаете почему? Потому что это наиболее простой способ. Программы, как и данные, состоят из ноликов и единиц. Для задания неперепрошиваемой памяти не нужны даже транзисторы — нужны просто разрывы в цепи или не разрывы.
Но сейчас в перспективе дешевле изготовить перепрошиваемую память. Т.к. ПО быстрее устаревает, чем железо.
Для тех, кого забрасывают в космос — требования другие. Их больше волнует разгерметизация или другие космические проблемы, чем инопланетяне с паяльниками. Доступа к тем схемам у любопытных хакеров нет.
Можно догадку? Apple заинтересована. Чем чаще у вас воруют телефон, тем чаще вы покупаете новый. А те, кто воруют, не входят в сегмент их рынка. Т.е. они бы его по такой цене никогда и не купили бы.
Автомобили? Ну где-то та же логика. Если своруют, с компанией ничего не случится — это ваши проблемы. Но перепрошивка лично вам выгоднее, потому что не надо новое устройство покупать, а можно перепрошить. Если бы я покупал телевизор с невозможностью перепрошивки, то через полгода он бы устарел.
Но эта логика никак не относится к сохранности вашей жизни. Опять догадка: если вы будете покупать автоматический автомобиль, у вас будет страховой договор. Если не что-то хуже для завода. За езду пьяным за рулем на неавтоматическом автомобиле отвечаете только вы, а также за аварии, которые совершили. Тогда будет иначе. Отвечать будет завод. И дать возможность перепрошивки вместе с возможностью убить, на это мало кто согласится. Тем более, что для ключевого железа ПО врядли будут бесконечные изменения, вроде входа в твитер или злых птичек. Не должен работать лазер с другим авто — значит не должен — это раз в полгода не меняется.
Не делите на черное и белое. Люди за 20 лет довольно сильно поменялись (как я помню). Может кардинальных нет изменений, с чего-то все время злое зло. Но тем не менее, система ценностей меняется. Если тысячу лет вас бы за коврик у входной двери убили, то сейчас такой коврик не интересен с т.з. убийства. Я, кстати, об этом и речь веду, что не стоит лазерный радар представлять, как вершину счастья, даже через десятки лет.
Мы уже говорим про относительность ценностей? Тогда осталось дойти до соглашения, что со временем цена предметов меняется. Алюминиевые ложки! ))
Хотел повеселить ))
Возможно это корень спора. Конечно, конечно. С голубой кровью и не воровавшие люди существовали всегда. Но как-то процент менялся. В голод, например, и за кусок хлеба убить могли. А сейчас иногда и просящий подаяния выбрасывает.
Понаехали? )))
Не спешите с обвинениями ))) Читал недавно статью от уважаемого программиста, где-то из хабра ссылка, так его цитата (в вольной форме): «даже если ваш коллега несет полную чушь, это еще не значит, что он не прав»