Программист-2
В то время, как простые философы спорят про курицу и яйцо (2D). Софисты-программисты решают что важнее: кодер, архитектор или манагер (3D). И напрочь, типа, забывают о 4-ой составляющей. А четвертым измерением является то, что нашептывает терпеливому кодеру, что и у него могут вырасти крылья. Парящему над рутиной архитектору, что его ж0па тоже, если нужно, выдержит эти километры кракозябр. А менеджера подтолкнет пообещать заказчику сроки, не посоветовавшись с первыми двумя. Жадность может еще не то...
Сейчас одна здоровенная и достаточно богатая (т.к. живет на деньги других) Новосибирская организация срочно пишет ТЗ. Делает она это в связи с окончанием СРОКОВ одного одурительно дорогого проекта, который неожиданно так потребовалось еще и показать в работе. А ни железо, ни ПО как надо не работают.
Думаете они в начале проекта не знали как правильно организовать работу? Просто, когда замаячила эта вереница нулей, большинство из них сказало: "А *б*сь оно все конем - раз живем!"
Вот и ТС, пишет что нужно два, а приму одного... Ну, тут может не от излишка денег, а наоборот.
Везде бабло
Сейчас одна здоровенная и достаточно богатая (т.к. живет на деньги других) Новосибирская организация срочно пишет ТЗ. Делает она это в связи с окончанием СРОКОВ одного одурительно дорогого проекта, который неожиданно так потребовалось еще и показать в работе. А ни железо, ни ПО как надо не работают.
Думаете они в начале проекта не знали как правильно организовать работу? Просто, когда замаячила эта вереница нулей, большинство из них сказало: "А *б*сь оно все конем - раз живем!"
Вот и ТС, пишет что нужно два, а приму одного... Ну, тут может не от излишка денег, а наоборот.
Везде бабло
Тут чего-то много понаписали, может повторюсь, но ... допущения в виде ч.б. деления на Создателя и Исполнителя не соответствует окружающей реальности, в каждом есть Создатель, в каждом, и не мной это замеченоЕсли уж на то пошло, то можно быть Создателем Хаоса и Исполнителем Совершенства
(а чо, не я стал пафосничать первый). Вобщем не знаю чем помочь :))
Набирайте толковых ребят с _нужным_ опытом. Фигня это что есть программисты пишущие хоть на чем. Ведь программисты они как военные (почти что). Решают поставленные перед ними задачи исходя из собственной специализации и ТТХ вооружения. Нужно взять крепость? Готовьте стенобитное орудие и призывайте стенобитчиков с мощным торсом и накачанными икроножными мыщами. Нужно организовать переворот - вызывайте отряд спецназа. А может надо обеспечить стратегическое превосходство? Пожалте тогда в РВСН! А если на все эти задачи набирать мастеров кунфу с десятым даном и прокаченным дзеном то недалеко и до казуса.
Вобщем пардон за туманные аллегории, как получилось так и рассказал - пошел я работать
Если уж на то пошло, то можно быть Создателем Хаоса и Исполнителем Совершенства(а чо, не я стал пафосничать первый). Вобщем не знаю чем помочь :))Набирайте толковых ребят с _нужным_ опытом. Фигня это что есть программисты пишущие хоть на чем. Ведь программисты они как военные (почти что). Решают поставленные перед ними задачи исходя из собственной специализации и ТТХ вооружения. Нужно взять крепость? Готовьте стенобитное орудие и призывайте стенобитчиков с мощным торсом и накачанными икроножными мыщами. Нужно организовать переворот - вызывайте отряд спецназа. А может надо обеспечить стратегическое превосходство? Пожалте тогда в РВСН! А если на все эти задачи набирать мастеров кунфу с десятым даном и прокаченным дзеном то недалеко и до казуса.
Вобщем пардон за туманные аллегории, как получилось так и рассказал - пошел я работать
Вы правы. Здесь технические вопросы обсуждают, а не вопрос распределения нефтяных гос. денег в путинскую эпоху. Если хочется обсудить второе, то это Вам надо бы обратить свой взор туда, где обитают армии агрессивно настроенных хомячков
Спасибо, благодетель 
> придется говнокодить со скоростью 100 строчек в день
Пардон, у меня возник вопрос по поводу этой сентенции.
100 строчек в день это я так понимаю имеется ввиду много что ли?
Пардон, у меня возник вопрос по поводу этой сентенции.
100 строчек в день это я так понимаю имеется ввиду много что ли?
100 строчек в день это я так понимаю имеется ввиду много что ли?Вообще говоря - дофига. Если считать "строчками" осмысленную деятельность системы, а не нарезку хтмля, комментарии и прочие декларации.
> Давай для простоты считать "осмысленным" код, который непосредственно выполняет бизнес-функцию - от обработки нажатия кнопки "сохранить" до записи в БД.
Это непонятное определение - код вне классов и деклараций не существует. Придавая смысл только лишь исполняемым операторам фактически оправдывается copy/paste, сильное связывание, нарушения ООП подходов и прочие весьма серьезные антипаттерны, ну если уж выделение интерфейсов и т.п. бессмысленно. Причем дизайн кода более трудоемкая вещь чем алгоритмика действия "обработки кнопки сохранить", опять же если мы не обсуждаем сложную алгоритмику какой-нибудь аля мат задачи
> Угу, и 90% из всего перечисленного либо генерируется средствами IDE, либо представляет собой тупейшую рутину
Выше я аргументировал почему это не так. Принять параметры, написать цикл, в котором положить их в query тоже в общем то не бох весть что, скорость разработки же не находится в прямой корреляции со скоростью печати
> Model-Driven Developmen
почитаю
> Конечно осмысленный.
Хех, а как же осмысленное лишь то что выполняет непосредственно бизнес функцию?
Это непонятное определение - код вне классов и деклараций не существует. Придавая смысл только лишь исполняемым операторам фактически оправдывается copy/paste, сильное связывание, нарушения ООП подходов и прочие весьма серьезные антипаттерны, ну если уж выделение интерфейсов и т.п. бессмысленно. Причем дизайн кода более трудоемкая вещь чем алгоритмика действия "обработки кнопки сохранить", опять же если мы не обсуждаем сложную алгоритмику какой-нибудь аля мат задачи
> Угу, и 90% из всего перечисленного либо генерируется средствами IDE, либо представляет собой тупейшую рутину
Выше я аргументировал почему это не так. Принять параметры, написать цикл, в котором положить их в query тоже в общем то не бох весть что, скорость разработки же не находится в прямой корреляции со скоростью печати
> Model-Driven Developmen
почитаю
> Конечно осмысленный.
Хех, а как же осмысленное лишь то что выполняет непосредственно бизнес функцию?
Всё же иногда полезно поискать готовые ответы. Например о количестве строк упоминается здесь.
Если Вы не поленитесь пойти по ссылке, то поймете, почему 100 строк в день рассматриваются как "много".
С другой стороны, очевидно, что вполне можно написать хоть 1000 строк осмысленного кода за день.
Была бы осмысленная задача, а код написать - это не проблема
И еще интересно - какие общие параметры Вашего проекта? Сколько человек в нем работает? Каков объем уже написанного кода? Сколько общая длительность (в чел-мес)?
Если Вы не поленитесь пойти по ссылке, то поймете, почему 100 строк в день рассматриваются как "много".
С другой стороны, очевидно, что вполне можно написать хоть 1000 строк осмысленного кода за день.
Была бы осмысленная задача, а код написать - это не проблема
И еще интересно - какие общие параметры Вашего проекта? Сколько человек в нем работает? Каков объем уже написанного кода? Сколько общая длительность (в чел-мес)?
А в этой жалкой неправильной 1С ЗП обратно пропорциональна количеству кода
> Всё же иногда полезно поискать готовые ответы
не поспоришь
> Если Вы не поленитесь пойти по ссылке, то поймете, почему 100 строк в день рассматриваются как "много".
не поленился - прошел. Кто этот человек? Он пишет какие-то вполне с виду разумные вещи, но в основном про то сколько кода попадает в конечный продукт, типа 10 - 12 строчек в день, я хз как он это оценил, откуда он взял эти цифры и когда его конечный продукт готов, сколько он строчек пишет в день и если даже скромные 100 то куда девается 90 потом (типа рефакторит одно по одному?). Свои цифры я взял со своего девелопмента и в какой-то степени это соотносится с девелопментом коллег. Причем не в конечном продукте, а ежедневно, так как если речь о конечном продукте, то там надо считать по какой-то методе, ессно этим заниматься не буду.
И собсно хотя и не поленился, но нифига не понял опять же почему 100 строчек это много? Да и в комментах ему пишут про 600 строчек в день, этим цифрам у меня больше веры.
> Была бы осмысленная задача, а код написать - это не проблема
Вообще без осмысленной задачи код писать действительно трудно. Но я бы уточнил, что во первых задачу надо осмыслить самому, во вторых владеть соответствующим инструментарием, тогда код написать действительно не проблема, а еще точнее - решаемая проблема
> И еще интересно - какие общие параметры Вашего проекта? Сколько человек в нем работает? Каков объем уже написанного кода? Сколько общая длительность (в чел-мес)?
В среднем человек 15 колбасят более 5 лет. Кода дофига.
не поспоришь
> Если Вы не поленитесь пойти по ссылке, то поймете, почему 100 строк в день рассматриваются как "много".
не поленился - прошел. Кто этот человек? Он пишет какие-то вполне с виду разумные вещи, но в основном про то сколько кода попадает в конечный продукт, типа 10 - 12 строчек в день, я хз как он это оценил, откуда он взял эти цифры и когда его конечный продукт готов, сколько он строчек пишет в день и если даже скромные 100 то куда девается 90 потом (типа рефакторит одно по одному?). Свои цифры я взял со своего девелопмента и в какой-то степени это соотносится с девелопментом коллег. Причем не в конечном продукте, а ежедневно, так как если речь о конечном продукте, то там надо считать по какой-то методе, ессно этим заниматься не буду.
И собсно хотя и не поленился, но нифига не понял опять же почему 100 строчек это много? Да и в комментах ему пишут про 600 строчек в день, этим цифрам у меня больше веры.
> Была бы осмысленная задача, а код написать - это не проблема
Вообще без осмысленной задачи код писать действительно трудно. Но я бы уточнил, что во первых задачу надо осмыслить самому, во вторых владеть соответствующим инструментарием, тогда код написать действительно не проблема, а еще точнее - решаемая проблема
> И еще интересно - какие общие параметры Вашего проекта? Сколько человек в нем работает? Каков объем уже написанного кода? Сколько общая длительность (в чел-мес)?
В среднем человек 15 колбасят более 5 лет. Кода дофига.
Я вообще не о том.Вот чуть ниже правильная мысль высказана:
Например, у меня была задача написать админку и вытащить веб-сервисы для управления парой-тройкой десятков сущностей (пользователи, роли, записи, заказы, счета и прочая муть). После того, как я потратил два дня на рутинную и монотонную работу "определить модель, написать сервис, подключить MVC-контроллер, сделать типовую CRUD-страницу в админке, потестировать" и закончил всего пять объектов, я обнаружил, что (а) мозг в отключке и постоянно хочется нажать ALT-TAB и пойти читать башорг, (б) 90% дефектов, возникающих по дороге - тупые опечатки и ошибки копипастинга. Вот это я называю "неосмысленный код". В результате я почесал репу и написал кодогенератор, которому можно скормить класс модели и он построит для него всё вышеперечисленное, за пару секунд и без тупых ошибок.
Вот чуть ниже правильная мысль высказана:скорость разработки же не находится в прямой корреляции со скоростью печатиПрекрасное определение "осмысленного кода"! Вот неосмысленный - это как раз тот, который находится в прямой корреляции со скоростью печати.
Например, у меня была задача написать админку и вытащить веб-сервисы для управления парой-тройкой десятков сущностей (пользователи, роли, записи, заказы, счета и прочая муть). После того, как я потратил два дня на рутинную и монотонную работу "определить модель, написать сервис, подключить MVC-контроллер, сделать типовую CRUD-страницу в админке, потестировать" и закончил всего пять объектов, я обнаружил, что (а) мозг в отключке и постоянно хочется нажать ALT-TAB и пойти читать башорг, (б) 90% дефектов, возникающих по дороге - тупые опечатки и ошибки копипастинга. Вот это я называю "неосмысленный код". В результате я почесал репу и написал кодогенератор, которому можно скормить класс модели и он построит для него всё вышеперечисленное, за пару секунд и без тупых ошибок.
> Я вообще не о том.Вот чуть ниже правильная мысль высказана:
> как же тогда измерять продуктивность рефакторинга, когда 1000 строк кода превращаются в 10
в -990
Понятно что количество строчек в день достаточно искуственный показатель продуктивности, тем более если суммировать за некий промежуток времени, можно уйти в ноль или даже в минус при каком-нибудь рефакторинге
Можно провести аналогию с танцемХороший и красивый танец не обязательно долгий и не измеряется количеством пройденного танцором пути, но разумное время должен занимать. Если танцор сделает очень красивые но всего 2 па и поклонится в ожидании аплодисментов, то ... не дождется :)) Так и программист должен работать а не тупить в мониторесли тормозит значит знаний не хватает, это вобщем нормально, но если такое постоянно то что-то тут не так.
Вот чуть ниже правильная мысль высказана:> как же тогда измерять продуктивность рефакторинга, когда 1000 строк кода превращаются в 10
в -990
Понятно что количество строчек в день достаточно искуственный показатель продуктивности, тем более если суммировать за некий промежуток времени, можно уйти в ноль или даже в минус при каком-нибудь рефакторинге
Можно провести аналогию с танцем
Хороший и красивый танец не обязательно долгий и не измеряется количеством пройденного танцором пути, но разумное время должен занимать. Если танцор сделает очень красивые но всего 2 па и поклонится в ожидании аплодисментов, то ... не дождется :)) Так и программист должен работать а не тупить в мониторесли тормозит значит знаний не хватает, это вобщем нормально, но если такое постоянно то что-то тут не так.да ну тебя, оценивать осмысленность кода это вообще задача едва ли не сложнее чем этот код написать, тем более если код чужойВ общем количественно осмысленные вещи наверное стоит считать в функиональных юнитах - скринах, сервисах и т.п. а придавать осмысленность строчкам безнадежное дело. Тем не менее механически работа программиста состоит в наборе текста, то бишь строчек. Поэтому сто в день мало!
В общем количественно осмысленные вещи наверное стоит считать в функиональных юнитах - скринах, сервисах и т.п. а придавать осмысленность строчкам безнадежное дело. Тем не менее механически работа программиста состоит в наборе текста, то бишь строчек. Поэтому сто в день мало!Дружище, Вы меня расстраиваете
Понятия не имею, кто этот человек, а ссылку я нашел за 3 сек поиском по Инету. Чем хорош его текст, так это тем, что имеется пруф-линк про 10-12 строчек в день. А этот пруфлинк ссылается на всем известную классическую книгу.
Однако вместо этого Вы сейчас "наколбасили" мне ответ размером в 112 слов, хотя было достаточно потратить 2 секунды, чтобы пойти по пруфлинку и еще 2 мин, чтобы прочитать, что там написано. Все Ваши вопросы тут же бы растворились.
Если Вы и Ваши 15 товарищей так же "колбасят" код, то ежедневные показатели в 300 строк совсем неудивительны
Так какие показатели для Вашего проекта по объёму кода?
Подскажу, как посчитать (ошибка будет не более чем в два раза в одну или другую сторону):
- выписываете весь проект,
- считаете общий объем исходников (в байтах),
- находите в проекте какой-нибудь большой файл (от 1000 до 10000 строк) и на нём оцениваете сколько символов в одной строке,
- зная это отношение, делите общий объем на оценку количества строк.
Получаются очень грубые цифры, но общее впечатление составить можно.
Да, я повторюсь: "локальная" скорость в 100, 300, 600 строк - это не такая уж большая цифра. Но на больших промежутках времени и с большой командой она обычно превращается в ничто.
P.S. Метрика оценки чего-либо по объему кода - очевидно ущербна. Думаю, здесь и спорить никто не будет
Понятия не имею, кто этот человек, а ссылку я нашел за 3 сек поиском по Инету. Чем хорош его текст, так это тем, что имеется пруф-линк про 10-12 строчек в день. А этот пруфлинк ссылается на всем известную классическую книгу.
Однако вместо этого Вы сейчас "наколбасили" мне ответ размером в 112 слов, хотя было достаточно потратить 2 секунды, чтобы пойти по пруфлинку и еще 2 мин, чтобы прочитать, что там написано. Все Ваши вопросы тут же бы растворились.
Если Вы и Ваши 15 товарищей так же "колбасят" код, то ежедневные показатели в 300 строк совсем неудивительны
Так какие показатели для Вашего проекта по объёму кода?
Подскажу, как посчитать (ошибка будет не более чем в два раза в одну или другую сторону
):- выписываете весь проект,
- считаете общий объем исходников (в байтах),
- находите в проекте какой-нибудь большой файл (от 1000 до 10000 строк) и на нём оцениваете сколько символов в одной строке,
- зная это отношение, делите общий объем на оценку количества строк.
Получаются очень грубые цифры, но общее впечатление составить можно.
Да, я повторюсь: "локальная" скорость в 100, 300, 600 строк - это не такая уж большая цифра. Но на больших промежутках времени и с большой командой она обычно превращается в ничто.
P.S. Метрика оценки чего-либо по объему кода - очевидно ущербна. Думаю, здесь и спорить никто не будет
и чего только люди не придумают, чтобы не использовать egrep + wc...
и да - UTF может быть больше одного байта
и да - UTF может быть больше одного байта
и чего только люди не придумают, чтобы не использовать egrep + wc...Не поверите вот так дедовским способом интегрально по байтам и оцениваем...
и да - UTF может быть больше одного байта
Как сами-то думаете - если сконвертировать программный код с английскими комментариями в UTF-8, то результат от оригинала будет сильно отличаться? Или имеем в рассмотрении код с захардкоженной локалью?
А я Фар пользую, в нём еще проще, чем грепать. Впрочем, это всё на вкус и цвет...
И да, насчет многобайтовых кодировок надо поправочный коэффициент вводить, согласен. Ну не маленькие ведь, можно догадаться
. Впрочем, это всё на вкус и цвет...И да, насчет многобайтовых кодировок надо поправочный коэффициент вводить, согласен. Ну не маленькие ведь, можно догадаться
Не поверите вот так дедовским способом интегрально по байтам и оцениваем...рукалицо.жыпег
Как сами-то думаете - если сконвертировать программный код с английскими комментариями в UTF-8, то результат от оригинала будет сильно отличаться? Или имеем в рассмотрении код с захардкоженной локалью?
Вы только что отказали в использовании своей методики для верстальщиков (в меньшей степени, да, но все же) и одноэсовцев...
правильный ответ - чуть выше =)
C:\>find ./ -name *.cpp | xargs egrep -v -e "^$|^[\s\t]*#" | wc -l
'xargs' is not recognized as an internal or external command,
operable program or batch file.
'xargs' is not recognized as an internal or external command,
operable program or batch file.
cygwin вам поможет
Строка - это строка.
Как ее посчитать - ответ дан.
Как оценивать результат - вопрос спорный, вот здесь, например, весьма интересно дается обзор метрик, которые чуть более объективно чем LOC могут оценить результат работы.
А всякий "интегральный подсчет" LOC-метрики настолько же отражает действительную производительность, как и "неинтегральный"
С моей точки зрения вообще это весьма эпическая метрика, сопоставимая с размером половых органов мужчин в сантиметрах, где только крайние значения имеют явно выведенный результат (слишком большой или слишком маленький ). Оценка остальных размером затруднена множеством особенностей и факторов
Как ее посчитать - ответ дан.
Как оценивать результат - вопрос спорный, вот здесь, например, весьма интересно дается обзор метрик, которые чуть более объективно чем LOC могут оценить результат работы.
А всякий "интегральный подсчет" LOC-метрики настолько же отражает действительную производительность, как и "неинтегральный"
С моей точки зрения вообще это весьма эпическая метрика, сопоставимая с размером половых органов мужчин в сантиметрах, где только крайние значения имеют явно выведенный результат (слишком большой или слишком маленький
). Оценка остальных размером затруднена множеством особенностей и факторов В этой постановке ответ тоже не-правильный. Почему не считаются пустые строки, строки из пробелов и табуляций? Ведь работник старался - писал пробелы, пальцы бил
На самом деле в быдлокодерско-конвейерной задаче, когда архитектура есть и всем понятно, как прописывать бизнес-правила, LoC очень даже хороший индикатор лени.
Для разработчика, согласен, нет нужды.
На самом деле в быдлокодерско-конвейерной задаче, когда архитектура есть и всем понятно, как прописывать бизнес-правила, LoC очень даже хороший индикатор лени.
Для разработчика, согласен, нет нужды.
Каюсь, тоже грешен (это я про "наколбасить").
Для такой хренотени как строки кода погрешность в 2 раза - самое то. Тем более эти "два раза" относятся к вопросам: считать комментарии или нет, пустые строки, где ставятся фигурные скобки...
Ну и скажите для своей подсистемы, неужели самому не любопытно ?
Чиста FYI: у меня перед глазами два проекта. В одном - 15 строк/день, в другом - 200 (посчитано с комментариями, пустыми строками). По общей длительности сравнимы (много больше 1 чел-года).
Для такой хренотени как строки кода погрешность в 2 раза - самое то
. Тем более эти "два раза" относятся к вопросам: считать комментарии или нет, пустые строки, где ставятся фигурные скобки...Ну и скажите для своей подсистемы, неужели самому не любопытно ?
Чиста FYI: у меня перед глазами два проекта. В одном - 15 строк/день, в другом - 200 (посчитано с комментариями, пустыми строками). По общей длительности сравнимы (много больше 1 чел-года).
Блин, посоны, может уже просто снимем штаны да померяемся?
Ну то есть где-то 50 строк/в день (это если считать по 30 символов в строке и 75 чел-лет).
Теперь ко мне окончательно пришло понимание, что я не знаю, как это всё интерпретировать и на кой хрен надо было выяснять.
Ну хоть развлеклись общением, сенкс
Теперь ко мне окончательно пришло понимание, что я не знаю, как это всё интерпретировать и на кой хрен надо было выяснять.
Ну хоть развлеклись общением, сенкс
Здесь он, здесь... просто прошлую тему зафлудили, и эту тоже. Я уж молчу, что прямые оскорбления не модерируются... но раз они есть - значит вопрос поднят верный.
Прежде чем меряться количеством говнокода, неплохо освоить такую книжечку как "Начала науки о прогаммах" 70-х годов прошлого веку. Там хотя бы, эти вопросы разбирались на нормальном объеме материала и различных языках, вплоть до Ассемблера... и вывод там банален: итоговая скорость разработки зависит не столько от инструментария/языка, сколько от "соображаловки" = "количество элементарных различений в секунду".
"мозг на 80% состоит из жидкости. Мало того, что, недоливают, так у некоторых она ещё и тормозная".
А тот вопль (а по-другому назвать нельзя), который раздался по поводу "бардака и разгильдяйства" поначалу - комментировать особо незачем. Потому что, как известно, кричит в первую очередь тот, у которого его больше. А то что (хуже/лучше), оно примерно так и практически везде - факт а не реклама. И это нормально. Потому что "идеально" отстроить не удается никогда. Пока отстраиваешь - жизнь меняется... в этом смысле ваше:
"Это верно для любого раздолбайства, проистекающего из неумения организовать рабочий процесс"
тоже верно для организации любого процесса. Вопрос в количественном присутсвии этого самого "раздолбайства". Но нулевым - оно бывает только у остановленного процесса. Это всё равно как требовать полного, идеального соблюдения ПДД на дорогах.
Правильно подумалось. Внутрикорпоративное ПО - не нужно никому, кроме этого самого бизнеса. И его задачи проистекают от потребностей того самого бизнесу. И ниоткуда больше. Собственно также, как и процесс вытачивания детальки... нужна бизнесу - он даст денег на работу по вытачиванию...
... в вашем примере ниже - всё правильно. ...когда начальник отдела ТАК говорит. Но вот когда он говорит "Я завтра (через неделю) привезу 150 ведер для нашей уборщицы" (которые бизнесу никуда не упали), а ещё если и вместо выполнения ЗАДАНИЯ по станку... результат = "капитан очевидность". Ну и кто "главный" бизнес или начальник отдела логистики?
Это утрированный пример между разработкой по заданию бизнеса и разработкой сферических вакуумных коней. А классический говнокод можно сопоставить с доставкой станка вовремя (а то и с задержкой), но в таком состоянии, которое исключает его нормальное применение... или сильно осложняет.
Тут проблема в "качестве приемки"... к сожалению в части ИТ - начальник начальника ИТ отдела - уже не специалист в ИТ и оценить правильность решения и его полезность (особенно отдаленную) - практически не в состоянии в 99% случаев.
Работает? ТЗ соответствует? Какие проблемы... а то что оно "соответствует" поверхностно и при первом же боевом применении валится (хуже когда при третьем)...
... такое возражение не зависит от направления поддержки бизнеса (логистика или софт), оно зависит от характера начальника соответствующего отдела. Ровно настолько, насколько он готов отвечать за принятые решения внутри отдела. Директоров логистики (и других направлений), которые прогибаются и берутся решать нерешаемые задачи - полно и их доля одинакова, независимо от направления отдела.
По себе, вот почему-то никогда не боялся так говорить... собственно работа на Гордона после этого и закончилась...
Прежде чем меряться количеством говнокода, неплохо освоить такую книжечку как "Начала науки о прогаммах" 70-х годов прошлого веку. Там хотя бы, эти вопросы разбирались на нормальном объеме материала и различных языках, вплоть до Ассемблера... и вывод там банален: итоговая скорость разработки зависит не столько от инструментария/языка, сколько от "соображаловки" = "количество элементарных различений в секунду".
"мозг на 80% состоит из жидкости. Мало того, что, недоливают, так у некоторых она ещё и тормозная".
А тот вопль (а по-другому назвать нельзя), который раздался по поводу "бардака и разгильдяйства" поначалу - комментировать особо незачем. Потому что, как известно, кричит в первую очередь тот, у которого его больше. А то что (хуже/лучше), оно примерно так и практически везде - факт а не реклама. И это нормально. Потому что "идеально" отстроить не удается никогда. Пока отстраиваешь - жизнь меняется... в этом смысле ваше:
"Это верно для любого раздолбайства, проистекающего из неумения организовать рабочий процесс"
тоже верно для организации любого процесса. Вопрос в количественном присутсвии этого самого "раздолбайства". Но нулевым - оно бывает только у остановленного процесса. Это всё равно как требовать полного, идеального соблюдения ПДД на дорогах.
Правильно подумалось. Внутрикорпоративное ПО - не нужно никому, кроме этого самого бизнеса. И его задачи проистекают от потребностей того самого бизнесу. И ниоткуда больше. Собственно также, как и процесс вытачивания детальки... нужна бизнесу - он даст денег на работу по вытачиванию...
... в вашем примере ниже - всё правильно. ...когда начальник отдела ТАК говорит. Но вот когда он говорит "Я завтра (через неделю) привезу 150 ведер для нашей уборщицы" (которые бизнесу никуда не упали), а ещё если и вместо выполнения ЗАДАНИЯ по станку... результат = "капитан очевидность". Ну и кто "главный" бизнес или начальник отдела логистики?
Это утрированный пример между разработкой по заданию бизнеса и разработкой сферических вакуумных коней. А классический говнокод можно сопоставить с доставкой станка вовремя (а то и с задержкой), но в таком состоянии, которое исключает его нормальное применение... или сильно осложняет.
Тут проблема в "качестве приемки"... к сожалению в части ИТ - начальник начальника ИТ отдела - уже не специалист в ИТ и оценить правильность решения и его полезность (особенно отдаленную) - практически не в состоянии в 99% случаев.
Работает? ТЗ соответствует? Какие проблемы... а то что оно "соответствует" поверхностно и при первом же боевом применении валится (хуже когда при третьем)...
... такое возражение не зависит от направления поддержки бизнеса (логистика или софт), оно зависит от характера начальника соответствующего отдела. Ровно настолько, насколько он готов отвечать за принятые решения внутри отдела. Директоров логистики (и других направлений), которые прогибаются и берутся решать нерешаемые задачи - полно и их доля одинакова, независимо от направления отдела.
По себе, вот почему-то никогда не боялся так говорить... собственно работа на Гордона после этого и закончилась...
меня спросили - я ответил. Количество кода и размер проекта это в каком то смысле можно считать "секси", но в общем то цимус не в размерекому что нравится на самом деле. Я так понимаю просто зашла речь о количестве строчек в день и разговор сразу свелся к тому что и кто понимает под этим. И не надо другим приписывать несуществующие комплексы
кому что нравится на самом деле. Я так понимаю просто зашла речь о количестве строчек в день и разговор сразу свелся к тому что и кто понимает под этим. И не надо другим приписывать несуществующие комплексыэто только одна подсистема, хотя и наверное самая большая. И безо всякого xml, пропертей и прочей сопутствующей кухни их то надо учитывать и как? Так что можно умножать на 3 (приборы?) Опять же среднее количество человек такое среднееЯ не могу сказать точно кто и сколько работал фул тайм и вообще 15 хм, не знаю - это просто навскидку.
Короче разбег может быть запросто от 3х до 5 раз
Я не могу сказать точно кто и сколько работал фул тайм и вообще 15 хм, не знаю - это просто навскидку.Короче разбег может быть запросто от 3х до 5 раз
Очевидно, эта проблема волнует их не так сильно. Только и всего.
Истины, "кто же такой программист", нет и быть не может. Потому как разным компаниям нужны разные программисты. Если это крупная "околобанковская" контора с давно устоявшимися бизнес-процессами, то ей скорее подойдёт крепкий профи, работающий исключительно по ТЗ, и полностью подчиняющийся тимлиду.
А если же это - игровой стартап, то вот им скорее нужен "и швец, и жнец, и на дуде игрец". При этом, его профессиональный уровень может быть ничуть не ниже, чем у первого работника.
P.S. 100 строчек кода в день - действительно маловато, на мой взгляд (хоть и не сильно). Не, если человек программирует однокристаллки на чистом C - тогда да, даже сотня будет являться прорывом. А если он клепает GUI-формочки на C#, тогда и 400-500 строк в день не будут являться чем-то огромным. Главное, чтобы сроки не срывались
Истины, "кто же такой программист", нет и быть не может. Потому как разным компаниям нужны разные программисты. Если это крупная "околобанковская" контора с давно устоявшимися бизнес-процессами, то ей скорее подойдёт крепкий профи, работающий исключительно по ТЗ, и полностью подчиняющийся тимлиду.
А если же это - игровой стартап, то вот им скорее нужен "и швец, и жнец, и на дуде игрец". При этом, его профессиональный уровень может быть ничуть не ниже, чем у первого работника.
P.S. 100 строчек кода в день - действительно маловато, на мой взгляд (хоть и не сильно). Не, если человек программирует однокристаллки на чистом C - тогда да, даже сотня будет являться прорывом. А если он клепает GUI-формочки на C#, тогда и 400-500 строк в день не будут являться чем-то огромным. Главное, чтобы сроки не срывались