Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Мой путь

Думал начать так: «Если бы мне дали почитать эту статью много лет назад я наверное сейчас....», но нет — неправда это. Это мой путь и ускорить его думаю не получилось бы никак. Знать и чувствовать — это небо и земля. Стоило сделать очень-очень-очень много ошибок, чтобы сейчас понимать то, что понимается. Пост написан, а значит найдет своего читателя. Желаю успехов.

Все началось с бытового компьютера ЛИК, на котором бессонными ночами в возрасте 8-12 лет я понял, что такое кремниевый друг и то, как с ним общаться. Это был период, когда компьютер был другом, но на Вы. Каждый день я стремился к нему, чтобы получить еще какую-то новую историю. Это было красиво, как и все в первый раз. Первая строка кода на интерпретаторе Бейсик, первая ассемблерная команда, первое обращение к видеопамяти... Это было скорее: «— а можно так? — что пожелаешь».

Длительный перерыв и встреча с Его Величеством ПК. Помню, на первый урок нам сказали купить дискету. Я купил две. Вторую разобрал тут же. Это было время бокса для дискеток, в которой с трудом посещалось 21 дискетка со всем, что я имел. Это было время Паскаля. Процедуры и функции, массивы и индексы, Begin-End и всякие алгоритмы отформатировали в мозгу некоторое место для дальнейших прорывов. Это была эпоха БИОСа и ДОСа, которая закончилась появлением Windows95. Как бы я не фукал сейчас Окна, но именно они мне показали, что такое черное по белому.

Потом были Delphi и Интернет. В это время появлялась идея, которая тут же реализовывалась за пару суток до ЕХЕ-шника. Как в анекдоте: «— что ты делаешь? — сейчас запустим и посмотрим!» Все было именно так. Процедурный стиль не оставлял меня. Если была кнопка — был и ее обработчик. В обработчике описывалось все, что должно было быть сделано. То, что может понадобиться в другом проекте, устранялось в отдельный файл-монстр — MyUnit.pas. В это время я впервые услышал и прочно заучил: ООП = полиморфизм + наследование + инкапсуляция. Но в моих проектах ООП и не пахло. Я его не чувствовал.

Время шло. Университет закончился. Устроился на работу. Язык для кофеварок, команда, SVN и много-много файлов на один WEB проект. Думал, не осилю. Осилил. Новый язык и моя команда заставили меня писать в одном файле не больше одного класса, научили новому слову Архитектура. Кто-то сказал что «метод, не вмещающийся на один экран — плохой метод». Разработка шла методом Try-Error — так же, как раньше. Нашел подходяще название привычному для меня стилю разработки — Google DrivenDevelopment. Понимаешь, это тогда, когда отключается Интернет и разработка приостанавливается.

Прошло еще немного времени, и появились тесты. Мне предложил их попробовать на вкус лидер проекта. И понеслась. Я сразу понял, зачем их придумали. Эра «сейчас запустим — проверим» закончилась. Началась эра jUnit. Пришлось немного повоевать с менеджерами. Я часто слышал: «зачем писать 10-20 строк кода для тестирования 2х?», «зачем тестировать то, что и так работает?» или «почему ты не пишешь хороший код сразу?». Сложно объяснить на пальцах — это чувствовать надо (или как говорят быть test infected). А так — люди ошибаются. Программисты — люди, которые ошибаются чаще. Именно тесты позволили мне больше не волноваться за код, отправленный в хранилище. Снизился стресс — повысилось качество работы. Со временем тестов стало больше и их преимущество проявились во всей красе. Я получил возможность приводить некрасивый код в более красивый, и делал это безопасно для проекта.

С помощью нового инструмента я и взялся за реализацию своего желания привести все в порядок. Чуть позже нашел этому название. Оказывается, все уже придумали. Началась новая познавательная эра — Refactoring. Открылась дверь в мир ООП. Я прочувстввоал, что такое метод, класс, интерфейс в ООП и как это все отличается от процедур и функций в процедурном программировании, что есть наследование и агрегация, по-новому изобрел некоторые шаблоны проектирования, о которых тоже узнал несколько ранее и до сих пор слепо использовал. Refactoring в паре с тестами позволили мне писать код еще быстрее и чище, плюс я за это все ничуточки не волновался. Но были и недостатки.

Открытием и новым периодом стал для меня TDD (Test Driven Development или разработка, управляемая тестированием). Я избавился сразу от всех недостатков подхода «вначале код, а потом тест». Я получил еще большего ускорения и простоты в коде. Абсолютно все покрыто тестами и каждый тест жизненно необходимым — без него нельзя сделать следующий шаг. Функционал «на будущее» остается в виде идеи на бумаге. — правило 80/20 проявило себя во всей красоте — минимум кода только чтобы заработало. Я стал более последовательным в разработке. И этим все не закончилось — до сих пор делаю интересные открытия... Как всегда — недостатки имеются...

Мне было сложно словами объяснить, что тест приходится писать до написания кода. Как написать тест на то, что еще не существует? На меня непонимающе смотрели, когда я продвигал тесты в команде, а когда заговорил о том, что мне не стоит думать об архитектуре или о том, что я забыл что такое Debug или о том, что я делаю более 200 ошибок в день, на меня начали смотреть еще более непонимающе. Единственное что давало 100% успех — когда я показывал то, что я делаю, подсаживаясь к напарнику за его компьютер.

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

Где-то в это время в мои руки попала книга Совершенный код. Библия программиста, скажу. Именно из нее узнал про XP (eXtreme Programming). Каково было мое удивление, когда и парное программирование и TDD и Refactoring и совместные разборки кода и еще что-то (что к тому времени для меня было уже родным и очевидным) я нашел в методике экстремального программирования от Кент Бека. Все такое близкое и все в одном месте... Я снова влюбился. Как оно все гармонично сочетается. Есть, конечно, и недостатки, но пока тащусь от достоинств.

А недавно я узнал, что недостаток понимания TDD классно снимается в BDD (Behavoir Driven Development). Cейчас интенсивно пробую. Идея в том, что не тесты пишутся вначале, а требования к системе. Ну а все остальное как в TDD :)

Наверное, самая революционная эра началась, когда начал замечать аналогии между программированием и жизнью. Кто-то говорит не путать личную жизнь и работу, но это невозможно. 8 часов, 5 дней в неделю не могут не отпечататься на все, что ты делаешь в «свободное» время. Я заметил, что в повседневной жизни стал более последовательный, перестал себе доверять: делая что-то, желаю получить обратную связь — как-то проверить новое убеждение. Понял, что программирование и жизнь имеют много общего, только в программировании причина и следствие стоят ближе во времени.

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

Что дальше? Не знаю, но уверен оно будет. Быть может, кто-то подскажет что? Буду рад любым напутствиям.

А сколько ошибок еще предстоит сделать...

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




41 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Автор как раз созрел для функциональных языков.

2 СанЁк Баглай> А у тебя как с этим, есть КПД? Плохо. Точнее 5−10%.Первый уровень — КруизКонтроль с запускаемыми тестами. Просто можно «капать» на мозги, что у большинства модулей тесты есть.Способ увиливания — делается пара малозначимых тестов и дальше про тесты забывают.Второй способ увиливания — эта подсистема слишком сложная и в ней слишком много изменяемых параметров. Причина — люди не хотят думать «как это тестировать». Просто не хотят. Не верят.Третий способ увиливания — ты такой умный, куда уж нам до тебя. И это после того, как человеку в паре пишеш ЮнитТесты. Показываеш. Человек соглашается, но тесты поддерживать отказывается.Четверый способ (часто спровоцированный проджект менеджером и отфонарным эстимейшином) — нехватка времени и желание сделать все как можно быстрее. Да, написание тестов требует времени и интеллектуальных усилий. Программа без тестов пишется быстрее (на 20%), а время, затрачиваемое на её дальнейшую поддержку, просто не фиксируется. Возникает иллюзия «экономии времени». А так как ошибки, при таком подходе, обычно, находятся случайно — достоверно не известно сколько их сделано.Впрочем проблема эта лежит совершенно не в ЮнитТестах, Нормальных Требованиях и в качестве кода. Проблема зажата между минимальной з/п, бюджетом разработки и трудности соизмерения производительности и эффективности.Быть производительным и эффективным не выгодно, особенно при незначительных различиях в з/п. Просто тех, кто тянет, больше грузят.

Vlad Romanenko, рад что вызвал положительные эмоции. leokom;).

Тень, спасибо за подробный комментарий и за наводку с Data Driven...Что касается «тыкания в одну кнопку», так это так же как и ходить-доказывать кому-то что тыкать не стоит. Помню, как только я открыл это чудное свойство ТДД, я вывесил над рабочим местом лист А4, где написал «дней без дебага» и каждый день ставил туда галочку. На меня смотрели как на диковинку. Еще чуть позже я просто заражал заинтересованных. Еще чуть позже только во время парных программингов, но так же с активным втиранием. Теперь считаю, что только примером и молча (пока не спросят) можно чего-то эффективно достичь — много времени на ожидание запроса «а как это ты так? », а потом эффективный диалог, в котором все сразу в подкорку уходит (без критики типа «ты дурак „-“ нет ты сам дурак»). А у тебя как с этим, есть КПД? Вот недавно задался вопросом «почему этот мужик так дорого берет за свои тренинги? ». Ответ — потому что он получает высоко мотивированных, желающих получить информацию, людей. А ломать чужую (без его ведома) психику и переводить на новый инструментарий (тем более не факт, что скоро снова прийдется переучиваться на что-то новое) — это себе во вред. Лучше выучить еще один инструментарий, а потом еще и еще один, а когда к тебе подойдут с вопросом «а как у тебя так выходит? » — вот тогда объяснить куда он попал и повести за ручку к результату. Кстати дебагом пользуюсь в тех случаях, когда чувствую что это будет эффективнее. И тут можно пойти дальше от «тыкания мышкой в одну точку». Например под eclipse Ctrl-R выполняет все за тебя до текущей линии, в которой останавливается (тебе стоит только оставить точку где-то на входе). А от мышки советую вообще отказаться — любая ИДЕ располагает множеством горячих клавиш, с помощью которых «тыкание» кажется уже не таким тривиальным. Ускоряться можно. Только кто хочет? Потому и советую показать примером — когда ты покажешь показатель (качество+время+результат) в несколько раз выше среднего, тебе с большей долей вероятности поверят. Спасибо за комментарий.

Спасибо за статью, получил удовольствие, многое созвучно своим переживаниям.:)

Андрей Церкус 8.05.2009 в 01: 22Тестирование — вопрос цены. Все решаемо. В крайнем случае наймом 10.000 китайцев.> Всегда интересовал вопрос — как написать юнит-тест кода, который занимается тем, что позиционирует в js div-ку в том месте, где сейчас находится > мышь.> И будет ли он надежным.Распознавание образов. Драйвер «мышки».> И еще вопрос — как написать юнит-тест какого-то куска кода, который работает с громадным числом вариаций входных данных, а выходные зависят в том числе и от глобальных переменных — времени, ввода пользователя в процессе выполнения преобразования.Локализацией и изоляцией (от неконтролируемого воздействия) подсистем через четкие интерфейсы с подменой реализаций на этапе тестирвания. Одна из подсказок — если что-то зависит от времени — текущее время должно быть параметром передаваемым в такую функцию. Кроме того, должен быть централизованный «источник времени» который на этапе Юнит тестирвания можно подменять (через какой-нить синглтон). Разумеется никаких слипов в программе быть не должно.Вторая подсказка — есть дата-драйвен тесты (мне они нравятся больше всего). Кода тест пишется один, но он просто занимается конвертацией CSV (+ каталога файлов, если надо) файла во входные и ожидаемые входные параметры (строка = 1 тест, строк много). Код есть жесткая функция с жесткими входными параметрами и жестким результатом выполнения (который в тесте сравнивается с ожидаемым). В этом слечае тест может быть обязательным атрибутом самой конфигурации системы (например, хранимой в СУБД). Тот, кто меняет (в СУБД) конфигурацию — отвечает и за прогон теста (зачастую с удовольствием).2СанЁк БаглайКакую-нить технологию, как убедить публику не пользоваться дебагом наработать удалось? Все кивают головой, но после этого убивают часы на тыкание в одну кнопку..., а в сочитании с глубоким нежеланием писать юнит тесты... так как проще ввести данные через пользовательский интерфейс (и тыкать помто в одну кнопку находясь в дебаге) чем написать простейший Юнит тест...Есть второй вариант псевдо юнит тестов — когда файл с тестом и сам тест в нем — один, человек руками меняет входные параметры, прогоняет тест и смотрит (глазами) результат (часто в дебаге).Есть идеи?

Спасибо, Саня! Статья очень понравилась, я ещё чуть больше стал знать о тебе. Да и о себе наверное...

Revenge_one, людям свойственно преувеличивать свои достижения и я не исключение. Все мы дети в большой песочнице, и, когда какой-то ребенок построил свой замок, пускай даже по книге «Замки из песка для чайников», он хочет чтобы все вокруг знали, что, в первую очередь, сделал его он сам, а потом уже с помощью других. Где-то я слышал: «все что хорошо сказано — мое». Revenge_one, спасибо вам за замечание. Лучше сказать и дать возможность устранить непонимание, чем просто подумать и составить неправильное мнение про человека, а потом постоянно доказывать себе что он именно такой и не иначе («а если он оправдывается, значит я прав! »).

2Сергей Волошин: акцент був зовсім не на тому. А про «піар» — це просто необхідно з сучасною швидкістю приросту «кодерів».2СанЁк Баглай: Ваші старання звичайно ж заслуговують поваги і шани, а тим більше я погоджуюсь із тим що користь від читання книг, які згадувалийсь вище, важко переоцінити. Звичайно до деяких речей рано чи пізно доходиш сам — просто із статті (для мене) виглядало так, що всі найкращі принципи ви самі по собі винайшли, а потім найшли що виявляєтьс таке вже є і навіть описано там-то і там-то. Ось я й засумнівався, що одна людина «винайшла» майже усі принципи сучасного ефективного програмування:). IMHO. Nothing personal.

smp, спасибо за ответ. Revenge_one и Сергей Волошин. “Увесь світ старався скільки часу, а виявляєцця усе то мона через ‘Мой путь’...” думаю, мной было бы потрачено еще много лет, чтобы без этих “стараний” выйти на текущий уровень. Не факт, что я проделал бы этот путь. Быть может, все осталось бы на процедурах, а я ушел в другую степь и через 20 лет придумал свою какую-то методологию. Не знаю. Потому хочу сказать спасибо Авторам тех книг, которые читал и тем людям, которые меня чему-то научили. Спасибо. Думаю, если забрать сейчас у всех интернет и книги, то пара-тройка поколений, и мы снова вернулись бы к мускульной силе.Св. Бубукий, хорошо, когда к целям везет. Теперь мы имеем кризис, он делает свое дело — забирает долги назад. Есть над чем подумать. Где-то слышал совет “давай больше чем берешь” — это я имел ввиду, когда говорил “я хочу у вас работать, я не знаю как, но научусь”.

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

Maxim Yemelyanov, спасибо. «Обычно проектирую сверху вниз» Это хороший инструмент, тоже пользуюсь его преимуществами. В SCRUM с его небольшими итерациями — самое то. «мне кажется я только сейчас начинаю понимать что-то в этом» кажется, я только начинаю понимать о чем вы.

Андрей Церкус, unit или блочное тестирование предназначено для того, чтобы тестировать какой-то черный ящик, если мы знаем, что подается на вход и что получается на выходе. Если удастся в вашем ящике, двигающем некий дивчик немного порефакторить и выделить блок который будет просто двигать, используя какой-то интерфейс, причем ему будет все равно что двигать, главное было бы оно двигабельно, то вы сможете протестировать такой модуль с помощью юнит теста. Можно так же установить координаты мыши и вызывая метод, проверить в какую область разместился дивчик. В общем, есть черный ящик. Как вы определите тот факт, что он рабочий? Вы передадите что-то на вход и проверите результат. Неважно как воздействует на вас результат — вы всегда можете это определить. Вот этому стоит научить компьютер. Подготовить входные данные, вызвать тестируемый черный ящик и как-то проверить результат. Он сделает это автоматически и скажет вам «красный», если система повела себя не так, как закладывалось."как написать юнит-тест какого-то куска кода, который работает с громадным числом вариаций входных данных" Думаю это не «кусок», а «кусочище». В таком случае я бы декомпозировал этот черный ящик на маленькие ящички и тестировал бы их независимо. А если это не получается, тогда утверждал бы с помощью теста: 1й тест «если в этот хаос я засуну 2, то на выходе сделав А-С-К-Е-А-А-И-А, я получу 45» 2й тест «если я передам −1, то я получу 5, при этом ничего делать не надо». И так много-много раз, пока не успокоюсь за тот код, с которым работаю. Первопричина создания теста — стресс, который на меня нагоняет код. Стресс, связанный с тем, что я не знаю, как код работает, или мне кажется, что код работает неисправно, или я хочу поставить какую-то контрольную точку, позволяющую мне сделать, к примеру, рефакторинг. Мне страшно — пишу тест. Мне спокойно — продолжаю работу. Если мне надо узнать, как поведет себя система, если я сделаю М, тогда я отладке предпочитаю написания тестирующего кода. Если кто-то спрашивает меня, как работает это, я предлагаю ему написать автоматический тест (перед тем изучив существующие тесты) чтобы узнать это. Это экономит время и оставляет наследие.

Устраивался на свою текущую работу тоже интересно. Я не знал, возьмут или нет, я просто пришел на собеседование, сказал: «я ничего не знаю из того, что мне перечислили, но готов учиться!» Меня взяли, не посмотрев ни на диплом, ни на те Делфи-проекты, которые я принес.

Санёк, такое бывает только в те редкие моменты, когда рынок растёт, как на дрожжах. В 1999−2002 годы так не было. Сейчас так, кстати, тоже уже не будет. Правильный ответ работадателя на такие фразы на собеседовании — «ну иди учись, кто тебе мешает». Такое уже наблюдалось в туевой хуче индустрий и в туевой хуче мест. Просто я подозреваю, что сейчас начнётся поучательство со стороны народа, который входил с таким же нулевым уровнем в 2004 и к 2009 уже вполне мог дорости до PMа молодёжи в режиме «а я в ваши годы», хотя людям тупо повезло с рынком, причём по причине, от них не зависящей: времени рождения.

2Revenge_one:

Увесь світ старався скільки часу, а виявляєцця усе то мона через «Мой путь»...

Мені здається принципи типу «одна голова добре, а дві краще» і «сім раз відмір — 1 раз відріж» з’явились набагато раніше ніж програмування, просто порівняно недавно їм додали піару, маркетингу, а програмуванню — ремесла замість magic-а.

Так написано сильно, гарно... Надихає певно молодих, ностальджи для тих памятає цифри на сист. блоці і коли вони зявились. Мені інше цікаво -, а як воно чуєцця — таким вот ко-винахідником усіх найкращих (для кого як, але по популярності...) практик розробки ПЗ? Увесь світ старався скільки часу, а виявляєцця усе то мона через «Мой путь»...

видимо не все понимают что такое юнит-тесты, хотелось бы прояснить немного.1 юнит-тесты, как правило, идут в связке в TDD те значала пишем тест где тестируем Ожидаемое занчение, потом функцию, реализующее это. Функция считается готовой если этот тест успешно пройден2 юнит тест тестирует 1 функцию.посему, если для создания класса, метод которого хотим тестировать, нужно создавать большой контекст из доп объектов, это говорит о вызокой связанности класса (рефекторинг и шаблоны в помощь) 3 входные данные это простые хордкодированые в тесте. Юнит тесты НЕ используются для тестирования реальных даных проверки диапазона значений и для тестов всей компоненты. Для этого есть функциональные, нагрузочные, аксептанс тесты (и тд итп)

Вкорінюється і набуває поширення слово-паразит «функционал» http://ru.wikipedia.org/wiki/ФункционалТреба чітко розрізняти «функціонал» і «функціональність»

хорошо написано, читается легко. продолжай, у тебя получается:) TDD/BDD не освоил и не использую. обычно проектирую “сверху вниз”, оттого и код пишется в стиле TDD (насколько я понимаю, что такое TDD), постепенно заглушки заменяются реальным кодом.про аналогию программирования с жизнью — супер. 40 (и более) часов в неделю конечно накладывают отпечаток. вспоминается, как Leonard Nimoy (актёр, игравший Спока в StarTrek-е) в книге I Am Spock описывает как роль Спока (всегда логичного, лишенного эмоций вулканца) изменила его жизнь: His second autobiography was I Am Spock (1995), and the title was meant to communicate that he finally realized his years of portraying the Spock character had led to a much greater identification between the fictional character and the real person. Nimoy had much input into how Spock would act in certain situations, and conversely, Nimoy’s contemplation of how Spock acted gave him cause to think about things in a way that he never would have thought if he had not portrayed this character. As such, in this autobiography Nimoy maintains that in some meaningful sense, he really is now Spock, and Spock is he, while at the same time maintaining the distance between fact and fiction.что дальше? возможно, всё только начинается. несколько моих знакомых, занимающихся своим любимым делом более 10 лет (а некоторые более 30) говорили: “мне кажется я только сейчас начинаю понимать что-то в этом”...

# Андрей Церкус 8.05.2009 в 01: 22Всегда интересовал вопрос — как написать юнит-тест кода, который занимается тем, что позиционирует в js div-ку в том месте, где сейчас находится мышь.И будет ли он надежным.И еще вопрос — как написать юнит-тест какого-то куска кода, который работает с громадным числом вариаций входных данных, а выходные зависят в том числе и от глобальных переменных — времени, ввода пользователя в процессе выполнения преобразования.

Никак. Это классическая проблема «точки останова Машины Тюринга», нерешаема, так как является NP-полной задачей.Но юнит-тест который даст гарантию с определённым уровнем вероятности здесь написать можно, например открыть окно броузера через ActiveX и посылать ему сообщения WM_Move с рандомными значениями.PSГде-то читал статью про софт пишущийся для космической техники, так вот там на одну строчку кода было несколько страниц документации и одна строчка кода стоила около 10000$. Вот там тестирование...

Всегда интересовал вопрос — как написать юнит-тест кода, который занимается тем, что позиционирует в js div-ку в том месте, где сейчас находится мышь.И будет ли он надежным.И еще вопрос — как написать юнит-тест какого-то куска кода, который работает с громадным числом вариаций входных данных, а выходные зависят в том числе и от глобальных переменных — времени, ввода пользователя в процессе выполнения преобразования.

АААА!!! Клева! Надо посмотреть. У нас специалист был в радиокружке, дома был самодельный спектрум, который родители без моего ведома выбросили за ненадобностью, ох я был зол! Что я буду делать на старости лет без него?; (А тетрадочка с кодом где-то есть еще...

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

Эхх, marrkiz. Жаль, что там был только один уровень... Эмулятор пробовал? Если чего — она у меня еще есть, можно попробовать воспроизвести;) пиииииииии.... тыдыш!...... вжвжвжжжвжвжвжуииииииииввжжвшшшвшвшвшвшшшвуиииииип! блииин... перематываем... Недавно делал порядок. Ну не могу я просто выкинуть эти кассеты. Рука не поднимается. Так же как и бокс, с 21 дискетками:) О! Интересно, а прочитается ли?...Кстати, если магнотофон подключить к какому-то усилителю, который включить на запись. Поднять уровень записи так, чтобы стрелочки зашкаливали, а с линейного выхода снять сигнал и подать на комп, то можно восстановить запись, которая так не читается. Я плакалЪ, когда открыл это свойство моего старого бобинника... Мой ЛИК еще огого! В прошлом году запускал. Бейсик, правда, немного глючит непонятно почему, но на ассемблере можно еще! Самая моя любимая игра была Клад, разработки нашего Электронмаша. У меня где-то пылятся все микросхемы, транзисторы и конденсаторы, которые нужны для сборки этого БК. Как-то на старости, где-то в бекапах гуглопедии найду этот пост, расплачусь, потом залезу на чердак (нет наверное правнуков попрошу), возьму свой паяльник импульсный в руки старые. Замучу мантажик навесной (дальше в развитии не пошел). Вот тогда и пригодится тетрадочка с кодом. А если нет, в той же гуглопедии найду журнал моделист конструктор за позапрошлый век и оттуда перепишу и специалиста и душмана и клад свой, любимый. Эххх...

2 Санек. Именно эта игрушка:)

marrkiz, это там где вертолетик летит и собирает чувачков машущих какой-то частью тела (кажется рукой), я другие чувачки отстреливаются? И еще такая мелодия на старте, которую до сих пор слышу. Там вконце под землей начиналось море и пробомбив грунт, можно было под землю опуститься. Глюк в том, что можно было отстреливать врагов, а они тебя не видят. Бомба, пущенная под землей, падает с неба. Вы про эту игрушку? Эххх... Жаль, что там только один уровень был. «делать проги таким образом, чтобы забыть о юнит тестах как о не нужной ерунде» о! Это самое то, что мне надо. Как только становится чуть комфортно — пора линять. Спасибо Николаю и вам за наводку. Когда знаешь, что впереди тупик — характер прогулки меняется.eugene_n, спасибо. Буду. Сейчас борюсь с показателем унылости/понятности/затянутости одной (уже написанной) статьи. Как будет готова, обязательно выложу.

2 СанЁк БаглайКакая ностальджи.Пиши еще! 2 Николай Палиенко +1

2 Николай Палиенко: под каждыми словом подпишусь.PS. Не флейма ради

имхо TDD тупиковая ветвь развития, как и Java. Нунжы более удобные языки, чтобы избавить программиста от рутины, и нужны программисты которые не лажают когда пишут 2+2=4. Реально тесты нужны для 10% кода, по краней мере в веб и десктоп программировании коим занимается в Украине 90% разработчиков. Мы польтора года пишем без тестов и ошибок меньше чем, а прошлом проекте с крутым тест кавереджом.Автору хотелось бы пожелать не зацикливаться на методологиях, которые суть маркетинг и способ организации баранов в стадо, а копать дальше в сторону более правильных инчтрументов для написания программ (Python и функциональные языки).

Санёк, спасибо за этот пост! +1 к ностальгие по «Специалисту»! В Душмана резался?: -) Было просто прозрением, когда поняли, что можно написать загрузчик, который, загружаясь в область стека и затирая его, получает сам управление, и потом загружает и запускает остальное! И не нужна команда G! Следующий этап имхо, тут присоединяюсь к flyman, делать проги таким образом, чтобы забыть о юнит тестах как о не нужной ерунде, как сейчас забыл о дебаге, я медленно, с трудом, но понемногу к этому подхожу. Вот для начала хорошая книжонка http://www.amazon.com/Toward-D.../

Denis Osetrov, спасибо. Вот как раз самое «больное» для меня было сделать ТДД привычкой. Любая привычка приходит за 20 дней. Завел пинарик и вперед. Когда привычка привилась — я обрадовался и вздохнул с облегчением. Сейчас «больно» бью себя по пальцам оттого, что иногда позволяю себе написать немного больше функционала, чем того требует тест. Приходится говорить себе «ээээ, чувак, так не пойдет», ремарить (а больнее когда просто удалять) избыточный (и чаще всего содержащий от 2 до 5 ошибок) код и подыскивать тест (тут уже тест, а не спецификацию), который бы выловил ту каку, которую я написал в реализации. Так в одной паре придумали игру. Очень мотивирует. По всем правилам парного программинга — один пишет минимум кода, чтобы тест заработал. Самого страшного и жуткого кода. Второй пытается с помощью тестов вывести его на чистую воду. Проигравает тестер, если ему больше нечего сказать или имплементатор, если тестер его заставил написать обговоренную изначально реализацию (достаточной для красивого коммита). А потом совместно делают рефакторинг того, что намудрили.Советую вам это делать в паре — так, подстегивая друг друга, 20 рабочих дней пройдет для вас двоих незаметно. А потом еще будет долго что вспомнить с напарником. Работает лучше любого тимбилдинга. Вспомнил как сказал Стив Макконнел: хорошего программиста (как и человека) делают таковым его привитые привычки. Ой! Чего-то я увлекся:) Успехов вам и мне!

Доброжелатель, спасибо почитаю. Не меняйте никанейма по жизни. Alexander, вас заинтересовало что-то конкретное? Если так — это можно сделать темой следующего поста. oshyshko, каюсь — слушал Гришковца, очень понравилось. Вполне возможно я несознательно допустил его вклад в статью. Но, кажется, теперь я знаю секрет его гениальности. Говорить про свой опыт можно часами. Тем более, если им некогда гордился, а теперь вспоминаешь как наивное и красивое детство. Попробуйте поведать что-то из своего прошлого. Уверен, будет тот же эффект. Что касается Спектрума. То, с чего начал статью (бытовой компьютер ЛИК) — это его брат, только не такой цветной. Те еж кассеты, тот же пиииииииии... тыдыш!... вжвжвжжжвжвжвжуииииииииввжжвшшшвшвшвшвшшшвуиииииип! Когда слушал эти байты и мыль только об одном -, а получится или нет? Где нам сейчас с флешками Х ГБайтными об этом думать. А было и с ручкой в тетрадку байт за байтом, когда магнитофон поломался. Советую, очень советую загрузить эмулятор с сети и забыться на неделю в свой любимый Z80. Мой был КР580ВМ80А Охх. Иду искать эмулятор...smp, я рад это слышать. Про моки слышал и чувствую острую необходимость. Завтра обязательно попробую. Пару дней назад прикручивал к проекту DBUnit. Пока остановился на том, что надо сконфигурировать ее для записи во вьюху. Св. Бубукий. Устраивался на свою текущую работу тоже интересно. Я не знал, возьмут или нет, я просто пришел на собеседование, сказал: «я ничего не знаю из того, что мне перечислили, но готов учиться!» Меня взяли, не посмотрев ни на диплом, ни на те Делфи-проекты, которые я принес. За первых же пару дней я освоил JSP. Это было так же, как и с обработчиками в делфи. Там было все, что надо для работы программы и М и В и Ц. Это позже я узнал что джиеспиха придумана для других целей... vkozhaev, я вот сегодня поднимался в горку на своем велике и думал о вашем комментарии: сейчас «больно»? — через месяц будет приятно. Все зависит от того, как мы относимся к этой боли. Тот, кто получает удовольствие, думаю, уже понял причинно-следственные связи на прошлом опыте. Лично я стремлюсь к тому, чтобы максимально делать свое хобби. Там любая «боль» в кайф. Вот собирал кубик рубика. Первый прорыв через боль и собрал, потом за 10 минут, за 5, 4, 3, 2.5, 2, 1.5, 1.3... На меня посмотреть с боку — чувак «болеет». Крутит и крутит. В маршрутке крутит, за обеденным столом крутит, на перекуре крутит, в туалете крутит. Сочувствую тому, кто нехотя бы взялся за то же дело только чтобы кому-то что-то доказать. Вот ему «больнее» всех. А если мотивация идет изнутри, тогда все немного иначе. Про «то, что не убивает»: если идти достаточно долго, то куда-то обязательно придешь. Остановка на этом пути — смерть, но смерть не так как мы привыкли ее видеть с косой, а просто остановка. Все когда-то останавливаются. И я вот с кубиком тоже остановился на 1 минуте и 20 секунд, но остановился потому, что потерял интерес. Продолжить и изучить другую методику скоростной сборки без мотивации для меня пока будет очень больно — жду попутного ветра. А есть и другая фишка — решать головоломку с закрытыми глазами. Но тоже будет побаливать. Владислав Максимчук, спасибо мне это приятно слышать. flyman, перефразируйте, пожалуйста. Кажется, я плохо понял.

Клас! Статья интересная, многое совпадает с моей историей. Но вот остальные моменты постараюсь подтянуть. Пока что ТДД и БДД не вошли крепко в повседневку.

1 Main KampfДумаю наступний крок — логічний доказ того, що програма (метод) працює згідно специфікації, тоді вернешся на початок спіралі

Как будто слушаешь Гришковца, только он тебе не про школу и детство, а про программирование.
Вот точно такую мысль подумал =) Хорошо написано.

В статье должна быть фраза «а потом в Киев пришли аутсорсеры и меня с моими нулевыми знаниями взяли на работу». Вообще-то до бума 2003 года порог вхождения был намного выше, чем обработчик в Delphi.

Блин, не понимаю я людей, которые радуются трудностям. Вот в упор не понимаю. То, что нас не убивает, конечно делает сильнее, но как быть с тем, что убивает? Или ты думаешь, что все сразу гениями рождаются, а те, кто не гении обязаны быть счастливы работая за похлёбку? По теме, нормальная статья, показывает путь человека от простого к сложному

В статье должна быть фраза «а потом в Киев пришли аутсорсеры и меня с моими нулевыми знаниями взяли на работу». Вообще-то до бума 2003 года порог вхождения был намного выше, чем обработчик в Delphi.

неплохо написано. Мне понравилось, уже есть стиль;) сам сейчас где-то на этой ступениPSты используешь mock-объекты в юнит тестах в TDD?

Прочитал как будто про себя. Автор молодец, точно подмечаешь суть.Как будто слушаешь Гришковца, только он тебе не про школу и детство, а про программирование. И всё кажется твоим.Осталось только вспомнить ZX Spectrum с его играми на кассетах.Спасибо!

статью надо было сразу «Моя борьба» называть:)

Підписатись на коментарі