Re: Огни разработки
От: VsevolodC Россия  
Дата: 08.07.09 07:02
Оценка: +1

Концептуальное единство
У большинства европейских соборов части, построенные разными
поколениями строителей, имеют различия в планировке и архитектурном стиле.
Более поздние строители испытывали соблазн "улучшить" проект своих
предшественников, чтобы отразить новые веяния моды и свои личные вкусы. В
итоге мирный норманнский трансепт создает конфликт с примыкающим к нему
возносящимся в высь готическим нефом, и результат столь же служит
восхвалению славы Господней, сколь и гордыни строителей.
Архитектурное единство Реймского собора находится в прямой
противоположности с таким смешением стилей. Источником наполняющей зрителя
радости служат как цельность конструкции, так и отдельные образцы
совершенства. Как сказано в путеводителе, цельность была достигнута
благодаря самоотречению восьми поколений строителей собора, пожертвовавших
своими идеями ради чистоты общего замысла. То что получилось в результате,
служит восхвалению не только славы Господней, но и Его могущества,
способного спасти грешных людей от их гордыни.
Хотя на создание программных систем не уходят века, в большинстве своем
они демонстрируют меньшую согласованность концепций, чем в любом соборе.
Обычно это происходит не оттого, что главные проектировщики сменяют друг
друга, а потому, что проект расщепляется на ряд задач, выполняемых разными
разработчиками.
Я убежден, что концептуальная целостность является важнейшей
характеристикой системного проекта. Лучше убрать из системы отдельные
необычные возможности и усовершенствования и реализовать единый набор
конструктивных идей, чем оснастить ее многими хорошими, но
невзаимосвязанными и несогласованными идеями.

Фредерик П.Брукс. Мифический человеко-месяц или как создаются программные системы
Re[9]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 08.07.09 08:00
Оценка:
VGn> А логистика где?

управление проектом, распределение ресурсов своих и "соседей".
принятие решений, что сделать сейчас, а что попозже

это не относится к логистике, но задачи те же
Re[10]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 08:10
Оценка:
DG>управление проектом, распределение ресурсов своих и "соседей".
DG>принятие решений, что сделать сейчас, а что попозже

DG>это не относится к логистике, но задачи те же


Задачи логистики — эффективно добыть и довезти куда-то какой-нибудь жизненно необходимый хлам.
При чём тут распределение ресурсов, а тем более принятие решений в проекте?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[11]: Огни разработки
От: Qbit86 Кипр
Дата: 08.07.09 08:18
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Задачи логистики — эффективно добыть и довезти куда-то какой-нибудь жизненно необходимый хлам.


Кроме того, задача логистики — это ещё и разводить рыбу в пруду :)
Глаза у меня добрые, но рубашка — смирительная!
Re[9]: Огни разработки
От: SergH Россия  
Дата: 08.07.09 08:19
Оценка:
Здравствуйте, VGn, Вы писали:

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


VGn>С экономикой и так ясно. А логистика где?


Тебе не кажется, что это немного оффтоп? Если что, речь про архитектора, который дома делает, а не архитектуру ПО

Экономика зависит от логистики. От того, какие материалы и ресурсы просто/возможно доставить к месту строительства. Или что нужно сделать, чтобы было просто. Вполне возможно, что этим отдельные люди занимаются, ни разу не участвовал в постройке большого дома.
Делай что должно, и будь что будет
Re[12]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 08:21
Оценка:

Почему Ферхюльст назвал уравнение логистическим, остается неизвестным.

... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 08.07.09 08:28
Оценка: 10 (1)
из нового

23. пиши в коде то, что ты действительно хотел сделать, а не что получается записать
а) пиши логику, а не физику
24. Все строки кода должны постоянно работать/использоваться (иначе их съедает ржа)
а) Покрывай тестами(или часто используемыми сценариями) весь код
b) резерв должен быть горячим, а не холодным
25. Название должно точно отражать содержимое (уже по названию должно быть понятно, что содержится внутри)
а) Программа должна работать
b) должно быть как можно меньше side-effect-ов
26. новое делай снаружи, старое интегрируй внутрь
а) чем большим количеством что-то используется, тем более оно ядернее и интегрируемее должно быть (и наоборот)
b) get, don't set — формируй новую реальность, а не меняй имеющуюся
c) Open for extension, closed for modification
27. Единообразие, согласованность (говоря A, говори и B)
a) Principle of least astonishment
28. Выделяй главное, убирай(скрывай) несущественное
a) Инкапсуляция
b) Вводи метафоры и абстракции
29. Скопируй, разберись, сделай лучше

Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 08.07.09 08:30
Оценка:
E>Существуют же еще и "анти-огни". Например, не изобретай велосипед. И как одно из частных его проявлений NIH syndrome.

поддерживаю.
записал так

Анти-Огни
1. Предварительное усложнение без четкого ответа "зачем?" корень всех зол
а) premature optimization is the root of all evil
b) любую проблему можно решить путём введения дополнительного абстрактного слоя (кроме проблемы слишком большого количества абстрактных слоёв).
2. не изобретай велосипед

Re[13]: «Вот, помню, был случай...»
От: Qbit86 Кипр
Дата: 08.07.09 08:32
Оценка:
Дело было в Лиманчике, играли как-то в крокодила, довелось мне объяснять жестами словосочетание «занимательная логистика» :) В общем, ключевым моментом для угадывания второго слова оказался изображённый жестами график одного из решений логистического дифура :)
Глаза у меня добрые, но рубашка — смирительная!
Re: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.07.09 08:22
Оценка: 30 (1)
Сформулировано введение, которое показывают откуда берутся огни

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

такая формулировка цели приводит нас к следующим требованиям на код:
Требования:
1. Код должен решать поставленную задачу
a) правильно
b) быстро
c) с минимальными затратами ресурсов
d) целиком
* порядок именно такой (т.е. лучше правильно, чем быстро; лучше быстро, чем оптимально и т.д.)
3. Код должен легко использоваться
4. Код должен быть готовым к любым условиям использования
а) Код должен легко повторно использоваться
b) Код должен вести себя адекватно даже в непредвиденной ситуации
5. Код должен быстро разрабатываться
6. Код должен легко модифицироваться
a) Код должен читаться (легко пониматься) человеком и компьютером
b) Код должен быть достаточно формализован (должна оставаться возможность автоматического\автоматизированного рефакторинга)

если ориентироваться на следующие огни, то добиться вышеуказанных требований будет проще

Огни:
...

Re[2]: Огни разработки
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 09.07.09 09:52
Оценка: 5 (1) -1
Здравствуйте, DarkGray, Вы писали:

DG>4. Код должен быть готовым к любым условиям использования

DG> а) Код должен легко повторно использоваться
DG> b) Код должен вести себя адекватно даже в непредвиденной ситуации

Из этого следует, что код должен быть безопасен, а следовательно:

1) Любая уязвимость, допущенная в коде будет рано или поздно использована (антиогонек "безопасность через сокрытие")
1.1) Безопасность через сокрытие скрывает безопасность
2) Код уязвим настолько, насколько уязвима его самая незащищенная часть (принцип слабого звена)

Я это к чему... Огни разработки безопасного кода интересны?

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[3]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.07.09 11:57
Оценка:
KV>Из этого следует, что код должен быть безопасен, а следовательно:

поддерживаю.

KV>1) Любая уязвимость, допущенная в коде будет рано или поздно использована (антиогонек "безопасность через сокрытие")

KV>1.1) Безопасность через сокрытие скрывает безопасность
KV>2) Код уязвим настолько, насколько уязвима его самая незащищенная часть (принцип слабого звена)

KV>Я это к чему... Огни разработки безопасного кода интересны?


конечно, интересно, пиши. буду ждать.
Re[4]: Огни разработки
От: Klapaucius  
Дата: 09.07.09 13:11
Оценка:
Здравствуйте, frogkiller, Вы писали:

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

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

Лично я не против многих путей. Просто, когда вдруг при этом ни с того ни с сего поминают про искусство, у меня возникают опасения, что сторонник какого-то пути не может объяснить чем этот путь лучше других.

F>А вообще твой пример с переполнением не имеет никакого отношения к TIMTOWTDI.


А я ничего не говорю про TIMTOWTDI. Я говорю про искусство, которое не имеет никакого отношения к TIMTOWTDI.
Да и переполнение не причина — причина, как известно, творческий подход к повторному использованию кода.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[8]: Огни разработки
От: Klapaucius  
Дата: 09.07.09 13:11
Оценка: +1
Здравствуйте, eao197, Вы писали:

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


На самом деле ничего не изменится. Даже если мы предположим, что в искусстве неправильные пути есть — мы не сможем отличить их от правильных — mensura Zoili-то у нас нет. Так что и смысла говорить о неправильных путях нет — раз уж различать мы их не умеем. Где те требования, которым должна отвечать картина "Охотники на снегу" и как мы проверим соответсвие? Требования эти только в головах существуют и во всех головах могут быть разными. А требования к программам, как правило, представляет сама жизнь — они объективны. И ракета замечательно соответствие этим требованиям проверила. С огоньком.

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


Это не столько программирование, сколько CS. Да и это даже не техническая эстетика сверхзвукового самолета, которую каждый может оценить, хотя это и красота практически полностью произошедшая из целесообразности. Это красота целесообразности, доступная только специалисту.
Так что это "искусством" можно назвать только в смысле "умение", а не в смысле "продукт творческой деятельности", о которой мы тут и говорим, нет?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[9]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.07.09 13:53
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


K>На самом деле ничего не изменится. Даже если мы предположим, что в искусстве неправильные пути есть — мы не сможем отличить их от правильных — mensura Zoili-то у нас нет.


Время, как правило, все расставляет на свои места.

K>Это не столько программирование, сколько CS.


Никогда не мог понять, почему может существовать CS в отрыве от программирования.

K>Так что это "искусством" можно назвать только в смысле "умение", а не в смысле "продукт творческой деятельности", о которой мы тут и говорим, нет?


Применительно к упонянутой frogkiller-ом идиоме TIMTOWTDI, когда нужно суметь выбрать один путь из множества, речь идет именно об "умении".

Хотя меня греет мысль, что некоторые результаты работы программистов все-таки можно считать искусством в смысле "продукта творческой деятельности".


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

DG>Сформулировано введение, которое показывают откуда берутся огни


Уже гораздо лучше От кучи разношёрстных принципов обо всём мы перешли к вполне конкретному понятию — коду. Осталось ответить на вопрос — зачем. Зачем код дожен легко повторно использоваться, зачем быть легко модифицируемым, какая разница легко он читается или сложно?
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 00:21
Оценка:
IT> Зачем код дожен легко повторно использоваться, зачем быть легко модифицируемым, какая разница легко он читается или сложно?

цель же вроде была прописана во введении — это разве не ответ на вопрос "зачем?"

Цель — код должен решать поставленную нами задачу за конкретный срок в том окружении, которое есть; и быть готовым к переформулировке или корректировке задачи по ходу (примечание: время на разработку и модификацию кода входит в срок)


т.е. все это нужно для того, чтобы с помощью этого кода можно было комфортно решить стоящую передо мной задачу (или перед кем-то другим)
Re[10]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.09 03:08
Оценка:
Здравствуйте, eao197, Вы писали:

E>Время, как правило, все расставляет на свои места.

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

E>Никогда не мог понять, почему может существовать CS в отрыве от программирования.

Хм. А ничего, что, к примеру, функан существует в отрыве от гидродинамики?

E>Хотя меня греет мысль, что некоторые результаты работы программистов все-таки можно считать искусством в смысле "продукта творческой деятельности".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 03:10
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

DG>цель же вроде была прописана во введении — это разве не ответ на вопрос "зачем?"


DG>

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


Это всё следствия.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Огни разработки
От: Vladek Россия Github
Дата: 10.07.09 05:05
Оценка:
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, DarkGray, Вы писали:


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


DG>>навскидку:


E>Я не заметил самого важного "огонька": "Программа должна работать!" (т.е. делать именно то, за что заплатили ее заказчики/покупатели).


Это базовое требование к профессии.
Developers, developers, developers, developers, developers, developers, developers... © Steve Ballmer
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.