Хороший код и говнокод

Это какой язык?

Это плюсы.

Нахрен ты оставляешь свои бессмысленные тексты?

Сказал «титан мысли».

Владимир

То есть если говорить про нашу полянку - тестировать надо то, что:

1. нетривиально

2. при этом широко используется (библиотека для неск. проектов) или регулярно меняется.

Я бы подумал насчёт сотрудничества с настоящими QA.

Это было бы здорово, но где их взять та… Вы вот случаем не из Москвы?;-)

1. во время выполнения транслирующий входные данные в выходные с минимальными объёмами потребления вычислительных ресурсов (памяти, процессорных таков, и т.д.)
2. модифицируемый минимальными затратами при незначительных изменениях в контрактах на входные / выходные данные

Часто это взаимоисключающие параграфы, т.к. чем больше оптимизаций, тем менее код очевиден.

Есть еще определенные правила безопасности

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

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

Типа как - «Мичурин умер от того, что ему с березы упал на голову арбуз».

Ну это когда система говно. Когда система норм то TLD работает, особенно есть L не после 5 лет поддержки.

Дык. Он явно пытался сделать это без кавычек, и что-то с чем-то синхронизировал.

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

Хипсторы, блин…

Требования не стоят на месте, клиентам стали нужны новые эффекты, больше кнопок в gui и всякое такое, всё таки процессить 3 мало связанных и плохо синхронизированных очереди в одном цикле обработки событий такое себе, да и читается так себе, а уж правится и вовсе по принципу домино.

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

Это было бы здорово, но где их взять та… Вы вот случаем не из Москвы?;-)

Я не из Москвы, да и QA владею только по вершкам в комплексе это довольно большая область знаний, сопоставимая как минимум с разработкой ПО. Но настоящих QA(не путать с QA automation) думаю в мск должно быть довольно много. Можно, подумать в сторону аутсорса у галер например. Сразу разочарую - тесты за вас они писать не станут. А вот рассказать что, как часто и как имеет смысл тестировать расскажут гораздо лучше чем аналитики с лора. В общем и целом, я знаю несколько таких инженеров и если вы организуете вакансию, то я могу отправить им ссылку на неё. Как минимум один кстати с вышкой именно про какую-то прикладную математику ;)

То есть если говорить про нашу полянку - тестировать надо то, что:

Ну в идеале конечно тестировать нужно всё…, но в реальной жизни лучше поступать примерно так. Только к TDD это мало отношения имеет, это скорее способ написания кода оставляющий тесты как артефакты, чем тесты как самоцель:) Но при таком подходе, если следовать ему буква в букву нельзя писать код который не тестируется, однако примерно в до 25%(четверть же) случаев считается, что отойти от этого подхода не есть плохо даже на тех проектах где считается что эта практика широко используется.

Вопрос про трюкачество думаю тут был в контексте понимания кода. Если непосвящённый человек увидит как кто-то правит биты указателя на объект он, может сказать что-то в духе: «что за уроды экономят на спичках». Хотя в очень большом количестве случаев как ни странно, он ещё и прав окажется, т.к. в реальной жизни lock, а уж тем более wait free требуется гораздо реже, чем можно встретить специалиста думающего что владеет этими техниками и знает когда их разумно применять :)

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

я знаю несколько таких инженеров и если вы организуете вакансию, то я могу отправить им ссылку на неё.

Спасибо. Вакансии это отдельная (печальная) тема. Поскольку деньги у нас главным образом государственные то … (дальше нецензурно).

Я бы повзаимодействовал с кем то знающим в формате неформальных бесед/семинаров/код ревью и пр. Потому что самому читать - я не знаю что. Есть вообще какой то сборник рецептов, адаптированный именно к нашей полянке а не про какой то энтерпрайз или как оно называется? Это нужен человек вроде Вас (условно;-)), имеющий с одной стороны богатый опыт, а с другой стороны толерантный, осознающий что в области наукоемкого софта (числодробилок) есть очень много специфики, включающей человеческое общение. Большинство аналитиков с ЛОРа не подходит, проходили;-)

Ну и отдельный вопрос оплаты - видимо налом почасовка. Хотя может кто то захочет джаст-фор-фан двинуть науку, тады можно его и в проект вписать, и статей понаделать;-)

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

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

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

Поскольку деньги у нас главным образом государственные то …

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

По-поводу книжки - есть «Роман об управлении проектами» но там не про код. С другой стороны там привносится понимание почему его качество величина субъективная и где граница когда надо вообще как-то начинать оценивать эту метрику.

какой то сборник рецептов, адаптированный именно к нашей полянке а не про какой то энтерпрайз или как оно называется

Для обычного ПО есть шаблоны проектирования «фабрика», «медиатор» и т.п.. Часто кажется что их сложно применять уже даже к системному софту, но на практике там они ещё уместней, но добавляются местечковыми шаблонами типа «цикл обработки событий», «оптимистичная синхронизация» или, например, «барьер». По-сути это как раз заготовки рецептов, где подразумевается «посолить по-вкусу». Но я не слышал про книги даже по системному программированию которые были бы сборниками подобных приёмов в чистом виде, сам бы с удовольствием прочёл такую поваренную книгу. Для плюсов есть свои «шаблоны проектирования» чаще именуемые идиомами, типа CRTP, copy-and-swap или pimpl часть из них описаны например у Джосатиса(вместе с инструкциями как половину 11ого стандарта на коленке сделать).

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

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

На момент написания, да, фактически то что сейчас модно называть state of art.

Это мнимое противоречие.

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

От «читаемости» кода требуется в первую очередь «что» и «зачем», но не «как».

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

больше оптимизаций

Оптимизация предполагает что задана целевая функция от параметров, для которой ищут минимум - локальный или глобальный.

Если целевая функция - это время работы программы или какого-то блока программы, то минимум будет при определенных параметрах (код прогрмаммы - тоже параметр).

Если например - редакторское расстояние между коммитами, то минимум будет при других параметрах.

Так что надо сперва дать определение, что есть оптимизация. Кто-то оптимизирует время программы, кто-то - время программиста, кто-то - размер исходников, кто-то - размер дельты между релизами, кто-то - расходы, кто-то - доходы…

Следует поискать так же человека знакомого с business development и десятком другим инвесторов которым шальное бабло жгёт карманы :)

Знаю таких людей, но книжки они писать не будут - в нашей стране о некоторых вещах лучше помалкивать:-)

Для обычного ПО есть шаблоны проектирования «фабрика», «медиатор» и т.п..

Да. Часть я открыл для себя сам, другая часть судя по всему мне пока не нужна. Хотя могу и ошибаться, надо ещё раз на них глянуть. Но я скорее не о том а о культуре разработки.

меня бы самого кто поучил бы как оно на самом деле должно быть

Ну тогда подумайте о соавторстве, я серьезно. Зачастую лучший способ что то понять - объяснить это кому то другому:-)

Поскольку деньги у нас главным образом государственные то …

А не ты ли дядя недавно хвастал, что в российской науке деньги лопатой гребешь?

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

Учитесь читать и понимать написанное.

Что, небось, пролетарские корни проверяют?

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

В коммерческих конторах все сильно проще

Вылези уже из танка. Программист сейчас - ИП. Заключаешь с ним контракт и все.

Вы с бухгалтериями институтов РАН дело имели?

https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does#Uses

какие преимуществе у вас возникли в связи с умением вести дела с бухгалтериями институтов РАН

как эти(умения из предыдущего абзаца) компетенции улучшили вас в смысле научных умений.

как эти(улучшения из предыдущего абзаца) способности повысили вашу инновационность.

???

Очевидно, он может работать в институтах РАН, т.к. с бухгалтерией в таких заведениях общаются чуть менее, чем все.

Естественно. Делают, что им говорят. Все решения по финансам и кадрам принимает руководитель проекта(ОКР). Нет никакой разницы между заключением контракта на разработку и изготовление электроники на стороне и контракта с Пупкин ИП на разработку по.

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

Ну-ну. Свежо питание…

Мои глаза!

Что за мудаки такой длиннючий быдлокод нарисовали? Их мама не учила в детстве, что файлы больше 1000 строк - дикость, а больше 5000 строк - мудачество?

Хороший код и говнокод

Хороший говнокод …

Хороший говнокод …

Очень хороший говнокод …

опенсорц-проект с хорошим кодом для образца

Питон

Нет.

или С++

Poco сколько-то лет назад мне показался вменяемым.