Где и как лучше учиться программированию?

[KaraNagai]

А если так. ...Анимал; Анимал->Хуман->Персон; Анимал->ДоместицАнимал->Пиггы;

мсье отрицает наличиие персоналити у свиней? )

да, можно хоть всю биологическую таксономию построить, но зачем?

Ну в этом случае надо Яву машину запустить, а в другом батч фаил (с линковшиком и запуском)... короче.

ну можно конечно и так на это смотреть, но все же объектные файлы редко деплоятся, в отличие от джаров и т.п...

а насчет "короче" я обязательно проверю. если удастся - сегодня.

Кхммм... Мы вроде не собирались модель мира описывать.

Обычно до модели мира слава богу не доходит Но как бы типичная ситуация: "а давайте вот это погибче/поуниверсальнее сделаем, а то мало ли потом..."... А в результате настает это "потом" и оказывается, что эта гибкость/универсальность никак к реальной ситуации не применима.

Вот Ludwig хороший пример привел: человек сначала делал неуниверсальные бухгалтерские системы, маялся с конфигурацией под конкретного заказчика. Маялся-маялся и понял какого рода универсальность ему нужна. И сделал. И заработало. А если бы он принялся за это в процессе разработки системы под первого заказчика, то к тому моменту, когда он на самом деле бы понял, какая универсальность ему нужна, он бы имел дело с гораздо более сложной проблемой + собственным психологическим барьером, кстати.

Что значит пойдет переписывать, кто ему позволит? Анархия! А почему такой код был написан с самого начала? Кто позволил? Менеджера и лид. программера в шею!

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

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

Сейчас Людвигу еще отвечу

KaraNagai добавил 20.06.2007 в 06:19
Людвигу:

хехехе прекрасно! Ты думаешь я случайно предложил именно класс сделать, а не функцию? Знал ведь что ты на это обратишь внимание )

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

А теперь учти еще, что если ты делал функцию там или класс, значит собираешься пользоваться ей скорее всего больше чем в одном месте. Так что умножь размер вышеописанного вызывающего кода скажем на 5.

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

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

Ты как-то говорил о множественном наследовании. Я это часто слышу от джавистов, мол в Си++ было много лишнего

Прошу учесть здесь, что меня джавистом можно назвать с большой натяжкой. На джаве у меня было всего три проекта плюс проекты по ресечу. И все - лишь в последние 5-6 лет.

Проблема не в том, что это "плохие" парадигмы, а в том, что они не всем по зубам.

"Не всем по зубам" значит проекты дороже а) потому что труднее подобрать кадры и они стоят дороже и б) потому что передача понимания кода от человека к человеку труднее.

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

А вот скажи, почему в С++ нельзя менять код из кода в процессе исполнения как в лиспе, а? ) А я тебе отвечу: потому что это ненеобходимо, а при использовании создает сложный трудно отлаживаемый код. И "не всем по зубам".

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

качество кода упало

Come on, качество кода упало. Да всегда 99% людей писали неэффективный и неаккуратный код. И главное никогда это никого особенно не волновало, кроме отдельных задач , где без этой эффективности нельзя выжить (ну и отдельных перфекционистов, разумеется )

а затраты на разработку в итоге поднялись

Это ты на каком основании утверждаешь? По мне так кодирование аналогичной функциональности сейчас достигается заметно быстрее и дешевле, чем раньше в бизнес-приложениях. Другое дело, что все одно собственно кодирование составляет меньшую часть стоимости разработки.

[TYA]

Сообщение от KaraNagai

мсье отрицает наличиие персоналити у свиней?

Персон неудачное название класса... за исключением, что и среди людей бывают "свиньи", и продавец торгуем именно ими.

Сообщение от KaraNagai

ну можно конечно и так на это смотреть, но все же объектные файлы редко деплоятся, в отличие от джаров и т.п...

Кара, причем сдесь деплоятся или нет. Речь шла об исполняемом коде... .класс или .жар являются псевдо-исполняемыми (Ява байткод).

Сообщение от KaraNagai

Обычно до модели мира слава богу не доходит Но как бы типичная ситуация: "а давайте вот это погибче/поуниверсальнее сделаем, а то мало ли потом..."... А в результате настает это "потом" и оказывается, что эта гибкость/универсальность никак к реальной ситуации не применима.

Это кто говорит, это у кого типичная ситуация? Есть требования к программе и задача программиста четко определить границы решения, что ешье? Все должно быть обосновано и согласовано с менеджером и заказчиком. И "мало ли потом..." говорит о не ясности цели и/или отсутствии тех. знаний.

Сообщение от KaraNagai

Вот Лудwиг хороший пример привел: человек сначала делал неуниверсальные бухгалтерские системы...

Этот человек не имел экспертизы в этой области. После ее приобретения, он понял что да как. Ему следовало бух. учет и микро экономику поучить (или чего там еше), либо эксперта нанять... Он пошел другим путем...

Сообщение от KaraNagai

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

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

Сообщение от KaraNagai

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

Не понял, квадратное уравнение решается по частям (для каждого действия отдельная функция), или одним разом? Кара, недостойно уважаемого джентельмена вводить правила по ходу действия, и тыкать этим в оппонента.

Сообщение от KaraNagai

А теперь учти еще, что если ты делал функцию там или класс, значит собираешься пользоваться ей скорее всего больше чем в одном месте. Так что умножь размер вышеописанного вызывающего кода скажем на 5.

Почему? Функция же в одном экземпляре? Это же некопи/пэйст, конечно если ты сейчас не скажесь, что функция/функции на самом деле инлайн.

Сообщение от KaraNagai

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

Ну слава Богу, а то я ж было подумал ты мыслишь так же, как сегодняшний свеже-ипеченный программист.
Меня по-крайней мере этому научили уже не первом курсе универа, да и в школе на уроках ЭВМ молодая красивая учительница не раз заставляла переписывать программу... А мы все не понимали в чем разница.

Сообщение от KaraNagai

б) потому что передача понимания кода от человека к человеку труднее.

Это не правило, а исключение, когда отсутствует тех. спек и/или у обучаемого не хватает тех. знаний.

[KaraNagai]

Кара, причем сдесь деплоятся или нет. Речь шла об исполняемом коде... .класс или .жар являются псевдо-исполняемыми (Ява байткод).

Как причем? Размер результирующей софтины - это размер того, что деплоится.

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

Это - типичная ситуация в очень многих местах. Что значит "все должно быть согласовано"... что-то должно быть согласовано, а что-то нет. Заказчику интересно, чтобы софтина отвечала требованиям (даже не функциональной спеке, а именно требованиям). Внутренние делатил реализации заказчик не всегда может того... comprehend.... равно как и внутренний нетехнический специалист. Стало быть так или иначе есть технический специалист принимающий решения на том или ином уровне. Если это что-то глобальное - это архитект, если какие-то детали реализации - просто программер. Или ты каждую строчку своего кода с менеджером согласовываешь?

И "мало ли потом..." говорит о не ясности цели и/или отсутствии тех. знаний.

Это говорит о стремлении решить будущие проблемы до их возникновения.

Этот человек не имел экспертизы в этой области. После ее приобретения, он понял что да как. Ему следовало бух. учет и микро экономику поучить (или чего там еше), либо эксперта нанять... Он пошел другим путем...

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

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

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

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

Не понял, квадратное уравнение решается по частям (для каждого действия отдельная функция), или одним разом? Кара, недостойно уважаемого джентельмена вводить правила по ходу действия, и тыкать этим в оппонента.

Квадратное уравнение решается одним вызовом. А требования ему я дал на вполне типичном уровне требований заказчика, по-моему.

Почему? Функция же в одном экземпляре? Это же некопи/пэйст, конечно если ты сейчас не скажесь, что функция/функции на самом деле инлайн.

Функция-то в одном, а вот вызов ее может быть в нескольких. В самых разных flavours. Просто вот гляди какая логика:

1. Один из основных резонов выделять куски кода в отдельные сущности состоит в том, что одинаковая функциональность требуется в нескольких местах.

2. Следовательно каждый байтик кода нашей сущности стоит в несколько раз "дешевле" каждого байтика ее вызова.

3. То есть если мы можем перенести часть сложности или вербозности вызова внутрь сущности - это надо непременно сделать (unless против этого есть какие-то другие аргументы, например порядка производительности или потребления памяти).

Это не правило, а исключение, когда отсутствует тех. спек и/или у обучаемого не хватает тех. знаний.

Что значит "исключение"? Даже если есть техспех и у всех хватает знаний, логически более сложный код будет требовать большего времени на понимание.

[Ludwig]

Kara:
Насчет дороговизны посредственного программирования я уже привел пример с Cisco NetFlow Collector-ом. Кстати уже и Adobe не отстает: Acrobat Reader превратился в такого монстра, что страшно его ставить. Бинарник такого объема мог бы управлять всеми спутниками на орбите одновременно. И не мудрено, что он такой багги - слетает, виснет, итд. и в кажой новой версии все хуже и хуже. А что в нем принципиально нового по сравнению со старой доброй версией 5? Ни-че-го. Ах да, он написан наверное на Си++, но не суть. Несложно прикинуть сколько народу работает над этим Акробатом, сколько народу тестирует, исправляет ошибки, итд. Акробат стал страшно дорого обходиться Адобу по одной лишь причине: посредственное программирование.

При этом существуют некоммерческие аналоги Акробата, сделанные одним человеком в свободное от работы время.

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

Есть такой Windows Registry, и у него есть API. Задача была, надо понимать, создать иерархическую штуку, в которой можно хранить некие параметры. К каждому параметру есть путь по дереву. Поскольку параметры могут быть очень маленькие, то хранить их в отдельных файлах как-то не хочется - были бы большие накладные расходы.

Так родился этот шедевр - Windows Registry, API которого состоит наверное из 50 функций, и каждая берет по 10-15 аргументов. Ну хорошо, я преувеличиваю, но что-то около того, загляните в доки Никто не станет спорить, что чтение документации, в которой каждый из аргументов каждой из функций объясняется в 5-30 строк текста - это просто самоубийство.

Сегодня как раз думал как можно было бы сделать похожую штуку в духе юниксоидного минимализма. Есть идеи? У меня есть, и это поможет понять как девелоперы Майкрософта, которые поленились немного пораскинуть мозгами, косвенно отняли уйму времени у других девелоперов и породили столько лишнего кода в Windows-приложениях. Это тоже к слову о дороговизне.

(А про универсальный суперджавакласс для решения квадратных уравнений - это к студентам, Kara )

[KaraNagai]

Насчет акробата... формат растет, Ludwig. И я почти уверен, что сам по себе ридер мало обходится. Обходится Акробат, Дистиллер и связанные с ним продукты. Там наверняка очень много общего кода.

А насчет аналогов - ну давай выкладывай линк на аналог. А я для них документов в индизайне погенерю и проверю. Сравним размер, сравним совместимость с форматами и так далее и тому подобное.

Так родился этот шедевр - Windows Registry, API которого состоит наверное из 50 функций, и каждая берет по 10-15 аргументов.

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

Кстати, буде API для работы с реджистри изначально ОО, с ним бы было удобнее работать.

Кстати, ты про линукс вот говоришь, а API какого-нибудь VFS под линуксом - эт те тоже не фунт изюма, особенно структуры.

Знаешь как просто стучаться к иерархическим структурам - сделай компактный API для файловой системы для начала

А про универсальный суперджавакласс для решения квадратных уравнений - это к студентам, Kara

Конечно-конечно, суперпрограммистам нашим это не пристало, они все больше API для работы с реджистри пишут ) На лиспе, я надеюсь?

Я тебе дал тривиальный пример чтобы ты показал мне преимущества С++ в локаничности и одновременно продемонстировал что по-твоему значит компактность. Ты отказался. Низачотъ те стало быть.

Людвиг, вот слушай, расскажи че ты по работе делаешь. Мне интересно откуда у тебя эта лебединая песнь перфекциониста родилась?

Вот Юра (TYA) он хоть мне и противоречит, но вроде как в тему все вещает, а ты...

[TYA]

Сообщение от KaraNagai

Как причем? Размер результирующей софтины - это размер того, что деплоится.

Давай рассматривать в целом, а не по кускам. Как же .класс поедет без Ява машины?
С одной стороны предоставляется исполняемый код, а с другой стороны Ява байткод, и с чем его пользователь будет есть?

Сообщение от KaraNagai

Это - типичная ситуация в очень многих местах.

Короче, я работал в одной компании, все было путем пока генеральный менеджер не ушел, а на его место пришел и привел с собой команду полных бездарностей... после этого из 20 человек инженеров, там осталось работать 3 и то только потому, что менеджемент "встрепенулся" и больше не принимает решения без согласования с инженерами. Я не припомню другого такого случая за всю мою историю работы в разных компаниях, и, я считаю, что такой подход не является для профессионального программиста типичным. Компания поменяла вид бизнеса, и сейчас занимается продажей того, что было сделано 5-8 лет назад, то что было сделано за последние пару-тройку лет мало кого интересует - качество не то, клиенты потихоньку уходят.
И никто меня не убедит, что нельзя уточнить требования и невозможно согласовать всю функциональность с клиентом до того как написана детальная тех. спецификация. Запрограмировать это уже как правило дело техники.

Сообщение от KaraNagai

... Или ты каждую строчку своего кода с менеджером согласовываешь?

Каждую, и не с менеджером, а с коллегой перед тем как код публикуется.

Сообщение от KaraNagai

Это говорит о стремлении решить будущие проблемы до их возникновения.

Только если не просто "мало ли", а дается четкое описание потенциальной проблемы, и если необходимо проводится исследование.

Сообщение от KaraNagai

Ты, видимо, не понимаешь что я хочу сказать...

Понимаю, сначала были задачи... потом появилась идея, кот. основывалась на полученном опыте. Ничего ногового.

Сообщение от KaraNagai

Вот странно что ты не понимаешь. Свобода как раз на депендабл программерах и строится. На людях умеющих взвешанные решения принимать и ответственно их исполнять самостоятельно работая в минимально необходимом фреймворке, и не уходя в штопор перфекционизма.

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

Сообщение от KaraNagai

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

А качество и имя ешье дороже.

Сообщение от KaraNagai

2. Следовательно каждый байтик кода нашей сущности стоит в несколько раз "дешевле" каждого байтика ее вызова.
3. То есть если мы можем перенести часть сложности или вербозности вызова внутрь сущности - это надо непременно сделать (унлесс против этого есть какие-то другие аргументы, например порядка производительности или потребления памяти).

2 - не понял, 3 - зависит от языка, но в целом верно.

Сообщение от KaraNagai

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

Никто не сомневается, я надеюсь. Но это имеет лишь косвенное отношение к стоимости проекта из-за текучки кадров.
Кстати, что кому-то "не по зубам" - я полностью согласен, и появился целый лагерь Ява программистов (и уменьшился лагерь С++ программистов), а "более высокая стоимость проекта" - не согласен..., за исключением если руки не оттуда растут (на то разные процессы разработки программ и придуманы - что бы сократить расходы и как можно меньше было риска, связанного с человеческим фактором). Дотком народ видать расслабил.

[KaraNagai]

Давай рассматривать в целом, а не по кускам. Как же .класс поедет без Ява машины?

ну может тогда еще операционку посчитаем? )

И никто меня не убедит, что нельзя уточнить требования и невозможно согласовать всю функциональность с клиентом до того как написана детальная тех. спецификация. Запрограмировать это уже как правило дело техники.

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

Каждую, и не с менеджером, а с коллегой перед тем как код публикуется.

Ну что ж тебе повезло значит
Скажи мне прямо смотря в глаза, что всю твою трудовую карьеру так и было ) Или хотя бы что всю твою тродвую карьеру это можно было бы внедрить в любой момент без увеличения стоимости проекта. Ась?

Только если не просто "мало ли", а дается четкое описание потенциальной проблемы, и если необходимо проводится исследование.

То есть в узде держутся неуемные рационализаторы по-любому. Как полиси. Это ж ведь не зря, да?

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

Не "делают, что им скажут", а "решают поставленные перед ними задачи". Две большие разницы. Я не против рацушек и т.п., я против того, чтобы рацушки делалис втихую и только по причине перфекционизма (или мнимой гениальности) исполнителя.

А качество и имя ешье дороже.

Ущерб качеству и/или имени в каждом кокретном случае можно оценить. Он может быть как больше стоимости тотального код ревью, так и меньше.

Но это имеет лишь косвенное отношение к стоимости проекта из-за текучки кадров.

Ну кадры они вообще имеют свойство течь. Кроме текучки есть еще внутренние пертрубации и т.п... Влияет это на стоимость, влияет.
Человеку в кухню софтовой конторы нормально въехать обычно надо 3-6 месяцев имхо. А средний срок работы человека на одной позиции в айти (статистика по штатам, правда) - 9-10 месяцев.

[Ludwig]

Kara:
Пример с квадратным уравнением насколько прост, что не покажет различия между С++ и Джавой, но зато покажет различия в подходах.

Ты хочешь вычислять в два этапа - дискриминант, а потом корни? Прекрасно. Извеснтый drawback ОО состоит в том, что каждый метод должен проверять состояние объекта, прежде чем делать свое дело. Например, метод вычисления корней должен проверить был ли уже вычислен дискриминант, и если нет, то в духе Джавы надо выкинуть исключение (и тем самым заставить пользователя обработать его).

С двумя же функциями все просто: вторая принимает в качестве параметра дискриминант. Не только сами функции будут проще, но и пользовательский код тоже - подозреваю, что он запишется в одну строку.

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

И не поленись, распиши свой суперкласс, и сравним с функциональным вариантом.

Теперь о Regisrty. Во-первых я посчитал, там 32 функции, только 2 или 3 - легаси, а остальное так или иначе может пригодиться. Не зря они там, не зря.

Но не дожидаясь от тебя конструктивного ответа (которого и так не дождался бы ), вот тебе юниксоидное решение.

Представь себе, что в системе есть некий UNIX Registry. Ты открываешь его документацию, и падаешь со стула: вместо сотен страниц там всего один абзац примерно такого содержания:

"UNIX Registry - это специальная файловая система, которая маунтируется под /var/reg и которая оптимизирована для работы с очень маленькими файлами. Приложения могут хранить в UR свои конфигурационные параметры, причем для простоты в одном файле может храниться один параметр, например число или строка. Каждое приложение создет свое поддерево конфиг. параметров под /var/reg/vendor/application/...".

Вот и всё. Секюрити и права доступа - как с файлами в UNIX. Удаленный доступ - NFS. Плюс бэкап можно делать легко с помощью tar (в Windows небось надо будет писать спец утилиту для бэкапа поддеревьев, верно?). Плюс в UNIX Registry работают все стандартные утилиты юниксовского юзерленда и сам sh.

И наконец, для доступа к UR не нужен никакой спец API. Можешь использовать stdio и dirent, которым уже почти 40 лет от роду То есть не надо учить ничего нового.

Это всё - вместо десятков функций с десятками параметров каждая и плюс сотнями страниц документации. В Windows все сделано в этом духе, к сожалению. Почти все API перенятые из OS/2 (привет, IBM!) и также разработанные позже самим Майкрософтом раздуты аналогичным образом.

Не важно чем я сейчас занят, но одно могу сказать: сильно сожелею, что вернулся в мир Windows. После UNIX - это настоящий pain in the ass. Мне показывают программу в 6000 (шесть тысяч) строк на Си++, которая делает то, что под UNIX сделал бы небольшой скрипт в 10 строк. О количестве ошибок я не говорю - оно сравнимо с количеством строк кода. Это все очень печально на самом деле, может поэтому я сейчас все так эмоционально воспринимаю

Ludwig добавил 20.06.2007 в 19:08
Хотелось что-нибудь процитировать из авторитетов, но вот эта статья почти вся - отличная цитата о Джаве:
http://www.paulgraham.com/javacover.html

[TYA]

Сообщение от KaraNagai

ну может тогда еще операционку посчитаем?

Не рекомендую. А вот исполняемый код сгенерить и сравнить можно, если ты еше хочешь опровергнуть мои сомнения.

Сообщение от KaraNagai

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

Короче, пусть возникают, лижь бы не выходили за рамки спека. К слову о код ревью, такие очаги гаснут еше в чреве, разными способами...
О стоимости проекта, я могу сказать, что время занимаемое на проверку ничтожно мало по сравнению со временем занимаемое на вылавливание ошибок тобой же (когда тебе же не у кого спросить, чего ты там мог намудрить), а уж тем более твоим коллегой (когда ты болен, или в отпуске, или исправляешь ошибки в другом месте) без код ревью.
У меня складывается такое впечатление, что код ревью у тебя вызывает некий испуг, неужели все так плохо? Сомневаюсь. Или еше хуже, ты думаешь о код ревью, как о ревью тысяч строк кода?
Глядишь тогда никто в тихомолку не будет лепить заплаты, прячась от начальства. Проше надо быть и люди к тебе потянутся.
Индийцы от нас сначала долго бегали с сырцами, а когда "к стенке прижали" - поняли, что ничего страшного в этом нет и даже очень полезно - проше и дешевле исправлять грубые ошибки на этапе разработки, чем на стадии тест.лаборатории когда порой уже и не помнишь чего там нарисовано, или еше хуже - оно везде такое красивое.
Текучка в 9-10 месяцев, может говорить лишь о том, что основная масса - контрактники, нанимаемые только на один-два проекта. Про перманент позиции сильно сомневаюсь.

[Inferno]

Спасибо за статью,Людвиг!Хоть я сам и не программист,но было интересно почитать.А ты сама на Яве программируешь?

[Ludwig]

Сообщение от Inferno

Спасибо за статью,Людвиг!Хоть я сам и не программист,но было интересно почитать.А ты сама на Яве программируешь?

Не сама, а сам

Нет. Честно говоря меня тоже всегда отталкивали вещи, за которыми стоят монстрозные компании. Хороший шанс был у C#, ведь такого парня наняли - Андерса Хейльберга (Turbo Pascal, Delphi), а в итоге оказалось, что чудес не бывает - Майкрософт есть Майкрософт. В итоге:

if (System.Text.RegularExpressions.Regex.IsMatch(s, sPattern, System.Text.RegularExpressions.RegexOptions.Ignore Case)) ...

(это из MSDN. Знаю, что можно записать чуть короче, но суть не меняется, и потом это MSDN, который читают начинающие программисты)

[Ellen]

Сообщение от Ludwig

if (System.Text.RegularExpressions.Regex.IsMatch(s, sPattern, System.Text.RegularExpressions.RegexOptions.Ignore Case)) ...

(это из MSDN. Знаю, что можно записать чуть короче, но суть не меняется,

а почему суть не меняется?
это действительно можно записать короче, и тогда все нормально выглядит.
using System.Text.RegularExpressions;
....
Regex.IsMatch(s, sPattern, RegexOptions.IgnoreCase))

Сообщение от Ludwig

и потом это MSDN, который читают начинающие программисты)

а продвинутые программисты, надо полагать, все наизусть помнят и MSDN не читают?

[Ludwig]

Сообщение от Ellen

а продвинутые программисты, надо полагать, все наизусть помнят и MSDN не читают?

Нет, я не в этом смысле Хотел сказать, что MS изначально учит писать длинно.

[Inferno]

Очепяточка вышла

[KaraNagai]

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

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

И таки да, он стоит денег. Вдумчивое ревью 100% написанного кода требует столько же время, сколько его написание.

Кстати, у тебя коллега репорт пишет в ходе своего ревью?
Что-то мне подсказывает, что у тебя там не процедура код ревью, а просто твой код доступен коллеге и он на него поглядывает. Без всяких обязательств.

У меня складывается такое впечатление, что код ревью у тебя вызывает некий испуг, неужели все так плохо?

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

Или еше хуже, ты думаешь о код ревью, как о ревью тысяч строк кода?

Так или иначе получается ревью тысяч строк кода. Ты можешь его размазать по каждому рабочему дню или делать скажем как регулярную процедуру. Но в год нужно ревьювить столько, сколько написано. За каждым разработчиком.

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

Для этого вполне достаточно выборочного ревью. Достаточно знать, что твой осознанный ляп _могут_ найти, чтобы его не делать.

Текучка в 9-10 месяцев, может говорить лишь о том, что основная масса - контрактники, нанимаемые только на один-два проекта. Про перманент позиции сильно сомневаюсь.

А какая разница? В среднем такая ситуация в любом случае. Ну ок, по перманентным позициям пусть будет 2 года. Уж раз в два года много народа и перманентую работу меняют. Это значит, что 10-20% времени у тебя сотрудники находятся в процессе въезжания в тему.

KaraNagai добавил 21.06.2007 в 08:47

Пример с квадратным уравнением насколько прост, что не покажет различия между С++ и Джавой, но зато покажет различия в подходах.

Он показывает разницу в подходах между тобой и мной, а не между С++ и джавой. На джаве тоже можно лепить API из функций. Они там имеют место быть даже в стандартных либах.

Ок. Ну покажи мне плиз пример достаточный для сравнения размера исходного кода.

Ты хочешь вычислять в два этапа - дискриминант, а потом корни?

Избави бог! Я хочу чтобы была возможность дать доступ к значению дискрименанта если это понадобится. И была возможность иметь такой доступ (равно как и доступ к корням и коэффициентам) из мест в коде отличных от места, в котором произошел собственно вызов.

Извеснтый drawback ОО состоит в том, что каждый метод должен проверять состояние объекта, прежде чем делать свое дело.

В данном случае на этапе извлечения корней, дискрименанта, коэффициентов и т.п. в месте, отличном от места вызова, состояние проверять не грех, да. Состояние объекта - неплохой индикатор состояния задачи вцелом. Ничего плохого в этом не вижу.

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

Там же где состояния тебе будут только мешаться нужно писать стейтлесс код.

Насчет реджистри - fair enough. Можно так. Правда API в результате будет не меньше, а больше. И реализация потребуется бОльшего размера. Но зато API будет знаком каждому. Такие вещи как считать DWORD значение из ключа будут делаться большим кодом. Будут также всякие излишества, совершенно ненужные типа позиционирования внутри значений и форматного вывода... И так далее и тому подобное. Короче, решение как решение. Сковывает тебя текущей концепцией файловой системы. В принципе жить можно с таким решением. Как и с текущим.

Не важно чем я сейчас занят,

Конечно же важно. Чем занят и чем занимался до того. Потому что то, что ты можешь считать способом мышления производным от С++ может оказаться способом мышления производным от твоих задач.