Минифест (манифест разработчиков-минималистов)

[1ex]

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

[kyrie]

Разве ж это манифест минималистов? Вот манифест минималистов: !

[Agent_Smith]

Вот манифест минималистов: programming-motherfucker.com

[kaichou]

Это манифест (зачёркнуто) не очень умных людей.

[saaivs]

Квинтэссенция опыта индустрии

[zviryatko]

Вот просто рад этой статье в понедельник )
Спасибо большое, распечатаю каждый пункт и повешу в офисе!

[mjr27]

Я просто оставлю это здесь www.python.org/dev/peps/pep-0020/

[dstarcev]

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

[PapaBubaDiop]

Сначала просто сделайте, потом сделайте правильно, потом сделайте лучше.

Вам еще прыгать. Никогда не делайте хорошо и правильно. Сначала делайте быстро.

[dstarcev]

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

PS мне еще всю жизнь «прыгать», чему я очень рад. Я никому не желаю останавливаться в развитии.

[PapaBubaDiop]

Хороший тост. Я с удовольствием присоединяюсь.

[dstarcev]

И еще большое спасибо за «Поле Чудес» — это было круто!

[nekt]

Прыгайте дальше. «Быстро» входит в «хорошо и правильно».

[gleb_kudr]

Краткое содержание статьи: лучше быть здоровым и богатым, чем бедным и больным.

[gleb_kudr]

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

[dstarcev]

Так лучше :)

[CKOPOBAPKuH]

пиши-код-блять.рф

[VolCh]

Конечно, вы можете с головой окунуться в какие-нибудь фреймворки модульных тестов типа Jasmine, JUnit, Mocha — но, безусловно, полезнее будет научиться писать код, который можно покрыть тестами (например, изолируя код от состояния и уменьшая связность компонентов).

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

P.S.Ошибка в переводе

высокая плотность — малая связность

Есть слово «связанность», а есть «связность» — практически антонимы в данном контексте. Обычный перевод «high cohesion — low coupling» — «высокая связность — малая/низкая связанность» или «высокое сцепление — малая/низкая связанность». Пишу не в личку, потому часто вижу это ошибку и в комментах, и в постах.

[80x86]

Вы правы. Спасибо.

[BlackRaven86]

«В один из наиболее продуктивных дней я удалил тысячу строк кода». Кен Томпсон

[AleksDesker]

«Боритесь за закон Парето» — странный подход для минималиста. Логичнее было бы бороться против него, выполняя только самые полезные 20% и не тратя 80% на рутину и выскабливание, отдавая это джуниорам, автоматизируя и т.п.
Да и остальной текст, вроде как бы по теме, только иногда с погрешностью 100%, не знаю уж проблема это перевода, формулировок или понимания.

[VolCh]

Написано же, что 80% усилий нужно оставлять на будущее. То есть реализовывать сейчас только те 20%, которые решат задачу на 80%. А остальное отложить на потом, когда более важные задачи будут решены. Причем с большой вероятностью это «потом» никогда не наступит в виду изменившихся требований.

[bak]

Только есть одна проблема. Выполняя всё быстро в какой-то момент может оказаться, что система пришла в настолько не поддерживаемое состояние, что теперь быстро занимает в 10 раз больше времени, чем раньше правильно. Поэтому, ИМХО, это правило плохо подходит для крупных проектов, разве что вы не хотите сделать хоть как-то, а потом уйти.

[VolCh]

Речь не идет, по-моему, о выборе между «писать говнокод быстро» и «писать правильно». Речь, прежде всего, о выборе реализуемых фич. Есть 10 требований к какому-то продукту с условно одинаковой длительностью реализации, реализовали 2 самых важных и даем заказчику «посмотреть». Получаем от него два новых фичереквеста и опять выбираем 2 самых важных из общих 10, реализуя их, и т. п. Глядишь так о 8 из первых 10 он и не вспомнит никогда :)

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

[4p4]

Удивительно, что вчера была опубликована моя статья на хабре:

habrahabr.ru/post/176669/

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

[valkoivo]

Правило Парето-Зенона. Если 20% труда дает 80% результата, то 20% от оставшихся процентов труда дает 80% оставшегося результата. Если продолжать трудиться, мы получаем уйму свободного времени и никогда не заканчивающийся проект.

[m36]

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

[notxcain]

YAGNI расшифровывается как You Ain't Gonna Need It (вам это не понадобится)

[80x86]

В оригинале было написано то, что было написано.
Я тиснул комментарий (на всякий случай).

[notxcain]

ну все таки смысл фразы имеет другой оттенок

[leMar]

Я перед тем как прочесть обычно бегло сканирую статью. Насканировалось:

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

Я аж кофе попрехнулся. Прочел, а оно вон че оказалось :)

[YgReEk]

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

[SAnatoly]

Видел на реальной практике как люди эти принципы применяли не правильно, в следствие этого их работа была долгой и крайне низкого качества. Возможно многие из этих принципов работают в стартапах, но не работают в корпоративном секторе, где надо внимательно, быстро и хорошо.
Даже скажу больше, все зависит не от самих принципов, а от человека. Тот, кто умеет — тот делает. А кто не умеет говорит, что 20% усилий дают 80% результата.

[SAnatoly]

>Лучшее — враг хорошего
Однако, от хорошего к великому — целая вселенная. Многие люди всю жизнь остаются лишь «хорошими», вместо того, чтобы взять и сделать оставшиеся 80% и стать действительно великими! Я же думаю вы знаете, почему Джобс крайне был чувствителен к минимальным деталям продукта!

[olekhy]

Читая перевод, заметил неточность в переводе:
(оригинал github.com/pabloguevarac/minifesto/blob/master/german.html#L74)
В переводе вы использовали «Синтакс» вместо «Синтеза». Инетресно чья ошибка ваша или автора.

[80x86]

Чёрт его не знает.
По смыслу что то, что другое не очень :(