Comments 39
KISS
И да, и нет. KISS скорее про сам код, но не о том, откуда берутся идеи, планы и как ведётся разработка продукта в общем.
The KISS principle states that most systems work best if they are kept simple rather than made complex; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.
Вообще, изначально это про то, что самолёт должен быть прост в починке. А в разработке софта — это в целом про разработку софта, а не только про код.
Это должно быть первой заповедью и разработчиков, и архитекторов, и вообще всех, вовлеченных в процесс разработки ПО!
Автор легко и непринуждённо убил архитектуру с паттернами — и посоветовал вместо них плодить костыли, названные для благовидности патчами.
Автор мне нравится.
Автор мне нравится.
Именно так. Я полагаю, дефект в его рассуждениях начинается со слов, что идеи — это плохо. Идея как решить проблему — это ведь тоже идея, только в отличие от патча, она подразумевает свободу творчества. И как раз в свободе творчества кроются наиболее элегантные и эффективные решения.
Идея хороша, когда она пришла тебе в голову, ты её реализовал, показал решение остальным и дальше оно было принято\исправлено\дополнено\отброшено. А когда она пришла в голову тебе одному, делать её должен кто-то другой, а не нужна она окажется никому вообще — вот тогда она плоха. Об этом автор и говорит.
Откуда автору известно, что идея окажется никому не нужна? Если он знает это наперёд, то он должен быть богаче Билла Гейтса и Сергея Брина, вместе взятых.
Более того, он должен уметь путешествовать во времени.
Более того, он должен уметь путешествовать во времени.
Вообще, это нормально, что идеи генерируют одни, а реализуют — другие.
Сценарист должен и режиссёрскую, и операторскую работу всегда сам выполнять?
Сценарист должен и режиссёрскую, и операторскую работу всегда сам выполнять?
Пожалуйста, Не Пишите Все Слова В Заголовках С Большой Буквы.
Это английский стиль, по-русски так писать нельзя. В русском языке в заголовках и именах собственных с большой буквы пишется только первое слово. Я серьезно, глаза кровоточат.
Это английский стиль, по-русски так писать нельзя. В русском языке в заголовках и именах собственных с большой буквы пишется только первое слово. Я серьезно, глаза кровоточат.
какие у вас слабые глаза и психика, тренируйте их.
От Таких Заголовков Еще Никто Не Умер. И английский стиль в среде IT вполне норм.
От Таких Заголовков Еще Никто Не Умер. И английский стиль в среде IT вполне норм.
Во-первых, это перевод, а в оригинале было «Simplicity Oriented Design», во-вторых, мне показалось правильным так это написать, в-третьих, некоторые вещи на русский лучше не переводить.
Вы что-то путаете.
У вас ссылка на код, в котором переменные написаны подобным стилем. Обратите внимание — именно переменные. Они пишутся слитно. Поэтому для них есть такое понятие как Naming Convention. По вашей ссылке — это CamelCase en.wikipedia.org/wiki/CamelCase
У вас ссылка на код, в котором переменные написаны подобным стилем. Обратите внимание — именно переменные. Они пишутся слитно. Поэтому для них есть такое понятие как Naming Convention. По вашей ссылке — это CamelCase en.wikipedia.org/wiki/CamelCase
Раз это перевод на русский, то надо стараться писать с учетом русской грамматики. В русской грамматике все слова с большой буквой считаются ошибкой. Не верите — посмотрите заголовки на любом качественном русскоязычном новостном сайте. А потом сравните с заголовками на англоязычном сайте.
Пруф:
— На глаза постоянно попадаются заголовки, каждое слово в которых написано с заглавной буквы. Знаю, что в английском языке это является нормой, а в русском?
— В русском языке в заголовках с большой буквы пишутся первое слово, имена собственные, а также начало второй части заголовка вроде Алиса, или Последний побег.
Пруф:
— На глаза постоянно попадаются заголовки, каждое слово в которых написано с заглавной буквы. Знаю, что в английском языке это является нормой, а в русском?
— В русском языке в заголовках с большой буквы пишутся первое слово, имена собственные, а также начало второй части заголовка вроде Алиса, или Последний побег.
Я не знаю, откуда Вы берёте эти нормы, мне всегда казалось правильным понятие «авторского стиля» — если автор посчитал нужным написать слово с большой буквы или поставить в этом месте запятую, то он прав, потому что это его произведение, а не та учительница русского языка, которая в 7-ом классе его учила что надо только с маленькой и без запятой.
Если Вам нужны пруфлинки — ну почитайте, например, Ильфа и Петрова, в том же «Золотом телёнке» есть не то что заголовки — целые предложения и абзацы капсом. Вы же не будете спорить с тем, что это вполне себе классическое произведение?
Если Вам нужны пруфлинки — ну почитайте, например, Ильфа и Петрова, в том же «Золотом телёнке» есть не то что заголовки — целые предложения и абзацы капсом. Вы же не будете спорить с тем, что это вполне себе классическое произведение?
Во-первых, речь не про капс и не про пунктуацию, а про правильное оформление заголовков и имен собственных (типа «Креативные ребята»). Во-вторых, вы путаете публицистику и литературу. В публицистике не существует никакого авторского стиля, тем более который мог бы нарушать общепризнанную грамматику языка. За такие экзерcиcы с большими буквами вас бы редактор лишил премии в любом издании, где занимаются именно публицистикой, и никакие разговоры про «авторский стиль» бы не помогли, это я вам совершенно точно говорю.
Вы просто не вполне в курсе про английскую грамматику, это общепризнанная норма в английском, которая отсутствует в русском. Извините, мне не особо интересно дискутировать на эту тему, я просто поделился некоторой информации из области, которую знаю досконально — если вы не хотите ее принимать, это ваше дело.
Вы просто не вполне в курсе про английскую грамматику, это общепризнанная норма в английском, которая отсутствует в русском. Извините, мне не особо интересно дискутировать на эту тему, я просто поделился некоторой информации из области, которую знаю досконально — если вы не хотите ее принимать, это ваше дело.
> Не знаю, откуда Вы берете эти нормы:
Есть Розенталь, есть Грамота.ру
> Мне всегда казалось — Мне всегда казалось, что число пи равно 5, но это никому не интересно.
Есть Розенталь, есть Грамота.ру
> Мне всегда казалось — Мне всегда казалось, что число пи равно 5, но это никому не интересно.
Между «число пи равно 5» и «буквочка должна быть маленькой» есть объективная разница: первое — математический факт, верность которого можно доказать или опровергнуть наукой. Второе — соглашение группы людей, которые договорились, что им так удобно. Если на основе того что пи равно 5 построить ракету — она упадёт, если написать заголовок капсом — суть текста не меняется. Ну и я всё-таки хотел бы увидеть правило, где было бы написано «известным писателям, типа упомянутых выше Ильфа и Петрова так делать можно, а какому-то tangro с Хабра — не положено, рожей не вышел». Есть такое у Розенталя и грамоты.ру?
От безграмотно составленных ТЗ и документации ракеты тоже падают, увы. Писать безграмотно — это все равно что говнокодить или ходить в грязных штанах. От этого тоже суть не меняется: программа работает, ноги не мерзнут.
Касательно «авторского» — авторская пунктуация или словоупотребление это не то же самое, что «как хочу, так и пишу, потому что я автор». Если вы отходите от общепринятых языковых норм, вы должны делать это для достижения какой-то цели. А насчет «есть ли такое у Розенталя или грамоты.ру» — проверьте, разве ж Вам кто-то не дает?
Касательно «авторского» — авторская пунктуация или словоупотребление это не то же самое, что «как хочу, так и пишу, потому что я автор». Если вы отходите от общепринятых языковых норм, вы должны делать это для достижения какой-то цели. А насчет «есть ли такое у Розенталя или грамоты.ру» — проверьте, разве ж Вам кто-то не дает?
Последний способ очень похож на unix подход к разработке — когда создается много простых утилит, которые хорошо делают одно действие. Но для следование такому подходу нужно грамотное и ненавязчивое руководство что бы разбить крупную задачу на атомарные действия.
Позвольте процитировать высказывание в тему:
легаси проект от проекта «с нуля» отличается лишь тем, что легаси — это говнокод сразу, а проект «с нуля» — говнокод чуть-чуть попозже
Ах вот как появился на свет PHP…
При желании, любой метод разработки можно превратить в ад. И написание патчей не исключение.
К примеру, можно в каждом патче делать по 5 багов и на каждый баг создавать новую задачу и новый патч.
Главное не методология а люди.
К примеру, можно в каждом патче делать по 5 багов и на каждый баг создавать новую задачу и новый патч.
Главное не методология а люди.
Есть много проектов, где не нужно решать уникальные задачи, и не нужен R&D. Например игрострой, все что можно уже сделали кчей разных вариантов, уже известны практики разработки, известная сложность, известный компромисы. На начальном этапе уже можно прикинуть, сколько нуна денег и выбрать путь для проекта. Либо это будет простенький говнокод с минимум архитектуры, и попробовать выплестнуть на рынок. Либо будет серьезно прорабатывать архитектуру, потому что проект будет поддерживатся и дизы уверены в его успехе.
Ссылка на оригинал конкретно статьи, а не просто главную 0MQ, как внизу поста.
Уж сколько раз писали, что всё зависит от задачи.
И не всегда «Креативные ребята» со списком фич — это плохо. Т.к. иногда продукт основывается именно на синергии фич, составляющей его уникальность(ТМ). Конечно, «уникальность продукта» — фраза заезженная и зачастую вызывающая лишь недобрую улыбку. Но тем не менее, это важное свойство.
Но, конечно, программисты у нас ребята на все руки, поэтому они легко могут судить о том, нужно рынку это или нет и т.п.
Насчёт «Они начинают объяснять, почему кое-что сделать трудно, а кое-что вообще невозможно, но…» — это вообще никак не связано с одним из трёх описанных «методов». Это связано лишь с тем, что среди «Креативных ребят» вообще нет технических специалистов. Что ж, такое часто бывает. Но опять же, добавьте технических специалистов в эту группу и первый метод начнёт приносить хорошие плоды.
И не всегда «Креативные ребята» со списком фич — это плохо. Т.к. иногда продукт основывается именно на синергии фич, составляющей его уникальность(ТМ). Конечно, «уникальность продукта» — фраза заезженная и зачастую вызывающая лишь недобрую улыбку. Но тем не менее, это важное свойство.
Но, конечно, программисты у нас ребята на все руки, поэтому они легко могут судить о том, нужно рынку это или нет и т.п.
Насчёт «Они начинают объяснять, почему кое-что сделать трудно, а кое-что вообще невозможно, но…» — это вообще никак не связано с одним из трёх описанных «методов». Это связано лишь с тем, что среди «Креативных ребят» вообще нет технических специалистов. Что ж, такое часто бывает. Но опять же, добавьте технических специалистов в эту группу и первый метод начнёт приносить хорошие плоды.
1. Плохо правила игры читали.
2. Вам не кажется, что туповато подшучивать над тем, что изначально «отмазано»?
3. И вообще, вы свежи, аки рис, сваренный три дня назад и оставленный на солнце.
2. Вам не кажется, что туповато подшучивать над тем, что изначально «отмазано»?
составляющей его уникальность(ТМ). Конечно, «уникальность продукта» — фраза заезженная и зачастую вызывающая лишь недобрую улыбку
3. И вообще, вы свежи, аки рис, сваренный три дня назад и оставленный на солнце.
Хорошая статья. Сродни исследованию «что такое хорошо и что такое плохо». К сожалению, описан пока только симптом болезни, а не сама болезнь. Я не видел ни одного исследования которое интересуется вопросом, почему корпорация, созданная ранее и приносящая прибыль в сотни мегабаксов превращается в конце-концов в поле битвы между двумя-тремя группировками внутри корпорации, которых разводит главный смотрящий (обычно генеральный директор который над схваткой и борется только за внимание акционеров и свои бонусы). Процесс который вы описали в первой части это результат не желания сделать лучше своим юзерам а возможность утереть нос другим группировкам. На юзеров все ложили приборы в этом процессе и такой и результат получился. :)
Любопытно, что «жизнь в долг», по горло в кредитах, уже вроде всеми осознаётся как что-то неправильное.
А вот про жизнь в «технический долг» люди до сих пор всерьёз пишут хвалебные статьи, будто это чуть ли не «серебряная пуля» и вообще здорово и прекрасно. Не думай о будущем, live fast die young.
А вот про жизнь в «технический долг» люди до сих пор всерьёз пишут хвалебные статьи, будто это чуть ли не «серебряная пуля» и вообще здорово и прекрасно. Не думай о будущем, live fast die young.
Мдя… Автор неплохо описывает картинки, но генерит полный бред, когда пытается делать выводы и рекомендации.
"… увольняет консультантов..."
Ни разу не видел такого! Как правило консультанты переходят в другой проект с повышением. Увы…
Ни разу не видел такого! Как правило консультанты переходят в другой проект с повышением. Увы…
Такие статьи обычно пишут люди экспертного уровня, которые отлично разбираются в архитектурах и паттернах. Да, такие люди умеют делать те самые патчи правильно. И они умеют из этих патчей сложить качественный (т.е. не глючный, что весьма не тривиально на самом деле), сложный (в плане комплексный) и нужный продукт. Они пользуются знаниями, не замечая того. Они делают все просто, потому что умеют делать это просто! Да, это KISS. И да, этому надо учиться.
А теперь вопрос: как этому учиться? Как отличить простое от сложного, если не знаешь, что такое сложное?
Чтобы достичь этого уровня как раз и надо упорно изучать архитектуру, паттерны, алгоритмы. И нужно владеть базовыми, фундаментальными знаниями.
А кричать в рупор «забейте на все и делайте простые пачти» — создание дополнительных барьеров для новичков, которые будут смотреть не в том направлении и писать глупости в комментах на Хабре.
А теперь вопрос: как этому учиться? Как отличить простое от сложного, если не знаешь, что такое сложное?
Чтобы достичь этого уровня как раз и надо упорно изучать архитектуру, паттерны, алгоритмы. И нужно владеть базовыми, фундаментальными знаниями.
А кричать в рупор «забейте на все и делайте простые пачти» — создание дополнительных барьеров для новичков, которые будут смотреть не в том направлении и писать глупости в комментах на Хабре.
Блин, как все это похоже на процесс разработки фирмы, где я сейчас работаю. Особенно, «разработка, направленная на создание мусора». Печально все это…
Patch-driven-development.
А вообще у меня дежавю. Мне кажется автор переизобретает скрам с его user-story и delivered value каждый спринт. Или это TDD с его минимальными правками для озеленения тестов.
Конечно нужно знать меру в кодоблудии, но эти патчи явно путь в ад. В какой то момент по патчам будет сложно понять что же код делает. Инкрементальный подход не всегда хорош.
А вообще у меня дежавю. Мне кажется автор переизобретает скрам с его user-story и delivered value каждый спринт. Или это TDD с его минимальными правками для озеленения тестов.
Конечно нужно знать меру в кодоблудии, но эти патчи явно путь в ад. В какой то момент по патчам будет сложно понять что же код делает. Инкрементальный подход не всегда хорош.
Sign up to leave a comment.
3 способа разработки