Comments 39
Приятно узнать себя минималистом )
Правда кое что прихрамывает, но эти места и сам знаю.
Отличный минифест, побольше бы минифестантов.
Разве ж это манифест минималистов? Вот манифест минималистов: !
Вот просто рад этой статье в понедельник )
Спасибо большое, распечатаю каждый пункт и повешу в офисе!
<лирика on>
Кстати, цитату про «написал бы покороче» кому только не приписывают — от Карла Маркса по Пастера. Мне нравится классический вариант «из письма другу»: «Извини, что пишу длинно, нет времени написать короче». Очень хорошая мысль. Ну а «Ваша работа закончена, когда из кода нельзя ничего выбросить» — как мне кажется, вообще отсылка к классическому ответу Микеланджело на вопрос «Как Вы создаете свои статуи?»: «Я беру камень и отсекаю всё лишнее»
<лирика off>

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

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

PS мне еще всю жизнь «прыгать», чему я очень рад. Я никому не желаю останавливаться в развитии.
Прыгайте дальше. «Быстро» входит в «хорошо и правильно».
Лучший код, написанный вами ­— это код, который вы не напишете. Просто потому, что он не может быть ошибочным.


Я расстроился :(
Краткое содержание статьи: лучше быть здоровым и богатым, чем бедным и больным.
Ого, как яростно заминусовали. Что ж, поясню. Подобные опусы вам ничего кроме лозунгов не дают. Чтобы из них что-то вынести, вы должны сами своей головой до них дойти.
«Вы должны X потому что один очень богатый чувак делал X каждый день и у него получилось». Это стиль тупой агитки. А в разработке думать надо башкой своей!
Конечно, вы можете с головой окунуться в какие-нибудь фреймворки модульных тестов типа Jasmine, JUnit, Mocha — но, безусловно, полезнее будет научиться писать код, который можно покрыть тестами (например, изолируя код от состояния и уменьшая связность компонентов).

Можно покрыть тестами почти любой код (кроме исследовательского и т. п., когда результаты не определены). Нужно научиться писать код, который легко покрывать тестами. Но сложно этому научиться без окунания с головой. Только когда попытаешься покрыть тестами достаточно большой проект, который «нельзя» покрыть тестами, тогда придет понимание как писать код, который легко покрывать. Заодно и понимание того, что стоит покрывать, а что нет. Прочитав книжку про TDD понимание не придет (ну или я совсем тупой). Только практика приведет к пониманию на уровне рефлекса.

P.S.Ошибка в переводе
высокая плотность — малая связность
Есть слово «связанность», а есть «связность» — практически антонимы в данном контексте. Обычный перевод «high cohesion — low coupling» — «высокая связность — малая/низкая связанность» или «высокое сцепление — малая/низкая связанность». Пишу не в личку, потому часто вижу это ошибку и в комментах, и в постах.
«В один из наиболее продуктивных дней я удалил тысячу строк кода». Кен Томпсон
«Боритесь за закон Парето» — странный подход для минималиста. Логичнее было бы бороться против него, выполняя только самые полезные 20% и не тратя 80% на рутину и выскабливание, отдавая это джуниорам, автоматизируя и т.п.
Да и остальной текст, вроде как бы по теме, только иногда с погрешностью 100%, не знаю уж проблема это перевода, формулировок или понимания.
Написано же, что 80% усилий нужно оставлять на будущее. То есть реализовывать сейчас только те 20%, которые решат задачу на 80%. А остальное отложить на потом, когда более важные задачи будут решены. Причем с большой вероятностью это «потом» никогда не наступит в виду изменившихся требований.
Только есть одна проблема. Выполняя всё быстро в какой-то момент может оказаться, что система пришла в настолько не поддерживаемое состояние, что теперь быстро занимает в 10 раз больше времени, чем раньше правильно. Поэтому, ИМХО, это правило плохо подходит для крупных проектов, разве что вы не хотите сделать хоть как-то, а потом уйти.
Речь не идет, по-моему, о выборе между «писать говнокод быстро» и «писать правильно». Речь, прежде всего, о выборе реализуемых фич. Есть 10 требований к какому-то продукту с условно одинаковой длительностью реализации, реализовали 2 самых важных и даем заказчику «посмотреть». Получаем от него два новых фичереквеста и опять выбираем 2 самых важных из общих 10, реализуя их, и т. п. Глядишь так о 8 из первых 10 он и не вспомнит никогда :)

Это не отменяет того, что за архитектурой нужно следить, покрывать тестами и проводить постоянный рефакторинг, не допуская наращивание технического долга, но не нужно закладывать в архитектуру суперрасширяемость и супергибкость на будущее. Прежде всего не нужно вводить уровни абстракции, которые сейчас не требуются. Код должен быть готов к их введению, но вводить заранее не нужно.
UFO landed and left these words here
Удивительно, что вчера была опубликована моя статья на хабре:

habrahabr.ru/post/176669/

библиотека yaui, построена именно на этих самых принципах. Как здорово, что вы тут опубликовали эти принципы, так точно выражающие мой подход, который всегда так не просто доносить до окружающих. Ведь если не понимать идей минимализма (и наномализма) то люди часто не впечатлены, поскольку привыкли оценивать по внешнему богатству по отдельным впечатляющим внешним элементам.
Правило Парето-Зенона. Если 20% труда дает 80% результата, то 20% от оставшихся процентов труда дает 80% оставшегося результата. Если продолжать трудиться, мы получаем уйму свободного времени и никогда не заканчивающийся проект.
Да да. Меня всегда принцип Парето формально удивлял. Люди с ГСМ очень его любят. Но при этом никто не думает, что для того, чтобы 20 процентов выстрелило, надо пропахать и 80 процентов.
А в манифесте тоже формально смешно звучит «Боритесь за закон Парето». Если это не закон и себя не проявляет, то давайте бороться за 10 процентов, а лучше за 5.
В оригинале было написано то, что было написано.
Я тиснул комментарий (на всякий случай).
Я перед тем как прочесть обычно бегло сканирую статью. Насканировалось:

Разработчикам… Манифет…
Убивайте в зародыше…
Уничтожайте… Чем быстрее, тем лучше…

Я аж кофе попрехнулся. Прочел, а оно вон че оказалось :)
Ждём лекции-анализа о «сканировании». С одной стороны lesswrong и компания с необходимостью отрицания опоры на прошлый опыт и эмперического подхода, с другой — экономия времени и плюшки в виде таких вот смыслов. В комментариях, как мне кажется, многим будет что добавить.
Видел на реальной практике как люди эти принципы применяли не правильно, в следствие этого их работа была долгой и крайне низкого качества. Возможно многие из этих принципов работают в стартапах, но не работают в корпоративном секторе, где надо внимательно, быстро и хорошо.
Даже скажу больше, все зависит не от самих принципов, а от человека. Тот, кто умеет — тот делает. А кто не умеет говорит, что 20% усилий дают 80% результата.
>Лучшее — враг хорошего
Однако, от хорошего к великому — целая вселенная. Многие люди всю жизнь остаются лишь «хорошими», вместо того, чтобы взять и сделать оставшиеся 80% и стать действительно великими! Я же думаю вы знаете, почему Джобс крайне был чувствителен к минимальным деталям продукта!
Only those users with full accounts are able to leave comments. Log in, please.