Tatsächlich sind die „guten“ und „schlechten“ Werte, über die wir oft sprechen, eine Beschreibung der Codequalität. „Gut“ bedeutet im Allgemeinen Code von hoher Qualität, und „schlecht“ bedeutet im Allgemeinen Code von geringer Qualität. Was die Beschreibung der Codequalität betrifft, hören wir neben relativ einfachen und groben Beschreibungen wie „gut“ und „schlecht“ oft auch viele andere Beschreibungen. Diese Beschreibungsmethoden sind semantisch umfangreicher, professioneller und detaillierter. Ich habe es gesammelt, sortiert und unten aufgelistet. Im Allgemeinen gibt es mehrere Standards, nämlich Lesbarkeit, Wartbarkeit, Skalierbarkeit, Wiederverwendbarkeit, Flexibilität, Testbarkeit usw.
Lesbarkeit
Software-Design-Guru Martin Fowler sagte einmal: „ Jeder Dummkopf kann Code schreiben, den ein Computer verstehen kann. „Gute Programmierer können Code schreiben, den Menschen verstehen können.“ Ins Chinesische übersetzt: „Jeder Dummkopf kann Code schreiben, den ein Computer verstehen kann.“ „Gute Programmierer können Code schreiben, den Menschen verstehen können.“ Es gibt sogar eine Zertifizierung innerhalb von Google namens Readability. Nur Ingenieure, die diese Zertifizierung erhalten haben, sind berechtigt, anderen die Übermittlung von Code während der Codeüberprüfung zu genehmigen. Es ist ersichtlich, wie wichtig die Lesbarkeit des Codes ist, denn die Häufigkeit, mit der der Code gelesen wird, übersteigt die Häufigkeit, mit der er geschrieben und ausgeführt wird, bei weitem.
Ich persönlich glaube, dass die Lesbarkeit des Codes einer der wichtigsten Indikatoren für die Bewertung der Codequalität sein sollte. Wenn wir Code schreiben, müssen wir immer berücksichtigen, ob der Code leicht zu lesen und zu verstehen ist. Darüber hinaus hat die Lesbarkeit des Codes großen Einfluss auf die Wartbarkeit des Codes. Denn egal, ob wir Fehler beheben oder funktionalen Code ändern und hinzufügen, das erste, was wir tun müssen, ist, den Code zu verstehen. Wenn Sie den Code nicht gut verstehen, ist es sehr wahrscheinlich, dass aufgrund unzureichender Berücksichtigung neue Fehler auftreten.
Da die Lesbarkeit so wichtig ist, wie sollten wir die Lesbarkeit eines Codeabschnitts bewerten? Wir müssen prüfen, ob der Code den Codierungsstandards entspricht, ob die Benennung aussagekräftig ist, ob die Kommentare detailliert sind, ob die Funktionslänge angemessen ist, ob die Modulaufteilung klar ist, ob er eine hohe Kohäsion und eine niedrige Kopplung erfüllt usw. Sie sollten auch positiv spüren, dass es für uns schwierig ist, eine Liste zu erstellen, die alle Bewertungsindikatoren abdeckt. Aus diesem Grund können wir die Lesbarkeit auch nicht quantifizieren.
Eigentlich ist die Codeüberprüfung eine gute Möglichkeit, die Lesbarkeit von Code zu testen. Wenn Ihre Kollegen den von Ihnen geschriebenen Code leicht lesen können, bedeutet dies, dass die Lesbarkeit Ihres Codes sehr gut ist. Wenn Kollegen beim Lesen Ihres Codes viele Fragen haben, bedeutet dies, dass die Lesbarkeit Ihres Codes verbessert werden muss
Wartbarkeit Wartbarkeit
Bezieht sich im Allgemeinen auf die Fähigkeit, Fehler schnell zu ändern oder Code hinzuzufügen, ohne das ursprüngliche Codedesign zu zerstören, ohne neue Fehler zu verursachen, was auf die Wartbarkeit des Codes hinweist. Wenn es um die Codierungsentwicklung geht, ist die sogenannte „Wartung“ nichts anderes als das Beheben von Fehlern, das Ändern von altem Code und das Hinzufügen von neuem Code. Der sogenannte „Code ist leicht zu warten“ bedeutet, dass der Code schnell geändert oder hinzugefügt werden kann, ohne das ursprüngliche Codedesign zu zerstören oder neue Fehler einzuführen. Der sogenannte „Code ist nicht einfach zu warten“ bedeutet, dass das Ändern oder Hinzufügen von Code ein großes Risiko für die Einführung neuer Fehler birgt und lange dauert.
Erweiterbarkeit
Die Fähigkeit des Codes, sich angesichts neuer Anforderungen in der Zukunft zu ändern. Im Allgemeinen kann bei der Entwicklung neuer Anforderungen der ursprüngliche Code entwickelt werden, ohne den ursprünglichen Code zu ändern Bei sehr wenigen Modifikationen bleiben in der Regel einige Funktionserweiterungspunkte vorbehalten.
Wiederverwendbarkeit
Versuchen Sie, das Rad nicht neu zu erfinden, das heißt, Sie können eine gemeinsame Codelogik auslösen und die Entkopplung vom Geschäftscode der oberen Ebene beibehalten ; Dieses Wort ist relativ weit gefasst. Normalerweise ähnlich wie Wartbarkeit, Skalierbarkeit und Wiederverwendbarkeit
Testbarkeit
Dies spiegelt sich in zwei Aspekten wider:
Diese Dimensionen sind einige der wichtigeren Indikatoren für die Beurteilung der Codedimensionen.
Hohe Kohäsion und geringe Kopplung sind etwas, worüber fast jeder Programmierer spricht, aber dieser Begriff ist zu weit gefasst und zu korrekt, daher haben kluge Programmierer mehrere objektorientierte Designprinzipien vorgeschlagen, um die Qualität zu messen des Codes:
Open-Close-Prinzip (OCP) (Open-Close-Prinzip) LKP ( Least-Knowledge-Prinzip)) / Demeter-Gesetz
Liskov-Substitutionsprinzip LSP (Liskov-Substitutionsprinzip)
Schnittstellensegregationsprinzip ISP (Schnittstellensegregationsprinzip)
Kombinations-/Aggregationswiederverwendungsprinzip CARP (Composite/Aggregate Reuse). Prinzip)
Jeder muss mit diesen Theorien vertraut sein, wenn wir Code schreiben, der nach diesen Prinzipien entwickelt wurde, mit anderen Worten, wir können sie verwenden Prinzipien zur Messung der Qualität unseres Codes.
Ich glaube, dass jeder Ingenieur qualitativ hochwertigen Code schreiben möchte und nicht ständig schlechten Code schreiben möchte, der nicht wächst und von anderen kritisiert wird. Wie können wir also qualitativ hochwertigen Code schreiben? Was qualitativ hochwertigen Code betrifft, haben wir gerade über die sieben am häufigsten verwendeten und wichtigsten Bewertungsindikatoren gesprochen. Daher ist die Frage, wie man qualitativ hochwertigen Code schreibt, gleichbedeutend mit der Frage, wie man Code schreibt, der leicht zu warten, leicht zu lesen, leicht zu erweitern, flexibel, prägnant, wiederverwendbar und testbar ist. Aber das Schreiben von gutem Code erfordert auch dies nicht Dies geschieht über Nacht und erfordert viel Übung und Anhäufung. Hier ein kurzes Beispiel:
Abstraktes Denken ist die wichtigste Denkfähigkeit unserer Ingenieure, da Softwaretechnologie im Wesentlichen eine abstrakte Kunst ist. Unsere Ingenieure müssen jeden Tag abstraktes Denken anwenden, um den Problembereich zu analysieren, zusammenzufassen, zu synthetisieren, zu beurteilen und zu begründen, wodurch verschiedene Konzepte abstrahiert, die Beziehung zwischen Konzepten untersucht und dann Geschäftsfunktionen durch Programmiersprachen realisiert werden Es geht nicht darum, Code zu schreiben, sondern Anforderungen zu klären, Konzepte zu klären und ein Gesamtverständnis der Anforderungen zu erlangen. Die Fähigkeit zur Abstraktion lässt mich und mein Team die qualitativen Veränderungen spüren, die sie für uns in Codierung und Design mit sich bringt.
Tatsächlich ist die Excel-Exportfunktion überall in unseren Projekten zu sehen, insbesondere unsere Betriebe hoffen, so viele Daten wie möglich auf einmal zu exportieren, um uns nicht zu sehr unter Druck zu setzen System, für Big Data Der Export von Mengen erfolgt im Allgemeinen asynchron Für eine so einfache Funktion, wie sollte sie abstrahiert werden?
public String exportXXX(参数) throws Exception { //业务实现 } public String exportXXX2(参数) throws Exception { //业务实现 }
Abstraktes Schreiben:
// export excel public interface IExcelExportTask { String export(BizCommonExportTask exportTask) throws Exception; } //样例实现类 XXXXExportTask implements IExcelExportTask { String export(BizCommonExportTask exportTask) throws Exception{ public String export(BizCommonExportTask exportTask) throws Exception { //组织数据筛选条件 TestReq queryReq = GsonUtils.toObject(exportTask.getInputParams(),TestReq.class); String fileName = String.format("%s%s%s", exportTask.getUploadFileName(),System.currentTimeMillis(),".xlsx"); String downUrl = excelService.uploadExcel(fileName, null, new Fetcher<PreOccupyModel>(PreOccupyModel.class) { //循环获取数据 @Override public List<TestModel> fetch(int pageNo, int pageSize) throws OspException{ TestQueryResp resp = testFethchLogic.fetchRecord(queryReq); return pageNo > resp.getPageNum() ? Collections.emptyList() :toExcelModel(resp); } }); return downUrl; } } public class XXXXExportTask1 implements IExcelExportTask { @Override public String export(BizCommonExportTask exportTask) throws OspException { TestQuery query = GsonUtils.toObject(exportTask.getInputParams(), TestQuery .class); String fileName = String.format("%s%s%s", exportTask.getUploadFileName(), System.currentTimeMillis(), ".xlsx"); return excelService.uploadExcel(fileName, null, new Fetcher<ExportItemModel>(TestModel.class) { @Override public List<TestModel> fetch(int pageNo, int pageSize) throws OspException { return XXXXLogic.queryExportItem(query, pageNo, pageSize); } }); } } //导出任务分发器 public class ExcelTaskDispacther extends ApplicationObjectSupport { public boolean dispacthTask(Long taskId) throws OspException { updateTaskStatus(exportTask,CommonExportStatus.CREATING,TransferExportStatus.CREATING,StringUtils.EMPTY); try { String beanName = getBeanName(); ExportTaskHandler exportTaskHandler = getApplicationContext().getBean(beanName , IExcelExportTask .class); if(exportTaskHandler == null) { log.warn(String.format("任务ID[%s]写入配置错误!", taskId)); return false; } updateTaskStatus(exportTask,CommonExportStatus.CREATE_SUCCESS,TransferExportStatus.CREATE_SUCCESS,StringUtils.EMPTY); log.info(String.format("任务ID[%s]RFID为[%s]处理成功", exportTask.getId(),rfid)); return true; } catch(BusiException ex) { log.info("任务ID[{}]失败,原因:{}", exportTask.getId(),ex.getMessage(),ex); updateTaskResult(); } catch(Exception ex) { log.info("任务ID[{}]失败,原因:{}", exportTask.getId(),ex.getMessage(),ex); updateTaskResult(); } return false; } }
Fall 2: Systembenachrichtigung
Um den Systemdurchsatz zu verbessern, werden die Systemverantwortlichkeiten in der heutigen Zeit immer detaillierter. Jedes Systemmodul muss häufig interagieren Bei komplexen Dateninteraktionsszenarien wie unserem Transferauftrag muss der Transferauftrag während des Stornierungsprozesses mit vielen Systemen interagieren und es gibt viele Interaktionen mit Filialen, Lagern und Bestandsmodulen. Was sollten wir tun? ?Wie kann man es abstrahieren? Das Folgende ist ein Codebeispiel für die Zuordnung von Interaktionen mit anderen Systemen. Wenn wir mit anderen Systemen interagieren, können wir tatsächlich jedes Mal, wenn wir interagieren, ein Ereignis schreiben Benachrichtigungsereignisse reichen aus.
2 Prinzip der Kombinations-/Aggregationswiederverwendung
In Bezug auf das Prinzip der Kombinations-/Aggregationswiederverwendung stoßen wir tatsächlich häufig während des Projektprozesses darauf, dass wir verschiedene Dokumente verwalten, z B. Bestellungen, Überweisungsaufträge usw., und für jede Art von Dokument gibt es verschiedene Überprüfungen. Schauen wir uns zunächst einen Code für den Bau- und Überweisungsauftrag an:
//接口定义 public interface BizNotificationHandler { /** * 抛异常会当失败处理 * 是否需要重试由BizNotificationStatus返回状态来决定 * @param bizNotification * @return * @throws OspException */ BizNotificationStatus handleNotification(BizNotification bizNotification) throws OspException; } //推送调拨差异数据给库存系统 public class SyncDiffToSimsAndBackQuotaHandler implements BizNotificationHandler { @Override public BizNotificationStatus handleNotification(BizNotification bizNotification) throws OspException { //业务逻辑实现 return BizNotificationStatus.PROCESS_SUCCESS; } } //占用库存 public class TransferOccupyInventoryHandler implements BizNotificationHandler { @Override public BizNotificationStatus handleNotification(BizNotification bizNotification) throws OspException { //业务实现 } } //在GPDC生成新条码 public class GpdcGenerateNewBarcodeHandler implements BizNotificationHandler { @Override public BizNotificationStatus handleNotification(BizNotification bizNotification) throws OspException { //业务代码实现 } }
Das obige ist der detaillierte Inhalt vonBeispielcode-Analyse für die Java-Projektentwicklung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!