Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 134
Какие-то они все у вас мудаки получились.
Ну не у меня, всё-таки, это же перевод.
Я видел много программистов. Вот эти гуру думающие рекурсивными комбинаторами и спящие с Art of Metaobject Protocol под подушкой — это стереотип. Чтобы получить представление, как работают хорошие программисты и о чем они думают очень советую книжку Coders at Work. На русском её пока нет к сожалению.
Новички — новички перегибают палку. По-разному. Слишком много оптимизируют, абстрагируют, защищаются от ошибок. Или наоборот, вообще не делают этого. Главное для новичка не запутывать себя принципами «правильного» программирования, не слушать бездумно знатоков, нужно самому разбираться и делать выводы, что работает, а что нет. Я вижу как люди начинают городить абстракции, запутываются. Они и видят что это не работает, но не могут себе признаться в этом. Их научили как «правильно», и все тут.
Новички — новички перегибают палку. По-разному. Слишком много оптимизируют, абстрагируют, защищаются от ошибок. Или наоборот, вообще не делают этого. Главное для новичка не запутывать себя принципами «правильного» программирования, не слушать бездумно знатоков, нужно самому разбираться и делать выводы, что работает, а что нет. Я вижу как люди начинают городить абстракции, запутываются. Они и видят что это не работает, но не могут себе признаться в этом. Их научили как «правильно», и все тут.
Думаю, что защита от ошибок не является отличительной чертой новичков.
Автор (не переводчик) достаточно зло написал, нашел в себе некоторые черты из всех 5 стадий:)
Автор (не переводчик) достаточно зло написал, нашел в себе некоторые черты из всех 5 стадий:)
Э не. это вы зря. :)
Я на заре своей карьеры вдруг резко осознал, что мой код слишком часто падает в ошибки. В результате, один из проектов над которым я работал-превратился в сплошную проверку на ошибку.
В итоге он точно также работал через маленькое черное отверстие, но все ошибки выводились в виде «Ошибка 1001-1600»
только таблицы ошибок я так и не составил :))
Я на заре своей карьеры вдруг резко осознал, что мой код слишком часто падает в ошибки. В результате, один из проектов над которым я работал-превратился в сплошную проверку на ошибку.
В итоге он точно также работал через маленькое черное отверстие, но все ошибки выводились в виде «Ошибка 1001-1600»
только таблицы ошибок я так и не составил :))
Зависит от инструментов и ситуации. Я на закате карьеры в Сбере писал на VBscript сортировщик входящих файлов — рассылка по почте, раскладывание по папкам. Вещь важная, поэтому почти над каждой строчкой приходилось фантазировать, какой sh!t может happens. А уж эмулировать те или иные ошибки, чтобы проверить, как работает программа — это отдельная песня.
И кроме подробного лога, который вела программа, приходилось еще рассылать сообщения админам почтой, на случай если что-то все-таки упадет.
И кроме подробного лога, который вела программа, приходилось еще рассылать сообщения админам почтой, на случай если что-то все-таки упадет.
Зависит от инструментов и ситуации. Я на закате карьеры в Сбере писал на VBscript сортировщик входящих файлов — рассылка по почте, раскладывание по папкам. Вещь важная, поэтому почти над каждой строчкой приходилось фантазировать, какой sh!t может happens. А уж эмулировать те или иные ошибки, чтобы проверить, как работает программа — это отдельная песня.
И кроме подробного лога, который вела программа, приходилось еще рассылать сообщения админам почтой, на случай если что-то все-таки упадет.
И кроме подробного лога, который вела программа, приходилось еще рассылать сообщения админам почтой, на случай если что-то все-таки упадет.
Это стадии, которые открыл в себе автор, частный случай.
Себя до конца не узнал ни в одном из образом. Видимо, уже нирвана.
А по-моему век живи — век учись, а зазнаек везде хватает.
Узнал себя в Abstraction Freak'e, улыбнулся и… задумался
Аналогично. Добило «читает шаблоны проектирования» и про «универсальный движок».
Желание все на свете обобщить очень мешает, больше времени проводишь где-то в облаках, абстрагируя все на свете, вместо того чтобы писать код, который решит твою проблему.
Грубо говоря, пишешь код для рисования квадрата и на пол пути начинаешь думать как бы обобщить, чтобы этот же код при изменении пары параметров рисовал кубы любой размерности.
Нужно выползать из этой стадии потихоньку :)
Желание все на свете обобщить очень мешает, больше времени проводишь где-то в облаках, абстрагируя все на свете, вместо того чтобы писать код, который решит твою проблему.
Грубо говоря, пишешь код для рисования квадрата и на пол пути начинаешь думать как бы обобщить, чтобы этот же код при изменении пары параметров рисовал кубы любой размерности.
Нужно выползать из этой стадии потихоньку :)
Застрял на «Ветеране». Не настолько комично, конечно, но отчасти узнаю самого себя.
И, да, никогда не начинал и не буду начинать имена классов с собственных инициалов. Считаю, что за такое нужно сразу больно бить линейкой по рукам, как в школе.
Вообще всё несколько преувеличено, на мой взгляд. Но, да, типичные ошибки как на ладони =)
И, да, никогда не начинал и не буду начинать имена классов с собственных инициалов. Считаю, что за такое нужно сразу больно бить линейкой по рукам, как в школе.
Вообще всё несколько преувеличено, на мой взгляд. Но, да, типичные ошибки как на ладони =)
Я тоже не начинал, однако видел, по крайней мере, одного такого человека. Надо ли говорить, что от использования таких классов бежал как от огня.
А я не понимаю. Почему?
Если, например, своя реализация списка или стека, почему бы не пометить её своими инициалами? Чтобы не путать с тем же STL.
Если, например, своя реализация списка или стека, почему бы не пометить её своими инициалами? Чтобы не путать с тем же STL.
Ничего не знаю о ваших реализациях стека и списка, хотя сам факт их наличия, как бы это сказать, немного смущает. В том же конкретном случае, к инициалам в именах класса прилагались симптоматичные для «подающего надежды гения» забавные конструкции, включая System.exit(1) в catch-блоках, которые, например, тихо и молча тушили tomcat без единого писка в логи.
Да и вообще, логика такова, что именам классов подобает отражать их назначение и содержание. Если же у списка или стека единственной особенностью является автор, то не понятно их назначение, если же нет — то почему не намекнуть на их назначение или особенности в названии класса?
Да и вообще, логика такова, что именам классов подобает отражать их назначение и содержание. Если же у списка или стека единственной особенностью является автор, то не понятно их назначение, если же нет — то почему не намекнуть на их назначение или особенности в названии класса?
потому что как правило ваши инициалы не имеют отношения к сущностям и предметным областям описываемым кодом.
*ваш КО*
*ваш КО*
В если namespace называть своими инициалами, это ничего? А то я уже о себе плохого мнения стал как-то ((((
А я-таки начинал (для своей СУБД на PHP :))
Я в детстве, когда только начинал программировать(на VB =) ), называл все переменные циклов ilya, по своему имени, потом сократил до i. Очень удивился, когда увидел, что большинство тоже называют переменные буквой i.
А уже недавно, когда писал открытый проект, наткнулся сруза на двух человек, которые начинали названия классов с фамилии…
А уже недавно, когда писал открытый проект, наткнулся сруза на двух человек, которые начинали названия классов с фамилии…
А я вот вынужден называть классы с префиксом так как сейчас пытаюсь ковырять юнити 3д и оно не поддерживает неймспэйсы :(
Возникает вопрос «А где тут я то?»
Уж точно не в финале :)
Уж точно не в финале :)
У меня в коллективе из пяти человек программистов все пятеро попадают под разные категории из статьи :)
А я — тот, кто не похож ни на одного из списка, хотя программирую уже лет 5.
очень похоже что я Abstraction Freak ))
Это напомнило одну историю из Дао Программирования:
Однажды был мастер программист, который писал неструктурированные программы.
Программист новичок, пытаясь подражать ему тоже стал писать неструктурированные программы. Когда же новичок попросил мастера оценить его успех, мастер раскритиковал его за то, что он пишет неструктурированные программы, сказав:
— То что подходит для мастера, не подходит для новичка. Ты должен понять Дао, прежде чем переступать через структуру.
Какие-то сомнительные этапы местами. «После нескольких лет программирования, освоив второй язык» — что, программист развивается через выучивание языков одного за другим? Это фигня какая-то получается…
просто редко кто начинает с изучения нескольких языков одновременно
Редко кто учится в вузе?
В вузе тож не всегда начинают программирование сразу с примеров на нескольких языках. Хотя, бывает, что не может не радовать. Да и программировать программисты частенько до вуза начинают…
Ну, например у нас просто не было единой согласованной программы на этот счёт, поэтому каждый преподавал то, что знал=)
У нас (МЭИ АВТФ) был (1998-2003) по сути 1 основной язык: С++, хотя некоторые лабы писались на c (gcc под linux), bash. Кроме того, приходилось писать на delphi, VB, C++Builder, FoxPro (СУБД). Кроме того: VHDL, ASM. Факультативно Java.
Судя по последнему пункту, все сишники у нас в компании- ветераны :)
А может всё-таки в «Юмор»?
Был поборником абстракции, работаю в одной команде с Ветераном, становиться «Гуру» не хочу :)
Как фрилансер я просто не смогу получить левелап до Ветерана :)
А я настолько обленился, что ушел в дауншифтинг и программирую в уме.
Как-то получается, что мне больше подходит «ветеран».
Прочитал все и задумался может я просто не программист, но таких ярко выраженных особенностей в себе не наблюдал. Хотя занимаюсь разработкой ПО уже порядка 10 лет. Правда я никогда не работал в крупных компаниях, возможно поэтому все стадии прошли для меня стороной и сохранился энтузиазм…
У меня были другие болезни — был ярым C++-шником долгое время, считал все остальное недоязыками. Сейчас конечно более взвешенно отношусь, и использую то что лучше подходит для конкретной задачи.
У меня были другие болезни — был ярым C++-шником долгое время, считал все остальное недоязыками. Сейчас конечно более взвешенно отношусь, и использую то что лучше подходит для конкретной задачи.
Знаете, это скорее описание этапов взросления человека, нежели чем описание подъема программиста над собой.
Что мне всегда не нравилось в этих обзорах, так это то, что авторы всегда пишут с позиции, как бы позволяющей оценивать самый верхний уровень компетентности. То есть по сути находясь выше даже самого верхнего уровня. Ну а дочитав данную конкретную классификацию до последнего пункта, стало очевидно, что автор — восторженный новичек в каком нибудь динамическом языке (судя по ycombinator.com это скорее всего лисп).
Дальше можно начать вечный холивор на тему dynamic vs static typing, вот только сейчас это неактуально — динамические языки пытаются ввести опциональные статические аннотации (без которых средний чисто динамически типизированный язык проигрывает среднему статически типизированному по эффективности не то, что в несколько раз — на несколько порядков), в статических языках есть type inference (типизация Хиндли-Милнера) и универсальный тип. Говорить же о том, что first-class functions являются преимуществом какого нибудь языка — это явная глупость, потому что они сейчас есть вообще везде (ну кроме Java, разве что).
Дальше можно начать вечный холивор на тему dynamic vs static typing, вот только сейчас это неактуально — динамические языки пытаются ввести опциональные статические аннотации (без которых средний чисто динамически типизированный язык проигрывает среднему статически типизированному по эффективности не то, что в несколько раз — на несколько порядков), в статических языках есть type inference (типизация Хиндли-Милнера) и универсальный тип. Говорить же о том, что first-class functions являются преимуществом какого нибудь языка — это явная глупость, потому что они сейчас есть вообще везде (ну кроме Java, разве что).
По моему я ветеран.
Как же тяжело дописывать и переписывать за поборниками абстракции. Особенно когда в самом коде нет бизнес логики.
Как же тяжело дописывать и переписывать за поборниками абстракции. Особенно когда в самом коде нет бизнес логики.
>Начинает имена классов со своих инициалов
Ничего не вижу в этом плохого, сам те классы, которые переношу между приложениями называют Rk_Что-тоТам, например Rk_Tree, Rk_Transactions.
Так проще отделить свои классы и их библиотеки от чужих, да и название как бы говорит: этот класс делает то-то и написан тобой.
Ничего не вижу в этом плохого, сам те классы, которые переношу между приложениями называют Rk_Что-тоТам, например Rk_Tree, Rk_Transactions.
Так проще отделить свои классы и их библиотеки от чужих, да и название как бы говорит: этот класс делает то-то и написан тобой.
Авторство нужно приписывать в комментариях.
А для логического деления в нормальных языках есть namespace, package в Java, хотя бы просто в отдельную папку положить.
Да и часто надоедает писать этот префикс перед каждым обращением к класу.
Хотя каждому свое, этой факт :)
А для логического деления в нормальных языках есть namespace, package в Java, хотя бы просто в отдельную папку положить.
Да и часто надоедает писать этот префикс перед каждым обращением к класу.
Хотя каждому свое, этой факт :)
… А теперь представьте, что с Вашим классом работать другому человеку. Для него не очевидно, что этот класс делает «то-то», и уж тем более, его писал не он. Подобные вещи решают ежеминутные задачи конкретного человека, но вносят дизинформационный момент в проект в целом.
ИМХО.
ИМХО.
Если вам так хочется, то для таких вещей люди придумали:
/**
*@author Ваши инициалы
*/
А вот называть классы своими инициалами, действительно очень плохой тон!!!
/**
*@author Ваши инициалы
*/
А вот называть классы своими инициалами, действительно очень плохой тон!!!
Т.е. даже гуру ошибается? А гдеже дзен?
Ошибаются все.
Дзэн не в отсутствии ошибок, а в принятии того факта, что они могут быть.
Дзэн не в отсутствии ошибок, а в принятии того факта, что они могут быть.
Осознать ошибки самое сложное. Так если ты их осознал, значит ты их больше совершать не должен. Ошибок не бесконечное число, значит совершенство есть)
Мудрый программист говорит о Дао и следует ему. Средний программист говорит о Дао и ищет его. Глупый программист говорит о Дао и смеется над ним. Если бы не было причины для смеха, то не было бы и Дао.
Высокие звуки сложны для восприятия. Движение вперед — путь к отступлению.
Великий талант проявляется в конце жизни. Даже совершенная программа по-прежнему содержит ошибки.
Из того же Дао программирования :)
А я считаю, что у каждого свой путь. Как нет одинаковых людей, так нет и одинаковых программистов. Потому вчитываясь каждый раз в подобные описания, я вижу лишь личное мнение автора или мешанину из случайно подобранных высказываний.
Т.е. даже гуру ошибается? А гдеже дзен?
Я уже перестал читать joelonsoftware.com. Когда я стану гуру? ;)
Я плакал :) До гуру, судя по всему, ещё не дошёл :)
Легко можно, при разделении задач на двухдневные.
Если срока я назвать не могу, называю 3 месяца, заказчик начинает понимать, что лучше дать мне другую.
Если срока я назвать не могу, называю 3 месяца, заказчик начинает понимать, что лучше дать мне другую.
Вернее, на очень короткие. бывают задачи на 15 минут, из которых 10 минут — на документирование её выполненности.
Поделить большую задачу заранее на 15-тиминутные (или даже двудневные) — без глубокого анализа не возможно, а анализ тож времени требует, и частенько должен включать попытки сделать несколько десятков первых этапов… Проще на него забить, и просто начать постепенно решать задачу.
Я не хотел бы вас с Zakus'ом обижать и уводить в глухую оборону, но молчать больше не могу. :)
Программирование — не какая-то особенная работа, она так же поддаётся оценкам с определенной точностью. Обычный инженерный труд. Когда разрабатывается новая модель телевизора, телефона, самолета, когда проектируется новое здание, инженеры не забивают на оценку и не рапортуют начальству «хрен его знает когда будет, мы забили на анализ — уже хреначим вовсю!». Более того, зачастую программное обеспечение является частью других более крупных проектов. И всё прекрасно оценивается. Понятное дело, везде есть погрешности и непредвиденные обстоятельства.
От вашего подхода к организации производства сильно несёт кустарщиной. Не обижайтесь, но ваши навыки в этой области сейчас находятся на уровне «подающий надежды гений», перечитайте.
Программирование — не какая-то особенная работа, она так же поддаётся оценкам с определенной точностью. Обычный инженерный труд. Когда разрабатывается новая модель телевизора, телефона, самолета, когда проектируется новое здание, инженеры не забивают на оценку и не рапортуют начальству «хрен его знает когда будет, мы забили на анализ — уже хреначим вовсю!». Более того, зачастую программное обеспечение является частью других более крупных проектов. И всё прекрасно оценивается. Понятное дело, везде есть погрешности и непредвиденные обстоятельства.
От вашего подхода к организации производства сильно несёт кустарщиной. Не обижайтесь, но ваши навыки в этой области сейчас находятся на уровне «подающий надежды гений», перечитайте.
Программирование — исследовательская работа, и как у любой исследовательской работы, сроки выполнения последующих этапов зависят как от результатов предшествующих, так и от исследовательской удачи, наблюдательности и ума исследователя. Кроме того, задача может оказаться вовсе не решаемой на текущем уровне развития технологий.
И никогда не разрабатывается новый телевизор, телефон, самолёт или здание в рамках заранее заданных сроков, если в нём есть хоть какая-то новизна. И делается множество проб и ошибок, моделей и их испытаний, пробных образцов и их исследований, хоть маркетинговых, хоть математических.
На самом деле, неверны оба эти описания в своей категоричности, ибо программирование бывает и тем, и тем. Не зря его пытаются поделить на проектирование и кодерство. И Вы говорите больше о втором, я больше о первом. Другое дело, что эти стороны неразделимы, и чистый проектировщик как правило рискует напроектировать то, что следующему за ним кодеру придётся перепроектировать под реалии контекста… И эффективнее, если проектировщик и кодер действуют в одном лице, или хотя бы в тесном взаимодействии.
И никогда не разрабатывается новый телевизор, телефон, самолёт или здание в рамках заранее заданных сроков, если в нём есть хоть какая-то новизна. И делается множество проб и ошибок, моделей и их испытаний, пробных образцов и их исследований, хоть маркетинговых, хоть математических.
На самом деле, неверны оба эти описания в своей категоричности, ибо программирование бывает и тем, и тем. Не зря его пытаются поделить на проектирование и кодерство. И Вы говорите больше о втором, я больше о первом. Другое дело, что эти стороны неразделимы, и чистый проектировщик как правило рискует напроектировать то, что следующему за ним кодеру придётся перепроектировать под реалии контекста… И эффективнее, если проектировщик и кодер действуют в одном лице, или хотя бы в тесном взаимодействии.
Согласен, что строятся абстрактные модели, прототипы, проводятся различные испытания, но это всё поддаётся оценке и всё это является неотъемлемой частью любого проекта. То что более-менее похоже на то что раньше уже создавалось оценивается более точно, то что меньше — менее точно. Не нужно из этого делать какой-то особой магии.
Если бы в этом была некая магия, реализация многих высокотехнологичных коммерческих проектов была бы невозможна, только потому что в принципе-то всё понятно, но программное обеспечение — хрен знает когда. Люди работают, как закончат — так можем двигаться дальше. Такой подход делает невозможным любое планирование. Ну представьте себе NASA которые сидят и не запускают ракету, потому что программисты программируют и нет никаких оценок.
Слава богу это не так.
И все ваши выкладки по поводу разделения и неразделения проектирования они происходят от того же заблуждения, что программирование содержит в себе некий элемент исследовательской работы.
Я не люблю аналогии со строительством, но здесь они уместны. Здание начинается с эскиза, потом выбор материалов, чертежи, рассчеты, а потом уже кладут кирпич. Если используются новые материалы — они предварительно тестируются, если новые технологии — проверяются. После этого строят. В этом случае ваша фраза про проектировщика звучит примерно так «Бывают инженеры которые понарисуют таких чертежей, что потом бригадир с рабочими сами додумывают или строят по-своему», «эффективнее если рабочий сам сочиняет что строить». Это не правда. Да, действительно, можно собраться с друзьями и за выходные построить баньку на даче без особого плана, но небоскребы так не строятся. И не спорьте.
При этом, что банька, что небоскреб, с определенной погрешностью легко оцениваются человеком который руководил/участвовал в проекте постройки баньки или небоскреба.
А элемент «исследовательской» работы это ни что иное как то время, которое вы тратите на преобретение необходимого опыта для выполнения данной работы. Если вы уже обладаете необходимой квалификацией вы не промахнетесь в 10 раз с оценками.
Если бы в этом была некая магия, реализация многих высокотехнологичных коммерческих проектов была бы невозможна, только потому что в принципе-то всё понятно, но программное обеспечение — хрен знает когда. Люди работают, как закончат — так можем двигаться дальше. Такой подход делает невозможным любое планирование. Ну представьте себе NASA которые сидят и не запускают ракету, потому что программисты программируют и нет никаких оценок.
Слава богу это не так.
И все ваши выкладки по поводу разделения и неразделения проектирования они происходят от того же заблуждения, что программирование содержит в себе некий элемент исследовательской работы.
Я не люблю аналогии со строительством, но здесь они уместны. Здание начинается с эскиза, потом выбор материалов, чертежи, рассчеты, а потом уже кладут кирпич. Если используются новые материалы — они предварительно тестируются, если новые технологии — проверяются. После этого строят. В этом случае ваша фраза про проектировщика звучит примерно так «Бывают инженеры которые понарисуют таких чертежей, что потом бригадир с рабочими сами додумывают или строят по-своему», «эффективнее если рабочий сам сочиняет что строить». Это не правда. Да, действительно, можно собраться с друзьями и за выходные построить баньку на даче без особого плана, но небоскребы так не строятся. И не спорьте.
При этом, что банька, что небоскреб, с определенной погрешностью легко оцениваются человеком который руководил/участвовал в проекте постройки баньки или небоскреба.
А элемент «исследовательской» работы это ни что иное как то время, которое вы тратите на преобретение необходимого опыта для выполнения данной работы. Если вы уже обладаете необходимой квалификацией вы не промахнетесь в 10 раз с оценками.
Этап исследовательской работы и в НАСА, и в строительстве и много ещё где — действительно часто очень сильно отделён от конкретно проектирования и реализации. В программировании софта для управления ракетами — видимо тоже. И там действительно оправдано написание кучи вариантов этого софта для отработки приёмов и выработки надёжных моделей API, по которым потом понятным и рассчитываемым образом строится ТЗ и кодеры понятным и рассчитываемым образом формируют окончательный вариант софта для конкретного применения.
Но не знаю уж к счастью или сожалению, подавляющее количество софта продаваемого пишется одновременно с исследованием его авторами соответствующей предметной области и ресурсов, тестируется фактически на покупателях, и практически никогда не переписывается заново и уже по плану по итогом этого изучения. И это — се ля ви, ибо бизнес.
Но не знаю уж к счастью или сожалению, подавляющее количество софта продаваемого пишется одновременно с исследованием его авторами соответствующей предметной области и ресурсов, тестируется фактически на покупателях, и практически никогда не переписывается заново и уже по плану по итогом этого изучения. И это — се ля ви, ибо бизнес.
Я пытался аппелировать к элементарной логике — нет оценок/невозможно оценить — нет плана — нет бюджета. А так не бывает, хотя бы потому, что уже готового программного обеспечения вокруг навалом и я сильно сомневаюсь что какая-то статистически-различимая его доля написана по схеме «как будет готово — так будет готово, а пока отлистывайте деньги». По вашему выходит, что заказная разработка ПО может осуществляться только по почасовке? Так это тоже не так.
Я могу написать проще — в сфере в которой работаю я могу оценить проект с погрешностью 10-15%. Проект в смежной области я могу оценить более грубо, но и то, скорее всего, смогу накидать смету и сроки которые позволят потом не заводить разговоры с заказчиком в духе «мы вылетели из бюджета».
И я, заметьте, не использовал весьма спорных аргументов в духе «подавляющее количество софта пишется так-то», ну, право, ну откуда у вас такие сведения?
Оправданий для невозможности оценить хотя-бы грубо (пусть 30%-40% ошибки) при наличии вменяемого технического задания нет. Если это невозможно сделать — никакого бизнеса вообще не будет. И не надо под отсутствие этого навыка подводить научную базу, используя весьма сомнительную аргументацию.
Я могу написать проще — в сфере в которой работаю я могу оценить проект с погрешностью 10-15%. Проект в смежной области я могу оценить более грубо, но и то, скорее всего, смогу накидать смету и сроки которые позволят потом не заводить разговоры с заказчиком в духе «мы вылетели из бюджета».
И я, заметьте, не использовал весьма спорных аргументов в духе «подавляющее количество софта пишется так-то», ну, право, ну откуда у вас такие сведения?
Оправданий для невозможности оценить хотя-бы грубо (пусть 30%-40% ошибки) при наличии вменяемого технического задания нет. Если это невозможно сделать — никакого бизнеса вообще не будет. И не надо под отсутствие этого навыка подводить научную базу, используя весьма сомнительную аргументацию.
В исследовательской сфере — бюджет берётся из грантов, дотаций и премий. Посему — оплата тоже не почасовая. Но риски. И план приблизительный, с априорным закладыванием как вариативности, так и обломов.
И лично я уверен, что подавляющая часть готового программного обеспечения сделана именно по схеме «как будет готово», и иметь ТЗ заранее не может в принципе.
В сфере заказной разработки — уверен, ситуация обратная: при подписании договоров на разработку весьма часто можно иметь уже проработанное ТЗ, не требующее от исполнителя новых исследований, и целиком опирающееся на уже сформированный у него опыт и его профессиональную и адекватную оценку собственной производитеьности.
Я спорю с вашей категоричностью, с отрицанием противоположной стороны. В том, что существует область изученного я не сомневаюсь. Мне странно, что Вы отрицаете область неизученного.
И лично я уверен, что подавляющая часть готового программного обеспечения сделана именно по схеме «как будет готово», и иметь ТЗ заранее не может в принципе.
В сфере заказной разработки — уверен, ситуация обратная: при подписании договоров на разработку весьма часто можно иметь уже проработанное ТЗ, не требующее от исполнителя новых исследований, и целиком опирающееся на уже сформированный у него опыт и его профессиональную и адекватную оценку собственной производитеьности.
Я спорю с вашей категоричностью, с отрицанием противоположной стороны. В том, что существует область изученного я не сомневаюсь. Мне странно, что Вы отрицаете область неизученного.
Это для новичков — исследовательская работа, а когда ты уже делал похожие задачи, что можно с достаточной точностью предсказать сроки (не забыв накинуть тройной запас времени).
Кроме того, есть метод работы, когда твой проект постоянно в рабочем состоянии (можно запустить и он будет работать), а время уходит на его совершенствование. И если не получается сделать вовремя какие-то фичи, то это не критично — в целом проект живой.
Кроме того, есть метод работы, когда твой проект постоянно в рабочем состоянии (можно запустить и он будет работать), а время уходит на его совершенствование. И если не получается сделать вовремя какие-то фичи, то это не критично — в целом проект живой.
Я уже лет пятнадцать довольно плотно программирую, и практически не встречал таких задач, которые уже ранее делал и могу повторить с закрытыми глазами и заранее рассчитать сроки выполнения. Единственно, в чём помогает накопленный опыт — с одной стороны быстрее искать нужную документацию, следы чужих наработок и разбираться в них, и с другой стороны угадывать некоторые грабли и тонкие места, соответственно заранее их обходя и подкладывая куда надо соломку.
Что касается «некоторых фич» — сами понимаете, этот подход применим далеко не всегда. Потому как без некоторых фич проект, может быть, будет и живой, но может оказаться неюзабельным и соответственно, бесполезным.
Что касается «некоторых фич» — сами понимаете, этот подход применим далеко не всегда. Потому как без некоторых фич проект, может быть, будет и живой, но может оказаться неюзабельным и соответственно, бесполезным.
Задача может быть каждый раз совершенно новой, но методы решения отдельных под-задач могут быть идентичными. Более того, можно решать задачу не самым оптимальным (с точки зрения логики) способом, но этот способ будет проверенным и предсказуемым.
По поводу «фич» — если фича не выходит, то можно либо потерять только часть вознаграждения, либо договориться решить вопрос другим путем. На моей практике, в большинстве случаев заказчик даже не придирается к некоторым недоработкам, если в целом проект его устраивает. Всегда можно договориться «погонять то что есть, вдруг найдутся проблемы посерьезней». А там глядишь, и все вполне устраивает. Да, это не лучший вариант, но лучшее враг хорошего.
По поводу «фич» — если фича не выходит, то можно либо потерять только часть вознаграждения, либо договориться решить вопрос другим путем. На моей практике, в большинстве случаев заказчик даже не придирается к некоторым недоработкам, если в целом проект его устраивает. Всегда можно договориться «погонять то что есть, вдруг найдутся проблемы посерьезней». А там глядишь, и все вполне устраивает. Да, это не лучший вариант, но лучшее враг хорошего.
Главное это гармония.
Дзен здесь.
Дзен здесь.
Я не подпадаю не под одну из категорий, вернее из каждой беру что-то свое =)
Например шаблонами я тоже увлекаюсь, но что бы лепить их в каждую программу… это уже слишком.
Люблю изобретать велосипед =)
Пытаюсь оставлять побольше комментов и юзать doxygen.
Например шаблонами я тоже увлекаюсь, но что бы лепить их в каждую программу… это уже слишком.
Люблю изобретать велосипед =)
Пытаюсь оставлять побольше комментов и юзать doxygen.
>… я задумался насколько распространены эти ошибки, и можем ли мы их категоризировать. Я попадался в каждую из этих ловушек хотя бы раз — в некоторые по нескольку, видел те же ошибки у других.
Начинали писать о «ментальных ловушках»…
> Вот она, моя карьера программиста как она есть.
… закончили этапами карьерного роста.
Даже не знаю, как оценить статью: забавная с точки зрения «ментальных ловушек» или совершенно плоская с точки зрения анализа эволюции разработчика?
Начинали писать о «ментальных ловушках»…
> Вот она, моя карьера программиста как она есть.
… закончили этапами карьерного роста.
Даже не знаю, как оценить статью: забавная с точки зрения «ментальных ловушек» или совершенно плоская с точки зрения анализа эволюции разработчика?
оу… я «гуру»… радоваться или плакать?
> программист начинает верить что архитектура любой программы должна быть обобщена, потом обобщена и, наконец, обобщена еще раз…
как это знакомо:) такое проходили если не все, то большинство, мне кажется
как это знакомо:) такое проходили если не все, то большинство, мне кажется
:) Хе-хе. Забавно.
В первой и второй стадии я точно был. Правда, я тогда не считал себе «Мессией мира программирования» — внутренности различных либ, в которые я заглядывал, этому не способствовали. А класс SV_Vector я даже реализовывал, хотя и не лично для себя, а при выполнении лабораторных.
А в тот момент, когда я готов был перейти в «абстракционисты», в организации, где я проходил практику, как раз создали и стали использовать фрэймворк, в котором натурально вся логика и все экранные формы описывались xml-конфигами. Поработав с этим ужасом, абстракционистом я не стал.
В первой и второй стадии я точно был. Правда, я тогда не считал себе «Мессией мира программирования» — внутренности различных либ, в которые я заглядывал, этому не способствовали. А класс SV_Vector я даже реализовывал, хотя и не лично для себя, а при выполнении лабораторных.
А в тот момент, когда я готов был перейти в «абстракционисты», в организации, где я проходил практику, как раз создали и стали использовать фрэймворк, в котором натурально вся логика и все экранные формы описывались xml-конфигами. Поработав с этим ужасом, абстракционистом я не стал.
Всегда боялся стать наркоманом по части абстракции, но в последнее время идея общего движка, работающего исключительно на конфигах и не требующего вмешательства в код, все чаще меня одолевает…
Я узнал себя! Я поборник абстранции, только обхожусь вместо 5 классов одним и не использую дурацкие неуклюжие паттерны типа фабрик и адаптеров.
И, почитав, следующие стадии — что то не хочется на них переходить ((.
И, почитав, следующие стадии — что то не хочется на них переходить ((.
Блин, я по ходу только на третьей стадии :( До гуру ещё работать и работать… Но это же и здорово, когда есть куда стремиться :)
Мне показалось что это не стадии которые проходит программист, а типы которые бывают. Ну, помните, как у Бидструпа с темпераментами. С грустью для себя понял, что я почти полный Abstraction Freak и даже «Паттерны проектирования» читать расхотелось :)
Странно, но не увидел себя ни в одной из категорий.
Попытки писать код предпринимаю больше 10 лет, занимаюсь в основном скриптоложеством — может быть это «карма» специализации?
Согласен, что каждый программист — отдельная «вселенная» со своими «тараканами и бабочками».
Думаю, что часто большинство классификаций — попытка засунуть голову в песок и не решать задачу, если, конечно, клиент платит за результат, а не за классификацию.
Есть две вещи, которые на приходится обращать внимание почти всегда:
1. Чужой код обычно хорошо воспринимается, если начать с конца листинга.
2. Генетически большинство программистов почти ничем не отличаются друг от друга — «все мы люди».
Компетентность «программиста» часто определяется количеством решенных задач.
Например при рекрутинге я использую такую схему (зачет/незачет):
1. Опишите применяемые Вами принципы работы с файловой системой?
2.… работы с СУБД?
3.… работы с GUI?
Да, я не встречал ни одного компетентного программиста, который не разбирается в «железе».
Да, и, компьютеры не так уж и много могут, логика же двоичная, принципы не изменяются уже 60 лет :)
Большинству «новичков» я советую больше читать, и, если еще не успели, то прочесть что-нибудь лёгкое на тему архитектуры процессора, например известного Чарльза Петцольда «КОД».
Лично у меня после осознания «как оно на самом деле работает» пропадало желание наслаждаться «детством», зато появилось ощущение конечности познания и принципиальной возможности самосовершенствования в заданном направлении.
Странный, конечно, комментарий, но уж — какой получился :)
Попытки писать код предпринимаю больше 10 лет, занимаюсь в основном скриптоложеством — может быть это «карма» специализации?
Согласен, что каждый программист — отдельная «вселенная» со своими «тараканами и бабочками».
Думаю, что часто большинство классификаций — попытка засунуть голову в песок и не решать задачу, если, конечно, клиент платит за результат, а не за классификацию.
Есть две вещи, которые на приходится обращать внимание почти всегда:
1. Чужой код обычно хорошо воспринимается, если начать с конца листинга.
2. Генетически большинство программистов почти ничем не отличаются друг от друга — «все мы люди».
Компетентность «программиста» часто определяется количеством решенных задач.
Например при рекрутинге я использую такую схему (зачет/незачет):
1. Опишите применяемые Вами принципы работы с файловой системой?
2.… работы с СУБД?
3.… работы с GUI?
Да, я не встречал ни одного компетентного программиста, который не разбирается в «железе».
Да, и, компьютеры не так уж и много могут, логика же двоичная, принципы не изменяются уже 60 лет :)
Большинству «новичков» я советую больше читать, и, если еще не успели, то прочесть что-нибудь лёгкое на тему архитектуры процессора, например известного Чарльза Петцольда «КОД».
Лично у меня после осознания «как оно на самом деле работает» пропадало желание наслаждаться «детством», зато появилось ощущение конечности познания и принципиальной возможности самосовершенствования в заданном направлении.
Странный, конечно, комментарий, но уж — какой получился :)
1С-ники поголовно гуру? =)
Быть ветераном круто. Это когда твоя прога всегда работает, несмотря на ошибки.
Быть ветераном круто. Это когда твоя прога всегда работает, несмотря на ошибки.
> Начинает имена классов со своих инициалов.
Даже и мысли такой не было. Откуда такие идеи появляются???
Даже и мысли такой не было. Откуда такие идеи появляются???
Чёрт, а что меня ждёт дальше после «гуру в кавычках»?…
Я бы сказал, что такая классификация не совсем верна. Так как не выделена черта классификации) но я понимаю, что сделано это, что называется, just for fan) поэтому было очень приятно увидеть себя почти во всех описанных стадиях)
Приятно узнать что ты «Ветеран».
Спасибо автору!
Увидел себя со стороны в разные периоды развития.
Ждём N стадий компетентности ;)
Увидел себя со стороны в разные периоды развития.
Ждём N стадий компетентности ;)
Спасибо — уже между последними двумя стадиями :) всё остальное прошел :)
1,3,5 стадии проходил, остальное мимо. ))
«Geek»
После попыток «творить» приходит осознание «сроков» и «доходности», уже не важно что и на чем писать… Just For Fun )
Отличительные особенности кода: кода мало, коментариев мало, мат в коде только по делу.
Ошибочное мнение: вот-вот допишу и потом спать…
Читает: написанный вечером код, удивляется и смеется с своих коментариев
Скорее всего скажет: я незнаю этой платформы… прожект писали полгода, документации нет, ничего неработает и через 2 недели дедлайн? интересненько :P
«Geek»
После попыток «творить» приходит осознание «сроков» и «доходности», уже не важно что и на чем писать… Just For Fun )
Отличительные особенности кода: кода мало, коментариев мало, мат в коде только по делу.
Ошибочное мнение: вот-вот допишу и потом спать…
Читает: написанный вечером код, удивляется и смеется с своих коментариев
Скорее всего скажет: я незнаю этой платформы… прожект писали полгода, документации нет, ничего неработает и через 2 недели дедлайн? интересненько :P
Всё это откровенный стёб :)
скорее ветеран, чем гуру. но все к тому идет :)
Видимо скобочки в конце постов — отметки на линейках
Узнал себя некоторое время назад в поборнике абстракций :)
Вторая стадия. Судя по всему, пожизненно…
Черт,… как же все предсказуемо.
Многое пересекается. Даже «инициалы», в свое время )
Лес абстракций или голый код — зависит от задачи. Иногда нужно быстро и на раз — сделал/сдал, а иногда поднять большую систему, зная, что тебе же её придется, поддерживать и развивать. Тогда и паккаджи/абстракции/прототипы/конфиги/тесты/ и куча еще всего скучного.
В общем, по задаче.
Многое пересекается. Даже «инициалы», в свое время )
Лес абстракций или голый код — зависит от задачи. Иногда нужно быстро и на раз — сделал/сдал, а иногда поднять большую систему, зная, что тебе же её придется, поддерживать и развивать. Тогда и паккаджи/абстракции/прототипы/конфиги/тесты/ и куча еще всего скучного.
В общем, по задаче.
Мы пойдем другим путем!
:-)
P.S. Как ни странно, я ни под одну Вашу категорию не подхожу.
К сожалению, никак не выберу время написать эссе о своем взгляде на проектирование и программирование.
:-)
P.S. Как ни странно, я ни под одну Вашу категорию не подхожу.
К сожалению, никак не выберу время написать эссе о своем взгляде на проектирование и программирование.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
5 стадий некомпетентности программиста