У меня тут создалось впечатление, что индусские программисты склонны к "размазыванию" логики и данных по максимальному количеству компонентов (классов, модулей, хранимых процедур и т.п.). Делают они это весьма уверенно и, помоему, подсознательно. Единственно рациональное объяснение это так они закрепляются на своем месте, т.к. им одним постижим принцип построения этой логики. Возможно им просто так комфортно, а раз комфортно то увеличивается продуктивность.
Далее все полусерьезно...
В связи с чем возникает вопрос, а может все эти принципы программирования (KISS, поддерживаемость, инкапсуляция и т.п.) я понимаю неправильно? И надо брать с индусов пример? Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?
D> Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?
Прок в том что потом (через месяц год, пять лет) будет проще поддерживать и развивать. Если код одноразовый — то глубоко пофиг как его писать. Но тут есть второй нюанс — будущее предсказывается очень тяжко, поэтому очень трудно заранее предсказать какой код будет одноразовым, а какой — нет O_O.
Здравствуйте, Driver, Вы писали:
D>У меня тут создалось впечатление, что индусские программисты склонны к "размазыванию" логики и данных по максимальному количеству компонентов (классов, модулей, хранимых процедур и т.п.). Делают они это весьма уверенно и, помоему, подсознательно. Единственно рациональное объяснение это так они закрепляются на своем месте, т.к. им одним постижим принцип построения этой логики.
Вполне вероятно.
На одной из моих прошлых работ местный связист никогда ничего не документировал и в результате кроме него никто не знал, что где как находится и устроено. Незаменимый человек, однако...
D> Возможно им просто так комфортно, а раз комфортно то увеличивается продуктивность.
И зачем такая продуктивность? Найми кого-то другого.
D>В связи с чем возникает вопрос, а может все эти принципы программирования (KISS, поддерживаемость, инкапсуляция и т.п.) я понимаю неправильно? И надо брать с индусов пример? Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?
Прок тот, что работа программиста, в отличие от пространства на Земле, пока что не ограничена. И лучше стремиться к новым достижениям, чем замыкать на себя старые.
Здравствуйте, Driver, Вы писали:
D> В связи с чем возникает вопрос, а может все эти принципы программирования D>(KISS, поддерживаемость, инкапсуляция и т.п.) я понимаю неправильно? И надо брать с индусов пример?
я за KISS принцип. и мой шеф тоже за него. так что мы нашли друг друга. вообще, сравните апи никсов с виндами. вы действительно считаете, что в CreateFile должно быть столько параметров? и что у нее должно быть такое удачное название? и что нам позарез нужны все аргументы CreateProcess. и что нам нужно 100500 API функций?
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
...
EOH>Прок в том что потом (через месяц год, пять лет) будет проще поддерживать и развивать. Если код одноразовый — то глубоко пофиг как его писать. Но тут есть второй нюанс — будущее предсказывается очень тяжко, поэтому очень трудно заранее предсказать какой код будет одноразовым, а какой — нет O_O.
В том то и дело, помимо этого еще надо подстраиваться под изменяющиеся бизнес требования, пока вы будете работать над качеством кода индус будет работать над уверенностью в будущем не обременяя себя заумными принципами. Получается что принципы программирования — удел менеджеров и Тим лидов, если они сами в этом разбираются.
... N>И зачем такая продуктивность? Найми кого-то другого.
Меня самого наняли.
... N>Прок тот, что работа программиста, в отличие от пространства на Земле, пока что не ограничена. И лучше стремиться к новым достижениям, чем замыкать на себя старые.
Стремиться надо туда куда хочется, но Для большинства это пространство ограничено проектами, сроками и бюджетом.
... М>я за KISS принцип. и мой шеф тоже за него. так что мы нашли друг друга. вообще, сравните апи никсов с виндами. вы действительно считаете, что в CreateFile должно быть столько параметров? и что у нее должно быть такое удачное название? и что нам позарез нужны все аргументы CreateProcess. и что нам нужно 100500 API функций?
Я с индусом тоже за него, вопрос в его толковании. Как ваш менеджер его практикует (он же индус)?
Здравствуйте, Eye of Hell, Вы писали:
D>> Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?
EOH>Прок в том что потом (через месяц год, пять лет) будет проще поддерживать и развивать. Если код одноразовый — то глубоко пофиг как его писать. Но тут есть второй нюанс — будущее предсказывается очень тяжко, поэтому очень трудно заранее предсказать какой код будет одноразовым, а какой — нет O_O.
В одном проекте с которым доводилось работать вся бизнес логика была разбита на 100500 классов, при этом каждый класс выполнял свою узкоспециализированную задачу и занимал не более 100 строчек. Между классами общение шло в основном через подписку. Код был супер структурированным, реюзабельность полная (если сможешь найти среди этих 100500 классов тот который нужен). Но понять бизнес логику по этому набору классиков — это просто невозможно. Понять как это все работает глядя только на код — тоже, да и с дебуггером не всегда. Боддерживать этот код было тоже очень сложно.
Фишка в том, что в предыдущей версии, когда код был монолитным, то для добавления новой фичи нужно было неделю его порефакторить а потом за день добавить фичу, в новой версии — неделю вкуриваешь как это работает. неделю пишешь 100 классиков для имплемента новой фичи и неделю дебужишь.
Так вопрос в том так ли нужно писать легкорасширяемый, реюзабельный код если в нем хрен разберешься?
UNIX way — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
Здравствуйте, catBasilio, Вы писали:
B>Здравствуйте, Eye of Hell, Вы писали:
D>>> Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?
EOH>>Прок в том что потом (через месяц год, пять лет) будет проще поддерживать и развивать. Если код одноразовый — то глубоко пофиг как его писать. Но тут есть второй нюанс — будущее предсказывается очень тяжко, поэтому очень трудно заранее предсказать какой код будет одноразовым, а какой — нет O_O.
B>В одном проекте с которым доводилось работать вся бизнес логика была разбита на 100500 классов, при этом каждый класс выполнял свою узкоспециализированную задачу и занимал не более 100 строчек. Между классами общение шло в основном через подписку. Код был супер структурированным, реюзабельность полная (если сможешь найти среди этих 100500 классов тот который нужен). Но понять бизнес логику по этому набору классиков — это просто невозможно. Понять как это все работает глядя только на код — тоже, да и с дебуггером не всегда. Боддерживать этот код было тоже очень сложно.
B>Фишка в том, что в предыдущей версии, когда код был монолитным, то для добавления новой фичи нужно было неделю его порефакторить а потом за день добавить фичу, в новой версии — неделю вкуриваешь как это работает. неделю пишешь 100 классиков для имплемента новой фичи и неделю дебужишь. B>Так вопрос в том так ли нужно писать легкорасширяемый, реюзабельный код если в нем хрен разберешься?
Кха... А вы точно уверены в том, что этот код "легкорасширяемый" и "реюзабельный"?
D>В том то и дело, помимо этого еще надо подстраиваться под изменяющиеся бизнес требования,
Как раз хорошо написанный код проще менять при изменении бизнес требований.
D>пока вы будете работать над качеством кода индус будет работать над уверенностью в будущем не обременяя себя заумными принципами.
Тут надо определяться — шашечки или ехать. Если мы работаем ради результата — у нас один процесс. Если чтобы подсидеть босса — то как бы совсем другой. Если наша задача — переспать с секретаршей — то совсем третий. Ну а если собственную квалификацию повышаем — то четвертый. А их еще комбинировать можно...
B>В одном проекте с которым доводилось работать вся бизнес логика была разбита на 100500 классов, при этом каждый класс выполнял свою узкоспециализированную задачу и занимал не более 100 строчек. Между классами общение шло в основном через подписку. Код был супер структурированным, реюзабельность полная (если сможешь найти среди этих 100500 классов тот который нужен). Но понять бизнес логику по этому набору классиков — это просто невозможно. Понять как это все работает глядя только на код — тоже, да и с дебуггером не всегда. Боддерживать этот код было тоже очень сложно. B>Фишка в том, что в предыдущей версии, когда код был монолитным, то для добавления новой фичи нужно было неделю его порефакторить а потом за день добавить фичу, в новой версии — неделю вкуриваешь как это работает. неделю пишешь 100 классиков для имплемента новой фичи и неделю дебужишь. B>Так вопрос в том так ли нужно писать легкорасширяемый, реюзабельный код если в нем хрен разберешься?
Наверное все дела в том что архитектура "сто классиков и подписка" была так же плоха, как и монолитная? Размер и количество классов — как бы нифига не критерий хорошей архитектуры и хорошего кода?
B>В одном проекте с которым доводилось работать вся бизнес логика была разбита на 100500 классов, при этом каждый класс выполнял свою узкоспециализированную задачу и занимал не более 100 строчек. Между классами общение шло в основном через подписку. Код был супер структурированным, реюзабельность полная (если сможешь найти среди этих 100500 классов тот который нужен). Но понять бизнес логику по этому набору классиков — это просто невозможно. Понять как это все работает глядя только на код — тоже, да и с дебуггером не всегда. Боддерживать этот код было тоже очень сложно.
B>Фишка в том, что в предыдущей версии, когда код был монолитным, то для добавления новой фичи нужно было неделю его порефакторить а потом за день добавить фичу, в новой версии — неделю вкуриваешь как это работает. неделю пишешь 100 классиков для имплемента новой фичи и неделю дебужишь. B>Так вопрос в том так ли нужно писать легкорасширяемый, реюзабельный код если в нем хрен разберешься?
+100. Это еще повезло, что все было хорошо структурировано, бывает и бардак, но с теми же 100500 классами.
Что-то чем больше вижу разных проектов, чем больше сам делаю, тем больше склоняюсь к KISS. Добавлять фичи в простой, но не предназначенный для расширения проект оказывается сильно легче, чем в переполненный всякими гибкостями и заделами на будущее, но оттого огромный проект.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, мыщъх, Вы писали:
М>вы действительно считаете, что в CreateFile должно быть столько параметров?
Да, я ими пользуюсь.
М> и что у нее должно быть такое удачное название?
Ну, название не особо удачное. Предложи лучше.
М> и что нам позарез нужны все аргументы CreateProcess.
Да, я ими пользуюсь.
М> и что нам нужно 100500 API функций?
Ты предлагаешь оставить одну: void SdelatsZaippis (void); ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, мыщъх, Вы писали:
М>>вы действительно считаете, что в CreateFile должно быть столько параметров? BBI>Да, я ими пользуюсь.
интересно как юниксоидам хватает open ? или поставим вопрос иначе: чего не хватает системным вызовам никсов в работе с файлами, что если в win api.
М>> и что у нее должно быть такое удачное название? BBI>Ну, название не особо удачное. Предложи лучше.
см. posix open. уже давно предложили.
М>> и что нам позарез нужны все аргументы CreateProcess. BBI>Да, я ими пользуюсь.
всемя? сразу? в каждой программе? ой. а если в первый аргумент кинуть нуль, то одного второго не хватит? кстати, при всем этом изобилии нету форка.
М>> и что нам нужно 100500 API функций? BBI>Ты предлагаешь оставить одну: void SdelatsZaippis (void); ?
я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Driver, Вы писали:
D>Навеяно общением с идусским дизайнером...
В разработке корпоративного программного обеспечения (особенно когда аджайл) самая большая проблема — проблема управления сложностью. По-индусски можно при желании реализовать нечто, если требования будут фиксированными, но если требования меняются каждый день, вносить изменения в код очень сложно. Собственно, индусский код хорош всем, кроме того, что не понятно что надо поправить, чтобы изменился какой-то аспект поведения системы. Чтобы держать все эти факты в голове, нужно быть тем самым индусом. Иначе, придётся тратить время (много времени) на поиск всех неочевидных связей. А когда у тебя есть 300 маленьких классов, в которых каждый напрямую взаимодействует не более чем с 2-3 другими, понять происходящее намного легче, т.к. ты можешь ограничить себя пониманием этих 1+3 классов.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, Banned by IT, Вы писали:
BBI>>Здравствуйте, мыщъх, Вы писали:
М>>>вы действительно считаете, что в CreateFile должно быть столько параметров? BBI>>Да, я ими пользуюсь. М>интересно как юниксоидам хватает open?
Не хватает.
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
int creat(const char *pathname, mode_t mode);
М> или поставим вопрос иначе: чего не хватает системным вызовам никсов в работе с файлами, что если в win api.
Это неблагодарное занятие — сравнивать их.
Да и флейму разведём.
М>>> и что у нее должно быть такое удачное название? BBI>>Ну, название не особо удачное. Предложи лучше. М>см. posix open. уже давно предложили.
три функции там где в WinAPI одна. Да ещё одна с ошибкой в написании.
М>>> и что нам позарез нужны все аргументы CreateProcess. BBI>>Да, я ими пользуюсь. М>всемя? сразу? в каждой программе? ой. а если в первый аргумент кинуть нуль, то одного второго не хватит?
Они децл разное делают.
М>кстати, при всем этом изобилии нету форка.
Архитектурно.
М>>> и что нам нужно 100500 API функций? BBI>>Ты предлагаешь оставить одну: void SdelatsZaippis (void); ? М>я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc.
Мне его никогда не хватало. Более того, я практически ничем оттуда не пользуюсь дальше базового функционала уровня memcpy, который практически весь давно уже intrinsic в компиляторах.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, мыщъх, Вы писали:
М>>Здравствуйте, Banned by IT, Вы писали:
BBI>>>Здравствуйте, мыщъх, Вы писали:
М>>>>вы действительно считаете, что в CreateFile должно быть столько параметров? BBI>>>Да, я ими пользуюсь. М>>интересно как юниксоидам хватает open? BBI>Не хватает. BBI>int open(const char *pathname, int flags); BBI>int open(const char *pathname, int flags, mode_t mode); BBI>int creat(const char *pathname, mode_t mode);
а теперь прочтите описание. creat это типа "сахар". хочешь юзай, не хочешь -- хватит open. аргумент mode можно не указывать, когда он не нужен. и типичный сценарий открытия файла это open с двумя аргументами.
М>>кстати, при всем этом изобилии нету форка. BBI>Архитектурно.
в курсе, что архитектурно. но в винде API разрабатывалось до архитектуры. и система писалась под API, а не API под систему, а система вообще собиралась поддерживать произвольный набор API, где win32 API был не цетром вселенной. поддержка posix была заявлена. и где мой fork в этом случае?
М>>я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc. BBI>Мне его никогда не хватало. Более того, я практически ничем оттуда не пользуюсь дальше базового функционала уровня memcpy, который практически весь давно уже intrinsic в компиляторах.
если писать через API, то это делать программу намертво привязанную к платформе. прямые вызовы API имеют смысл только в системных программах (скажем, вот написал я дампер памяти -- там сплошные API вызовы и смысла помещать их в "обертки" нет, ибо на том же линухе дампер не нужен и мы просто прочтем память процесса как файл).
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>всемя? сразу? в каждой программе? ой. а если в первый аргумент кинуть нуль, то одного второго не хватит? кстати, при всем этом изобилии нету форка.
ЕМНИП, ты же сам когда-то где-то писал, что виндовый CreateProcess удобнее форка.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, мыщъх, Вы писали:
М>>всемя? сразу? в каждой программе? ой. а если в первый аргумент кинуть нуль, то одного второго не хватит? кстати, при всем этом изобилии нету форка. P>ЕМНИП, ты же сам когда-то где-то писал, что виндовый CreateProcess удобнее форка.
на заборах тоже много интересного пишут. и пока одни пишут, другие их поправляют. вот страшие товарищи прочитали и объяснили, что форкнуть процесс стоит дешево, а вызывать CreateProcess -- все равно что в булочную на истребителе летать.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Driver, Вы писали:
D>В том то и дело, помимо этого еще надо подстраиваться под изменяющиеся бизнес требования, пока вы будете работать над качеством кода индус будет работать над уверенностью в будущем не обременяя себя заумными принципами. Получается что принципы программирования — удел менеджеров и Тим лидов, если они сами в этом разбираются.
Ты точно не путаешь качество кода с навороченностью архитектуры? Наиболее качественный код прост настолько насколько это возможно для данной задачи и пишется он при равной функциональности быстрее индусокода.
