Постоянная работа для программера в Москве

← →
Игорь Шевченко © (2004-04-05 13:59) [80]

Тимохов © (05.04.04 13:54)

Вот MS Office, например, крупный проект. Или тот же Delphi (из всем известных).

← →
Юрий Зотов © (2004-04-05 14:03) [81]

> Тимохов © (05.04.04 13:54) [79]

Где-то читал информацию по принятой в буржуйляндских софтверных компаниях классификации. Крупным они считают проект начиная с 500 тыс. строк на ЯВУ (насколько я понимаю, имеются в виду собственноручно написанные строки, а не используемые сторонние библиотеки).

← →
Тимохов © (2004-04-05 14:04) [82]

> Юрий Зотов © (05.04.04 14:03) [81]

значит у нас крупный, т.к. все свое...

← →
Странник © (2004-04-05 14:06) [83]

> Иксик © (05.04.04 13:51) [77]

> Имхо, проектированием и кодированием действительно должны
> заниматься разные люди.

Но совместно!

← →
Rule © (2004-04-05 14:08) [84]

>Иксик © (05.04.04 13:41) [73]

Прошу прощения :)
Виноват ...
ЗЫ: хотя НЛО не обижаються на уфологию и уфологов в частности ... :) (это была шутка в смысле ЗЫ-шутка а перед этим не шутка)

← →
Юрий Зотов © (2004-04-05 14:08) [85]

> Тимохов © (05.04.04 14:04) [82]

Дык... как это - "все свое"? А VCL вы разве не используете? Тогда вам и Delphi была бы на фиг не нужна.

← →
Тимохов © (2004-04-05 14:20) [86]

> Юрий Зотов © (05.04.04 14:08) [85]

я ориентируюсь на total lines в compiling при build all.
Там разве vcl учитывается?

← →
Иксик © (2004-04-05 14:37) [87]

> Rule © (05.04.04 14:08) [84]

Да я, вообще-то, ничего против не имею, просто недавно тут была тааакая дискуссия по поводу того, что может считаться наукой, а что нет, поэтому боюсь Иксология не потянет. :))))

> Странник © (05.04.04 14:06) [83]

Разумеется, просто большинство работодателей хотят "всего и сразу". Может быть вопрос стоило поставить немного иначе, например:
"способность работать с иерархией классов с порядка 10 уровнями вложенности. И не навести в ней бардак!" :))

← →
Anatoly Podgoretsky © (2004-04-05 14:37) [88]

Тимохов © (05.04.04 14:20) [86]
Учитывается если в путях, но кроме VCL еще могут быть и постороннии компоненты, например у многих стоит RX и подобное, часто их размер суммируется.

← →
Юрий Зотов © (2004-04-05 15:21) [89]

> Тимохов © (05.04.04 14:20) [86]

Если при проходе отладчиком по F7 Вы заходите в код любого пакета (в том числе, пакета VCL) - значит, код этого пакета в статистике тоже учитывается.

← →
Тимохов © (2004-04-05 15:25) [90]

> Юрий Зотов © (05.04.04 15:21) [89]

:))) Да знаю я - это был вопрос утверждение.
У меня vcl не суммируется.

Так, что строки чисто мои...

← →
Юрий Зотов © (2004-04-05 15:34) [91]

> Тимохов © (05.04.04 15:25) [90]

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

← →
Тимохов © (2004-04-05 15:41) [92]

> Юрий Зотов © (05.04.04 15:34) [91]

Все у нас гибко (даже очень). Просто я отстаивал точку зрения, что гибкость не однозначеное решение. Возможно, иногда нужно ей пожертвовать...

Во многих новый кусках системы я отгибкости отказываюсь в пользу скорости разработки.

← →
Юрий Зотов © (2004-04-05 16:04) [93]

> Тимохов © (05.04.04 15:41) [92]

> Во многих новый кусках системы я отгибкости отказываюсь в
> пользу скорости разработки.

О чем и речь. Заточка под конкретику. Появится необходимость заточки пол другую конкретику - и бывшая скорость разработки превратится в свою противоположность. О поддержке разномастных проектов уже даже и не говорю.

← →
Тимохов © (2004-04-05 16:05) [94]

время покажет :))))))

← →
Fantasist © (2004-04-05 19:50) [95]

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

Не всегда, не всегда. Во-первых, бывают такие конкретики, изменения которых очень мало вероятно. Например стоят у нас MS SQL Server"а. Давно уже стоят и я не представляю факта, который может сподвигнуть компанию перейти на другой SQL server или вообще другой источник данных. Разработка заточенна именно под этот сервер, и пытаться сделать обобщенный интерфейс было бы просто недопустимой тратой времени, которого нам и так практически не дают. Можно привести и другие примеры, где теоретически может существовать несколько вариантов, но вероятность использования каких-то других, кроме выбранного, исчезающе мала. И в этом случае я тоже ставлю на скорость разработки. Правда, должен сказать, что делаю так не потому что мне так нравиться, а такая у нас жизнь - разработка должна быть выполненна быстро.
Бывают и другие случаи, когда разработка обобщенного ядра очень сложна в проектировании. Был у нас случай, когда при переходе на другую платформу было заодно решено и перепроектировать продукт, дабы был он настраевыемый, вместо расширяемого. Раньше у нас настройка под клиента был просто набор того же кода подправленного под логику клиента. Сделали теперь "настраиваемым". Сама по себе идея была правильна, но сложность явно превысила расчитываемую. Настройки под клиентов порой бывают настолько различными, что не укладываются в систему "настроек". То есть не смотря на правильность идеи, реально более правильным был все-таки расширяемый путь. Правда, надо сказать, что в этом проекте все-таки был опять таки плохой мэнеджмент. Времени под разработку выделили только в таком количестве, что хватало только переписать код. Проектировка вообще не была никому не порученна и времени на нее не выделялось. Тем не менее, реалии таковы, что времени чтобы создать настолько настраиваемую систему, чтобы можно было настроить под любого клиента требовалось гораздо больше, чем нам могут дать. Наше начальство не считает позволительным заставлять клиентов ждать.

Так что я согласен с Тимоховым. Гибкость - это очень хорошо, это одна из первых вещей, о которой я забочусь, но бывает, что ей выгоднее пожертвовать.

← →
Тимохов © (2004-04-05 19:53) [96]

> Fantasist © (05.04.04 19:50) [95]

Раз уж вы со мной согласились, я тоже соглашусь с вами (причем искренне) :)))))

Расширяемая система лучше, чем настраиваемая, т.к. первая намного проще...

← →
Fantasist © (2004-04-05 19:57) [97]

> Расширяемая система лучше, чем настраиваемая, т.к. первая
> намного проще...

Вот, вот, это именно та характеристика, которую я забыл упомянуть -"намного проще".

>[95],[96]
что-то вы путаете, имхо...

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

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

> Тимохов
> Fantasist

Вообще говоря, гибкость - это, в том числе, и расширяемость тоже. И об этом говорилось - см. [71], п.2. Почему Вы эти два понятия противопоставили - мне непонятно.

А НЕгибкость - это и НЕнастраиваемоть, и НЕрасширяемость. Это только ПЕРЕделываемость. Жесткая заточка. "Написал-выбросил". И об этом тоже говорилось - тоже см. [71], п.2.

И еще см. [98].

> Почему Вы эти два понятия противопоставили - мне непонятно.

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

> т.п. - про это нельзя сказать "намного проще".

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

>Fantasist
ок, не надо скриптового языка, не надо плагинов.

я про что говорю - если система не спроектирована модульно, нету интерфейсов между модулями и, следовательно, нет возможности переписать какой-то модуль, изменив его логику и не затронув всю остальную систему - о какой "расширяемости" можно говорить?

а сделать реально расширяемую систему - "намного проще" не получится.

> нет возможности переписать какой-то модуль, изменив его
> логику и не затронув всю остальную систему - о какой "расширяемости"
> можно говорить?

Ну уж с этим не поспоришь. :)

> а сделать реально расширяемую систему - "намного проще"
> не получится.

Если говорить совершенно обобщенно, то это уже слегка другой разговор. Тут мы говорили о дополнении/изменении функциональности противопостовляя расширяемость и настраиваемость.
Так-то, конечно, никто не спорит, что сделать большой качественный (настраиваемый/расширяемый/еще чего-нибудь?) продукт работа не простая.

> Anatoly Podgoretsky © (05.04.04 13:06) [67]
> SPeller © (05.04.04 11:14) [45]
> Ну доказал, что ты знаешь, что такое иерархия, но какая
> то она простая и линейная. Кстати не шутка.

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

2 Тимохов.

10 тыс. строк вмеру коментированого кода занимает порядка 300Kb.

Вы говорите об 1 млн. строк, т.е. у вас исходники составляют приблизительно 30Mb кода. Скажите, сколько лет Вы занимаетесь этим проектом? И неужели до сих пор принцип "отказываюсь в пользу скорости разработки" имеет место?

> [36] Думкин © (05.04.04 06:33)

Поддерживаю! ;)
Вот только часто приходится наоборот - нам к ним....

> [43] Плохиш (05.04.04 11:02)
> Что в Москве уже стало легко вид на жительство получить?

По последним сведениям людей "оттуда" - 600 руб. в любой ментовке

Постоянная работа для программера в Москве Найти похожие ветки