Re[3]: Огни разработки
От: frogkiller Россия  
Дата: 07.07.09 12:42
Оценка:
Здравствуйте, SergH, Вы писали:

F>>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.


SH>Не кинут. Было в исходном посте.


SH>21. there's more than one way to do it


Ух. Я до стольких считать не умею слишком много букв, я не осилил — и полез со своим перлом. Сорри.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[3]: Огни разработки
От: frogkiller Россия  
Дата: 07.07.09 12:44
Оценка:
Здравствуйте, Klapaucius, Вы писали:

F>>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.


K>Ага. И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение.

K>Дело в том, что в искусстве нет неправильных путей. В программировании они есть. Это важное различие. Давайте о нем не забывать.

Ну, и единственный путь тоже может завести не туда

А вообще твой пример с переполнением не имеет никакого отношения к TIMTOWTDI.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[3]: Огни разработки
От: dotneter  
Дата: 07.07.09 13:42
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

Может стоит перенести в http://wiki.rsdn.ru/ ?
Talk is cheap. Show me the code.
Re[4]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 14:07
Оценка:
D>Может стоит перенести в http://wiki.rsdn.ru/ ?

пока рано.

пока это лишь черновик над который надо думать, дискутировать и т.д.
а для этого нужна большая аудитория и диалог (в вики и то, и другое — хуже)
вот когда более-менее устаканится (по крайней мере, первая волна), можно переносить в вики.
Re[6]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 07.07.09 14:09
Оценка:
SH> А возможно ему ещё третья нога понадобится, из области экономики-логистики.
Быстро убегать от заказчика?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[7]: Огни разработки
От: SergH Россия  
Дата: 07.07.09 14:13
Оценка: 1 (1)
Здравствуйте, VGn, Вы писали:

SH>> А возможно ему ещё третья нога понадобится, из области экономики-логистики.

VGn>Быстро убегать от заказчика?

Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.
Делай что должно, и будь что будет
Re[5]: Огни разработки
От: dotneter  
Дата: 07.07.09 14:31
Оценка: 1 (1)
Здравствуйте, DarkGray, Вы писали:

D>>Может стоит перенести в http://wiki.rsdn.ru/ ?


DG>пока рано.


DG>пока это лишь черновик над который надо думать, дискутировать и т.д.

DG>а для этого нужна большая аудитория и диалог (в вики и то, и другое — хуже)
DG>вот когда более-менее устаканится (по крайней мере, первая волна), можно переносить в вики.
Дискутировать уже есть где, а как редактировать? Например зачем 1а и 9 когда есть solid и grasp?
Talk is cheap. Show me the code.
Re[6]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 15:28
Оценка:
D> Дискутировать уже есть где, а как редактировать?

редактирование списка я пока хочу оставить за собой, потому что у любого проекта должен быть один "отец" особенно на ранний стадиях, и у меня есть идея(пока еще плохоформулируемая) как все это структурировать.
окончательный текущий вариант на http://blog.metatech.ru/post/ogni-razrabotki.aspx

соответственно, задавай вопросы, предлагай изменения — я буду это слушать, буду с этим спорить, буду с этим соглашаться... и сделаю все по своему

D> Например зачем 1а и 9 когда есть solid и grasp?


согласен.
поэтому:
первый пункт трансформировался в более общий

1. жуй по частям (сложные вещи делаются, как складывание простых элементов)
a) unix-way(Пусть каждая программа делает одну вещь, но хорошо)
b) single responsibility principle


Solid уехал в раздел: "Огни применяемые в разных языках/подходах и т.д."
а grasp уехал в раздел "Паттерны, которые применяются для достижения вышеперечисленных огней"
Re: Огни разработки
От: IT Россия linq2db.com
Дата: 07.07.09 15:51
Оценка: +3 :)
Здравствуйте, DarkGray, Вы писали:

DG>здесь же благодаря большой аудитории хочется найти/вспомнить и другие огни, а также обсудить уже перечисленные


Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re: Огни разработки
От: mazurkin http://mazurkin.info
Дата: 07.07.09 16:00
Оценка:
DarkGray wrote:

> здесь же благодаря большой аудитории хочется найти/вспомнить и другие огни, а также обсудить уже перечисленные


Три богатыря: low coupling / high cohesion / tight incapsulation
Posted via RSDN NNTP Server 2.1 beta
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 17:08
Оценка: +1
IT>Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей

да есть такое, и особенно, на данный момент, меня беспокоит, что часто разработчики пытаются спорить о том, какой код/решение лучше/хуже — не зная(не помня) этих принципов
Re[3]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.07.09 17:37
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

IT>>Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей


DG>да есть такое, и особенно, на данный момент, меня беспокоит, что часто разработчики пытаются спорить о том, какой код/решение лучше/хуже — не зная(не помня) этих принципов


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.07.09 17:50
Оценка: +2
Здравствуйте, Klapaucius, Вы писали:

E>>Тогда программирование -- несомненно искусство. А ПО разбившегося Ариан 5 одно из ярчайших проявлений направления "шок-арт": одним маленьким арифметическим переполнением пустить на воздух $500M!


K>Иманно это я и написал:

K>

K>И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение

K>Это лицо программирования как искусства. Нет багов — есть выражение внутреннего мира художника. Тесты и спецификации не нужны — неверных путей все равно нет.

Все это получается только в том случае, если вашу точку зрения считать правильной. Если же, напротив, верить в то, что в искусстве вполне есть неправильные направления (тот же самый шок-арт или творения типа "Черного квадрата"), то и картина выходит совсем другой.

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

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

Другое дело, что искусство это прикладное...


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Огни разработки
От: IT Россия linq2db.com
Дата: 07.07.09 18:14
Оценка: 11 (2) +1
Здравствуйте, DarkGray, Вы писали:

IT>>Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей


DG>да есть такое, и особенно, на данный момент, меня беспокоит, что часто разработчики пытаются спорить о том, какой код/решение лучше/хуже — не зная(не помня) этих принципов


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

Ну, например.

1. single responsibility principle.

Главным образом упрощает восприятие и процесс поддержки кода, т.к. программная сущность, удовлетворяющая такому принципу, отвечает за одну единственную функцию. Имеет прямое отношение к cohesion (как там правильно перевести).

2. premature optimization is the root of all evil.

Любая оптимизация усложняет код в разы. Преждевременная оптимизация усложняет код в разы, не решая при этом никаких других проблем. Т.е. при premature optimization мы вносим дополнительное усложнение в код, не получая ничего взамен.

и т.д.

В результате может оказаться, что этот список базвордов можно сократить как минимум вдвое и увидеть где они пересекаются и дополняют друг друга, а где противоречат и почему.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Огни разработки
От: IT Россия linq2db.com
Дата: 07.07.09 18:28
Оценка:
Здравствуйте, SergH, Вы писали:

SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.


Это называется — грам, градус, копейка
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 19:20
Оценка:
IT>Нужен не просто список принципов, нужен список с указанием где и когда каждый из принципов применим или не применим и почему. Тогда такому списку цены не будет.

именно, это и хочется сделать.
Re[8]: Огни разработки
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 08.07.09 04:03
Оценка:
Здравствуйте, SergH, Вы писали:
SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.
Ага. Типичный пример — дизайн IKEA. То, что они делают — одновременно и эстетично, и функционально, и рентабельно. Всякий раз фигею с того, как они выбирают размер дощечек для шкафа так, чтобы их можно было сложить в упаковку с плотностью почти что 100%.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.07.09 06:09
Оценка: 1 (1) +1
Здравствуйте, DarkGray, Вы писали:

DG>исходный пост http://blog.metatech.ru/post/ogni-razrabotki.aspx


DG>здесь же благодаря большой аудитории хочется найти/вспомнить и другие огни, а также обсудить уже перечисленные


Существуют же еще и "анти-огни". Например, не изобретай велосипед. И как одно из частных его проявлений NIH syndrome.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 06:32
Оценка:
SH>>> А возможно ему ещё третья нога понадобится, из области экономики-логистики.
VGn>>Быстро убегать от заказчика?

SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.


С экономикой и так ясно. А логистика где?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[8]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 06:32
Оценка:
E> Обычный ширпотреб, коего и в программировании полно.

От картины есть польза. Она дырку на обоях закрывает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.