Comments 39
Приятно узнать себя минималистом )
Правда кое что прихрамывает, но эти места и сам знаю.
Отличный минифест, побольше бы минифестантов.
Правда кое что прихрамывает, но эти места и сам знаю.
Отличный минифест, побольше бы минифестантов.
Разве ж это манифест минималистов? Вот манифест минималистов: !
Вот манифест минималистов: programming-motherfucker.com
Квинтэссенция опыта индустрии
Вот просто рад этой статье в понедельник )
Спасибо большое, распечатаю каждый пункт и повешу в офисе!
Спасибо большое, распечатаю каждый пункт и повешу в офисе!
UFO just landed and posted this here
Я просто оставлю это здесь www.python.org/dev/peps/pep-0020/
Делайте хорошо и правильно, а не плохо и неправильно. Обожаю такие посты. Те, кто поймет о чем речь в посте, уже применяют эти правила так или иначе. А те, кто еще недостаточно опытен, все равно не смогут применять эти правила, пока не дойдут до них сами. Нельзя просто прочитать пост и перепрыгнуть через несколько уровней профессионального развития.
Сначала просто сделайте, потом сделайте правильно, потом сделайте лучше.
Вам еще прыгать. Никогда не делайте хорошо и правильно. Сначала делайте быстро.
UFO just landed and posted this here
Краткое содержание статьи: лучше быть здоровым и богатым, чем бедным и больным.
Ого, как яростно заминусовали. Что ж, поясню. Подобные опусы вам ничего кроме лозунгов не дают. Чтобы из них что-то вынести, вы должны сами своей головой до них дойти.
«Вы должны X потому что один очень богатый чувак делал X каждый день и у него получилось». Это стиль тупой агитки. А в разработке думать надо башкой своей!
«Вы должны X потому что один очень богатый чувак делал X каждый день и у него получилось». Это стиль тупой агитки. А в разработке думать надо башкой своей!
Конечно, вы можете с головой окунуться в какие-нибудь фреймворки модульных тестов типа Jasmine, JUnit, Mocha — но, безусловно, полезнее будет научиться писать код, который можно покрыть тестами (например, изолируя код от состояния и уменьшая связность компонентов).
Можно покрыть тестами почти любой код (кроме исследовательского и т. п., когда результаты не определены). Нужно научиться писать код, который легко покрывать тестами. Но сложно этому научиться без окунания с головой. Только когда попытаешься покрыть тестами достаточно большой проект, который «нельзя» покрыть тестами, тогда придет понимание как писать код, который легко покрывать. Заодно и понимание того, что стоит покрывать, а что нет. Прочитав книжку про TDD понимание не придет (ну или я совсем тупой). Только практика приведет к пониманию на уровне рефлекса.
P.S.Ошибка в переводе
высокая плотность — малая связностьЕсть слово «связанность», а есть «связность» — практически антонимы в данном контексте. Обычный перевод «high cohesion — low coupling» — «высокая связность — малая/низкая связанность» или «высокое сцепление — малая/низкая связанность». Пишу не в личку, потому часто вижу это ошибку и в комментах, и в постах.
«В один из наиболее продуктивных дней я удалил тысячу строк кода». Кен Томпсон
«Боритесь за закон Парето» — странный подход для минималиста. Логичнее было бы бороться против него, выполняя только самые полезные 20% и не тратя 80% на рутину и выскабливание, отдавая это джуниорам, автоматизируя и т.п.
Да и остальной текст, вроде как бы по теме, только иногда с погрешностью 100%, не знаю уж проблема это перевода, формулировок или понимания.
Да и остальной текст, вроде как бы по теме, только иногда с погрешностью 100%, не знаю уж проблема это перевода, формулировок или понимания.
Написано же, что 80% усилий нужно оставлять на будущее. То есть реализовывать сейчас только те 20%, которые решат задачу на 80%. А остальное отложить на потом, когда более важные задачи будут решены. Причем с большой вероятностью это «потом» никогда не наступит в виду изменившихся требований.
Только есть одна проблема. Выполняя всё быстро в какой-то момент может оказаться, что система пришла в настолько не поддерживаемое состояние, что теперь быстро занимает в 10 раз больше времени, чем раньше правильно. Поэтому, ИМХО, это правило плохо подходит для крупных проектов, разве что вы не хотите сделать хоть как-то, а потом уйти.
Речь не идет, по-моему, о выборе между «писать говнокод быстро» и «писать правильно». Речь, прежде всего, о выборе реализуемых фич. Есть 10 требований к какому-то продукту с условно одинаковой длительностью реализации, реализовали 2 самых важных и даем заказчику «посмотреть». Получаем от него два новых фичереквеста и опять выбираем 2 самых важных из общих 10, реализуя их, и т. п. Глядишь так о 8 из первых 10 он и не вспомнит никогда :)
Это не отменяет того, что за архитектурой нужно следить, покрывать тестами и проводить постоянный рефакторинг, не допуская наращивание технического долга, но не нужно закладывать в архитектуру суперрасширяемость и супергибкость на будущее. Прежде всего не нужно вводить уровни абстракции, которые сейчас не требуются. Код должен быть готов к их введению, но вводить заранее не нужно.
Это не отменяет того, что за архитектурой нужно следить, покрывать тестами и проводить постоянный рефакторинг, не допуская наращивание технического долга, но не нужно закладывать в архитектуру суперрасширяемость и супергибкость на будущее. Прежде всего не нужно вводить уровни абстракции, которые сейчас не требуются. Код должен быть готов к их введению, но вводить заранее не нужно.
UFO just landed and posted this here
Удивительно, что вчера была опубликована моя статья на хабре:
habrahabr.ru/post/176669/
библиотека yaui, построена именно на этих самых принципах. Как здорово, что вы тут опубликовали эти принципы, так точно выражающие мой подход, который всегда так не просто доносить до окружающих. Ведь если не понимать идей минимализма (и наномализма) то люди часто не впечатлены, поскольку привыкли оценивать по внешнему богатству по отдельным впечатляющим внешним элементам.
habrahabr.ru/post/176669/
библиотека yaui, построена именно на этих самых принципах. Как здорово, что вы тут опубликовали эти принципы, так точно выражающие мой подход, который всегда так не просто доносить до окружающих. Ведь если не понимать идей минимализма (и наномализма) то люди часто не впечатлены, поскольку привыкли оценивать по внешнему богатству по отдельным впечатляющим внешним элементам.
Правило Парето-Зенона. Если 20% труда дает 80% результата, то 20% от оставшихся процентов труда дает 80% оставшегося результата. Если продолжать трудиться, мы получаем уйму свободного времени и никогда не заканчивающийся проект.
Да да. Меня всегда принцип Парето формально удивлял. Люди с ГСМ очень его любят. Но при этом никто не думает, что для того, чтобы 20 процентов выстрелило, надо пропахать и 80 процентов.
А в манифесте тоже формально смешно звучит «Боритесь за закон Парето». Если это не закон и себя не проявляет, то давайте бороться за 10 процентов, а лучше за 5.
А в манифесте тоже формально смешно звучит «Боритесь за закон Парето». Если это не закон и себя не проявляет, то давайте бороться за 10 процентов, а лучше за 5.
YAGNI расшифровывается как You Ain't Gonna Need It (вам это не понадобится)
Я перед тем как прочесть обычно бегло сканирую статью. Насканировалось:
Разработчикам… Манифет…
Убивайте в зародыше…
Уничтожайте… Чем быстрее, тем лучше…
Я аж кофе попрехнулся. Прочел, а оно вон че оказалось :)
Разработчикам… Манифет…
Убивайте в зародыше…
Уничтожайте… Чем быстрее, тем лучше…
Я аж кофе попрехнулся. Прочел, а оно вон че оказалось :)
Видел на реальной практике как люди эти принципы применяли не правильно, в следствие этого их работа была долгой и крайне низкого качества. Возможно многие из этих принципов работают в стартапах, но не работают в корпоративном секторе, где надо внимательно, быстро и хорошо.
Даже скажу больше, все зависит не от самих принципов, а от человека. Тот, кто умеет — тот делает. А кто не умеет говорит, что 20% усилий дают 80% результата.
Даже скажу больше, все зависит не от самих принципов, а от человека. Тот, кто умеет — тот делает. А кто не умеет говорит, что 20% усилий дают 80% результата.
Читая перевод, заметил неточность в переводе:
(оригинал github.com/pabloguevarac/minifesto/blob/master/german.html#L74)
В переводе вы использовали «Синтакс» вместо «Синтеза». Инетресно чья ошибка ваша или автора.
(оригинал github.com/pabloguevarac/minifesto/blob/master/german.html#L74)
В переводе вы использовали «Синтакс» вместо «Синтеза». Инетресно чья ошибка ваша или автора.
Sign up to leave a comment.
Минифест (манифест разработчиков-минималистов)