Durch V. Berba Velasco Jr. Ph.D.
Über den Jahren beachtete I.ve eine Menge, wie Firmen Computerprogrammierer
einziehen. Während dieser Zeit
beachtete I.ve, wie Manager häufig anstellenentscheidungen treffen, die
scheinen, sinnvoll kurzfristig zu sein, aber die langfristiges Chaos ergeben
Sie. I.ve gesehen die Art der
Verwüstung die dieses Dose wreak und wie, es zu verwüsten zur company.s Zukunft
sein kann.
Kennzeichnung mögen einige Wörter über die heute sagen.
Die Firmen, denen I.ve gewöhnlich Bezahlung Aufmerksamkeit
Angelegenheiten wie Industriehintergründe, Jahre der Erfahrung, und so weiter
beobachtete. Sie möchten welche
Arten von Projekten die Bewerber an bearbeitet haben, die Kompilatoren und
Vertrautes der Betriebssysteme they.re mit, die kennen Kommunikationsprotokolle
und Softwarepakete they.ve verwendete, und so weiter. Viele
möchten auch in der employee.s Arbeit Ethik und der Beschaffenheit auskennen,
aber im Ende, kochen die anstellenentscheidungen häufig unten zur employee.s
Arbeit Erfahrung und wieviel Training, das Person benötigen würde.
Alle die sind wichtige, vernünftige Betrachtungen. Da
ich diese Firmen zwar beobachtete, beachtete ich daß die meisten von them.about
80% oder von more.paid wenig oder keine Aufmerksamkeit, ob der Bewerber eine
saubere, lesbare programmierenart hatte.
Sie wurden tief ungefähr betroffen, ob der Bewerber die Arbeit erhalten könnte erledigt, und didn.t scheinen, sich
viel ungefähr zu interessieren, ob ihre Software durch andere leicht verstanden
werden und geändert werden könnte, Jahre niederwerfen die Straße.
Gewissermaßen ist dieses verständlich.
Schließlich ist das sofortige Ziel
der meisten Firmen, Arbeitsprodukte zu entwickeln, die sie verkaufen können. Was
viele jedoch vergessen ist, daß sie marathoners sein sollen, nicht sprinters. Sie
müssen in der Fertigung des gesamten Rennens und kleiner ausgedrückt in dem
Erzielen der kurzfristigen Siege ausgedrückt mehr denken.
Es verrät auch ein bestimmtes naivete über die sofortige
Beschädigung, die aus schlechter programmierenart resultieren kann. Schließlich
sogar ist die beste Software selten bug-free. Ein
Programmierer, der saubere schreibt, lesbare Software ist, seine eigene Arbeit
zuverlässig auszuprüfen als jemand, das Patchworkcode schreibt. Das
letzte kann Verlegenheiten that.s diskutierbar schneller (und sogar zur
Verfügung stellen strittig!), aber die Resultate sind unreliable.and, wenn Zeit
kurz ist, that.s ein Luxus, den Firmen nicht sich leisten können.
Arbeitgeber sollten auch sich erinnern, daß das, das Art, gut
ist zu programmieren, nicht etwas leicht unterrichtetes that.s ist. Jeder
kompetente Programmierer kann die Mechaniker der Sprachensyntax- und
Funktionsanrufe erlernen; jedoch ist jemand, das wenig über die Kunstfertigkeit
der strukturierten Programmierung oder der korrekten Gegenstandlagebestimmung
versteht, unwahrscheinlich, diese Sachen auf dem Job zu erarbeiten. I.ve,
die diesem gesehen werden, geschehen (oder eher, Ausfallen zum zu geschehen)
oft.
Dieses, trotz des Überflußes an den Büchern und Journale, die diese Sache an der großen Länge beraten über.
Ich denke auch, daß Firmen grössere Aufmerksamkeit auf die
zukünftigen employee.s technischen Schreiben Fähigkeiten lenken sollten;
schließlich können externe Unterlagen (z.B. Benutzerhandbücher,
Designunterlagen) zur software.s Haltbarkeit kritisch sein. Außerdem
in meiner Erfahrung, sind Programmierer, die gut auf englisch schreiben,
wahrscheinlicher, Software auch zu schreiben. Und
warum nicht? Programmiersprachen
sind schließlich gerechte that.languages. Jemand,
das auf englisch gut sich ausdrücken kann, ist wahrscheinlicher, in seinem
Quellenprogramm offenbar und effektiv in Verbindung zu stehen außerdem.
Aus diesen Gründen dränge ich auf jede mögliche Firma that.s
einen Programmierer anstellend, um incisive Fragen über eine applicant.s
Kodierungart zu stellen. Wie nennt
er seine Variablen? Wieviele
Linien des Codes sollte eine Funktion besetzen? Verwendet
er globale Variablen und wenn so, wenn? Welche
Arten der Bücher hat er auf programmierenart gelesen? Ideal
sollten Firmen um Proben eines applicant.s Quellenprogramms und der technischen
Unterlagen auch bitten, zu überprüfen daß diese Lektionen in Praxis gesetzt
sind. Dieses nimmt eine wenig
Extrabemühung, aber es kann einer Firma helfen langfristigen, Erfolg um der
zweifelhaften kurzfristigen Gewinne willen zu opfern zu vermeiden.
Über den Autor:
V. Berba Velasco jr., Ph.D. ist eine ältere elektrische und
Software Engineer an zellularer Technologie Ltd. (http://www.immunospot.com,
http://www.elispot-analyzers.de,
http://www.elispot.cn, http://www.elispot.co.jp) wo
er mit großem Stolz dient. Er hat gesehen, wie korrekte Aufmerksamkeit zur
Software-Brauchbarkeit, -haltbarkeit und -eleganz den Unterschied zwischen
mittelmäßigen Produkten und den großen buchstabieren kann.
