Вам не страшно открывать редактор?

    В какой-то момент я стал замечать, что пишу более качественный: оптимальный, логичный и читаемый код, но пишу его медленно. По крайней мере, куда медленнее, чем лет 15 назад. Да, на старый код без слёз не взглянешь: всё можно сделать оптимальнее и, по крайней мере, читабельнее. Но код был написан быстро.

    Проблема в контроле. Я стал жестче и глубже контролировать код и… стал тратить на этот контроль слишком много ресурсов.

    Основной принцип прост. Если контролю подлежит 10-20% случаев, то на контроль надо тратить… 0% ресурсов. Баги и переписывания всё равно будут. Но лучше разделить кодирование и отладку и на время кодирования об ошибках вообще забыть.


    Немного теории и аналогий


    Выдающийся психолог Лев Семёнович Выго́тский, показал, что действия человека итерационны. И состоят из его действия, контроля над этим действием и исправления ошибок.

    Например. Когда ребенок тянется рукой к игрушке – это происходит за несколько итераций:
    • Выдвинуть руку вперед
    • Оценить расстояние до игрушки
    • Еще выдвинуть
    • Проверить тактильный контакт
    • Дать команду пальцам на сближение.
    • И т.д.
    Для взрослых пример – движение мышки. Когда мы «тыкаем» в ссылку, то первым быстрым движением подводим курсор в область ссылки, оцениваем положение курсора и доводим до движение конца. Либо дополнительным быстрым рывком, либо чуть менее быстро и более плавно, чем в начале движения. Это получается настолько быстро и привычно, что движение кажется слитным.

    Наработка автоматизма – это отключение контроля. Или перевод его в более оптимальные, подсознательные формы.
    1. Контроль по реперным точкам – пример с мышкой. Мы не контролируем движение курсора всегда, мы контролируем его в одной контрольной точке рядом с целью. Мы делаем это очень быстро и на автомате, поэтому движение выглядит слитным.
    2. Подсознательный контроль. Если на раздражитель есть стандартная реакция, то быстро нарабатывается подсознательный ответ. Когда мы промахиваемся по ссылке, мы не останавливаемся и не начинаем анализировать «кто виноват и что делать?». У подсознания достаточно информации, чтобы рассчитать завершающую фазу движения в фоновом режиме (и сразу же отправить на исполнение).
    3. Контроль по прерыванию. Когда движение «набито до автоматизма», то контроль включается, если что-то идёт не так. Например, заглючил драйвер мышки или комп подвис. Расчёт траектории стал сложен. В этом случае мы, включаем речевой аппарат для «слива» эмоций и несколькими сознательными итерациями доводим мышь. Поскольку драйвер глючит редко (а колесики с намотанным на них мусором уже почти история), то и контроль нужен редко.
    А самое главное, мы даже и не думаем, что можем промахнуться по ссылке. (Не напоминайте мне про мобильные браузеры).

    Цена вопроса


    В «Аквариуме» Суворова-Резуна упоминаетcя различие в подготовке спецназовцев и цирковых артистов.

    «Я уже грамотен и понимаю, что человек может ходить и по телеграфному проводу над бездонной пропастью. Все дело в психологической закалке. Человек должен быть уверен, что ничего плохого не случится, и тогда все будет нормально. Цирковые артисты тратят годы на элементарные вещи. Они ошибаются. У них нет научного подхода. Они базируют свою подготовку на физических упражнениях, не уделяя достаточно внимания психологии. Они тренируются много, но не любят смерть, боятся ее…»


    Автор сгущает краски. Но смысл понятен – спецназовцы отказываются от контроля (я не могу упасть), а цирковые развивают контроль до совершенства (я могу упасть, но почти в любой момент могут исправить ситуацию, поэтому я должен контролировать почти любой момент)

    Технология удержании равновесия проста (пусть не на проволоке, где специфичные движения, а, скажем, по узенькой доске). Нужно идти с постоянной скоростью четко ставя ноги. Небольшая ошибка в постановке ноги или отклонении корпуса не страшна. Страшно её исправление. Попытка восстановить якобы потерянное равновесие, приводит к резонансу, каждая новая попытка раскачивает ещё сильнее. Чем выше доска, тем выше цена ошибки, и тем раньше включается контроль. А с ним смертельно опасная «работа над ошибками».

    Итак, нам нужно две вещи. Не реагировать на небольшие отклонения. Поступательное движение само их сгладит. И уметь чётко, не входя в резонанс исправлять ошибки большие.

    Спецназовцы ходят над пропастью не каждый день, скорее по особым случаям (по крайней мере без страховки). Посему достаточно научить их не бояться ошибок на высоте и, следовательно, самой высоты. Отсутствие работы над ошибками (или ограниченный вариант – противодействие порывам ветра) будет выливаться в смертельные случаи слишком редко (тренированный человек редко фатально ошибается, плюс есть страховка). И не стоит тратить годы на выработку «контррефлексов» на каждый возможный случай.

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

    Как писать код, зная всё это?


    С теоретической частью закончено. Давайте, не расслабляясь, к практике.

    Главное из чего мы должны исходить – в нашем коде меньше ошибок, чем нам кажется. По крайней мере мы должны в это верить, пока пишем код. В идеале считать, что не можем ошибаться в принципе.

    Скажете бред? А что какова наша реакция, если код заработал с первой попытки: WTF?!!! Что я не так делаю?!!!

    С возрастом опытом мы всё более уверены, что должны ошибаться. И заранее ждем этого. Написали три строчки? Там может (!) быть ошибка. Надо проверить. Нет ошибки? Это как-то подозрительно. Надо покурить и подумать.

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

    Не беспокойтесь, просто выделите достаточно времени для отладки. А если его окажется слишком много, то с чистой совестью почитайте Хабр.

    Дисклаймер


    Эти рекомендации относятся к опытным программистам.

    Если вы только начинаете карьеру, пренебрегать контролем нельзя ни в коем случае.

    Чем тщательнее вы себя контролируете, тем быстрее нарабатывает автоматизм. По сути именно для этого контроль и нужен… для более эффективной наработки автоматизма. На любой стадии развития.

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

    Итак…

    Работайте большими итерациями


    Разделяйте фазы написания, проверки и отладки. Считайте, что вы не ошибаетесь в коде. По крайней мере пока его пишите, вы не может ошибаться. Вообще.

    Старайтесь написать как можно больше кода не останавливаясь, как минимум закончить функциональный блок (Upd: но оставьте время, чтобы тестирование/отладку закончить «сегодня», «до обеда» (до любого большого перерыва), не откладывайте её ненадолго и вообще не откладывайте). Остановка для проверки и отладки кода – это переключение контекста, на которое тратятся ресурсы и сбивается ритм. Проверку кода можно и нужно вынести в отдельную фазу перед отладкой. А отладку начать «сверху вниз». Начните так делать, и вы удивитесь, как часто код может заработать сразу или сразу после исправления синтаксических ошибок. (Upd: Я попробовал и был так удивлён, что написал эту статью).

    Главное, не останавливайтесь для проверок. Не надо проверять порядок аргументов вызова функции по справочнику, если мы его примерно представляем. Это можно будет сделать потом (а возможно и не придется никогда). (Upd: Если использует ASSERT'ы, и не можете придумать условие сразу — поставьте в коде метку и идите дальше. Если используете строгую методологию, напишите _ASSERT(false) и забудьте про это место до ревью/отладки.)

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

    Если нужно использовать несколько однотипных блоков (а вы не уверены, что они работоспособны) не надо проверять первый блок, как мы обычно делаем. Просто напишите, как вам кажется правильным или вынесите блок в функцию. Поправить несколько блоков в последствие выгоднее, чем терять темп и мысль.

    Upd: Большой кусок кода не должен означать, что качеством кода надо жертвовать без причин. Пишите сперва комментарии, потом блоки, потом код. Сделайте этот процесс привычным, чтобы он не вызывал каких либо заминок.

    Да, иногда, стоит пожертвовать производительностью ради лаконичности и читаемости. Точнее говоря, просто не надо заморачиваться производительностью без необходимости.

    Да, иногда стоит оставить некрасивую конструкцию. Если её переделка нас задерживает, а мы готовы рваться впёрёд на всех парах. В этих случаях ставьте метки в комvентариях. Я использую TODO и HACK. Они сильно помогают перед финальным ревью (естественно, в альфе их уже быть не должно, как кода, который они помечали).

    Проверка до отладки


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

    Впрочем, если есть уверенность, что всё написано правильно, нужно сразу запускать код на исполнение. Как я упоминал, вы будете поражены, как часто он работает как и задумано с первой попытки. Чем больше контроля – тем больше неуверенности и больше вероятностей сделать не так.

    Однако если что-то пошло не так, то…

    Не спешите с дебагером


    Итак, Хьюстон, у нас проблемы.

    Втыкаем брек пойнт или отладочный вывод в код и на исполнение? Стоп!

    Что нам это даст? Вариантов два. Первый, мы убеждаемся, что ошибки здесь нет и начинаем проверять другое место. Второй, мы убеждаемся, что ошибка тут и радостно лезем её чинить. Отличный метод. Позволяет «эффективно» потратить рабочее время с чистой совестью. Мы ж не на хабре сидим – мы отлаживаемся.

    На самом деле, когда мы выбрали точку для отладки – мы сделали 60% работы. Мы же не просто так её выбрали (ну я на жто надеюсь). Давайте сделаем оставшиеся 40%. Ну, или хотя бы 30%, а 10% оставим на вероятность эпик фейла.

    Всё что нам нужно – это сделать шаг назад. Назад по коду. Мы ждем, что в этом месте будут проблемы. Почему именно здесь? Что здесь может быть не так? Часто достаточно посмотреть код, чтобы это увидеть.

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

    А если мы ничего не нашли «методом пристального взгляда»? Эээ… Вы по-прежнему уверены, что репер надо поставить именно в этом месте?

    Если нужна точка для диагностики проблем, то, по крайней мере, эффективно использовать двоичное деление. Давайте сразу проверим, есть ли ошибка в середине функционального блока? Разобьём код пополам и поставим репер.

    Нет, мы всё-таки хотим плясать от начала. Ладно. Но вот в чём проблема. Если ошибка есть в начальном фрагменте, будем ли мы «копать глубже»? То есть писать ещё какой-то отладочный вывод, позволяющий более чётко идентифицировать ошибку. Будем? Так давайте сразу его и напишем. Зачем запускать программу два раза. Возможно, до этого и не дойдёт, просто подумав какая именно дополнительная информация нам нужна, мы часто сразу поймем где затыка.

    По той же логике имеет смысл проверить ещё несколько реперных точек сразу. 80% ошибок – это отсутствие сигнала (действия, результата), а не его искажение. Более того, искажение результата – это, скорее всего, его отсутствие на предыдущем этапе. Расставляя несколько реперных точек, мы ещё раз волей-не волей просматриваем программу. И «волшебным образом» находим ошибки, до запуска дебагера.

    Не бойтесь поднимать глаза и смотреть на код выше предполагаемого места сбоя, очень часто там уже поставлена табличка «Я здесь! Люблю, жду! Твоя ошибка».

    Не придумывайте себе проблемы заранее



    Известный (возможно самый известный) игрок в покер Дойл Брансон, знаменитый весьма агрессивной игрой, говорил (не ручаюсь за достоверность цитаты), «Когда меня спрашивают, что я буду делать, если соперник поднимет мою ставку, я отвечаю: Не знаю, но пусть он сперва поднимет. А вот потом уже я буду думать над этим.»

    Вспомним «комплекс непрофессионала», когда профессионал зная, что проблема не решаемая и почему, отказывается даже начинать работу. Новичок, не обладая такими знаниями, начинает делать работу и … делает.

    На самом деле, это происходит не так чтобы часто и часто не совсем так. Профессионал знает, что написав 300 строк кода из, скажем, требуемых 400, он столкнётся с проблемой. И он даже знает с какой. Он не начинает писать код, а пытается сразу найти решение будущей проблемы. Находит решение (если профи не STFW, то он не профи, так ведь?), но выясняется что это решение неполное и у него есть недостатки. Которые можно исправить, если найти решение для вот этого проблемного участка… И такое решение находится, только вот,… есть нюанс…

    Как вы догадываетесь – это прямой путь в депрессию. Хабр, баш, анекдоты, новости, ЖЖ и даже порносайты политические дебаты. Депрессия конечно отступит, но работа стоит. Что же делать?

    Прыгать. Надо прыгать. То есть писать ту часть кода, в которой проблем нет. Когда мы дойдём до страшной проблемы, которую мы, в силу своей опытности, заметили заранее… Может выясниться, что она решается простым путём, её можно обойти или такой функционал уже не нужен.

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

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

    Также в лес проблемы связанные с производительностью. Я как-то поймал себя на том, что пытаюсь более оптимально переписать цикл на 1000 итераций. Вроде дело полезное. Но я перед этим разбираю мегабайтный JSON файл в памяти. Кого волнует, что я вложенность временного хэша снижу на уровень. Пользователь и так секунду ждёт. Ему 20 миллисекунд погоду сделают?

    Да-да, производительность тоже в лес, а лес в топку До разумного предела, разумеется… Если у нас сейчас тысяча пользователей, не надо писать приложение, которое потянет миллион. Плохо конечно писать приложение только на тысячу пользователей, но и перезакладываться более чем на порядок – мягко говоря, не оптимально. С ростом «клиентуры» придется менять и функционал и возможно движок. И зачем лишний контроль за идеальностью кода, который будем переписывать?

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

    Просто садитесь, и пишите код. Пусть не и идеальный. Я верю, что вы его доведёте в процессе.

    Не спешите искать новую лопату


    Помню, как меня не по детски бесил python после perl. Такое впечатление, что гонщика заставили сесть в трамвай. Да трамвай скоростной, а рельсы гладкие и блестящие, и скорости те же, но… Там где я привык осознанно использовать умолчания, python выкидывал exception. Вдруг я не знаю, что такого элемента в хэше может и не быть. Это ж катастрофа!

    Меня стали контролировать, я стал злиться и терять время. Терять время и злиться. Мне показалось, что лучшее решение это ruby (помните анекдот про уток?).

    С одной стороны хорошо. Разобрался пусть и «на пальцах» с рельсами. Заодно лучше понял, как работает перловый Catalyst. С другой стороны на три месяца забросил проект, который сейчас обратно пишу на питоне.

    На самом деле, на питоне надо писать «pythonic», а не пытаться применять перловую парадигму: беспорядок в источниках – управляемый беспорядок в памяти – порядок на выходе.

    Вывод из вышеприведенного сумбура сделать сложно. Но он есть. Не спешите менять средство разработки или библиотеки.

    Идеальных средств разработки не бывает. У новой лопаты штык изогнут под более удобным углом. Но вот ручка,… сильно непривычная и норовит ударить сами знаете куда.

    Проблема в выборе инструмента – это опять же путь к депресии. Нет уверенности в том, что новый инструмент подойдёт. А время на его изучение придется тратить. Делать тесты и набивать шишки. Набитые шишки – это скатывание к всё более мелким и мелким операциям. А стало быть потери инерции и скорости.

    Upd: Пробовать новые инструменты стоит когда есть запас времени. А не когда поджимают идеи или сроки. Или и то и то. Искать новые инструменты в такой ситуации — часто это стоять на месте. Рано или поздно у вас случиться откат, когда идей нет, а работа вся либо сделана, либо не так важна, чтобы её делать. По крайней мере делать её 14 часов в сутки. Это время хорошо посвятить новому.

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

    Не бойтесь выкидывать


    Я не помнил точно фамилию психолога, на которого ссылался в начале статьи. Если бы я не нашёл в своём бардаке «Введение в психологию» Б.Ю. Гиппенрейтер, то я бы просто удалил этот абзац, чтобы не откладывать публикацию. Я в черновую вычистил статью от ошибок, но их осталась пачка. Я чувствую. Не могу понять только где ;)

    Но если вам нравится статья – то ошибки фактор маловажный. А если не нравится,… то ещё более маловажный.

    Если хотите что либо сделать, делайте сразу. И публикуйте сразу.

    Не бойтесь конкурентов. Если вы что-то не доделали, то конкуренты, скорее всего тоже не доделают. Причём именно то, что не доделали вы. Им же надо спешить, чтобы подвинуть вас с рынка. А когда они повторят ваши ошибки,… вы уже выйдете с новой версией на новом белом коне… с семью ногами.

    Отполировать бархоткой можно в процессе. Есть продукты эппла. Где немалая часть цены – технологическая эстетика. Но… в них просто пожертвовано было другое. Например, первый макинтош ради законченности корпуса был лишен слотов для плат расширения, что стало одним из факторов его проигрыша IBM PC (по крайней мере, по объему продаж).

    Да, Джобс рискнул отказаться от ненужного. И пусть он, возможно, проиграл ту битву, но сосредоточившись на сильной стороне – дизайне, в итоге сделал Apple, нынешним Apple.

    Отказывайтесь от того, что не потянете или что мешает выходу прямо сейчас. Не бойтесь выдавать пользователям обрезанные беты. Они куда лучше необкатанных альф.

    Большинство изящных решений находится именно в процессе эксплуатации. Главное её начать.

    Шлите на…


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

    Шлите его на…

    Сразу. Без интеллигентостей и попыток объяснить, почему вы сделали именно так. Ну, если он конечно не ваш начальник. В этом случае… я пару раз рисковал послать начальника. И в итоге выигрывал я, особенно если начальник менялся.

    Если вы что и сделали плохо, это только повод сделать следующую работу лучше. Или сильно лучше. Главное не останавливаться, не оглядываться и не смотреть вниз.

    Вы что-то сделали. Вы получили опыт. Вы получили удовольствие от сделанной (по крайней мере доведённой до конца) работы.

    Upd. Что же считать конструктивной критикой? Это предложение как улучшить вашу работу. Особенно просто реализуемые и обоснованные. Это ссылки на подобные проекты из которых вы можете почерпнуть новые идеи. Это технологии (да-да те самые новые лопаты), которые пригодятся, если придётся делать качественный рывок, например по производительности.

    А неконструктивные критики… Эта система контроля. Используемая в 10% случаем. А, следовательно, не нужная.

    Upd И ещё раз подведём итоги


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

    И самое главное


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

    Всё идёт хорошо.
    Поделиться публикацией

    Комментарии 115

      +15
      Какая хорошая и нужная статья!

      Вы сэкономили многим людям деньги на антидепрессантах.
        +7
        антидепрессанты — это весело же!
          +1
          А главное — вкусно!
          –4
          а Вы потратили время остальных людей на чтение бесполезного комментария.

          Хинт:
          image
            +3
            А вы потратили время на троллинг.
          +19
          > в нашем коде меньше ошибок, чем нам кажется
          Ну здесь можно сказать только одно — ха-ха-ха.
          Разве что это является мантрой для самовнушения :)
            +4
            Тсссс… не выдавайте никому эту тайну;)

            Так оно и задумывалось
              +1
              Над «в любой программе есть ошибки» мы смеемся.
              А в «в моей программе ошибок нет» либо слепо верим, либо так же слепо не верим.
                0
                > Colwin

                Вау, ты таки как простой смертный бываешь на Хабре.

                > Над «в любой программе есть ошибки» мы смеемся.
                > А в «в моей программе ошибок нет» либо слепо верим, либо так же слепо не верим.

                Что происходит, когда твой код становится чужим, а чужой — твоим? (merge в одном функциональном scope; поддержка legacy; поддержка того, что изначально написал ты, а потом поддерживал какой-то другой человек; итп)
                  0
                  Второй случай — слепо не верим :-)
                  P.S. Привет-привет :-)
              +1
              Сейчас объясню идею. Мы начинаем писать программу. Допустим я недавно писал «эскпертную» систему поиска соответствий в базе статистики. Наша база oracle, база к которой надо привяpаться общается через JSON простыни.

              Пишу первый шаг привязки что-то типа.

              $rec = $dbh->selectrow_arrayref('select from expert_base ...
              $top_catalog = first {
              $rec->{JSON_VALUE} eq $_->{id}
              } @{$json->{sport}};


              Сразу хочется написать

              warn $top_catalog;

              Или даже

              warn Dumper($top_catalog);

              Вопрос зачем? Я так уверен что тут в 4 строчках ошибка? Не лучше ли сразу идти дальше.

              Если я начну ловить ошибки которых нет, я сразу признаю, что ошибок больше чем я думаю. Логично?)
                +4
                Лев Семёнович изумился бы, во что вылились его наработки %)

                Если я начну ловить ошибки которых нет, я сразу признаю, что ошибок больше чем я думаю. Логично?)


                Логично лишь то, что вы признали бы в этом случае, что ошибки возможны. И это признание ни в коем разе не могло бы быть связано с указанной количественной характеристикой. Ошибки действительно возможны.

                Однако же, неоспоримо, что на переключение между контекстами будет затрачено какое-то время, и по возможности его следует минимизировать, и ваш подход вполне имеет право на жизнь. Впрочем, наряду со множеством других.
                  0
                  Ошибки возможны, но не в то время когда пишу код. Я супермен, я гений, я супермозг! Ну по крайней меря так думаю. Вот когда тестируюсь, я параноик. а когда ревьюшу код, я эстет.

                  Ну да с «серебряной пулей» постоянные проблемы. А так хочется.
                    0
                    Как минимум всегда ставлю проверку корректности запросов
                    my $sth = $DBH->prepare($sql)|| die "[prepare] $DBI::errstr";
                    


                    А в целом логгирование очень упрощает «разбор полетов»
                  0
                  Ну и что?
                  Я лично часто после логически законченного участка кода вставляю assert'ы.
                  Во-первых они повышают субъективную уверенность в коде, во-вторых — никак не влияют на производительность. И, в-третьих, не отнимают много времени.
                    +1
                    Когда-то я писал фрагментик кода, где нужно было обязательно отлавливать все ошибки и писать в лог. Работа была с деньгами пользователей и во избежание матов с их стороны, я очень тщательно обрабатывал все эксепшены, которые могли вылететь. В итоге я подловил даже такую ситуацию, когда эксепшн ну никак не мог вылететь, но я все равно обработал этот блок и написал что-то вроде log(«It's unbelievable!!!').
                    Как думаете, какая первая запись появилась в моем логе? ) В итоге оказалось там просто опечатка была, а по логике действительно не могло там ничего вылететь.
                  +20
                  Далеко не у каждого программиста поиск нетривиальных решений задач приводит к депрессиям. У таких программистов отношение к проблеме иное — чем сложнее далось решение, оказавшееся в итоге гораздо эффективнее самого очевидного варианта, тем большее удовольствие от работы они получают.

                  Ваш подход хорош, когда создаваемый продукт «стандартен» и не требует поиска нетривиальных решений, которые, к слову, могут заключаться и в переходе на другие языки программирования.
                  Но даже на рынке стандартных тривиальных продуктов может сложиться так, что ваш конкурент соберёт команду таких программистов, которые окажутся «управляемыми перфекционистами». Т.е. у него получится за меньший срок сделать продукт качественнее, чем у вас. И что же тогда будете делать вы? Вам нужно предпринимать какие-то новые шаги в сторону лучшего продукта, но к вашей ноге прицеплена большая и тяжёлая гиря в виде текущего кода, созданного по принципу «TODO: will fix this someday».

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

                  И я бы не стал категорически отметать ни 20-миллисекундные оптимизации, ни выбор новых инструментов, ни критику со стороны. Потому что практика показывает, что там, где есть возможность оптимизировать 20мс, иногда можно найти оптимизацию в 2 секунды, если посмотреть на задачу под другим углом. А то, что поначалу казалось неконструктивом, оказывается очевидной правдой — просто на тот момент у тебя не было достаточного опыта и глубокого понимания проблемы, что заставляло тебя говорить абсолютную чепуху, на которую знающие люди реагировали резко, без лишних объяснений, но по существу.
                    –14
                    Эмм… вы читали дисклаймер?

                    Нет? Тогда идите на… (с)
                      +13
                      Читал. Продолжим?
                        –12
                        Тогда концепция действительно не поменялась. Раз читали и не поняли.

                        Ваша позиция деструктивная критика. Логичная, но деструктивная.
                          +11
                          Это была не критика, а контраргументация.
                            –3
                            Ок.

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

                            Я сказал, что поиск нетривиальных решений приводит к депрессии? +1 к троллингу. я сказал что к депрессии приводит отсутствие решения. И не надо впадать в депрессию заранее. До того как мы подойдём к этому решению. Сперва к нему надо подойти. А там или решение появится или задача поменяется.

                            > Ваш подход хорош, когда создаваемый продукт «стандартен» и не требует поиска нетривиальных решений, которые, к слову, могут заключаться и в переходе на другие языки программирования.

                            Опять же где вы это увидели. Мой подход в разделении программирования и отладки. И психологичиском настрое писать прямо сейчас и не думать об ошибках и проблемах. Вам +1. А нет, вы смешали два понятия из разных частей статьи. Это контрагрументация или софистика? Еще +2.

                            Ок, давайте опять же отвечу, что если есть решение которое можно сесть и со скрипом запрограмировать на том, что есть, это лучше чем тратить время на ожидание и изучение волшебного решения. Хотя эта часть статьи спорна поэтому сниму с троллинга -1 балл.

                            > Но даже на рынке стандартных тривиальных продуктов может сложиться так, что ваш конкурент соберёт команду таких программистов, которые окажутся «управляемыми перфекционистами». Т.е. у него получится за меньший срок сделать продукт качественнее, чем у вас. И что же тогда будете делать вы? Вам нужно предпринимать какие-то новые шаги в сторону лучшего продукта, но к вашей ноге прицеплена большая и тяжёлая гиря в виде текущего кода, созданного по принципу «TODO: will fix this someday».

                            [irony]Если у конкурента есть такие замечательные и талантливые люди, то наиболее оптимально эту команду использовать для повторения чужих разработок. Это общеизвестный факт. Скорее эта команда выпустит коня на пяти ногах, пока пользуясь моей аналогией вы будете красиво отпиливать у него 6ую. За трллинг 0.

                            >А решение, на мой взгляд, очень простое. Нужно просто понимать, что ключ к продуктивности лежит как в оттачивании имеющихся навыков, так и в получении новых. Поэтому в какие-то моменты могут быть провалы в продуктивности, связанные с обучением. Их нужно воспринимать как часть нормального процесса, а для этого стоит просто переключиться на другую шкалу измерения продуктивности. Например, вместо строк кода/функциональных единиц выбрать количество освоенного материала за период времени.

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

                            >И я бы не стал категорически отметать ни 20-миллисекундные оптимизации, ни выбор новых инструментов, ни критику со стороны. Потому что практика показывает, что там, где есть возможность оптимизировать 20мс, иногда можно найти оптимизацию в 2 секунды, если посмотреть на задачу под другим углом.

                            А я бы стал. Оптимизировать скорее надо частые операции пусть даже и дешевые, а не редкие пусть даже дорогие. К тролингу не за что, а вот за матчасть -1.

                            А то, что поначалу казалось неконструктивом, оказывается очевидной правдой — просто на тот момент у тебя не было достаточного опыта и глубокого понимания проблемы, что заставляло тебя говорить абсолютную чепуху, на которую знающие люди реагировали резко, без лишних объяснений, но по существу.

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

                            И вы продолжаете это называть контраргументацией? ;) И удивляться почему я последовал собственному совету и вас послал?)
                              +15
                              > И вы продолжаете это называть контраргументацией? ;) И удивляться почему я последовал собственному совету и вас послал?)

                              Я удивляюсь почему у вас вообще такое отношение к человеку, который пытается построить диалог в обсуждении материала. Обвинить кого-то в троллинге и нехватке матчасти, попутно послав его подальше, может абсолютно любой. Это гораздо проще, чем попытаться понять о чём говорит другая сторона.

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

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

                              Вот моя позиция, которую вы, в следствие своего пренебрежения к чужому мнению, не заметили.
                                –10
                                вы опять выдергиваете фразы из контекста и вольно интерпретируете слова. Поэтому я позволяю принебрежение к вашему мнению.

                                Если хотите более уважительного отношения, относитесь более уважительно к чужим текстам
                                  –8
                                  Поздравляю, вы отличный тролль.

                                  Жаль что я не последовал собственному совету и таки вступил с вами в дискуссию. В ней вы однозначно победили — извините у меня нет времени дальше дикутировать с человеком единственное желание которого показать, что я неправ, только потому что он лучше знает как надо.

                                  Похожий случай был с моей крайней короткрометражкой. Я показал своему знакомому. Который кстати сам ничего не снимает. Он меня достал вопросом где изменение характера героини (да изменение характера очень фактор). Я ответил, что изначально планировалось, что я играю с настроением зрителя, а характер не трогаю. Нет изменения характера и всё. Не нужно оно там, мне нужно не сопродвижение, а сопереживани от зрителя.

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

                                  Меня начали грузить какими-то новомодными сценарными концепциями. Я честно попытался объяснить, что вот тут хочу вызвать сочуствие, вот тут грусть, тут заинтересованность тут улыбку. И удержать восприятие зрителя.

                                  Меня начали спрашивать, что по этому поводу сказал бы известный буржуйский сценарист. Откуда я знаю. Это моя работа, а не его. как сценарист — я сработал идеально. Как режиссер да — накосячил местами. Человек словил батхерд, и свалился в истерики «КАК ТАК МОЖНО?» пришлось ему сказать, что я о нем думаю — одним словом.

                                  Ничего потом поговорили, побухали. Разобрались. Бывает ;)
                                    +3
                                    Хотел бы добавить, что не зря придумали парное программирование.
                                    Оно позволяет разделить написание и анализ кода между двумя разными людьми, но в одно и то же время.
                                    Эффективность этого подхода, насколько я знаю, всегда оказывалась выше, чем просто написание и анализ кода обоими по-отдельности.
                                      +1
                                      Самое сложное — это договориться и построить так работу. А то начинается, что человеку нужно свой код дописать, ему не до твоего. Или оба под нагрузкой — не до ревью — лишь бы инвестору что-то показать.

                                      А так работает замечательно.
                                    0
                                    тем не менее спасибо, спор с вами помог более связно изложить некоторые мысли ;)
                                +8
                                А конструктивной критикой, в таком случае, будет похвала? «Молодец, хорошо написал. Можно и нужно лучше, но всё равно молодчага» — такой себе подход для обучения человека, от которого многого-то и не ждут.
                                  –3
                                  Нет. На самом деле статья сумбурная и местами спорная. Но в изначальном комментарии выше лейтмотив был такой «ты ничего не понимаешь и тебя просто ругали мало, но ничего я исправлю.»

                                  Я пытался сейчас на работе программирую на pl/sql, js, perl,delphi сейчас ещё прибавится java и c под андроид. Ещё и не по работе есть прикольный стартап, до которого с лета руки не доходили.и еще съемки. В общем крыша хорошо едет. Вплоть до зависания. Подловил себя на излишнем контроле и лишних итерациях на отладке и поиске серебряной пули для стартапа. Вот и статья)

                                  Правда уже понял, как стоит переписать.
                                    +7
                                    А может вы просто слишком распыляетесь? Такие случаи, по-моему, описывали и до этого. Как вариант — можно уменьшить нагрузку, сконцентрировавшись на более узком кругу задач.

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

                                    Иначе откуда брать знания? Книги все по рефакторингу не перечитать, за блогами всеми не уследить, все самые свежие 3rd-party-решения в книгах не описаны — а ведь именно это всё помогает работать наиболее продуктивно.

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

                                      Проблема в том, что это не более опытный сотрудник. В личку объясню почему. А меня ругать нельзя, я над-мотивированный и полезависимый. Поругаешь не по делу я сразу заявление на стол. Просто потому, что буду считать, что раз не справляюсь не вижу смысла дальше работать. Про код ревью,… у меня хороший код. В основном. Бывают исключения. На пред-предыдущей работе, написал дикий код под дикие требования. Собрался зарефакторить, а меня перевели на другой проект. Потом контора распалась на две. В той, в которой остался код, меня потом долго поминали, душевно. Хотя попросили бы объяснил, как просто всё переписать.

                                      Я и не говорю, что не нужен рефакторинг. Лучше сказать пишите код, пока рефакторинг не понадобится. Потом уделите время рефакторингу.

                                      Просто не надо заниматься рефакторингом пять раз на дню и не надо им заниматься пока он реально не нужен. А если занялись то ломитесь вперёд как лось. Полурефакторинг хуже, чем никакого.

                                      Масштабирование по функционалу или производительности?
                                        +1
                                        «Поругаешь не по делу я сразу заявление на стол» — это очень трудная позиция для восприятия новых знаний, да и вообще очень трудная позиция(для окружающих). Я бы не хотел с вами работать :) Все мы считаем свой код хорошим, насколько это правда может сказать только более опытный и авторитетный коллега, не обязательно сотрудник.

                                        Насчёт «полурефакторинга» не совсем ясно, его просто не бывает. Рефакторинг — процесс итеративный и постоянный, постепенное улучшение качества кода. То есть он != переписыванию всего с нуля и по-новой. И проводить его лучше сразу, ведь не даром существует знаменитая мантра red/green/refactor (и тут), откладывая его *до нужды* можно хорошенько запустить проект. Это как раз описанные выше случаи.

                                        Конечно, многое зависит от культуры сообщества, в модных ruby-python-комьюнити это само собой разумеется и приветствуется. А масштабирование я имел в виду функциональности.
                                          –1
                                          А меня, действительно очень редко ругают. И я это тяжело переживаю (полезависмость — это зависимость от чужого мнения) и стараюсь до такого не доводить. Я сейчас шаманю с мелким проектом надеюсь через неделю две его выложить в исходниках и естественно этим похвастаться. Тогда можно будет и оценить.

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

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

                                          К счастью я попадал в ситуацию глобального штурмового рефакторинга один раз. С тех пор сильно не люблю PHP. Просто плохие воспоминания.
                                    +1
                                    хотя когда хвалят приятно, да)
                                –13
                                -4, как минимум 4 человека не дочитало статью до конца (по крайней мере предпоследнюю главу) и сразу полезло в комментарии
                                  +21
                                  Необоснованная грубость, пусть даже обёрнутая в цитату, меняет отношение других к человеку. А безапелляционные отсылы перечитать статью — это просто некрасиво.
                                    –9
                                    Знаю, но всё же рискнул быть последовательным. Отзывы выше.
                                +2
                                > У таких программистов отношение к проблеме иное — чем сложнее далось решение, оказавшееся в итоге гораздо эффективнее самого очевидного варианта, тем большее удовольствие от работы они получают.
                                Согласен. На скорую руку можно писать, когда нужно быстро запустить проект, прям очень быстро. А вообще большинство программистов, опытных и увлеченных самим процессом программирования, относятся к коду как к искусству. И когда их заставляют писать быстро и лишь бы работало, частенько просто увольняются с такой работы :)
                                +3
                                принципы годятся и на другие области, не только программирование:)

                                я не программист, было интересно примерять описанные подходы на свою работу.
                                  0
                                  спасибо
                                    0
                                    Присоединяюсь насчет других областей. Спасибо за интересный топик.)
                                    +6
                                    >в нашем коде меньше ошибок, чем нам кажется
                                    ну да, ну да :)
                                      0
                                      есть аксиома тестерская, что в проге всегда есть ошибки, сколько б ее не тестировали и не исправляли:)

                                      вопрос лишь в важности этих оставшихся ошибок.
                                        +1
                                        Угу, возможно основная ошибка — это начало работой над программой? )
                                        0
                                        Вам не страшно открывать редактор? ;)

                                        Мне страшно, сразу представляю сколько ошибок я сейчас наделаю. Поэтому предпочитаю говорить себе. что на этот раз ошибок наделаю меньше.

                                        И чтобы вы думали — оно работает. Попробовал методику, если кратко, что написано выше:
                                        — писать большой кусок не обращая на ошибки и не лазая в документацию
                                        — перед компиляцией (писал на давно забытой дельфи) пробежать по коду
                                        — не использовать дебаггер… сразу

                                        Был удивлен — оно сработало.

                                        Была пара мелких багов, быстро выловились. Забыта фича, мгновенно дописалась, как вспомнилась. В доках пришлось посмотреть одну функцию и у одной порядок параметров. Дебагер не ипользовал.

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

                                          При TDD это нормально. При прототипировании (на выброс) тоже.

                                          > не использовать дебаггер… сразу

                                          А лучше — никогда.

                                          Вообще, я понял смысл вашей статьи только после этого комментария. Возможно, следовало озаглавить весь текст вопросом «Вам не страшно открывать редактор?», тогда ЦА была бы ясна и не нарастало бы по мере чтения раздражение от непонимания причин написания статьи. =)
                                            0
                                            хорошая идея, спасибо)
                                              +1
                                              Внезапно сегодня утром увидел топик с названием «Вам не страшно открывать реактор?». Новое название видел вчера :)
                                        +2
                                        Не хватает только тезиса что ошибки можно не исправлять, т.к. «минус на минус дает плюс». В реальных проектах реально иногда бывает что реальная ошибка реально исправляется другой реальной ошибкой, извините за реальную тавтологию:) Это да. Но полагаться на это — опасновато.
                                          0
                                          Нет, здесь другое. Надо переписать статью, то ли я неправильно написал то ли меня неправильно поняли ;)

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

                                          Дальше, не спешить обкладываться дебаг информацией. На времени отладки можно сэкономить если не аытаться ловить ошибки механически.
                                            +1
                                            Можно даже усерднее обобщить содержание, если правильно вас понимаю:

                                            1. Идем от общего к частному.
                                            2. Не отвлекаемся.

                                            Если есть ясные требования, особенно сформулированные в виде тестов, можно писать код абсолютно как попало и знать, что а) ошибки от нас не ускользнут, и б) мы всегда успеем что-то улучшить и предусмотреть, не поломав программу. Но писать тесты к коду гораздо сложнее, чем код к тестам; а писать требования к тестам намного труднее, чем тесты к требованиям. Поэтому надо идти от общего к частному, от требований к реализации, не перепрыгивая через ступеньки. И тогда на душе будет спокойно :)

                                            К слову, TDD освобождает голову тем же методом, что и GTD, Pomodoro, etc.: разделяй и властвуй. Если работа не скомкана в «истерически защитное» программирование со страхом что-то упустить, а разделена на внятные процессы (а-ля: collect stuff, process stuff, organize, do; write specs, write tests, write func stubs, remove *one* xfail mark and write func), всё получается легко и естественно.
                                              +1
                                              Я бы добавил третий пункт — он основной в моей статье.

                                              3. Не сомневаемся
                                          +6
                                          мне кажется, по этой технологии работают на ВАЗе. сначала собирают что-то похожее на автомобиль, главное ведь собрать, а потом начинают допиливать напильником.

                                          а по сути, мне кажется, с увеличинием опыта работы, каждый изпытывает это на себе. если я в начале перепроверял себя после каждой строчки в ВУЗе, то сейчас, после пары лет работы, начинаю проверку после написания всего класса/функции.
                                          пы.сы.: интересно, существует ли фобия неправильно написанного кода и как она называется? :)
                                            0
                                            А у меня наоборот. В вузе писал очень большими кусками. Сейчас стал мельчить. Да, задачки сейчас нетривиальные и постоянно приходиться что-то новое изучать пробовать, но надо наступать себе на хвост и ломиться вперёд;)
                                              0
                                              > пы.сы.: интересно, существует ли фобия неправильно написанного кода и как она называется? :)

                                              наверняка существует. по крайней мере я точно тяжело страдаю тяжелой ее формой. как называется — не знаю и не уверен, что хочу ее лечить
                                                0
                                                нет. я не об этом.
                                                написал, например, класс. проверил — без ошибок. перепроверил — без ошибок. начал писать другой класс. недописав его, возвращаюсь к первому, чтобы проверить его еще раз. вот как-то так…
                                              +1
                                              рекомендую на эту тему
                                              habrahabr.ru/blogs/arbeit/88443/
                                                0
                                                весело ;) Боюсь я сейчас 4ый тип — и надо из него выбираться;)
                                                0
                                                Интересно, что же сподвигло автора на написание этой статьи… Текст заставил меня задуматься. Да, с одной стороны, счастливый работник — это подарок для предприятия, но как сделать так, чтобы счастливый работник не стал зажравшимся…
                                                  +2
                                                  Идея вобщем здравая, но как и все имеет свои последствия. Если разрабатывать что-то сравнительно большое то детали начинают ускользать сквозь пальцы и потом это легко вылезает в ощутимые проблемы.
                                                  Лично я прихожу к выводу, что не зависимо ни от чего ни на какой конкретный подход полагаться вообще нельзя, к сожалению. Всегда надо сидеть и соображать головой, иначе будет лажа. Будь то обвешивание всего ассертами или откладывание дебага и тестов на потом, или еще чего угодно. Имхо.
                                                    0
                                                    имхо, достаточно в комментариях по ходу написания кода как попало обозначать возможные ошибки, а потом уже превращать эти комменты в новые тесты к коду и уже под тесты подгонять код в следующих итерациях. возможно, заодно куча подобных ошибок найдется, когда голова свободна от реализации конкретной функциональности.
                                                      0
                                                      я использую метки в комментах TODO и HACK и перед сдачей грепаю исходники. Помогает.
                                                    +5
                                                    Тема знакома, вспоминая с каким энтузиазмом не за деньги я програмил 8 лет назад, и с каким за деньги сейчас. Щас уже другие масштабы программирования, ты делаешь уже другой объем задач, ты это делаешь за деньги и ты ответственен за тот код который пишешь. Раньше, кстати я именно так и программировал, как автор, тупо в лоб кучу кода. Сейчас же всё изменилось.

                                                    Тут возникает одна дилемма:

                                                    1) либо програмить как пишет автор, не проверяя ошибок, но есть опасность забыть то место, например где ты исправлял, пробегаясь по коду, а потом потратить больше времени на поиск ошибок. Вообщем то, что предлагает автор идеально для написания кода с нуля. А вот когда ты вносишь коррективы сразу в кучу файлов, в разные места (ну к примеру 10 файлов), есть вероятность того, что ты забудешь из за чего у тебя в коде сыр-бор и где ты опечатался в одной переменной. Такой подход конечно быстрее, но на деле — ты можешь потратить больше времени на исправлении/переписывании логики, переменных и тд.

                                                    2) програмить, проверяя каждый блок. Такой способ аналогичен фразе «тише едешь дальше будешь». Вообщем он не идеален, если у вас горят сроки, зато вероятность что вы совершите ошибку — минимальная.

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

                                                    Несколько примеров из моей жизни:

                                                    У меня был случай, когда мне довелось програмить игру Зодор (типа Ночного Дозора) я писал движок в режиме онлайн, люди выполняли текущее задание, а я програмил следующее :) у нас была виртуальная гонка, мало того я был еще оператором, которому звонили или писали в icq некоторые команды и просили проверить найденный код и выдать след. задание (не у всех был инет с ноутом). Кстати в той игре, всё прошло гладко, за исключением одной маленькой ошибки, из-за которой мой скрипт в конце не засчитывал одной команде код, я так и не смог этот момент отладить, слишком много было написано, и пришлось статистику вручную корректировать и распечатывать, на меня тогда немного обозлились. А представьте я накосячу в игре Encounter, скандал на всю страну бы был.

                                                    Был и другой случай, когда мне нужно было составить 250 договоров за ночь и привезти их к утру в другой город. Каждый договор подшивался вручную, опечатывался пломбой, ставилась печать, подпись, у нас был целый конвейер, делали мы это в троём, то есть ошибок допускать было нельзя. Прежде чем печатать все 250 договоров, я печатал образцы, каждый договор был около 10 страниц, мы пробегались быстренько глазами, если всё ок я продолжал печатать остальные уже не проверяя. Хорошо что мой брат взял меня с собой, так как когда мы приехали в город выяснилось, что половина договоров оказалась не правильные, ошибка срабатывала на некоторые реквизиты. И это всё из-за одной моей маленькой ошибки, пришлось всё переписывать на месте уже не за ночь, а за 2 часа, так как время поджимало, договора надо было сдавать, я програмил прям в каком-то гос. учреждении где эти же договора и принимали (знаете забавно сидеть как попугаю, на которого все пялятся, нужно так от всех абстрагироваться, как будто ты тут один). Мы там даже принтер где-то нарыли, в городе Чкаловск в выходной день его достать было практически невозможно. Мне тогда было очень обидно, но опыт был получен бесценный, к счастью все договора в итоге приняли. Такие дела.
                                                      0
                                                      Нет, к сожалению, для исправления ошибок — метод не применим. Одна ошибка — одна итерация. Да, возможно большая. Но исправлять пачку несвязанных ошибок я не рискну.

                                                      С дилеммой согласен. Но считаю, что код написать пока пишется, до упора. Вот как запал прошёл, можно заняться сборкой/тестирование/отладкой. Всё равно эксперимента показывали, что больше полутора часов кодирования мне в одну итерацию не удавалось уложить.

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

                                                      Ну ночные работы на флажке каждый программист может припомнить, главное, чтобы как у вас всё кончалось хорошо и код был востребованным. Обиднее когда выкладываешься в последнюю секунду, а тебе говорят: «Молодец, правда инвестор сегодня приехать не сможет. Но ты всё равно молодец».
                                                      +4
                                                      Я перестал бояться совершать ошибки в коде с тех пор как стал активно использовать TDD. Потом долго боялся совершить ошибку в тестах. Потом понял, что вероятность допустить ошибку и в тесте, и в коде очень мала, если не разделять по времени написание теста и кода, чтобы не писать код на основании теста, а писать его под действием образа о том, что я имел в виду когда писал тест. А так как юнит-тесты довольно малы, как и код их реализующий, то локализация ошибки элементарна. Да и по сфейлившему ассерту сразу видно где ошибку допустил (actual 10, expected 11 — если имел в виду, что 10 должно быть, значит в тесте, если что 11, то значит в коде). Так что что такое дебаггер почти забыл.

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

                                                        Как правило стараюсь в таких местах писать «плавно» с короткими ветвлениями кода.

                                                        С отладкой же часто ловил себя на мысли, что в 80% случаях ошибку ловлю чуть выше места, где поставил «баголовку». Стал заставлять себя делать небольшое ревью вверх от места куда руки тянуться забить дебаг вывод. Оказалась нехилая экономия.
                                                          +2
                                                          В последнее время всё больше ембеддерством занимаюсь (ARM Cortex-M3, AVR), так там методы с использованием тестов пригождаются как нельзя лучше, т.к. найти баг обычно заметно сложнее, чем при разработке для PC: код запускается на целевом устройстве, а отлаживается через плату-отладчик (JTAG или SWD) на хосте через режим target remote в GDB. Вдобавок, если выполнение кода поставлено на паузу, это ещё не значит, что кристалл совсем ничего не делает — в нём может работать периферия (интерфейсные модули, таймеры, контроллер DMA), которая может менять содержание памяти и регистров независимо от основного кода, напрямую. Короче, здесь ковыряние в отладчике — удовольствие ниже среднего, и гораздо эффективнее писать тесты и расставлять ассерты по всему коду, иначе можно потратить полдня на поиск гейзенбага.
                                                          +1
                                                          Прошу прощения, но какое отношения статья имеет к GTD? Есть блоги типа «разработка». Всё-таки разработка ПО в статье первична, а сама методология GTD в ней не упоминается вообще. Есть же тут не программисты, которые бы хотели видеть в блоге «GTD» статьи если уж не о самой GTD, то от общей продуктивности, тайм-менеджементе и чём-то близком, но не о продуктивности программиста, не имеющей к непрограммистам никакого отношения.
                                                            0
                                                            ок, перенесу)
                                                              +1
                                                              Спасибо! Хотя «Ненормальное программирование» тоже не подходит, это уже вопрос к админитсрации Хабра, ибо блога типа «Продуктивность программиста» здесь нет, а учитывая что программистов тут всё же большинтсво, наверное, он нужен, учитывая популярность «GTD» и смежного «Human resources».
                                                            0
                                                            Программирую больше 3 лет один проект на делфи, иногда что-то переделываю. И вот мои наблюдения:
                                                            Полностью согласен, что чтобы не впасть в депрессию от выбора худшего зла (так как времени дается ограниченное количество), нужно начать писать код и возможно (как было как раз вчера), дойдя до нужного места, мысли придут сами собой.

                                                            А также лишние проверки работоспособности кода способны потратить чуть ли не 2 часа в день… А это четверть нормального рабочего дня. Но если их совместить в одну, то она выйдет гораздо короче, за пол часа все можно проверить и исправить.

                                                            И самое интересное, что когда на тебя давят и нужно сделать быстрее, то даже как-то не обдумывая начинаешь писать не проверяя. Быстро, по плану делать все доработки ничего не проверяя. А только потом в конце проверяешь и исправляешь синтаксис и другие мелкие ошибки.

                                                            Также недавно подумал: «надо быстрее написать, так что длинные переменные не для нас». Лучше я в декларации переменной добавлю комментарий, что она значит, а называться она везде будет CTL, а не CreateToolsLoaderObject. Благо в Delphi можно с контролом кликнуть по переменной (функции и т.п.) и посмотреть на ее объявление и быстро вернуться через ALT+Left.

                                                            В общем я за то, чтобы спланировать структуру ПО (функции, модуля), а дальше писать, запуская на проверку очень редко.
                                                              0
                                                              А вот с длинными переменными проблема решается с помощью тенинга набора и автокомплита. У меня память короткая. Я же завтра буду думать, что это флаг нажатия Ctrl.

                                                              На этом больше сэкономишь, чем потеряешь, другое дело, что CreateToolsLoaderObject — плохое название. ToolsLoader — лучше. Или LoaderObject. В зависимости от контекста — обычно двух слов хватает.
                                                                0
                                                                Автокомплит несомненно необходимая вещь и без него сложнее намного, но в данном случае три буквы, точка, имя метода гораздо быстрее набирается нежели с использованием автокомплита и длинных названий. (и насколько бы человек тренирован не был, он все равно быстрее наберет короткое слово, чем более длинное, хоть и не целиком).

                                                                Завтра не забудешь, т.к. есть комментарий в объявлении переменной.
                                                                А если там лоадеры для нескольких тулов есть, то двух слов как бы недостаточно получается.

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

                                                                  0
                                                                  Да, в команде сложнее.

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

                                                                  Как и стандарные: переменные цикла i,j,k,m (l — не люблю использовать — спутаешь с единицей — вот радости будет), s,str — «временные» строковые, tmp — для обмена.

                                                                  Так и «свои» например result — для возврата (пошло кстати с дельфи), rec, — для записи БД или курсора, cur — для «текущей» рабочей переменной. А для нестандартных переменных — таки придумываю имена.

                                                                  Кстати, лучше использовать сокращения, чем аббревиатуры например ctObj и т.д. Буквы экономятся, а контекст остаётся «читаемым».
                                                                0
                                                                А также лишние проверки работоспособности кода способны потратить чуть ли не 2 часа в день…

                                                                Автоматизировать их, не?
                                                                  0
                                                                  Автоматизировать проверку работы инструмента смещения вершины в 3D-редакторе, в котором нет возможности на данном этапе загрузить готовую сцену. Как?

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

                                                                  Но не везде все можно автоматизировать, особенно проверку работы какого-то инструмента, который включается после загрузки ПО, создания сцены и т.п. Конечно можно свести к минимуму работу по кликам при проверке, но на это тоже надо тратить время и это рационально только тогда, когда уверен, что эту часть будешь еще долго отлаживать и дописывать.
                                                                    0
                                                                    Подсунуть инструменту фейковую сцену и фейковый пользовательский ввод? Честно говоря, я почти ничего не понял начиная со слова «смещения», потому конкретных методов предложить не могу. Но, например, я тестирую приложение по работе с БД без обращений к ней и даже не имея на дев-машине СУБД (к удаленной тоже не подключается). Конечно, потом тестирую и в реальном окружении ручками, но это редко, после завершения большого этапа. А так запускаю тесты десятки раз в день, если не сотню, но времени уходит немного на них.
                                                                      0
                                                                      Я конечно понимаю, что вы смогли расписать мои слова "свести к минимуму работу по кликам при проверке, но на это тоже надо тратить время и это рационально только тогда...", используя другие слова и модное слово «фейк». Но я уже написал, что это бывает очень не рационально.
                                                                      Не понятны слова «3D-редактор» или «вершина»?

                                                                      Объясню для вас подробнее:
                                                                      допустим я на этот инструмент трачу один рабочий день вместе с отладками. Подготовить фэйковую сцену, сделать его автоматическую подгрузку и т.п. до самого этого инструмента займет около 2 рабочих дней. Это не нужно совсем, когда я на следующий день буду работать с совсем другой частью программы и мне не нужно будет грузить эту сцену вообще? Платят тут за скорость и результат, а не за идею правильно кодить. Так что расчитываю я для себя, нужна ли мне эта оптимизация в будущем или нет или когда потребуется тогда и напишу.
                                                                        0
                                                                        «Загрузка готовой сцены» непонятна прежде всего из предметной области. «Проверка инструмента» из требований тоже, но уже непонятен необходимый уровень проверки. Что подаётся на вход проверки и что должно быть на выходе. Если на входе надо эмулировать перемещения мыши на уровне ОС это одна трудоемкость, Если достаточно вызвать из теста что-то вроде scene.getNodes(current_node).move(from_point, to_point), то другая. То же с выходом. Если нужно проверять действительно ли ОС вывела точку на экран, это одна, если достаточно проверить, что у узла изменились координаты, то другая.

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

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

                                                                          Дальнейшее обсуждение вопроса тестирования проекта будет лишь холиваром (причем Вашим с планами моего начальства).
                                                                            0
                                                                            Я, видимо, меньшинство :) В архитектурных 3D-редакторах такого понятия нет вроде бы, а с другими не работал.
                                                                +2
                                                                В последнее время, проанализировав свою работу, проблемы с мотивацией и т.п., понял одну простую вещь: спецификации писать надо. Тогда и ошибок будет намного меньше, и стоить их исправление будет дешевле, и мотивация не будет теряться из-за отсутствия видимого результата, т.к. будет виден прогресс по выполненным пунктам спеки.

                                                                  +1
                                                                  Это да. В институте предчувствуя приход «полярного куся», выписывал порядок действий по изучению, написанию и сдачи хвостов. И этот магический листочек со спеками — оченно выручал. Поэтому из института меня выгоняли всего два раза;)
                                                                    +1
                                                                    А в качестве спецификаций могут выступать тесты :) Извините, не удержался.
                                                                      +1
                                                                      +1
                                                                        0
                                                                        Не согласен. (В этом месте сторонники TDD ставят мне минусы.) Вы так или иначе будете тестировать конкретную реализацию или конкретный интерфейс (что в коде, что в UI). А, значит, стадия проектирования никуда не девается. И как вы себе представляете проектирование в тестах?
                                                                          0
                                                                          В тестах я формализую неформализованные требования к методу, классу, подсистеме, системе в целом. Описываю что подаётся на вход и что должно быть на выходе. Проектированием занимаюсь при декомпозиции приёмочных/функциональных тестов на модульные и интеграционные.
                                                                            0
                                                                            Наверное, если сильно извратиться, то можно заменить спеку тестами. Только вот как потом с этим работать стороннему разработчику? Или даже банальнее — команде?

                                                                            Да и не все протестировать возможно.
                                                                              0
                                                                              Почему извратиться? Просто пишете спеку не по-русски/английски, а на некоем DSL, который прочитать может даже не айтишник. А если у него есть хоть малейшая способность к индукции, то и написать многие кейсы по образцу. Для некоторых инструментов тестирования этот DSL даже является подмножеством естественного языка, без использования спецсимволов например, просто словарь и грамматика меньше и сильнее формализованы.

                                                                              А как работать стороннему разработчику, если в разработке используется, например, система контроля версия, фреймворки какие-то, библиотеки? Или привлекают разработчиков уже знакомых с этими инструментами, или дают им время на освоение.

                                                                              Вы же не пишете в спеке «подаём на вход то-то, неизвестно что получаем»? Если есть спецификация, то есть и способ проверки соответствия системы её требованиям. Проверять можно ручками, а можно автоматизировать этот процесс. Даже в тестировании приложения, непосредственно работающего с железом, можно свести ручную проверку к минимуму. Например, приложение в каких-то ситуациях должно зажигать лампочку, а в каких-то гасить. Вроде проверить нельзя автоматически, если не ставить фотодатчик, изолированный от других воздействий на время тестирования (хотя тоже вариант). Но можно написать один-два метода или функции вроде switchLampOn()/switchLampOff() или switchLamp(boolean), проверить его ручками (и глазками), а потом лишь проверять автоматически вызывается он или нет в нужных ситуациях.
                                                                                0
                                                                                Возможно вы и правы. Лично я не верю, что тесты понятнее спеки и лучше помогают в написании кода по ним. Но у меня опыта в TDD — ноль, а все видимые мною тексты на эту тему, к сожалению, описывают проекты уровня hello world'a, а не чего-то адекватного.
                                                                                  0
                                                                                  Понятнее вряд ли. DSL всё таки не естественный язык: с одной стороны «мусора» больше, с другой — гибкость и выразительных средств меньше. То есть читаться читается и что хотели сказать в принципе понятно, но выглядит как речь человека, который недавно начал изучать иностранный язык и пытается на нём общаться, имея под рукой словарик небольшой и пару-тройку правил грамматики выучил.

                                                                                  А помогают больше. Проверить соответствие кода такой спеке можно одним хоткеем в современных IDE. Особенно заметны преимущества на интерпретируемых языках или языках/в IDE с хорошей поддержкой инкрементального компилирования, когда буквально каждую строчку можно практически моментально проверять.
                                                                      +2
                                                                      (offtopic)
                                                                      ИМХО Суворов писал не об отказе от контроля, а о получении удовольствия от риска.
                                                                      (/offtopic)
                                                                        0
                                                                        Это метод отказа от контроля. Но вы правы.
                                                                          0
                                                                          По крайней мере так можно рассматривать. Поэтому я оборвал цитирование.
                                                                          +2
                                                                          Создалось впечатление, что написание тестов позволило бы избежать множества проблем, описаных в статье.
                                                                            +2
                                                                            ИМХО, Ваш принцип необходимо применять только вкупе с принципом «разделяй и властвуй». Т.е. для небольших участков кода. Написал законченный участок — пробежал код глазками на предмет ошибок. А для более крупного кода необходимо сразу проводить декомпозицию на такие мелкие участки, накидывать план. На этом уровне действительно не нужно думать над ошибками кодирования — на нем нужно думать над ошибками логики в целом.
                                                                            Ну, и так далее. На каждом уровне — своя детализация и упор на разные типы ошибок. И, тем не менее, принцип маленьких, обозримых блоков, очень хорошо работает. С одной стороны — красивый и структурированный дизайн, с другой — не менее красивый и корректный код. Иногда некорректный — но процент подобных ошибок падает с опытом. Просто на автомате учитываешь разные варианты входных данных, не задумываясь.
                                                                              +1
                                                                              Спасибо, тов. Автор. :) Пост длиннющий, но читается на одном дыхании и с удовольствием. Сразу видно, что Вам самому он нравится.

                                                                              Еще и содержание позволяет взять что-то новое для себя.

                                                                              В общем… Только спасибо могу сказать.
                                                                                +2
                                                                                > Баги и переписывания всё равно будут. Но лучше разделить кодирование и отладку и на время кодирования об ошибках вообще забыть.

                                                                                проблема: заказчик может быть несогласен. Он может с помощью экспертов вычитать код (или изменения в коде для поддержки legacy) и натыкать носом в «непрофессионализм», после чего послать в пешее эротическое путешествие.

                                                                                Или вот совсем жесть: один из заказчиков требовал с нас гарантированное исправление бага, т.е. если баг помечен как «закрыт» («отправлен на тестирование», «wontfix» итп), то любые его переоткрытия и переисправления делаются уже за наши деньги (и делать мы их будем, потому что в условиях контракта заявлены критерии качества финального продукта).
                                                                                  0
                                                                                  Тут моя ошибка — я не написал, что большой кусок кода — это работа по времени от получаса до нескольких часов. Потом небольшой период на холодное ревью и большой период на отладку.

                                                                                  Коммитить неотлаженный код — нельзя. Потому что нельзя никогда, разве что в бранч.

                                                                                  Идея в том, чтобы не перебивать рабочий порыв мелкими итерациями — кусок кода, запуск, отладка, где кусок кода — 5-10 строк. Лучше закончить сразу функциональный блок на одном дыхании. А потом его быстро вылизать.

                                                                                  Я стал мельчить из-за опасений. Что могу ошибаться и потом долго отлаживать большой кусок. Но попробовав работать простынями выяснил, что код получается более стабильный.
                                                                                    +1
                                                                                    Если требуется отладка, большая чем исправление опечаток, на кусок 5-10 строк, то разве не увеличится пропорционально время на отладку куска в 50-100-1000 строк? При том, что за несколько часов вполне можно выйти из контекста первых 5-10 строк и при ревью уже не заметить каких-то локальных логических ошибок, типа a[i][j] = 0 вместо a[j][i] = 0, и долго отлаживать код ниже, вместо того чтобы быстро его отладить сразу после написания?
                                                                                      0
                                                                                      Даже если и увеличится — это нестрашно. Код написанный одним куском потребует меньше времени, чем код написанный с «перекурами» на проверку. А время общей отладки будет в большинстве случаев меньше времени на отладку иттерационную.

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

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

                                                                                      При работе в команде, естественно, пишу «как здесь принято». И в конце дня стараюсь сделать ревью написанного за день, а то люблю костыль вбить или идиому новую попробовать. А проблема костыля не в том, что он костыль — системы подпорок и соплей порой успешно живут долгие годы, а в том, что либо он оторван от кода и коллегам не понятно, что это за фигня такая. Либо, что ещё хуже, когда коллегам не понятно, что это костыль. Соберешься потом его прибить, а там из костыля уже цельный емпайр-стейт-билдинг вырос.
                                                                                        0
                                                                                        Если писать код, а потом думать как его проверить или проверять ручками, то, да, несомненно больше. Но вот если сначала подумать как его можно проверить автоматически, сформулировать простой способ проверки (или разбить сложный на несколько простых), то собственно проверка будет практически моментальной, а локализация неуспешной будет тривиальна.

                                                                                        Ключевая фраза «проверка должна быть простая», следствие — проверяемый код тоже получается простым, 5-10 строк. В чём-то подход совпадает с вашим. Есть задача, как её полностью просто проверить не ясно, не то что как её решить. Ну и ладно. Выделяем какую-то подзадачу, которую понимаем как просто проверить и решить. Или подподподзадачу. Формулируем проверку (пишем тест): что на входе, что на выходе, какие побочные действия. Проверяем. Фейл, ведь код мы ещё не написали. Пишем код, он получается небольшой и простой, ведь проверка простая. О всяких «а вдруг придётся изменить логику», «вдруг это будет медленно», «что с результатом делать дальше» не думаем. Проверяем. Если нет — дебажим, это просто, код небольшой, сложной логической ошибки сделать не могли. Если всё ок решаем так же следующую «братскую» подподподзадачу (тест, код, возможно простейший дебаг). Проводим мини-ревью этих подподподзадач, видим общий или даже похожий код — выносим его в отдельный метод. Проверяем, что ничего не сломали в процессе (новый метод не тестируем специально, тестируем первые два, раз они работают — значит не сломали). Сломали — дебажим. Не сломали — следующего «брата». Опять мини-ревью. Ага, все подподподзадачи, имеющие общего родителя мы решили. Теперь можем просто проверить и решить её, подподподзадачи уже проверены, нюансы разные в них учтены и мы им доверяем. Пишем тесты на эту родительскую задачу, они получаются простые, ведь мы не проверяем то, что уже проверили в процессе решения «детских» подподподзадач. Пишем код, чтоб эти тесты проходили, код простой — вызов уже решенных и проверенных подподподзадач.

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

                                                                                        Если вы пишите ассерты до того как пишите код, то вы уже сделали большой шаг в этом направлении :)
                                                                                          0
                                                                                          Ну это вопрос о первичности яйца или курицы.

                                                                                          Я если пишу ассерты, то чаще после кода который надо проверять, лишь иногда до. В принципе написание раньше — лучше организует, но немного тормозит. Имхо, это зависит от того как человек думает. Когда знаю, что должно получиться, но не знаю как, то сперва пишу условия. Когда знаю, как нужно сделать, но не уверен, что именно получится, то сперва код. Если знаю что и как, то все равно сперва код. Но опять же ассерты — для меня подстраховка в опасном месте. Поэтому — как то не сложилось.

                                                                                          Плюс в контексте статьи я бы предложил писать сразу несколько простых функциональных блоков. И прогонять их после того, как выдыхаешься.
                                                                                      0
                                                                                      А если тогда использовать TDD?
                                                                                        0
                                                                                        Я вот читал статью и чуть ли не после каждого предложения говорил себе «тут должно быть TDD, чтобы отладкой вообще не заниматься» :)
                                                                                    0
                                                                                    Спасибо за статью! Помогло сформулировать у себя в голове кое-что, осознал, что сам пытаюсь придерживаться такого подхода, но пропускаю стадию пред-отладки (вычитывание кода перед запуском), из-за чего ловлю много граблей.
                                                                                      +3
                                                                                      Я бы не взял автора на работу.
                                                                                        0
                                                                                        Спасибо, есть что применить в практике.
                                                                                        P.S. заметную часть текста можно было бы заменить на фразу «мне нравится разработка сверху-вниз».
                                                                                        P.P.S. ещё хотелось бы уточнить правило до:«Когда ты перед экраном — садись и делай, но забудь про то, что можешь делать неправильно. Думать надо во время прогулки (езды в метро, пути на работы, ...).». Но как сделать, чтобы сий метод не выливался в перекуры каждые 30 минут на подумать — я не знаю.
                                                                                          +1
                                                                                          В метро я работаю над сценариями, идеально, интернета нет — час ехать, программировать уже/ещё не хочется ;) На работе есть время пока приветствия чай кофе. Как раз поднять записи и наметить план наступления.

                                                                                          Хорошая кстати методика. Перед уходом с работы записать в рабочий блокнот, что хочется (ни в коем случае не планируется) сделать завтра. С утра читая записи, наметить, чем в первую очередь надо заняться и как.

                                                                                          В периоды тотальной разработки выручает сильно:
                                                                                          — план на один день актуален;
                                                                                          — он на тебя не давит;
                                                                                          — есть четкая картина, что делать;
                                                                                          — возможность играть с детализацией;
                                                                                          — есть возможность коррекции плана на свежую голову

                                                                                          Вечером новый план. В конце этапа пробежаться по блокноноту и посмотреть не сделанные или уже неактуальные задания. Перписывать задания не надо — вероятность забыть что-то важное небольшая. А неважное — оно неважное.
                                                                                          –1
                                                                                          Очень хорошая статья. Спасибо.
                                                                                            +1
                                                                                            Прочитал 3 первых абзаца, и остановился.
                                                                                            Причина 1: страшно читать эту статью. С редактором сейчас всё проще.
                                                                                            Причина 2: Сам углубился в анализ методик генерации собственного кода, и нахожусь в активной стадии порождения тезисов о более оптимальном программировании.
                                                                                            Причина 3: Прочитав эту статью, велика вероятность, что некоторые тезисы доработаются, некоторые рассеются. Но, вероятнее всего, как это обычно и бывает, почти полностью трансфомируется (читай: расеется) ресурс, задействованный на выявление собственных истин создания кода.

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

                                                                                            P.S. Стаж 5 лет.
                                                                                              0
                                                                                              Именно так ;)

                                                                                              Понимаю, что статью надо переписывать. По крайней мере выкидывать начало и конец. А середину дорабатывать напильником;)

                                                                                              Хорошо очень писалось и я зачем-то воткнул два подраздела из задумываемой статьи по гейм-дизайну. Там ситуация немного другая и хотя корреляции тоже есть и я считаю, что они правильные, всё таки аргументации не хватает и сформулировано жестковато.
                                                                                              +1
                                                                                              Да, все верно. Эта методика настолько эффективна, что действительно приводит к феерическим волшебным результатам. Даже в области, как моя, где упавший код на продакшене это проблема катастрофическая, даже тут ваш подход работает на ура. Сначала проводим грубую кривулину из точки А в точку Б, а потом допиливаем там, где падает.
                                                                                              На эту модель хорошо функциональные тесты ложатся.
                                                                                                0
                                                                                                Теперь редактор открывать не страшно. Но очень страшно нажимать кнопку «Run»…

                                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                Самое читаемое