Comments 19
Любую реализацию нужно начинать с реализации тестов.
То есть, прежде чем начать писать программу, надо продумать как эту программу тестировать.
Ага, а любую музыку желательно начинать с записи ее нот на стане.
Кроме того, что не нужно умножать сущности, всегда помним о тезисе «это нам никогда не понадобится». И, скорее всего, оно не понадобится на самом деле.
Как только принцип YAGNI не понимают люди. Вот некоторые его понимают так «не просили — не делаю — меньше работать». В этом ли, так сказать, его суть?
В целом, не смотря на популярность этих принципов из статьи, у них у всех есть обратный эффект.
Ага, а любую музыку желательно начинать с записи ее нот на стане.
:) не думаю. музыка — она в душе. а код — это текст и, прежде, чем его писать, много чего нужно сделать. а тест иногда помогает понять что и, может быть, не сделать зря. впрочем, вы понимаете, что я имею в виду, судя по приведённой аббревиатуре.
насчёт обратного эффекта — согласен. в нашем календарике есть даже отмазочный антипаттерн «сделано ровно то, о чём просили». правда, некоторые продолжают часто делать лишнюю работу вместо того, чтобы вместо остановиться и подумать. и тут полезно вспомнить принцип номер три.
У меня вообще не получается писать что-то для вызова кода, пока я не написал сам код. Потому что в процессе написания и поиска решения переберешь с десяток вариантов. А если что-то уже написал для вызова, то потом придется менять. Это отвлекает, и пока меняешь, основная мысль может исчезнуть.
:) не думаю. музыка — она в душе. а код — это текст и
А для меня музыка это звуки, а код в душе. Об этом можно спорить бесконечно. У TDD-подхода есть одна важная обратная сторона — очень часто на выходе получается говно, потому что разработчик пишет так, чтобы проходило придуманные тесты, не сосредотачиваясь на том, КАК оно их проходит. Короче, для применения TDD нужне немалый опыт разработки, иначе это просто модное слово в списке используемых методологий, которое к тому же мешает разработке качественного кода.
Сразу вспомнил одну компанию, в которой довелось работать. Там было 4 разработчика, включая лида, все сидели в одном кабинете. Но мы каждое утро и вечер проводили stand-up митинги, отжирая час рабочего времени и каждую пятницу играли в planning poker, который, кстати, никогда не соответствовал реальности, но затрачивали на него часа 3-4, а в особо запущеных случаях весь. А компания делала свои собственные, не очень большие сайты.
Это просто к примеру мешающего «модного слова» в списке используемых модных слов. Потом перешел в компанию, где, несмотря на то, что народу было больше, не страдали фигней, а писали код. На прошлом месте за 3 месяца так ничего и не доделали до конца, на новом с нуля за месяц онлайн игру, выдерживающую 10к юзеров онлайн.
Может, в той компании, где вы разрабатывали онлайн-игру, просто было всё в порядке с мотивацией и управлением?
И все разработчики знали, что и как надо делать, были мотивированы работать, а не «страдать фигней», и не хотели тратить время на различные «длинные и бесполезные» собрания, с менеджерами проекта и продукт-оунером?
И все разработчики знали, что и как надо делать, были мотивированы работать, а не «страдать фигней», и не хотели тратить время на различные «длинные и бесполезные» собрания, с менеджерами проекта и продукт-оунером?
В первой тоже всё было в порядке с мотивацией и все знали что и как надо делать. Проблема лишь в том, что там как в ОП-посте было правило «СНАЧАЛА РАЗРАБАТЫВАЕМ ТЕСТЫ, ТОЛЬКО ПОТОМ ПИШЕМ КОД». Только вместо тестов стнед-ап митинги и планинг покер. Многие компании, в которых довелось работать пишут тесты ради тестов и работают по Scrum\XP ради работы по Srum\XP, понимаете о чем я? Инструменты и методологии нужно использовать тогда, когда это действительно необходимо. Иначе получается, что мы прикатываем экскаватор ради того, чтобы бы выкопать ямку в 10 см.
И это повальная проблема в разработке ПО. Мы берем фреймворки для разработки простых вещей, используем ООП для написания чего-то, что с легкостью укладывается в процедурную парадигму и так далее.
И это повальная проблема в разработке ПО. Мы берем фреймворки для разработки простых вещей, используем ООП для написания чего-то, что с легкостью укладывается в процедурную парадигму и так далее.
Почему именно шесть раз? Потому что до шести внимание на это обычно не обращают.
Странно, у меня уже после второго какой-то зуд начинается, наверное я поломан :(
Велосипед уже существует
Это аксиома! Только так и начинаю новую работу.
9. Мысли читать никто не умеет
Это отличная формулировка и не только в IT.
Коллеги, не забыли про документацию к программе? Наверное раздел «Разработчику» идеально надо писать сразу после первого удачного запуска самой первой версии приложения и поддерживать её на уровне, чтобы любой новый разработчик мог её у себя запустить самостоятельно, а то нарушается п.9.
Коллеги, не забыли про документацию к программе? Наверное раздел «Разработчику» идеально надо писать сразу после первого удачного запуска самой первой версии приложения и поддерживать её на уровне, чтобы любой новый разработчик мог её у себя запустить самостоятельно, а то нарушается п.9.
именно так! правда, для этого у нас (уверен, что не только у нас) есть правила ведения проекта, где наличие сопровождающей документации обозначено как обязательная часть и структурировано по типам: README, ChangeLog, комментарии в коде, wiki и пр. впрочем, пункт 9 это подразумевает. как бы :)
Это круто! Правда!
Коллеги, меня интересует один момент. Не задумывались ли вы над таким функционалом при разработке, чтобы поиск по проекту был из одной точки? Т.е. вот есть исходный код, документация в wiki и т.д. Не пробовали объединить поиск по всему проекту? У меня, например, все проекты находятся в gitlab, много информации я выкладываю в виде html-страниц. Наверняка похожие мысли могли проскакивать?
Коллеги, меня интересует один момент. Не задумывались ли вы над таким функционалом при разработке, чтобы поиск по проекту был из одной точки? Т.е. вот есть исходный код, документация в wiki и т.д. Не пробовали объединить поиск по всему проекту? У меня, например, все проекты находятся в gitlab, много информации я выкладываю в виде html-страниц. Наверняка похожие мысли могли проскакивать?
тут сложно. у нас twiki + svn. ссылки из twiki указывают на исходники. но поиска в svn нет.
Я не вижу нужды смешивать, для поиска по исходникам есть IDE, и задачи из которых вытекает необходимость поиска в коде отличаются от задач, которые приводят к поиску в документации. Скорее есть смысл привязывать какие-то вещи в документации к метаданным репозитория, то есть веткам коммитам и тд. Но такие системы есть, например atlassian, там вполне можно связать jira (таск трекер) + confluence (вики) + bitbucket (система контроля версий) + bamboo (CI) и много что еще.
1. «По возможности, программа должна выполнять одно действие, но зато делать это хорошо.» — программа должна выполнять то, что хочет заказчик. Не больше и не меньше. Если по любым причинам заказчик хочет швейцарский нож с 38 лезвиями, именно его и надо сделать (предварительно проифнормировав заказчика о более удачных решениях, если такие есть). Я к тому, что сами себе придумывают задачи/программы 5% программистов, а делают что-то по заказу 95%.
2. © Квартет И, «День радио» — копирайт не Квартета И, не они придумали спектакль и даже не играли всех ролей, а являлись лишь частью труппы.
2. © Квартет И, «День радио» — копирайт не Квартета И, не они придумали спектакль и даже не играли всех ролей, а являлись лишь частью труппы.
ну, не все программы пишутся под заказчика. а то, что хочет заказчик может быть реализовано разными способами.
к примеру, делаем мы прибор, а в нём энное количество функций. если платформа прибора *nix-based, то софт прибора ни в коем случае не будет одной программой. это всегда довольно сложная система, которая состоит из некоторого количества компонентов, работа которых по отдельности заказчика совершенно не волнует. а так, конечно, процесс разработки на заказчика завязан. но на верхнем уровне. а советы для обычных программистов. чтобы не забывали и не усложняли лишний раз.
насчёт 38 лезвий — тоже верно. правда, это ближе к области согласования спецификаций, ТЗ и пр.
про «квартет и» — допишу сейчас.
к примеру, делаем мы прибор, а в нём энное количество функций. если платформа прибора *nix-based, то софт прибора ни в коем случае не будет одной программой. это всегда довольно сложная система, которая состоит из некоторого количества компонентов, работа которых по отдельности заказчика совершенно не волнует. а так, конечно, процесс разработки на заказчика завязан. но на верхнем уровне. а советы для обычных программистов. чтобы не забывали и не усложняли лишний раз.
насчёт 38 лезвий — тоже верно. правда, это ближе к области согласования спецификаций, ТЗ и пр.
про «квартет и» — допишу сейчас.
Более того: не все заказчики на самом деле понимают, что нужно хотеть. Некоторые из них не понимают, что то, чего они хотят, на самом деле хотеть нельзя, потому что такое решение долго не продержится и придется его переделывать. При работе в таких условиях, работа по принципу YAGNI — есть зло. Код будет выкидываться периодически, а время проекта пожираться.
> Unix-way
Сложность решения задачи будет представлять уже интеграция атомарных программулечек в единое решение. Выполнение будет далеко не оптимальным.
> Велосипед существует
Существует не велосипед, а средства передвижения. От лыж до железной дороги. Типичные проблемы сторонних решений: либо оно сырое и требует значительного допила руками, либо оно негибкое и его сложно приспособить для своей задачи, либо оно чересчур абстрактное, громоздкое и сложное в использовании, что проще все написать самому. Плюс все это противоречит первому пункту.
> Сначала тесты
Сначала моделирование и прототипирование! Чтобы хотя бы было из чего писать эти тесты.
> Не нужно отрабатывать время
К сожалению, платят именно за время, а не за продуктивность.
Сложность решения задачи будет представлять уже интеграция атомарных программулечек в единое решение. Выполнение будет далеко не оптимальным.
> Велосипед существует
Существует не велосипед, а средства передвижения. От лыж до железной дороги. Типичные проблемы сторонних решений: либо оно сырое и требует значительного допила руками, либо оно негибкое и его сложно приспособить для своей задачи, либо оно чересчур абстрактное, громоздкое и сложное в использовании, что проще все написать самому. Плюс все это противоречит первому пункту.
> Сначала тесты
Сначала моделирование и прототипирование! Чтобы хотя бы было из чего писать эти тесты.
> Не нужно отрабатывать время
К сожалению, платят именно за время, а не за продуктивность.
> Велосипед существует
Существует не велосипед, а средства передвижения. От лыж до железной дороги. Типичные проблемы сторонних решений: либо оно сырое и требует значительного допила руками, либо оно негибкое и его сложно приспособить для своей задачи, либо оно чересчур абстрактное, громоздкое и сложное в использовании, что проще все написать самому. Плюс все это противоречит первому пункту.
На тему велосипедов можно смело писать новую статью. Ибо выбор между «писать самому» и «использовать готовое» часто требует анализа плюсов и минусов. Но в целом, всегда стоит обратить внимание на существование уже готового решения.
Sign up to leave a comment.
Спорные, но актуальные принципы разработки