Здравствуйте, SergH, Вы писали:
F>>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.
SH>Не кинут. Было в исходном посте.
SH>21. there's more than one way to do it
Ух. Я до стольких считать не умею слишком много букв, я не осилил — и полез со своим перлом. Сорри.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Klapaucius, Вы писали:
F>>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.
K>Ага. И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение. K>Дело в том, что в искусстве нет неправильных путей. В программировании они есть. Это важное различие. Давайте о нем не забывать.
Ну, и единственный путь тоже может завести не туда
А вообще твой пример с переполнением не имеет никакого отношения к TIMTOWTDI.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
пока это лишь черновик над который надо думать, дискутировать и т.д.
а для этого нужна большая аудитория и диалог (в вики и то, и другое — хуже)
вот когда более-менее устаканится (по крайней мере, первая волна), можно переносить в вики.
Здравствуйте, VGn, Вы писали:
SH>> А возможно ему ещё третья нога понадобится, из области экономики-логистики. VGn>Быстро убегать от заказчика?
Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.
Здравствуйте, DarkGray, Вы писали:
D>>Может стоит перенести в http://wiki.rsdn.ru/ ?
DG>пока рано.
DG>пока это лишь черновик над который надо думать, дискутировать и т.д. DG>а для этого нужна большая аудитория и диалог (в вики и то, и другое — хуже) DG>вот когда более-менее устаканится (по крайней мере, первая волна), можно переносить в вики.
Дискутировать уже есть где, а как редактировать? Например зачем 1а и 9 когда есть solid и grasp?
D> Дискутировать уже есть где, а как редактировать?
редактирование списка я пока хочу оставить за собой, потому что у любого проекта должен быть один "отец" особенно на ранний стадиях, и у меня есть идея(пока еще плохоформулируемая) как все это структурировать.
окончательный текущий вариант на http://blog.metatech.ru/post/ogni-razrabotki.aspx
соответственно, задавай вопросы, предлагай изменения — я буду это слушать, буду с этим спорить, буду с этим соглашаться... и сделаю все по своему
D> Например зачем 1а и 9 когда есть solid и grasp?
согласен.
поэтому:
первый пункт трансформировался в более общий
1. жуй по частям (сложные вещи делаются, как складывание простых элементов)
a) unix-way(Пусть каждая программа делает одну вещь, но хорошо)
b) single responsibility principle
Solid уехал в раздел: "Огни применяемые в разных языках/подходах и т.д."
а grasp уехал в раздел "Паттерны, которые применяются для достижения вышеперечисленных огней"
IT>Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей
да есть такое, и особенно, на данный момент, меня беспокоит, что часто разработчики пытаются спорить о том, какой код/решение лучше/хуже — не зная(не помня) этих принципов
Здравствуйте, DarkGray, Вы писали:
IT>>Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей
DG>да есть такое, и особенно, на данный момент, меня беспокоит, что часто разработчики пытаются спорить о том, какой код/решение лучше/хуже — не зная(не помня) этих принципов
Наверное поэтому еще можно спорить о том, является ли программирование искусством или нет: не зная всех этих принципов можно написать отличную программу и зная все эти принципы можно успешно завалить разработку. Все базируется на индивидуальном вкусе и опыте разработчика.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Klapaucius, Вы писали:
E>>Тогда программирование -- несомненно искусство. А ПО разбившегося Ариан 5 одно из ярчайших проявлений направления "шок-арт": одним маленьким арифметическим переполнением пустить на воздух $500M!
K>Иманно это я и написал: K>
K>И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение
K>Это лицо программирования как искусства. Нет багов — есть выражение внутреннего мира художника. Тесты и спецификации не нужны — неверных путей все равно нет.
Все это получается только в том случае, если вашу точку зрения считать правильной. Если же, напротив, верить в то, что в искусстве вполне есть неправильные направления (тот же самый шок-арт или творения типа "Черного квадрата"), то и картина выходит совсем другой.
Живопись, например, считается искусством. Но (на мой крестьянский взгляд), подавляющее количество производимых сейчас картин не имееют к искусству никакого отношения (как то: портреты на заказ, почти лубочные пейзажи, которыми торгуют в переходах метро или на рынках, копии старых картин, современные закосы под абстракционизм, росписи восстанавливаемых церквей и пр.) Обычный ширпотреб, коего и в программировании полно.
Между тем и там, и там есть настоящие шедевры. Которые возникли благодоря озарению автора и большому количеству вложенного автором труда. Например, различные виды сортировок, алгоритмы поиска, семафор Дейкстры и пр. Такие вещи вполне можно считать произведениями искусства программирования.
Другое дело, что искусство это прикладное...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, DarkGray, Вы писали:
IT>>Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей
DG>да есть такое, и особенно, на данный момент, меня беспокоит, что часто разработчики пытаются спорить о том, какой код/решение лучше/хуже — не зная(не помня) этих принципов
Это от того, что эти принципы не всегда очевидны, часто неинтуитивны, иногда противоречивы и не объясняют главного — какая именно проблема решается в каждом конкретном случае. Другими словами, сам по себе такой список представляет мало ценности, т.к. в таком виде больше похож на помойку принципов. Нужен не просто список принципов, нужен список с указанием где и когда каждый из принципов применим или не применим и почему. Тогда такому списку цены не будет.
Ну, например.
1. single responsibility principle.
Главным образом упрощает восприятие и процесс поддержки кода, т.к. программная сущность, удовлетворяющая такому принципу, отвечает за одну единственную функцию. Имеет прямое отношение к cohesion (как там правильно перевести).
2. premature optimization is the root of all evil.
Любая оптимизация усложняет код в разы. Преждевременная оптимизация усложняет код в разы, не решая при этом никаких других проблем. Т.е. при premature optimization мы вносим дополнительное усложнение в код, не получая ничего взамен.
и т.д.
В результате может оказаться, что этот список базвордов можно сократить как минимум вдвое и увидеть где они пересекаются и дополняют друг друга, а где противоречат и почему.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, SergH, Вы писали:
SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.
Это называется — грам, градус, копейка
Если нам не помогут, то мы тоже никого не пощадим.
IT>Нужен не просто список принципов, нужен список с указанием где и когда каждый из принципов применим или не применим и почему. Тогда такому списку цены не будет.
Здравствуйте, SergH, Вы писали: SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.
Ага. Типичный пример — дизайн IKEA. То, что они делают — одновременно и эстетично, и функционально, и рентабельно. Всякий раз фигею с того, как они выбирают размер дощечек для шкафа так, чтобы их можно было сложить в упаковку с плотностью почти что 100%.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>исходный пост http://blog.metatech.ru/post/ogni-razrabotki.aspx
DG>здесь же благодаря большой аудитории хочется найти/вспомнить и другие огни, а также обсудить уже перечисленные
Существуют же еще и "анти-огни". Например, не изобретай велосипед. И как одно из частных его проявлений NIH syndrome.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
SH>>> А возможно ему ещё третья нога понадобится, из области экономики-логистики. VGn>>Быстро убегать от заказчика?
SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.
слишком много букв, я не осилил — и полез со своим перлом. Сорри.
Если нам не помогут, то мы тоже никого не пощадим.
