Философия разработки на примере синглтона

[tengiz]

Т.е. снова: децат

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

[tengiz]

Мое убеждение - правильно и есть просто. Код не должен быть сложнее функциональности, которую код реализует.

В целом - да, "не надо преумножать сущности", но бывает, что, казалось бы простая, функциональность требует непростых вещей для эффективной (в плане перфоманса) реализации и поэтому сделать эфффективный код еще и простым - не представляется возможным. Не в смысле того, что код - слоеное спагетти с говном, а в том плане, что приходится привлекать достаточно сложные сущности из advanced CS, специально заточенные под задачи такого рода. Имхо, 90-95% обычной девелоперской работы под этот расклад не попадают, но иногда приходится сталкиваться и с таким.

Так как вопрос было о "философии", то и ответ на опрос общественного мнения был "философский". Но есть еще и продукция, там бывает всякое, это понятно. Чисто для буквоедства - если "приходится привлекать достаточно сложные сущности из advanced CS", то тут уже суть становится сложной, поэтому правило - сложный код допустим только для сложного substance - вполне соблюдено.

[Boriskin]

Т.е. снова: децат

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

имо, "детсад" имелся в виду.

[Boriskin]

Чисто для буквоедства - если "приходится привлекать достаточно сложные сущности из advanced CS", то тут уже суть становится сложной, поэтому правило - сложный код допустим только для сложного substance - вполне соблюдено.

Тут надо разделять, о простоте чего идет речь, функциональность или формализация оной: простая и интуитивная для конечного пользователя функциональность может оказаться весьма нетривиальной при формализации и соответственно очень нетривиальной при реализации. Если формализация проста - тогда вопросов нет.

[tengiz]

Тут надо разделять, о простоте чего идет речь, функциональность или формализация оной: простая и интуитивная для конечного пользователя функциональность может оказаться весьма нетривиальной при формализации и соответственно очень нетривиальной при реализации. Если формализация проста - тогда вопросов нет.

Да, понятно. Справедливое уточнение. Под "функциональностью" я имею в видут суть того, что делает собственно код, а не то, как это видит пользователь.

[Roy]

На примере компании, в которой я работаю, сложилось такое мнение.

Когда компания начинает свой нелёгкий путь в виде стартапа - выбора особо нет как писать. Единственные критерий - быстро, поэтому получается говнокод в любом случае.

Еще бывает что разработкой руководят люди, ничего не понимающие в процессе - тогда даже говно не получается.

Вобщем у них главный принцип - сделай хоть как, но как можно быстрее, а потом много раз переписывай.

Тут надо понимать, что ФБ - это просто веб-сервис, и выпустить, добавить, удалить, отмотать можно все что угодно за пару минут. Они счас регулярно чтото тестируют на географических сегментах, "эту хрень для Бразилии добавим, а эту хрень для Польши уберем, как несыгравшую".

А теперь представим, что скажем Адоба выпустила новую версию CS и спустя пару миллионов проданных версий оказалось, что там чтото охрененно сломалось, и надо чинить весь install base. Головняк феерический и тяп-ляп уже не обойдешься.

Можно подытожить так: Если ты (годный) манагер
1). посмотри на свой проект
2). посмотри на состав своей команды
А теперь выбирай степень говнокодистости vs степень последующего геморроя.

[turic]

Я не против, as long as their shit is their problem, not mine.

Не факт, что просле лени и размышлений "shit" будет меньше.

[Boriskin]

Я не против, as long as their shit is their problem, not mine.

Не факт, что просле лени и размышлений "shit" будет меньше.

У сферического коня в вакууме - да. У меня лично - будет меньше. У вас - хез, не возьмусь судить.

[АццкоМото]

Т.е. снова: децат

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

децат = детский сад
курить тут: http://lurkmore.to/%D0%9F%D0%B0%D0%B4%D ... 0%BA%D0%B8

[Kolbasoff]

Манго тут не причем, сначала надо курить концепцию о NoSQL, потому как сравнение теплого и мягкого немного не корректно. Знаменитый Фаулер с курением концепции может немного помочь

Концепция понятна, область приложения и все такое. Однако в сухом остатке это просто склад данных и какой-бы склад не был, требуется инструмент что бы эти данные извлекать. SQL и есть такой инструмент. Он был разработан с участием лингвистов, у него очень "натуральный" синтакс. Он очень "эстетичен" с инженерной точки зрения. Посмотрев на монговский язык, приходит сравнение с дизайном Понтиак Ацтек.

Допустим, в NoSQL базе нет joins но есть конвейеры (pipes). Вот мне натурально такой синтакс приходит на ум:

(SELECT field11, ... FROM collection1 WHERE ... etc) PIPE TO (SELECT а.field21, ... FROM collection2 a, PIPE b WHERE a.field21=b.field11, ... etc) PIPE TO (SELECT ...) etc.

Вместо этого предлагается писать такую кукарямбу на JS, который ну никаким боком не заточен под запросы к базе. И так гордо заявлять "мы NoSQL".

[Kolbasoff]

Вместо этого предлагается писать такую кукарямбу на JS, который ну никаким боком не заточен под запросы к базе. И так гордо заявлять "мы NoSQL".

Вот даже старина Цукер со мной согласен, забацал тулзец to inspect the current state of your OS X or Linux operating system by writing SQL queries: http://www.sitepoint.com/osquery-explore-os-sql/