Когда тебя каждые пять минут гоняют от одной задачи к другой — не поднимите. Вот вообще никак. Кроме истерзанных нервов ничего не будет. Да еще и при увольнении выскажут много чего интересного.
Однако в защиту товарища хотелось бы упомянуть, что обычно у нас капиталисты говорят о каких-то рисках и прочее, однако вот оборотной стороной (прибылью) никогда не делятся с работниками.
Не про безответственное отношение сотрудника, а про любителей каждую проблему выдавать за срочную и исключительно по вине сотрудника (неоплачиваемую).
Но опять же, лично мое мнение, что возможность вызвать сотрудника в случае ЧП в любое время — это реально важно. Факторы бывают разные. Невозможно все предусмотреть на всех уровнях.
Вы уже сами описали, что смешали работу нескольких специальностей.
Я же описывал именно "возможность" напрягать мозги в одном направлении в течении долгого времени. По опыту — максимум возможностей — 8 часов, и то после тренировок. И кстати результаты совпадают с общественной практикой, люди вообще больше 8 часов в день не могут продуктивно работать над чем-то в течении всего года. Замечу, речь именно о среднесуточной нагрузке в течении года, а не "две недели 60 часов отработал, а потом неделю отдыхал".
Когда есть возможность смешивать работу — ревью, очистка, отладка и т.д. — это облегчение работы.
аналитика, менеджера, программиста, тестировщика и DevOps.
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!
Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Но в целом — да. У нас так хаят "неквалифицированную рабочую силу", что забывают насколько "заказчики" бывают недалеки и неквалифицированны вообще во всех сферах кроме "заплатить меньше, получить больше".
Тоже посчитал — 3-4 часа в день именно на написание кода.
Зависит от тренировки. Если начинал с самого детства, то лет за 10 можно и 6-8 часов в день выдерживать. Зависит еще сильно от общего физического состояния.
В 14 лет с трудом выжимал из себя 15-40 минут непрерывной концентрации на коде — поэтому везде ходил с блокнотом и карандашом — писал всякую хрень. К 30 годам 6 часов непрерывной умственной нагрузки — даже усталости нет.
Однако при приближении к 8 часам есть снижение всех когнитивных навыков, т.е. вообще всех, падает реакция, глаза болят и висок ноет (левый). По 7-8 часов в день больше 14 дней подряд не выдерживаю, нужен отдых. Силой никто не гонит, просто "хочется еще".
Если так весь год работать, то нужен отпуск примерно 48 дней.
Субъективно, согласен — но пища для размышлений есть.
Поняв что надо сделать — надо понять как это сделать
Так ведь уже сказали, что декомпозиция осуществлена. Все остальные операции — уже очень легкие и не требуют существенного труда.
Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость.
Описал выше. Тренировка и общая физическая подготовка. Стоит обратить внимание на ваше питание. Почитайте про то, как маленькие улучшения коммулятивно дают прирост в разы.
Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа
Такой же подход, отвлекаюсь на приготовление обеда и т.д. Отвлечение на другую деятельность лучше всего позволяет мозгу отдохнуть.
У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить…
"Многие" даже траншеи не копали. На прошлой работе начальник вполне легко мог отвлечь посреди задачи, или вовсе что-то обсуждать.
Это не проблема кодинга, а проблема воспитания людей и коммуникации между ними. Вы же не сможете в деталях объяснить быт и труд шахтера? Каждый человек живет в своем мире, просто у кого-то он размером с горошину — представления о других людях соответственные.
Было время, когда маленькие одноклеточные "засрали" всю планету кислородом, от чего началось глобальное похолодание и массовое вымирание этих одноклеточных. Вся планета была покрыта ледяным щитом.
Подход при котором для начала люди хотя бы привели вычисления того, что данный подход действительно дает больше производства кВт энергии на каждый затрачиваемый кВт энергии.
Подход, при котором с небес для начала на землю спускаются и оценивают то, что есть на самом деле, а не то, во что хотелось бы верить. Земля усеянная ветряками и солнечными панелями — это утопия. Этот источник ЭЭ сугубо нишевый и никогда не сможет быть, как вы уже сказали, конкурентноспособным по отношению даже к грязным ТЭЦ, от которых необходимо избавляться, так как углеводороды лучше тратить на бытовую химию — те же пластики. Причем это еще вопрос, кто загрязняет среду больше ТЭЦ или производство панелей и ветряков, которые менять надо чуть и не каждые 2 года, тогда как ТЭЦ нуждается только в смене фильтра. Все эти шумихи сейчас существуют только потому, что на это тратятся огромные деньги в виде дотаций и прочих субсидий.
Количество людей можно легко вычислить на основе оценки количестве энергии (общей) поступающей в систему под названием "Земля". Так как основным источником является Солнце, а остальное скорее всего не составляет и 1%, то ими можно для упрощения пренебречь.
Получив оценку входящей энергии — нужно определить, сколько требуется каждому человеку для того, что бы жить. Таким образом и вычисляется максимально допустимая "наивная" оценка. Почему наивная? Потому что человечество не всю энергию само поглощает. Но она хороша тем, что это даст число, при котором последствия от перенаселения станут необратимыми и войнами и геноцидами уже ничего не исправишь, дает терминальную оценку, которую вполне можно разделить на 10, для гарантии безопасности человечества и использовать как предел численности населения. Вас такой ответ устроит? Заранее прошу прощения, что не привожу конкретную цифру, так как не обладаю точными исходными данными относительно того, какой поток энергии от солнца падает на землю. Особенно если учесть, что он является функцией от множества параметров.
Надо понимать, что солнечные панели и ветряки вместе с эрозией песчаных побережий для песка и загрязнением окружающей среды, вследствие добычи редкоземельных элементов, появятся сами, причем разумеется без того, что идет "вместе".
Все больше и больше статьи напоминают утопии для успокоения людей, не знающих ничего об инженерном деле. Надеюсь, что ухудшение инженерной культуры в современном обществе — всего лишь корреляция.
Так все же вопрос, откуда солнечные панели? И откуда возьмутся сотни тысяч квадратных километров площадей с солнечными панелями для каждого такого экополиса? Кто будет их обслуживать? Если автоматика, то кто будет обслуживать армию этих автоматов?
Если же сотни тысяч людей в городе не нужны… то вопрос, почему в этих городах будет жить пара тысяч человек? Куда остальные денутся? "Не впишутся в рынок"?
Продолжение идей "золотого миллиарда"? Да даже для него потребуется такой парк ветряков (которые не всегда работают), и настолько огромные площади, занятые солнечными панелями, что даже современная экономика их не сможет поддерживать.
И прошу, оставьте ваши шутки про "сахару в панелях", один песчаный шторм и все ваши панели можно либо в мусор отправлять, либо чистить придется. Кто этим займется?
И вопрос, куда девать отработанные солнечные панели? Перерабатывать? Энергии не хватит. На изготовление-то уходит море ЭЭ, а вы еще переработку желаете.
Проблема в том, что для получения газа надо тратить энергию, и кпд будет не 10-15% как у угля, а 0,1-1%. Вам оно надо? По экологии ударит куда как сильнее и результаты потомки еще будут расхлебывать.
Все это из разряда "экологически-чистых" автомобилей Тесла, кпд у которых не лучше, чем в ДВС, только в отличие от ДВС, который конкретно сейчас выделит Х углекислого газа — электромобиль сожрет энергии все на тот же Х (которая идет от тех самых теплых углесжигательных станций) + некоторая доля Х, требуемая для транспортировки, да еще при хранении утечки ЭЭ происходят во всех аккумуляторах. Я уже не говорю, что утилизировать использованный аккумулятор куда как сложнее, чем выхлопные газы, которые в худшем случае содержат небольшие примеси тяжелых металлов, от которых можно спастись обязав всех ставить фильтр на выхлопную трубу.
Попробуйте посчитать, что значит производить биотопливо в промышленных масштабах, а главное — откуда столько отходов взять? Вам потребуются тонны биоотходов (кто их сортировать будет?), что бы получить несколько кВт ЭЭ.
На 1/3 энергии от солнца и ветра нужно превратить огромные территории в зоны отчуждения похлеще Чернобыля, там вообще ничего не должно быть, совсем. К тому же на производство солнечных панелей нужно много ЭЭ, откуда ее брать? От солнечных панелей? У них КПД очень низок, а применять эти панели есть смысл только в солнечных широтах (тропики и экватор) и выдавать одна панель размером в 1 м2 будет пару Вт/ч.
Гидро-станции — вы представляете сколько нужно затопить территорий, что бы было 17% по всему миру?
ТЭЦ и АЭС занимают такой большой сегмент рынка ЭЭ в мире не из-за того, что какому-то политику что-то захотелось, а потому что это в разы дешевле, меньше вредит экологии планеты в целом (а не только в вашей любимой Хермании) и главное, что это все предсказуемо, планируемо. С солнечными панелями и ветряками у вас не только цена подскочит, но и упадет выработка энергии в среднем == убийство промышленности.
И не надо выдавать "экологически-чистые" технологии, спасающие экологию вашей страны за счет чьей-то другой, которая производит сырье для ваших "экологически-чистых" технологий.
Да вы хотя бы поинтересовались бы, что такое песочная мафия (Sand mafia), и какие законы принимают, что бы песок с пляжей не собирали.
Java — тоже растущий и развивающийся язык. Из-за более раннего старта, нежели шарп — имеет больше легаси кода и больший технический долг. У шарпа такое будет рано или поздно. Поэтому замедление в последние годы для меня не является чем-то из ряда вон выходящим.
То что полезные фичи вносятся в джаву не говорит о том, что шарп хорош.
К шарпу у меня только одна претензия, которая на корню пилит ее использование — отсутствие кросс-платформенности (mono — это не c#, а опенсорсная разработка никакого отношения к мелкософту не имеющая).
Валидатору требуется для проверки NamedValue 4 обязательных константных аргумента и доступ к данным, класса SequenceType.
Предлагаете, что лучше устанавливать внешний валидатор, когда процедура проверки одна и не меняется? И в принципе не может изменится?
С method-object получается более компактный код.
Есть другой вариант парсер конфигураций 1С. В зависимости от типа объекта в xml, необходимо выполнять свою логику, причем она отличается сильно, но общего очень много.
у базового класса тонна информации, вроде около 10 полей (как констант, так и изменяемых), все необходимы при анализе. Часть создается в процессе анализа.
Раньше весь код представлял из себя кашу разных методов с 5-6 аргументами как минимум, сейчас 3 аргумента максимум и весь код разбит на функциональные блоки — вот конфигурируется документ, вот загружается контент из xml, тут определяются типы.
Про быстродействие даже говорить не хочется, оно просто в разы выше.
Хотя важнее именно повышение читаемости кода.
Или лучше иметь один класс (который в принципе нельзя разбить на независимые друг от друга классы без создания нереального количества мусорного кода), и 100+ методов в нем?
Если не страшно, вот пример из реального, работающего проекта, в исходном виде 1500 строк:
Часть класса
final class MetaDataMapper
{
/**
Огромное количество констант
**/
MetaDataMapper( VirtualFile file, 1СDocument sdk, 1СDocument target, @Nullable Element root )
{
this.file = file;
this.sdk = sdk;
this.target = target;
this.root = root;
resolver = new OneCv8ClassResolver( target );
sourceFile = new SourceFileStub( file.getAbsoluteName().substring( 1 ), null );
dummyDeclareStatement = DeclareStatementModifier.dummy( file );
}
private final VirtualFile file;
private final SourceFileStub sourceFile;
private final 1СDocument sdk;
private final Element root;
private final 1СDocument target;
private final OneCv8ClassResolver resolver;
private final DeclareStatementModifier dummyDeclareStatement;
private ClassBuilder classBuilder;
private List<ClassBuilder> transformationClasses;
void mapElement()
{
if( file.getName().startsWith( "Subsystem." )
|| file.getName().startsWith( "WSReference." )
|| file.getName().startsWith( "CommonAttribute." ) )
return;
if( root.getTagName().equalsIgnoreCase( "Configuration" ) )
{
target.newClass( "System.Конфигурация.ЭтаКонфигурация" )
.parent( TYPE_CONFIGURATION )
.superClass( TYPE_CONFIGURATION.classReference() )
.declareStatement( asStatement( root ) )
.customData( ATTR_UUID, root.getAttribute( ATTR_UUID ) )
.build();
return;
}
Element properties = XmlUtils.getSingleElementOrDie( root, TAG_PROPERTIES );
Element innerInfo = XmlUtils.getSingleElementOrNull( root, TAG_INNER_INFO );
Element internalInfo = XmlUtils.getSingleElementOrNull( root, TAG_INTERNAL_INFO );
Element childObjects = XmlUtils.getSingleElementOrNull( root, TAG_CHILD_OBJECTS );
Element standardAttributes = XmlUtils.getSingleElementOrNull( properties, TAG_STANDARD_ATTRIBUTES );
resolveThisClass();
transformationClasses = new ArrayList<>();
if( innerInfo != null || internalInfo != null )
new ClassTransformer( innerInfo, internalInfo ).doTransform();
if( childObjects != null )
readChildren( childObjects, standardAttributes, classBuilder, transformationClasses );
if( properties != null && root.getTagName().equalsIgnoreCase( "Document" ) )
registerDocumentSpecials( properties );
notifyComplete();
}
void mapFormElement()
{
if( !root.getTagName().equalsIgnoreCase( "Form" ) )
throw new IllegalStateException();
resolveThisClass();
FormAttributeReader attributeReader = new FormAttributeReader( classBuilder, transformationClasses );
readFormAttrs( attributeReader, TAG_ATTRIBUTES, TAG_ATTRIBUTE );
readFormAttrs( attributeReader, TAG_PARAMETERS, TAG_PARAMETER );
Element elements = XmlUtils.getSingleElementOrNull( root, TAG_ELEMENTS );
if( elements != null )
new FormElementsReader( elements ).read();
Element commands = XmlUtils.getSingleElementOrNull( root, "Commands" );
if( commands != null )
new FormCommandsReader( XmlUtils.getChildren( commands, "Command" ), asStatement( commands ) ).read();
notifyComplete();
}
void mapPredefined()
{
if( !root.getTagName().equalsIgnoreCase( "predefinedData" ) )
throw new IllegalStateException();
resolveThisClass();
for( Element item : XmlUtils.getChildren( root, "item" ) )
{
String name = XmlUtils.getTextContentOrDie( item, "name" );
Element codeElement = XmlUtils.getSingleElementOrNull( item, "code" );
String attrType = null;
if( codeElement != null )
attrType = codeElement.getAttribute( "xsi:type" );
1CType type = StringUtils.isBlank( attrType )
? getFieldType( item, "type" )
: resolver.resolveType( Collections.singletonList( attrType ) );
classBuilder.field( name ).type( type ).declareStatement( asStatement( item ) ).build();
}
notifyComplete();
}
void mapTxtFile()
{
1CClassReference reference = resolver.buildClassStructure( file.getName() );
if( reference == null )
throw new IllegalStateException( "Unable to resolve class: " + file );
classBuilder = target
.editClass( reference )
.modifier( dummyDeclareStatement );
transformationClasses = new ArrayList<>();
new PlainClassTransformer().doTransform();
notifyComplete();
}
private void resolveThisClass()
{
1CClassReference reference = resolver.buildClassStructure( file.getName() );
if( reference == null )
throw new IllegalStateException( "Unable to resolve class: " + file.getName() );
classBuilder = target.editClass( reference );
Element properties = XmlUtils.getSingleElementOrNull( root, TAG_PROPERTIES );
if( !root.getTagName().equals( "predefinedData" ) )
classBuilder.declareStatement( asStatement( root ) )
.customData( ATTR_UUID, root.getAttribute( ATTR_UUID ) );
String tagName = root.getTagName();
if( FORMS.contains( tagName.toLowerCase() ) && isManagedForm() )
{
classBuilder.parent( TYPE_MANAGED_FORM )
.modifier( Modifiers.ENFORCE_PARENT_CLASS );
}
else if( properties != null && tagName.equalsIgnoreCase( "Constant" ) )
registerConstantValueField( properties );
else if( properties != null && tagName.equalsIgnoreCase( "SessionParameter" ) )
registerSessionParameter( properties );
}
private void notifyComplete()
{
classBuilder.build();
if( transformationClasses != null )
transformationClasses.forEach( ClassBuilder:: build );
}
private void registerDocumentSpecials( Node properties )
{
ClassBuilder newRegisterRecordsCollection = createRecordsCollection();
createSpecialFields( newRegisterRecordsCollection );
Element registerRecords = XmlUtils.getSingleElementOrNull( properties, "RegisterRecords" );
if( registerRecords != null )
for( Element element : XmlUtils.getChildren( registerRecords, "xr:item" ) )
registerDocumentSpecialMember( newRegisterRecordsCollection, element );
newRegisterRecordsCollection.build();
}
private void registerDocumentSpecialMember( ClassBuilder newRegisterRecordsCollection, Node element )
{
String typeName = element.getTextContent();
1CClassReference reference = resolver.buildClassStructure( typeName );
1CClass aClass = reference == null ? null : target.getClassOrNull( reference );
if( aClass == null )
log.warn( "Failed to resolve: " + typeName );
else
{
String name = aClass.getName();
String memberTypeName =
OneCv8Types.NAMESPACE + '.'
+ aClass.getParentClass().classReference().getName() + "НаборЗаписей." + name;
1CType memberType = OneCv8Types.parse( memberTypeName );
newRegisterRecordsCollection
.field( name )
.type( memberType )
.declareStatement( asStatement( element ) )
.buildField();
}
}
private void createSpecialFields( ClassBuilder newRegisterRecordsCollection )
{
1CType type = newRegisterRecordsCollection.getReference().to1CType();
for( ClassBuilder aClass : transformationClasses )
if( REF_DOCUMENT_OBJECT.equals( aClass.getSuperClass() ) )
aClass
.field( "Движения" )
.type( type )
.declareStatement( aClass.getDeclareStatement() )
.build();
}
@NotNull
private ClassBuilder createRecordsCollection()
{
1CClassReference newRegisterRecordsCollectionReference =
OneCv8Language.reference( REF_RECORDS_COLLECTION.getFullName() + '.' + classBuilder.getReference().getName() );
if( target.getClassOrNull( newRegisterRecordsCollectionReference ) == null )
return target.newClass( newRegisterRecordsCollectionReference )
.superClass( REF_RECORDS_COLLECTION )
.parent( REF_RECORDS_COLLECTION.to1CType() );
return target.editClass( newRegisterRecordsCollectionReference );
}
private void registerSessionParameter( Node properties )
{
ClassBuilder paramClassBuilder = target.editClass( REF_SESSION_PARAMETERS );
String name = Utils.getObjectName( properties );
1CType type = getFieldType( properties, TAG_TYPE );
paramClassBuilder
.field( name ).type( type ).declareStatement( asStatement( root ) ).build()
.build();
}
private void registerConstantValueField( Node properties )
{
1CType fieldType = getFieldType( properties, TAG_TYPE );
classBuilder.field( "Значение" )
.type( fieldType )
.declareStatement( asStatement( root ) )
.build();
}
private boolean isManagedForm()
{
Element properties = XmlUtils.getSingleElementOrNull( root, TAG_PROPERTIES );
String formType = properties == null ? null : XmlUtils.getTextContentOrNull( properties, "FormType" );
return "managed".equalsIgnoreCase( formType );
}
private void readFormAttrs( FormAttributeReader attributeReader, String tagName, String childTagName )
{
Element attributes = XmlUtils.getSingleElementOrNull( root, tagName );
if( attributes != null )
for( Element element : XmlUtils.getChildren( attributes, childTagName ) )
attributeReader.read( element );
}
private void readChildren( Node childObjects, @Nullable Node standardAttributes, ClassBuilder primaryClass, List<ClassBuilder> secondaryClasses )
{
AbstractChildReader classFieldReader = new ClassFieldReader( primaryClass, secondaryClasses );
AbstractChildReader tabularSectionReader = new TabularSectionReader( primaryClass, secondaryClasses );
AbstractChildReader commandReader = new CommandReader( primaryClass, secondaryClasses );
Collection<Element> children = XmlUtils.getChildren( childObjects );
for( Element child : children )
{
String tagName = child.getTagName();
if( ALLOWED_CLASS_FIELDS.contains( tagName.toLowerCase() ) )
classFieldReader.read( child );
else if( TAG_TABULAR_SECTION.equalsIgnoreCase( tagName ) )
tabularSectionReader.read( child );
else if( TAG_COMMAND.equalsIgnoreCase( tagName ) )
commandReader.read( child );
else if( !SKIPPED_CLASS_FIELDS.contains( tagName.toLowerCase() ) )
log.error( "Skipping child object of unknown type - " + tagName );
}
if( standardAttributes != null )
{
Collection<Element> attributes = XmlUtils.getChildren( standardAttributes );
StandardAttributeReader reader = new StandardAttributeReader( primaryClass, secondaryClasses );
attributes.forEach( reader:: readAttribute );
}
}
private 1CType getFieldType( Node properties, String typeTagName )
private IStatement asStatement( Node node )
private final class FormElementsReader
{
private final Element elements;
private final ClassBuilder elementsSubClass;
private final 1CClassReference parentClassReference;
private final Deque<1CClassReference> eventTypeSource = new LinkedList<>();
void read()
void read( Node elementsNode )
}
private final class FormCommandsReader
{
private final List<Element> commands;
private final ClassBuilder formCommands;
void read()
}
private final class FormAttributeReader extends AbstractChildReader
{
@Override
void read( Element element )
}
private final class SubTableAttributeReader extends AbstractChildReader
{
private final String className;
private final 1CType parentClass;
private final 1CClassReference pathToColumns;
@Override
void read( Element element )
}
private final class StandardAttributeReader
{
private static final String CUSTOM_DATA_KEY_ALIAS = "alias";
private final ClassBuilder primaryClass;
private final List<ClassBuilder> secondaryClasses;
void readAttribute( Element attribute )
}
private static final class AttributeTemplate
{
private String name;
private 1CType type;
private final Collection<Modifier> modifiers = new HashSet<>();
void addModifier( Modifier modifier )
void setType( 1CType type )
public void setName( String name )
String getName()
1CType getType()
Collection<Modifier> getModifiers()
}
private abstract class AbstractChildReader
{
private final ClassBuilder primaryClass;
private final Collection<ClassBuilder> secondaryClasses;
ClassBuilder getPrimaryClass()
Collection<ClassBuilder> getSecondaryClasses()
1CType getXmlFieldType( Node properties, boolean useClassType, String typeTagName )
abstract void read( Element element );
void forEachClass( Consumer<ClassBuilder> callback )
}
private final class ClassFieldReader extends AbstractChildReader
{
@Override
void read( Element element )
}
private final class TabularSectionReader extends AbstractChildReader
{
@Override
void read( Element element )
}
private final class CommandReader extends AbstractChildReader
{
@Override
void read( Element element )
}
private final class ParentMembersReplacer
{
private final ClassBuilder currentClass;
private final Collection<1CClassReference> typesToReplace;
private final 1CClass parent;
private boolean typeReplaced;
void copyMembersFromParent()
}
private class PlainClassTransformer
{
private ClassBuilder current;
void doTransform()
void doPrimaryClassTransformations()
void produceType( String name, @Nullable String uuid, Modifier declareStatementModifier )
void registerField( 1CClassReference classReference )
void registerSubClass( String subClassParentName )
}
private final class ClassTransformer extends PlainClassTransformer
{
private final Element innerInfo;
private final Element internalInfo;
@Override
void doTransform()
}
}
Внутренности вложенных классов вырезал специально.
Работает это быстрее, чем прошлая реализация примерно в 2-3 раза (из-за других оптимизаций получилось намного выше). Просто потому что стэк не нагружается избыточной и ненужной работой, не говоря о том, что методы стали не по 100-150 строк в среднем, а по 50 максимум.
И загрузка десятка тысяч файлов xml не за 5 минут осуществляется, а за <30 секунд.
А вы говорите, что вложенные классы никогда нельзя применять.
С вашим подходом и синглтон — это убогий костыль, за который надо сажать и отбирать диплом.
Может все дело в том, что применять надо уметь инструмент? Знать где оно применимо?
PS а с inner-классами вообще беда-беда… они отвратительно влияют на читабельность родительского класса и допустимы в основном тогда, когда являются банальным представлением данных без средств обработки этих данных. Ну т.е. конструктор и геттеры… ну и опционально — сеттеры.
Почитайте что такое method-object.
У вас 10 параметров у функции, 9 из них всегда константы, а функцию вы вызываете много раз в цикле.
Вынести в вложенный класс и у вас будет большой конструктор и вызов метода с одним параметром. Это экономит стек.
Уже в том месте, где изначальный метр превратился в 6,5617 фута.
Из-за вот таких вот приколов самолеты падали, потому что заправляли-заправляли, а топлива на половину пути. То что вам кажется некомпетентным может на деле оказаться необходимостью конкретного случая.
Мы не говорили по поводу написания ТЗ. Так же как и на том уроке по дифурам — вам уже дали ТЗ, оно уже существует. Обсуждать его нечего.
Вы пытаетесь дать себе больше степеней свободы, что бы не напрягаться и сделать побыстрее, в то время как иногда ваше "побыстрее" может стоить млрд баксов при внедрении, и все из-за того, что вы сочли, что заказчик некомпетентен. Угадайте, будут ли вас нанимать?
Я вижу вы спорщик знатный, поэтому откланяюсь. То, что до вас пытался донести я и еще один человек до меня — вы понять отказываетесь. Все время на "заказчиков-идиотов" указываете, только вот мир немного иначе устроен. Не ч/б.
Желаю вам успехов.
Когда тебя каждые пять минут гоняют от одной задачи к другой — не поднимите. Вот вообще никак. Кроме истерзанных нервов ничего не будет. Да еще и при увольнении выскажут много чего интересного.
Однако в защиту товарища хотелось бы упомянуть, что обычно у нас капиталисты говорят о каких-то рисках и прочее, однако вот оборотной стороной (прибылью) никогда не делятся с работниками.
Не про безответственное отношение сотрудника, а про любителей каждую проблему выдавать за срочную и исключительно по вине сотрудника (неоплачиваемую).
Но опять же, лично мое мнение, что возможность вызвать сотрудника в случае ЧП в любое время — это реально важно. Факторы бывают разные. Невозможно все предусмотреть на всех уровнях.
Вы уже сами описали, что смешали работу нескольких специальностей.
Я же описывал именно "возможность" напрягать мозги в одном направлении в течении долгого времени. По опыту — максимум возможностей — 8 часов, и то после тренировок. И кстати результаты совпадают с общественной практикой, люди вообще больше 8 часов в день не могут продуктивно работать над чем-то в течении всего года. Замечу, речь именно о среднесуточной нагрузке в течении года, а не "две недели 60 часов отработал, а потом неделю отдыхал".
Когда есть возможность смешивать работу — ревью, очистка, отладка и т.д. — это облегчение работы.
Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Но в целом — да. У нас так хаят "неквалифицированную рабочую силу", что забывают насколько "заказчики" бывают недалеки и неквалифицированны вообще во всех сферах кроме "заплатить меньше, получить больше".
Это решаемо, но в целом — да. Возможность хотя бы экстренно выйти на связь в случае ЧП — очень важна.
Либо же просто не работать в таких областях, где такое может произойти.
Зависит от тренировки. Если начинал с самого детства, то лет за 10 можно и 6-8 часов в день выдерживать. Зависит еще сильно от общего физического состояния.
В 14 лет с трудом выжимал из себя 15-40 минут непрерывной концентрации на коде — поэтому везде ходил с блокнотом и карандашом — писал всякую хрень. К 30 годам 6 часов непрерывной умственной нагрузки — даже усталости нет.
Однако при приближении к 8 часам есть снижение всех когнитивных навыков, т.е. вообще всех, падает реакция, глаза болят и висок ноет (левый). По 7-8 часов в день больше 14 дней подряд не выдерживаю, нужен отдых. Силой никто не гонит, просто "хочется еще".
Если так весь год работать, то нужен отпуск примерно 48 дней.
Субъективно, согласен — но пища для размышлений есть.
Так ведь уже сказали, что декомпозиция осуществлена. Все остальные операции — уже очень легкие и не требуют существенного труда.
Описал выше. Тренировка и общая физическая подготовка. Стоит обратить внимание на ваше питание. Почитайте про то, как маленькие улучшения коммулятивно дают прирост в разы.
Такой же подход, отвлекаюсь на приготовление обеда и т.д. Отвлечение на другую деятельность лучше всего позволяет мозгу отдохнуть.
"Многие" даже траншеи не копали. На прошлой работе начальник вполне легко мог отвлечь посреди задачи, или вовсе что-то обсуждать.
Это не проблема кодинга, а проблема воспитания людей и коммуникации между ними. Вы же не сможете в деталях объяснить быт и труд шахтера? Каждый человек живет в своем мире, просто у кого-то он размером с горошину — представления о других людях соответственные.
И мешали этим кодить.
Такая же фигня, людей "навешивали" на успевающих, при этом научить их было чему-то нереально из-за "пнх".
А ничего, что последствием кислородной катастрофы стало как раз оледенение, цианобактерии? И речь не про четвертичное, а гуронское оледенение.
Было время, когда маленькие одноклеточные "засрали" всю планету кислородом, от чего началось глобальное похолодание и массовое вымирание этих одноклеточных. Вся планета была покрыта ледяным щитом.
Так частная собственность же "священна". Ты чего хочешь отобрать у бедных капиталистов прибыль?
Решится все по старинке на самом деле. В начале 20 века уже проходили это все.
Подход при котором для начала люди хотя бы привели вычисления того, что данный подход действительно дает больше производства кВт энергии на каждый затрачиваемый кВт энергии.
Подход, при котором с небес для начала на землю спускаются и оценивают то, что есть на самом деле, а не то, во что хотелось бы верить. Земля усеянная ветряками и солнечными панелями — это утопия. Этот источник ЭЭ сугубо нишевый и никогда не сможет быть, как вы уже сказали, конкурентноспособным по отношению даже к грязным ТЭЦ, от которых необходимо избавляться, так как углеводороды лучше тратить на бытовую химию — те же пластики. Причем это еще вопрос, кто загрязняет среду больше ТЭЦ или производство панелей и ветряков, которые менять надо чуть и не каждые 2 года, тогда как ТЭЦ нуждается только в смене фильтра. Все эти шумихи сейчас существуют только потому, что на это тратятся огромные деньги в виде дотаций и прочих субсидий.
Количество людей можно легко вычислить на основе оценки количестве энергии (общей) поступающей в систему под названием "Земля". Так как основным источником является Солнце, а остальное скорее всего не составляет и 1%, то ими можно для упрощения пренебречь.
Получив оценку входящей энергии — нужно определить, сколько требуется каждому человеку для того, что бы жить. Таким образом и вычисляется максимально допустимая "наивная" оценка. Почему наивная? Потому что человечество не всю энергию само поглощает. Но она хороша тем, что это даст число, при котором последствия от перенаселения станут необратимыми и войнами и геноцидами уже ничего не исправишь, дает терминальную оценку, которую вполне можно разделить на 10, для гарантии безопасности человечества и использовать как предел численности населения. Вас такой ответ устроит? Заранее прошу прощения, что не привожу конкретную цифру, так как не обладаю точными исходными данными относительно того, какой поток энергии от солнца падает на землю. Особенно если учесть, что он является функцией от множества параметров.
удалено
Надо понимать, что солнечные панели и ветряки вместе с эрозией песчаных побережий для песка и загрязнением окружающей среды, вследствие добычи редкоземельных элементов, появятся сами, причем разумеется без того, что идет "вместе".
Все больше и больше статьи напоминают утопии для успокоения людей, не знающих ничего об инженерном деле. Надеюсь, что ухудшение инженерной культуры в современном обществе — всего лишь корреляция.
Так все же вопрос, откуда солнечные панели? И откуда возьмутся сотни тысяч квадратных километров площадей с солнечными панелями для каждого такого экополиса? Кто будет их обслуживать? Если автоматика, то кто будет обслуживать армию этих автоматов?
Если же сотни тысяч людей в городе не нужны… то вопрос, почему в этих городах будет жить пара тысяч человек? Куда остальные денутся? "Не впишутся в рынок"?
Продолжение идей "золотого миллиарда"? Да даже для него потребуется такой парк ветряков (которые не всегда работают), и настолько огромные площади, занятые солнечными панелями, что даже современная экономика их не сможет поддерживать.
И прошу, оставьте ваши шутки про "сахару в панелях", один песчаный шторм и все ваши панели можно либо в мусор отправлять, либо чистить придется. Кто этим займется?
И вопрос, куда девать отработанные солнечные панели? Перерабатывать? Энергии не хватит. На изготовление-то уходит море ЭЭ, а вы еще переработку желаете.
И еще одну, что бы собирать весь создаваемый мусор.
Егор с таким подходом сможет объекты со стека в долгоживущие записать. Уверен, что сможет. Так что да прибудет с ним FullGC.
Проблема в том, что для получения газа надо тратить энергию, и кпд будет не 10-15% как у угля, а 0,1-1%. Вам оно надо? По экологии ударит куда как сильнее и результаты потомки еще будут расхлебывать.
Все это из разряда "экологически-чистых" автомобилей Тесла, кпд у которых не лучше, чем в ДВС, только в отличие от ДВС, который конкретно сейчас выделит Х углекислого газа — электромобиль сожрет энергии все на тот же Х (которая идет от тех самых теплых углесжигательных станций) + некоторая доля Х, требуемая для транспортировки, да еще при хранении утечки ЭЭ происходят во всех аккумуляторах. Я уже не говорю, что утилизировать использованный аккумулятор куда как сложнее, чем выхлопные газы, которые в худшем случае содержат небольшие примеси тяжелых металлов, от которых можно спастись обязав всех ставить фильтр на выхлопную трубу.
Попробуйте посчитать, что значит производить биотопливо в промышленных масштабах, а главное — откуда столько отходов взять? Вам потребуются тонны биоотходов (кто их сортировать будет?), что бы получить несколько кВт ЭЭ.
На 1/3 энергии от солнца и ветра нужно превратить огромные территории в зоны отчуждения похлеще Чернобыля, там вообще ничего не должно быть, совсем. К тому же на производство солнечных панелей нужно много ЭЭ, откуда ее брать? От солнечных панелей? У них КПД очень низок, а применять эти панели есть смысл только в солнечных широтах (тропики и экватор) и выдавать одна панель размером в 1 м2 будет пару Вт/ч.
Гидро-станции — вы представляете сколько нужно затопить территорий, что бы было 17% по всему миру?
ТЭЦ и АЭС занимают такой большой сегмент рынка ЭЭ в мире не из-за того, что какому-то политику что-то захотелось, а потому что это в разы дешевле, меньше вредит экологии планеты в целом (а не только в вашей любимой Хермании) и главное, что это все предсказуемо, планируемо. С солнечными панелями и ветряками у вас не только цена подскочит, но и упадет выработка энергии в среднем == убийство промышленности.
И не надо выдавать "экологически-чистые" технологии, спасающие экологию вашей страны за счет чьей-то другой, которая производит сырье для ваших "экологически-чистых" технологий.
Да вы хотя бы поинтересовались бы, что такое песочная мафия (Sand mafia), и какие законы принимают, что бы песок с пляжей не собирали.
Тссс, парень, первое правило либералов — никогда не говорить про жертвы
репрессийхалатности либеральной политики.Java — тоже растущий и развивающийся язык. Из-за более раннего старта, нежели шарп — имеет больше легаси кода и больший технический долг. У шарпа такое будет рано или поздно. Поэтому замедление в последние годы для меня не является чем-то из ряда вон выходящим.
То что полезные фичи вносятся в джаву не говорит о том, что шарп хорош.
К шарпу у меня только одна претензия, которая на корню пилит ее использование — отсутствие кросс-платформенности (mono — это не c#, а опенсорсная разработка никакого отношения к мелкософту не имеющая).
Проблемы обратной совместимости шарпа (первая выдача гугла):
https://docs.microsoft.com/ru-ru/dotnet/framework/migration-guide/version-compatibility
Для джавы подобного не замечал, хотя переводил большой проект с 6 на 7, а затем и на 8.
На лохивар не затянете, сударь.
Их и там достаточно. Не говоря о том, что совместимость между версиями почти полностью отсутствует.
Каждый инструмент обладает своими достоинствами и недостатками. Как инженер вы должны их видеть и применять тогда, когда эффект будет максимален.
А кивать на костыли только ради перфекционизма… интересный выбор, но Ынтырпрайз держится на решении задач, а не написании кода.
Как пример: https://github.com/lastrix/asn1s/blob/master/asn1s-core/src/main/java/org/asn1s/core/type/x680/collection/SequenceType.java
Валидатору требуется для проверки NamedValue 4 обязательных константных аргумента и доступ к данным, класса SequenceType.
Предлагаете, что лучше устанавливать внешний валидатор, когда процедура проверки одна и не меняется? И в принципе не может изменится?
С method-object получается более компактный код.
Есть другой вариант парсер конфигураций 1С. В зависимости от типа объекта в xml, необходимо выполнять свою логику, причем она отличается сильно, но общего очень много.
у базового класса тонна информации, вроде около 10 полей (как констант, так и изменяемых), все необходимы при анализе. Часть создается в процессе анализа.
Раньше весь код представлял из себя кашу разных методов с 5-6 аргументами как минимум, сейчас 3 аргумента максимум и весь код разбит на функциональные блоки — вот конфигурируется документ, вот загружается контент из xml, тут определяются типы.
Про быстродействие даже говорить не хочется, оно просто в разы выше.
Хотя важнее именно повышение читаемости кода.
Или лучше иметь один класс (который в принципе нельзя разбить на независимые друг от друга классы без создания нереального количества мусорного кода), и 100+ методов в нем?
Если не страшно, вот пример из реального, работающего проекта, в исходном виде 1500 строк:
Внутренности вложенных классов вырезал специально.
Работает это быстрее, чем прошлая реализация примерно в 2-3 раза (из-за других оптимизаций получилось намного выше). Просто потому что стэк не нагружается избыточной и ненужной работой, не говоря о том, что методы стали не по 100-150 строк в среднем, а по 50 максимум.
И загрузка десятка тысяч файлов xml не за 5 минут осуществляется, а за <30 секунд.
А вы говорите, что вложенные классы никогда нельзя применять.
С вашим подходом и синглтон — это убогий костыль, за который надо сажать и отбирать диплом.
Может все дело в том, что применять надо уметь инструмент? Знать где оно применимо?
Почитайте что такое method-object.
У вас 10 параметров у функции, 9 из них всегда константы, а функцию вы вызываете много раз в цикле.
Вынести в вложенный класс и у вас будет большой конструктор и вызов метода с одним параметром. Это экономит стек.
Уже в том месте, где изначальный метр превратился в 6,5617 фута.
Из-за вот таких вот приколов самолеты падали, потому что заправляли-заправляли, а топлива на половину пути. То что вам кажется некомпетентным может на деле оказаться необходимостью конкретного случая.
Мы не говорили по поводу написания ТЗ. Так же как и на том уроке по дифурам — вам уже дали ТЗ, оно уже существует. Обсуждать его нечего.
Вы пытаетесь дать себе больше степеней свободы, что бы не напрягаться и сделать побыстрее, в то время как иногда ваше "побыстрее" может стоить млрд баксов при внедрении, и все из-за того, что вы сочли, что заказчик некомпетентен. Угадайте, будут ли вас нанимать?
Я вижу вы спорщик знатный, поэтому откланяюсь. То, что до вас пытался донести я и еще один человек до меня — вы понять отказываетесь. Все время на "заказчиков-идиотов" указываете, только вот мир немного иначе устроен. Не ч/б.
Желаю вам успехов.