Зачем это было написано, если есть множество книжек по методологиям разработки (в том числе extreme programming, scrum, tdd), по программированию в целом и в частности, о том, «как пасти котов» и про «идеальный код»? Книг много, но разработчики, к несчастью, их читать не любят. Ну, ладно, любят, но не все. У них, мол, своя специфика. Квинтэссенция нужна. И проще, ближе, понятнее. Вот поэтому. И в жизни чаще всего приходится вспоминать, вернее, не забывать, именно те, которые перечислены ниже.
Посмотрев на историю страницы в нашем корпоративном twiki, я обратил внимание, что небольшой список с пояснениями, на основе которого сделана эта публикация, начал своё существование в 2006 году и неспешно дополнялся до 2011 года. Потом почему-то заглохло. Может быть, у кого-нибудь из читателей появится желание что-то добавить?
Простота
Если решение задачи оказывается слишком сложным, то с вероятностью 99% способ решения неверен.
Unix-way
По возможности, программа должна выполнять одно действие, но зато делать это хорошо.
Бритва Оккама
Кроме того, что не нужно умножать сущности, всегда помним о тезисе «это нам никогда не понадобится». И, скорее всего, оно не понадобится на самом деле.
Велосипед уже существует
Прежде чем изобретать свой способ решения, неплохо было бы оглядеться: может быть, кто-то уже решил проблему и сделал это лучше, чем мы хотим. Не забываем про мир свободных программ.
Повторы
Если действие повторяется больше шести раз, то пора это действие тем или иным способом автоматизировать. Варианты: написать скрипт, создать класс, записать макрос.
Почему именно шесть раз? Потому что до шести внимание на это обычно не обращают.
Тесты
Любую реализацию нужно начинать с реализации тестов.
То есть, прежде чем начать писать программу, надо продумать как эту программу тестировать. И начать тестировать. Даже если нет реализации того, что тестируется. Тесты помогут понять, что нужно делать и как, а что — нет.
Подкустовные выползни
«Подкустовные выползни появляются на свет сразу. как следует из названия, они выползают из-под куста.» © «День радио», Квартет И и другие участники спектакля.
Подкустовных выползней не бывает. И не нужно даже пытаться решить _всю_ задачу _сразу_. Просто поверьте, что это невозможно. но если разбить ее на части, то решение подзадач становится вполне реальным.
Время
Отработать больше часов не значит сделать больше. Продуктивность и отработка времени — совершенно противоположные понятия.
Очевидное
Вы думаете, что кто-то умеет читать ваши мысли? Это ошибочное суждение. Телепатов в нашем несовершенном мире можно встретить только в зеркале. Поэтому, прежде чем что-то сделать, основываясь на своём представлении об информированности окружающих, нужно убедиться, что окружающие «в курсе». Или «в теме».
То есть, всегда необходимо информировать коллег о своём видении проекта и своей роли в нём. А то сами они не догадаются.
Коротким списком
- Простота
- Unix-way
- Бритва Оккама
- Велосипед существует
- Повторы — автоматизировать
- Сначала тесты
- Подкустовных выползней нет
- Не нужно отрабатывать время
- Мысли читать никто не умеет
Комментарии (19)
f0rk
30.06.2015 22:20+9Почему именно шесть раз? Потому что до шести внимание на это обычно не обращают.
Странно, у меня уже после второго какой-то зуд начинается, наверное я поломан :(
crazybrake Автор
30.06.2015 22:48+3у нас — шесть. до этого лень. принцип больше применим к автоматизации рутинных действий. второй раз не означает, что рутинные действия начались. третий — повод задуматься, но четвёртый-пятый идут на автомате. зато шестой — вот оно наше всё!
AlexZaharow
01.07.2015 09:09+2Велосипед уже существует
Это аксиома! Только так и начинаю новую работу.
9. Мысли читать никто не умеет
Это отличная формулировка и не только в IT.
Коллеги, не забыли про документацию к программе? Наверное раздел «Разработчику» идеально надо писать сразу после первого удачного запуска самой первой версии приложения и поддерживать её на уровне, чтобы любой новый разработчик мог её у себя запустить самостоятельно, а то нарушается п.9.crazybrake Автор
01.07.2015 09:48Коллеги, не забыли про документацию к программе? Наверное раздел «Разработчику» идеально надо писать сразу после первого удачного запуска самой первой версии приложения и поддерживать её на уровне, чтобы любой новый разработчик мог её у себя запустить самостоятельно, а то нарушается п.9.
именно так! правда, для этого у нас (уверен, что не только у нас) есть правила ведения проекта, где наличие сопровождающей документации обозначено как обязательная часть и структурировано по типам: README, ChangeLog, комментарии в коде, wiki и пр. впрочем, пункт 9 это подразумевает. как бы :)AlexZaharow
01.07.2015 10:15Это круто! Правда!
Коллеги, меня интересует один момент. Не задумывались ли вы над таким функционалом при разработке, чтобы поиск по проекту был из одной точки? Т.е. вот есть исходный код, документация в wiki и т.д. Не пробовали объединить поиск по всему проекту? У меня, например, все проекты находятся в gitlab, много информации я выкладываю в виде html-страниц. Наверняка похожие мысли могли проскакивать?crazybrake Автор
01.07.2015 13:09тут сложно. у нас twiki + svn. ссылки из twiki указывают на исходники. но поиска в svn нет.
f0rk
01.07.2015 13:25Я не вижу нужды смешивать, для поиска по исходникам есть IDE, и задачи из которых вытекает необходимость поиска в коде отличаются от задач, которые приводят к поиску в документации. Скорее есть смысл привязывать какие-то вещи в документации к метаданным репозитория, то есть веткам коммитам и тд. Но такие системы есть, например atlassian, там вполне можно связать jira (таск трекер) + confluence (вики) + bitbucket (система контроля версий) + bamboo (CI) и много что еще.
dyadyaSerezha
01.07.2015 14:10+11. «По возможности, программа должна выполнять одно действие, но зато делать это хорошо.» — программа должна выполнять то, что хочет заказчик. Не больше и не меньше. Если по любым причинам заказчик хочет швейцарский нож с 38 лезвиями, именно его и надо сделать (предварительно проифнормировав заказчика о более удачных решениях, если такие есть). Я к тому, что сами себе придумывают задачи/программы 5% программистов, а делают что-то по заказу 95%.
2. © Квартет И, «День радио» — копирайт не Квартета И, не они придумали спектакль и даже не играли всех ролей, а являлись лишь частью труппы.crazybrake Автор
01.07.2015 14:52+2ну, не все программы пишутся под заказчика. а то, что хочет заказчик может быть реализовано разными способами.
к примеру, делаем мы прибор, а в нём энное количество функций. если платформа прибора *nix-based, то софт прибора ни в коем случае не будет одной программой. это всегда довольно сложная система, которая состоит из некоторого количества компонентов, работа которых по отдельности заказчика совершенно не волнует. а так, конечно, процесс разработки на заказчика завязан. но на верхнем уровне. а советы для обычных программистов. чтобы не забывали и не усложняли лишний раз.
насчёт 38 лезвий — тоже верно. правда, это ближе к области согласования спецификаций, ТЗ и пр.
про «квартет и» — допишу сейчас.
MrEsp
05.07.2015 02:35Более того: не все заказчики на самом деле понимают, что нужно хотеть. Некоторые из них не понимают, что то, чего они хотят, на самом деле хотеть нельзя, потому что такое решение долго не продержится и придется его переделывать. При работе в таких условиях, работа по принципу YAGNI — есть зло. Код будет выкидываться периодически, а время проекта пожираться.
Throwable
01.07.2015 16:36+2> Unix-way
Сложность решения задачи будет представлять уже интеграция атомарных программулечек в единое решение. Выполнение будет далеко не оптимальным.
> Велосипед существует
Существует не велосипед, а средства передвижения. От лыж до железной дороги. Типичные проблемы сторонних решений: либо оно сырое и требует значительного допила руками, либо оно негибкое и его сложно приспособить для своей задачи, либо оно чересчур абстрактное, громоздкое и сложное в использовании, что проще все написать самому. Плюс все это противоречит первому пункту.
> Сначала тесты
Сначала моделирование и прототипирование! Чтобы хотя бы было из чего писать эти тесты.
> Не нужно отрабатывать время
К сожалению, платят именно за время, а не за продуктивность.
andrewiWD
01.07.2015 17:02> Велосипед существует
Существует не велосипед, а средства передвижения. От лыж до железной дороги. Типичные проблемы сторонних решений: либо оно сырое и требует значительного допила руками, либо оно негибкое и его сложно приспособить для своей задачи, либо оно чересчур абстрактное, громоздкое и сложное в использовании, что проще все написать самому. Плюс все это противоречит первому пункту.
На тему велосипедов можно смело писать новую статью. Ибо выбор между «писать самому» и «использовать готовое» часто требует анализа плюсов и минусов. Но в целом, всегда стоит обратить внимание на существование уже готового решения.
MrEsp
Ага, а любую музыку желательно начинать с записи ее нот на стане.
Как только принцип YAGNI не понимают люди. Вот некоторые его понимают так «не просили — не делаю — меньше работать». В этом ли, так сказать, его суть?
В целом, не смотря на популярность этих принципов из статьи, у них у всех есть обратный эффект.
crazybrake Автор
:) не думаю. музыка — она в душе. а код — это текст и, прежде, чем его писать, много чего нужно сделать. а тест иногда помогает понять что и, может быть, не сделать зря. впрочем, вы понимаете, что я имею в виду, судя по приведённой аббревиатуре.
насчёт обратного эффекта — согласен. в нашем календарике есть даже отмазочный антипаттерн «сделано ровно то, о чём просили». правда, некоторые продолжают часто делать лишнюю работу вместо того, чтобы вместо остановиться и подумать. и тут полезно вспомнить принцип номер три.
michael_vostrikov
У меня вообще не получается писать что-то для вызова кода, пока я не написал сам код. Потому что в процессе написания и поиска решения переберешь с десяток вариантов. А если что-то уже написал для вызова, то потом придется менять. Это отвлекает, и пока меняешь, основная мысль может исчезнуть.
hlogeon
Потому что перед тем как писать, надо сначало продумать свои решения и их архитектуру. Придумать ЧТО и КАК ИМЕННО ты будешь писать. Инче, вместо принятия правильных, красивых и изящных решений Вы принимаете первые попавшиеся, необдуманные и невыстраданные.
hlogeon
А для меня музыка это звуки, а код в душе. Об этом можно спорить бесконечно. У TDD-подхода есть одна важная обратная сторона — очень часто на выходе получается говно, потому что разработчик пишет так, чтобы проходило придуманные тесты, не сосредотачиваясь на том, КАК оно их проходит. Короче, для применения TDD нужне немалый опыт разработки, иначе это просто модное слово в списке используемых методологий, которое к тому же мешает разработке качественного кода.
Сразу вспомнил одну компанию, в которой довелось работать. Там было 4 разработчика, включая лида, все сидели в одном кабинете. Но мы каждое утро и вечер проводили stand-up митинги, отжирая час рабочего времени и каждую пятницу играли в planning poker, который, кстати, никогда не соответствовал реальности, но затрачивали на него часа 3-4, а в особо запущеных случаях весь. А компания делала свои собственные, не очень большие сайты.
Это просто к примеру мешающего «модного слова» в списке используемых модных слов. Потом перешел в компанию, где, несмотря на то, что народу было больше, не страдали фигней, а писали код. На прошлом месте за 3 месяца так ничего и не доделали до конца, на новом с нуля за месяц онлайн игру, выдерживающую 10к юзеров онлайн.
ishevchuk
Может, в той компании, где вы разрабатывали онлайн-игру, просто было всё в порядке с мотивацией и управлением?
И все разработчики знали, что и как надо делать, были мотивированы работать, а не «страдать фигней», и не хотели тратить время на различные «длинные и бесполезные» собрания, с менеджерами проекта и продукт-оунером?
hlogeon
В первой тоже всё было в порядке с мотивацией и все знали что и как надо делать. Проблема лишь в том, что там как в ОП-посте было правило «СНАЧАЛА РАЗРАБАТЫВАЕМ ТЕСТЫ, ТОЛЬКО ПОТОМ ПИШЕМ КОД». Только вместо тестов стнед-ап митинги и планинг покер. Многие компании, в которых довелось работать пишут тесты ради тестов и работают по Scrum\XP ради работы по Srum\XP, понимаете о чем я? Инструменты и методологии нужно использовать тогда, когда это действительно необходимо. Иначе получается, что мы прикатываем экскаватор ради того, чтобы бы выкопать ямку в 10 см.
И это повальная проблема в разработке ПО. Мы берем фреймворки для разработки простых вещей, используем ООП для написания чего-то, что с легкостью укладывается в процедурную парадигму и так далее.